Layout

Elonn has exactly two layers: Carry and Field.

There are no other layers.

Entry, Results pane, Findings, Dashboards, cards, panels, windows, form fields, controls, title bars, content areas, and other Objects or runtime presentation structures are not layers.

"Workspace" is not a layer and has no architectural meaning in the Elonn platform.

Carry

Carry is the non-geographic layer.

Carry contains Objects that are available to the member without being geographically anchored to surrounding reality.

Objects opened from Findings, Dashboards, and other interactions are opened on Carry unless they are explicitly placed on Field.

An Object does not become a different type of Object because it is on Carry. "Carry object" is a descriptive term for an Object on Carry, not a canonical Object type.

A runtime determines how Objects on Carry are presented.

"Carry panel", "carry window", "carry card", and similar terms may describe runtime presentation. They are not World or Service data primitives.

Field

Field is the geographically restrained layer.

Field contains Objects whose placement is anchored to surrounding reality.

Places and Objects placed at locations in surrounding reality are represented on Field.

An Object does not become a different type of Object because it is on Field. Its Placement determines that it is on Field.

Field and Carry are the only layers in Elonn.

Entry

Entry is Elonn's single member-facing point of entry.

Entry accepts member input and submits that input to the platform as a Call.

Entry is presented on Carry.

No other permanent interface elements are presented alongside Entry. Diagnostic information may temporarily be displayed by development runtimes and is not part of the canonical layout.

Entry consists of a form field and its available controls.

The available controls are:

• microphone indicator, when voice input is available;
• submit, when required by the runtime;
• clear;
• show/hide.

The microphone indicator toggles voice input.

The submit control submits the current Entry content. A runtime may omit a visible submit control when it provides another appropriate means of submission.

The clear control clears the Results pane. It does not clear Entry and has no effect on Carry, Field, or Objects placed on either layer.

The show/hide control shows or hides the Results pane. It does not hide Entry.

When all controls are present, the Entry layout is:

form field - microphone indicator - submit - clear - show/hide

Controls that are unavailable or unnecessary in a runtime are omitted without changing the order of the remaining controls.

There is no title bar above Entry.

The form field occupies the leftmost portion of Entry. Controls are presented to its right.

The shapes, dimensions, and runtime-specific presentation of the form field and controls are determined by each runtime.

Entry is the canonical concept. Its representation as a bar, panel, or other visual structure is runtime presentation and is not canonical.

Results pane

The Results pane presents Findings returned in response to Calls submitted through Entry.

The Results pane exists only while it contains Findings.

When no Findings have been returned, there is no Results pane.

When the clear control removes all Findings, the Results pane ceases to be displayed.

The Results pane is cumulative. New Findings are added above existing Findings, with the newest Findings at the top.

Existing Findings remain until the Results pane is cleared.

The show/hide control collapses or reveals the Results pane without removing its Findings. When the Results pane is collapsed, only Entry remains visible.

Only Findings are displayed in the Results pane.

A runtime displays each Finding as a card or another runtime-appropriate representation. "Card" describes runtime presentation and is not a canonical Object type.

Focusing a Finding opens the Object referenced by that Finding on Carry.

The Results pane is not a layer. It is an interface structure associated with Entry and presented on Carry.

Finding

A result returned for presentation in the Results pane is called a Finding.

A Finding references the Object to which the result pertains.

Findings are contained by the Results pane. They are not Placements on Carry or Field.

A Finding does not duplicate the Object it references.

Findings are carried explicitly in a World Dataset's findings list, newest first (see
finding.md). World adds a Finding for each of a fresh Entry search's own new top-level
results; the list otherwise carries forward unchanged. Results-pane membership and Carry/Field
placement are independent lifecycles — placing, navigating, or closing an Object never removes
its Finding, and being listed as a Finding never implies the Object is unplaced. Only the clear
control (world.clear) removes a Finding. A Runtime populates the Results pane from
findings; it does not decide what is a Finding by treating every unplaced entity as one, and
it does not infer that opening or closing something changes the Results pane.

Focusing a Finding opens its referenced Object on Carry. This is a World operation: the
Runtime submits the focus to World, and World places the referenced Object on Carry (adding
its carry Placement and navigation entry) and returns the new snapshot. When the Finding
carries an open Action, the Runtime invokes that Action; otherwise it submits world.focus
naming the Finding's Object. A Runtime never places a Finding's Object on Carry itself. The
Finding itself is untouched by this — the Object remains listed in the Results pane, and World
keeps its data and actions intact for as long as it does, even if the panel is later closed.

Once an Object has been opened, subsequent navigation within that Object remains within the Object as defined by Object navigation.

How a runtime visually represents a Finding is determined by that runtime. A Finding may therefore be referred to as a "card" or "results card" when discussing a particular runtime presentation, but those terms are not canonical.

Focus and alt focus

