Object
Purpose
An Object represents a distinct entity.
Objects are the primary building blocks of the Canonical Data Model. They represent anything that may exist, be identified, be referenced, or participate in relationships or actions.
The Canonical Data Model defines the structure of an Object but does not define the available Object types.
---
Structure
An Object consists of:
type- Identifies the kind of Object.content- Contains the data associated with that Object.
The interpretation of content is determined by type.
---
Characteristics
- Objects are typed.
- Objects are independent.
- Objects may contain any valid data.
- Objects are immutable.
---
Canonical presentation fields
In a World Dataset, every Object and Collection carries one top-level title and one
top-level summary, and every Action one top-level target. World resolves these into a
single field each (from the historical spread of content.name / content.description /
top-level name / description, and target / content.{target,object,collection,resource})
before the Dataset reaches a Runtime. A Runtime reads exactly that one field per entity; it
does not walk a fallback chain across content and top-level, and it does not substitute an
invented placeholder when the field is empty.
Presentation and navigation
How an Object is presented once it is placed on Carry — its title bar (back, collapse, close),
its content area, and navigation within it (following links in place, the back control,
navigation history belonging to the Object) — is defined by layout.md. That behavior is
required; its visual treatment is determined by each Runtime.
---
Objects from interpreted source formats
When a Service interprets a source format such as HTML into canonical data (see html.md), an
element becomes an Object only when the thing it represents has independent identity or utility
within Elonn. The source tag alone does not determine Object identity: div and span are
never promoted; headings and paragraphs contribute structured content but are not independently
promoted; a video or iframe may be promoted when it has distinct identity. A semantic region
(header, navigation, main content, sidebar, secondary sidebar, footer) is an addressable part of
the document, never independently promoted (html.md, Semantic regions). A document with
no promotable descendant is itself the Object.
HTML interpretation produces a document Object (its content.content is the ordered
structured-content tree) and, for media with independent identity, a video or audio Object.
These are Object types a Service produces; the Canonical Data Model does not enumerate Object
types (see html.md, Produced structures).
---
Recognized type: service.dashboard
A service.dashboard Object represents one approved Service's operable interface, built
generically by Conductor from that Service's Publication and cached Contract — never
hand-authored per Service.
content carries the Service's own declared identity (service_id, service_name,
service_purpose) and its Publication capabilities list. actions.local contains one action
per declared entrypoint (falling back to model_selectable: true operations), each a bare
operation_invocation (service + operation, no arguments) — the existing generic
argument-enrichment and form-rendering pipeline fills and renders it identically to any other
action, with no Dashboard-specific runtime code.
A service.dashboard Object is placed on Carry (a carry Placement — see placement.md). Its
entry points are actionable: focusing one may open an Object on Carry, or open another Dashboard
on Carry. Once content is opened within an Object, navigation within that Object follows the
Object navigation rules in layout.md and does not create additional Objects on Carry.
Example of an instance:
{
"id": "service.dashboard:messages.elonn",
"type": "service.dashboard",
"title": "Messages",
"summary": "Owns open one-to-one member message threads outside Social context.",
"content": {
"service_id": "messages.elonn",
"service_name": "Messages",
"service_purpose": "Owns open one-to-one member message threads outside Social context.",
"capabilities": [
{"id": "message_thread_retrieval", "description": "Retrieve and search the member's own one-to-one message threads."}
]
},
"actions": {
"local": [
{
"id": "messages.list",
"type": "invoke_operation",
"label": "Show recent messages",
"operation_invocation": {"service": "messages.elonn", "operation": "messages.list"}
}
]
}
}
Meaning:
This is Messages' Service Dashboard. Selecting "Show recent messages" fires messages.list with
whatever source: model arguments its Contract declares, filled in the same generic form flow
identity.profile.update already uses.
---
Recognized type: conductor.clarification_request
A conductor.clarification_request Object represents Conductor asking the member a genuine
question about a Call it could not yet resolve — not a list of guesses, a single question with
no action to submit. It is synthesized generically by Conductor itself, produced only when no
candidate Service could be resolved with real confidence and nothing else offered would help.
Ordinary ambiguous retrieval (a bare search that could plausibly mean more than one thing) is
not reserved for this Object — Conductor resolves that by attempting every plausible Service
and composing the results, not by asking; this Object is reserved for the request nothing
plausible could satisfy at all, or a consequential action whose target or reading is genuinely
unresolved.
content carries only question (the clarifying question text, also resolved onto the Object's
top-level summary per Canonical presentation fields). It carries no action and no preset
payload. The member answers it the same way they continue any other Thread (thread.md): an
ordinary next input, carrying the same context.thread_id forward. World forwards that answer
back to Conductor as an ordinary new Call carrying this same Thread's context.thread_history
— which includes this very question as a prior Turn — so Conductor reads the member's new input
together with that history as one combined, evolving intent. There is no separate resume
protocol, no opaque original_call round-tripped to the client, and conductor.elonn is not a
registered Service at all: Conductor has no operation a client ever explicitly invokes to
"answer" a clarification.
A conductor.clarification_request Object carries no actions and is never a destination a
member navigates into.
Example of an instance:
{
"id": "conductor.clarification_request:a1b2c3",
"type": "conductor.clarification_request",
"title": "One more thing",
"summary": "Looking for pizza nearby, a recipe, or something else?",
"content": {
"question": "Looking for pizza nearby, a recipe, or something else?"
},
"actions": {
"local": [],
"inbound": [],
"outbound": []
}
}
Meaning:
Conductor could not confidently resolve what was meant and is asking the member to say more.
The member's next ordinary input in the same Thread — not a submitted action — is read together
with this Turn's own history as the member's full, combined intent, and resolution runs again
the same way any other Call is resolved.
---
Recognized content format: drawing_surface
An Object whose content.format is drawing_surface presents an editable 2D surface a member
draws freehand marks onto — a Paint document, or any other Service's sketch, annotation, or
whiteboard Object. content.format is independent of type: type remains Service-defined (for
example paint.document), while drawing_surface is the shared, Service-neutral instruction
that tells a Runtime how to present the content — the same relationship a model-sourced
argument's constraints.format: markdown has to type: string (see the Service Contract
Authoring Guide). A Runtime recognizes drawing_surface from this field alone; it does not infer
drawing behavior from the Object's type, its owning Service, or any Service-specific field name.
There is no surface, hosted, or per-Service "editor kind" concept in the canonical model.
A drawing_surface Object's content additionally carries:
- width, height — the surface's dimensions.
- source_resource — the id of a Resource of type drawing.marks (see
drawing-operation.md) holding the surface's current marks as an ordered list of Drawing
Operations. This is the surface's editable state; a Runtime does not render from it directly
(see graphics_resource, below).
- graphics_resource — the id of a Resource of type graphics.svg (see svg-profile.md)
holding the current rendered projection of source_resource, conforming to the SVG Profile.
A Runtime renders this Resource's markup when presenting the surface's current marks; it does
not read source_resource's Drawing Operations to decide how a mark looks (svg-profile.md,
Ownership).
- preview_resource — the id of a Resource holding a static preview image of the surface, when
one exists.
A member adds a mark through the Object's own declared Actions, exactly as with any other edit:
one of the Object's local Actions declares an operation whose Contract carries an argument of
type: drawing_operation. A Runtime renders that argument as live freehand input over the
surface's current marks (see the Service Contract Authoring Guide) — sourced from
graphics_resource, the same as any other presentation of this surface — and submits it through
the same generic Action dispatch every other operation uses. A Runtime does not need to know the
operation's name or the owning Service to do this — it recognizes the declared argument type,
not a name on the Action or the Object.
Example:
{
"id": "paint.document:...",
"type": "paint.document",
"title": "Untitled",
"content": {
"format": "drawing_surface",
"width": 1024,
"height": 768,
"source_resource": "resource:...",
"graphics_resource": "resource:...",
"preview_resource": "resource:..."
}
}
Meaning:
This Object is an editable drawing surface. A Runtime renders graphics_resource for the marks
drawn so far, shows preview_resource where a static thumbnail is wanted instead, and lets the
member draw more through whichever of this Object's Actions carries a drawing_operation
argument — built the same way for a Paint document today as for any future Service's drawing
Object. The owning Service reads and writes source_resource directly; a Runtime has no need to.