Elonn Developer

MD

Thread

canonical/thread.md

Thread

Purpose

A Thread is a related, ordered set of Turns, with its own identity, an owner, and a lifecycle
state. It is the general structure behind any ongoing, multi-step interaction — a member's
search refined over several messages, a Message or Social DM container, a titled Conversation
— though this document defines only the generic structure; each owning Component defines what
its own Turns contain.

A Thread is independent of every other Thread, including another Thread owned by the same
member, and independent of any particular Runtime or runtime session — the same Thread can
continue from a different device without transferring any Runtime- or Service-internal state.

A Turn is one step within a Thread: the member's input for that step, and the resolved result
for it. Turns are ordered and append-only within their Thread.

Used By

Structure

A Thread consists of:

- id — Identifies the Thread.
- owner_id — The member who owns this Thread.
- status — active or cleared.
- turns — The ordered, append-only list of this Thread's Turns, each:
- ordinal — This Turn's position within the Thread.
- input — The member's own input for this Turn.
- result — A reference to this Turn's resolved result (e.g. dataset_id).
- created — When this Turn was recorded.
- created / updated — When this Thread was started and last added to.

The canonical structure is defined in thread.json.

Semantics

A Thread's Turns are read in build order: each Turn is understood in light of the Turns before
it, so they are presented oldest-first, in the order they happened — the same way one open
Message thread's own messages are read (see message.md). This is the opposite of a *list of
independent Threads* (or a list of independent Findings), which is presented latest-first,
since independent items don't depend on one another and the most recent is usually the most
relevant.

A Call that belongs to a Thread carries context.thread_id; omitting it starts a new Thread.
The owning Component resolves the current input together with a bounded window of the
Thread's recent Turns (context.thread_history) rather than treating the input as a fresh,
disconnected request — a follow-up like "slices nearby" is resolved using what the Thread
already knows, with no separate request/resume protocol.

Clearing a Thread sets its status to cleared. This ends that Thread only — it never
affects any other Thread, and never deletes or undoes anything already committed outside the
Thread (e.g. an Object kept open on Carry, a Field placement).

Scope

A Thread is the general ordered-Turns structure. It does not define:

- what a Turn's input or result contain for any particular owning Component — that is
defined by whichever Component owns that kind of Thread (World, for search Turns; Messages,
for its own message Threads; Social, for Conversations and Social DMs);
- how many Threads a member may have open at once, or how a Runtime decides which Thread is
currently showing — a Runtime shows whichever Thread its current view's restore already
resolves to (see layout.md), not a Thread-picking mechanism of its own;
- presentation beyond ordering — a Thread's Turns may be rendered using the sequence
Collection type (collection.md) once materialized into a Dataset.

Invariants

- Every Thread has a unique identifier and exactly one owner.
- A Thread's Turns are ordered and append-only; an existing Turn is never edited or reordered.
- Writing to, reading, or clearing one Thread never reads or writes any other Thread's data,
including another Thread owned by the same member.
- Clearing a Thread changes only that Thread's own status; it never deletes or reverts
anything already committed outside the Thread.

Related Models