Focus and alt focus are the two canonical interactions for acting on selectable content — a Finding, a link, or an addressable part of an Object's own content (see html.md, Semantic regions, for the HTML case).

Focus targets the current Object: it directs the interaction's result into whatever Object is already the member's current container, or — when there is no current Object to redirect, as with a Finding — it establishes a new current Object. Focus never opens an additional Object alongside one that already exists for the same interaction.

Alt focus targets a new Object instead: it opens the interaction's result in an Object of its own, on Carry, without altering the content or navigation state of any Object already open.

focus -> current Object
alt focus -> new Object

Focusing a Finding (above) and focusing a link within an Object (Object navigation, below) are both applications of focus; alt-focusing either opens a new Object instead.

Physical input — click, tap, gaze, gesture, long-press, right-click, or another supported mechanism — is Runtime-specific. A Runtime maps its available inputs to focus and alt focus; it does not encode a device gesture into canonical data, and a Runtime may change its input mapping without changing what focus or alt focus mean. Canonical semantics are not Runtime-specific.

Object presentation

An Object presented on Carry has a title bar and a content area.

The title bar identifies the Object and provides controls for interacting with its presentation.

The title bar includes:

• back;
• collapse;
• close.

The back control is available when the Object has a previous navigation state.

The collapse control collapses the Object's content area. When collapsed, only the title bar remains visible on Carry.

Expanding the Object restores its content area.

The close control closes the Object and removes it from Carry.

Collapsing an Object does not close it, remove it from Carry, or alter its content or navigation state.

Closing an Object removes its presentation from Carry.

The title bar, controls, content area, and their visual treatment are runtime presentation. Their required behavior is defined here, but their appearance is determined by the runtime.

Object navigation

An Object opened from a Finding is the container for subsequent interaction with that Object's content.

Objects may contain conversations, events, web results, messages, documents, Service content, and other kinds of content.

Content within an Object may contain links and other navigable references.

A link is a canonical reference — a Resource, or a Relationship to one — that carries the
platform operation for following it (see resource.md, relationship.md). A Runtime follows
a link by submitting that operation. It never opens a URL string itself, and never fabricates
an Object from one.

Focusing a link within an Object opens the referenced content within the current Object. Alt-focusing the same link opens it in a new Object instead, leaving the current Object unchanged (Focus and alt focus, above).

Focusing a link within an Object does not open another Object on Carry.

Navigation within an Object changes the content presented within that Object while preserving the Object as the member's current container.

A new Object is opened only when an interaction explicitly alt-focuses, or otherwise explicitly opens, an Object. Navigation within an existing Object does not continuously create additional Objects on Carry.

Navigation history belongs to the Object.

The back control returns the Object to its previous content or navigation state.

Using back does not open another Object, close the current Object, or alter its Placement on Carry.

Focusing links and using back change the content or navigation state of the current Object without creating additional Objects.

Displaying content the Object already holds — such as switching among a document's own regions, or returning to one via back — is still a World operation, but never a Service call: World changes its own state (which region is focused, pushed onto the same history a document swap pushes onto) without invoking Conductor. Opening content that does not yet exist in the Dataset — such as following a link to a document not yet interpreted — calls a Service. Both are focus, and both go through World; the difference is only whether a Service is involved, not whether World is.

Breadcrumbs are not part of the current Object navigation model.

Dashboard

A Dashboard is an Object that exposes the entry points defined by a Service contract.

Dashboards are normally opened on Carry.

A runtime presents Dashboard entry points in a manner appropriate to that runtime.

Dashboard entry points are actionable.

Focusing or activating a Dashboard entry point may open an Object on Carry.

A Dashboard entry point may also open another Dashboard on Carry.

Once content has been opened within an Object, ordinary navigation within that Object follows the Object navigation rules and does not create additional Objects.

Dashboard is an Object type.

"Dashboard panel", "dashboard window", and similar terms describe possible runtime presentations. They are not layers or canonical Placement types.

Window

"Window" is a noncanonical presentation term.

It may be used informally to describe a flat or rectangular runtime representation of an Object or other interface structure.

A Window is not a layer.

A Window is not equivalent to Carry or Field.

Window does not identify a canonical Object type, Placement type, or architectural structure in Elonn.

Code must not depend on "window" as an architectural concept. Existing uses of the term in code should be evaluated individually and replaced where they incorrectly assign architectural meaning to it.

"Workspace" is not a replacement for "window".

Workspace is noncanonical and has no architectural meaning in the Elonn platform.

Layer invariant

Elonn has exactly two layers:

• Carry
• Field

This is a closed set. No third layer exists.

No Object, interface structure, presentation structure, runtime construct, or informal term creates an additional layer.

An Object may be placed on Carry or Field according to its Placement.

Interface structures such as Entry and Results pane may be presented on Carry but do not themselves define layers.

Terms including window, workspace, panel, card, Dashboard, Results pane, Finding, Entry, title bar, and content area must never be interpreted as layers.