Parked
Until Resolved

Chord v2 was built slice by slice, and each slice answered "the provider is not there" for the case in front of it. Slice 1 made self.get of a type nobody serves throw, because a typo in a type name should fail loudly. Slice 3b made remote holds survive link drops, so a missing provider on another host became a refused hold that the consumer retries. Slice 8 made self.registry a dependency that waits for a value. Each answer was reasonable alone. Together they give five outcomes for one situation.

The differences are not about the situation. Whether the notes plugin is missing on this host or on the worker, the notes view cannot work until someone installs it. Yet in one case the view is broken until a reload, in the other it polls the worker every minute for the rest of the session, and the reload that finally brings the plugin back cannot revive a reference that got gone.

The deadlock without a cycle

The startup barrier has a worse problem. Sol reproduced it against the current code (/tmp/dep-graph-sol-barrier.log).

C has no dependencies and is registered the moment S's setups ran. Its hold waits anyway, because incoming holds wait for pendingLoad, and pendingLoad is the whole of load: the setups and the barrier that waits for every host-lifetime object, A included. Two jobs share one promise. Holds only need the first ("are the types registered?"); the second ("has every plugin had its first try?") is for the app. Mixing them makes an acyclic chain across two hosts wait until a timeout fires.

Timers standing in for events

Both problems have the same root. Where Chord does not know when something will change, it polls or waits for a deadline: the identity backoff retries a dependent whose remote provider refused it; the activation deadline breaks the startup knot; the same deadline is the only answer to two objects on two hosts that start at the same moment and need each other, a cycle the activation chains cannot see (design §6, "Known limitation").

A timer is the right tool when nothing else can tell Chord that the world changed: a disk that may be back, a worker process that may start this time, a silent transport. It is the wrong tool when an event exists or can exist. A missing plugin comes back through a reload, which is an event on the host that serves it. A dependency going live is an event. A link opening is an event. The model below uses those events and keeps timers only where no event can exist.

The first change is a separation the code makes only halfway today: between what a reference asks for and what currently answers it. When the notes view on W does self.get(NoteStore, {}), it asks for "the NoteStore of this host, as the host, at contract version 3". Which object answers is a second question, and the answer can change: no object yet, an object activating, a live one, a failed one, none again after a reload, a new one after the next.

A request and its holder

A request is the asking part: type (or registry), params, principal and the consumer's contract version. Every request has exactly one holder, which made it and is the only one that ends it.

That list is the whole of how a request ends. A request never ends because its provider is missing, went away or does not fit. Today it does in two places: a self.get of a type nobody serves throws before the request exists, and a reload that removes a type sends gone. Both go.

The address decides where

A request goes to one place, and the address decides which. For a local type, the place is this host. For a remote type, the consumer computes the address from the params with its own contract's hostAddress function (design §3; placement until 2026-10-29): Notes { session: "S1" } is placed on Session { id: "S1" }. If that is this host's address, the request goes here; otherwise over the route for that kind, or over the parent link.

Until 2026-10-29 the code checked something else first: whether the type is registered here. A type placed on this host but not registered yet was sent over the parent link, which is wrong twice. Sol's example: the server has address Server, the catalog type is placed on Server, and no facet serves it yet. That code, Placement.reference (host/placement.ts, now host/destination.ts), sent the server's own request over a parent link the server never had, and when the catalog plugin was installed later, nothing woke that request, because it was never registered as waiting here. The rename removed the first half; slice 7 builds the wait.

The rule, from the reviews (Sol B1, Astra F1): the destination never depends on what is registered when the type names an address. A request placed here whose provider is missing is unbound here, waiting for the name. A version check compares the consumer with the provider actually selected, never with a same-name registration on the consumer's own host (today #assertRoute does that before choosing the destination, so worker W1 serving Notes v1 rejects a Notes v2 request placed on W2, which serves v2).

Every remote type declares its hostAddress (owner, 2026-10-29, who also renamed placement to it). Until then remote() allowed leaving it out, a leftover of slice 3a, which built remote objects over one link before host kinds existed; such a type went "here if served, otherwise the parent", which needed its own fallback and a re-placement when a tab that loads before it connects gets its first parent link (Opus, Sol). Opus and Fable proposed making it required; the owner agreed.

What the check finds

Once placed, the provider found there is checked: served, a fitting version (the current one or an accepted older one, with the fingerprint computed from the provider's own history), authorize, and the provider's own host-address check. The request is then bound (to an object here, or to a hold over a path), or unbound with a reason:

The reasons that wait for a name (unpublished, not_served, version, compose) are kept in an index under that name, on the host that decided them: the consumer's host for a local request, the provider's host for a hold that arrived over a link. The provider already keeps such holds today as refused (remote/hold.ts), and retry re-runs them. installing belongs to the provider host's own install; no_link lives on the path, where the next link holds the request again, as today. Every index drops an entry when its request ends, so a released getter, a closed tab or a revoked guest leaves nothing behind. A refused request (no authority, bad params) is never indexed: a later publication cannot grant authority.

The publication gate

There is one short gate. Before a host has run its facets' setups, it does not know what it serves, so it cannot tell "not served" from "not registered yet". A worker connects to its parent before it loads (W6), so holds can arrive in that window, and p2's web shell holds references before its own load resolved.

So a request made on a host, or arriving on its links, before the host's first publication is not placed at all: it is unbound unpublished and shows loading. The publication places it. Without this gate the request would be placed by a half-empty registration table (Fable's trace: W1's own Notes sent over the parent, relayed back by the server, forever), and a tab would see "not served" during every worker start (Opus's trace).

The gate is not the barrier. It lasts only until the setups ran, and the setups are synchronous code at the start of load: they register types and registries and contribute, and wait for nothing. That is the difference that ends the startup deadlock (chapter VI).

ref.state keeps its four kinds: loading, live, failed, ended. What changes is one new kind of failure cause.

type RefState =
  | { kind: "loading" }
  | { kind: "live" }
  | { kind: "failed"; cause: FailureCause; retryAt: number | undefined }
  | { kind: "ended"; error: ChordError };

type FailureCause =
  | { kind: "transient"; error: ChordError }   // the object's own effect failed (an open, a follow): backoff
  | { kind: "broken"; error: ChordError }      // the object's own code, a cycle, or authority: retry() or a reload
  | { kind: "waiting"; error: ChordError };    // not the object's fault: woken by an event, never by a timer

The mapping

Whether a request that is not live shows loading or failed { waiting } follows from what it waits for:

The intuition is "is something under way?": an activation, a reconnect, an install, a load. When something is under way, the reference waits and calls park; when nothing is, the reference says what is missing and calls fail fast. The reviewers pointed out that "under way" is not something Chord can observe in general (a parent reconnect is the app's, a resolve may hang), so the table is the rule and the intuition only explains it.

A link drop and an unload, side by side

The owner's point was that a link going away is like the provider's plugin unloading. For the request they are the same: it stays, it keeps its last values readable, it binds again when a provider is reachable, and its holder notices nothing but the state. They differ in what is under way.

One difference must stay: calls already sent. When a link drops, a sent call's outcome is unknown, so it fails and is not resent. When a plugin unloads on the same host, its handlers are drained on the old code (design §21). Location decides nothing else.

The owner's instinct was that an object is parked until its dependencies all cleanly resolve. This chapter makes that exact: what a dependency is, what the parked object shows, what it keeps, and where parking ends.

What counts as a dependency

A dependency is a request an attempt makes in its factory and needs live before the object may go live:

• self.get(Type, params), local or remote: one rule for both;
• self.registry(R): a registry at the reader's version (chapter X);
• a keyed pin, ref.notes.at(key) on another object's keyed member: the key must be loaded.

Two things are not dependencies. self.follow(attach) is the attempt's own step: its attach runs Durable's code and may fail like an open, with the object's own transient failure and backoff (a follower that wants to recover the moment a new harness appears declares self.retryOn on the registry it reads the harness through). And a ctx.get in a method is not part of the object's activation at all: it is the call's request.

The dependency check

An attempt runs its factory, hydrates its persisted singletons (they are the object's documents, kept across attempts, as today), makes its requests, and is parked while any dependency is not live (and hydrated). What it shows follows its dependencies:

When every dependency is live, the attempt passes the dependency check and runs its own steps: its natives in declaration order, its follow attaches, the member checks, its derives. Those are bounded by its own readyTimeout deadline, as today. Then it goes live.

The dependency check is the boundary between waiting and working (Astra's F3). Before it, the attempt holds no natives; after it, a dependency that leaves live is treated as after live (R18): the attempt goes on, and its calls through that reference meet the reference's state. So a parked attempt never holds a native, and an attempt that opened a native is never parked. It is not a rule of its own: it is R18's rule for live objects (a dependency that goes away leaves the object live; same-host calls in flight finish, remote ones fail, new calls meet the reference's state), applied from the dependency check on. Without that boundary a contributor unloading while the attempt opens its natives would leave it half open and parked, or force a seal, a drain and a fresh attempt for a dependency the object may not even use at once.

No clock while parked

A parked attempt has no dependency deadline and no backoff. Its readyTimeout deadline is paused while it is parked, as eager migrations already pause it (attempt.ts, deadline.pause()), and resumes with the budget left when the attempt passes the check. Today a dependency that does not go live within 60 seconds fails its dependent transient, which then retries with backoff from 1 to 60 seconds. Both go: the dependent is woken when the dependency changes, and the time a dependency takes is bounded where it runs, by that dependency's own steps.

What a parked attempt keeps

It keeps its documents (the object's), its declarations and its requests (R18's holding today), and its seal token. It keeps no native. It ends with its object: when its last holder releases it, or, for a host-lifetime object, when its plugin is removed or the host closes. A parked object with params that nobody holds any more ends and releases its requests, so a whole parked chain goes when its top is released.

broken is the object's own fault

After the model, broken means exactly three things: the object's own code failed (a throwing factory, a derive that throws at activation, a hydration or migrate that fails, a document fingerprint mismatch, an open that throws broken(...)), the object is on a cycle, or it lost its authority (forbidden, a dependency that ended). Everything an object waits for, including a provider that is itself broken, makes it waiting. The difference matters for recovery: a broken object needs ref.retry() or a reload of its own plugin; a waiting one recovers by itself when what it waits for recovers.

Retry passes on

A Retry button on a waiting object should do something. Opus's trace: the tab's Panel waits for the server's Dash, which waits for Catalog, which is broken by a factory bug that a configuration fix would heal at the next attempt. The user sees "waiting for Dash: waiting for Catalog: …" and presses Retry. Today Panel would re-check, find Dash still failed and do nothing.

So ref.retry() on a failed { waiting } object retries its failed blockers, hop by hop, with the existing retry message over links: it retries the blockers that are broken or transient (the only ones a retry can change), passes through the waiting ones, and leaves the rest alone. Each retry carries an operation id, so a diamond of dependencies retries a shared leaf once. Retry of a broken or transient object starts a new attempt, as today. A retryOn value call still retries a failed object as slice 8 decided; while the object is parked waiting, it does nothing: its dependencies decide.

A reload of the parked object itself

The parked attempt's factory never runs again while it is parked, with one exception: a reload of the object's own plugin replaces the parked attempt with the new factory's attempt, as one handover: the new requests are made and bound first, then the old ones released (Astra: a dependency held only by this object, unchanged by the reload, must not end in between; today's #activate already binds before #releasePrevious). If the new code no longer declares the missing dependency, the object can go live at once.

After live, nothing changes

R18's second half stays: once an object is live, a dependency that leaves live (a link drop, a removal) leaves the object live. Its calls that use the dependency get the dependency's state: they park while it is loading and reject while it is failed. Reactivating every live consumer on every dependency loss would turn one worker disconnect into closed natives, withdrawn contributions and aborted jobs on the server; the reviewers agreed it should not.

A model without timers lives or dies by its wakes: a wake that is lost leaves an object parked forever. So the wakes are kept to two kinds of event, each with one owner, and every unbound request and every parked attempt is subscribed to exactly the events that can change it.

Every change, not only "live"

Draft 1 woke a parked attempt only when a dependency went live. Astra, Fable and Sol found the same hole: a dependency that moves from loading to failed, or from one cause to another, leaves its dependent showing a stale state, and a dependent that should now show failed { waiting } keeps parking calls. So a parked attempt re-evaluates on every state change of any of its dependencies and updates what it shows. It leaves parking only when all of them are live. Its factory never re-runs on a wake.

Three details keep this correct and cheap:

• Coalesced, after the batch. Wakes run after the batch that caused them (a publication, a commit, an inbound bound), once per object, so a commit that changes three dependencies wakes their dependent once, and no factory runs inside another owner's batch.
• Remembered. A change that arrives while the attempt runs its own steps or tears down is remembered and applied after (today's R18 wake memory, generalized).
• Indexed by name. A publication touches only the unbound requests waiting for the names it serves. A reload of notes never looks at requests waiting for search.

Across a link: no new message

The wake across hosts needs no new message kind. Today a provider keeps a hold it could not serve as refused, and a retry from the consumer re-runs its start. The model adds one thing: the provider re-runs its refused holds itself, at its own publication, for the names that publication serves.

Two existing messages change: failed carries the new cause kind waiting, and loading and a waiting failed carry the provider's attempt id for the cycle probe (chapter VIII). The pinned list of causes and its test change with them, and PROTOCOL_VERSION stays 1 until p3 ships.

Registries

A registry reader is woken at every transition of the registry's value at its version to usable: when the registry is served, when it composes for the first time, when an older reader's mapping succeeds again after it failed. Today RegistryValueSource wakes only at the very first good value (#valued), which a registry whose provider is removed and added again would never pass a second time.

load does three things today: it runs every facet's setup, it publishes them (types served, registries composed once, contributions in their tables), and it waits until every host-lifetime object has had its first outcome. The promise of the whole thing, pendingLoad, is also what incoming holds and host.hold wait for. That is the startup deadlock of chapter I.

Publication first

The model splits load at the publication:

1. Setups. Every facet's setup runs. Setups only declare: host.serve, self.contribute, host.references. They are synchronous and wait for nothing.
2. Publication. All declarations become visible at once, in one batch: types served, registries served and composed once, contributions in their tables. Nothing activates inside that batch.
3. Wakes. After the batch, every request that waited for the publication (unbound unpublished) is placed, and every unbound request for a name the publication serves is re-evaluated.
4. First outcomes. The host-lifetime objects activate. Whether load waits for them is the barrier question below.

Requests wait for step 2 only. Since the setups wait for nothing, a host always reaches step 2, and a request from another host can never wait for this host's activations. Chapter I's knot comes apart:

The barrier: (a) or (b)

What is left of the barrier is the app's question "has every plugin had its first try?". R17 needs it: p3's base code resumes the harness after load, so the first turn sees the tools of every plugin that loaded. Two shapes are on the table.

(a) Chord keeps it. load resolves when every host-lifetime object of this load has a first outcome: it is live, failed by its own cause, or parked with no blocker that is a local object still without its first outcome. In code, per object:

const firstOutcome = (o: Obj): boolean =>
  o.live || o.ownFailure || (o.parked && o.blockers.every((b) => !b.local || firstOutcome(b)));

So CodeMode → Harness, both local, waits until the harness had its outcome: code mode is parked on a local object that is still in its first attempt, so code mode is not done. A wait on another host, or on a dependency that failed, ends the first pass: the barrier never waits for another host, a retry, a later contribution or a reload. The signal is separate from the readiness dependents wait for (Sol: resolving that for a parked object would let its dependents open natives too early), and it is counted once per object, never reopened by retries. An object of the cohort that ends before its first outcome (its plugin removed, the host closing) settles its entry as ended, and host.close settles a load that is still waiting (Astra).

(b) The app keeps it. load resolves after the publication. Chord adds host.startup, a watchable of the host-lifetime objects and their first outcomes with causes; base code decides when to resume (Fable). The tracker is the same; only who awaits it changes.

Three of the four reviewers recommend (a): the activation graph is Chord's, and every app that wants R17's behaviour would otherwise build the same cohort tracker. Fable recommends (b): the policy belongs to the app, and p2 already has three different ones. Owner decision 1.

What the barrier does not promise

Neither shape can promise that every tool is there for the first turn, and the model does not pretend it can. Sol reproduced it against today's code (/tmp/barrier-sol-first-outcome.log): object A's open fails on its first attempt (A's first outcome); B goes live and contributes; the registry changes and retryOn wakes A for a second, slow open; load resolves with only B's contribution in the table. Tools found in onLive (MCP) arrive later by design. What a first turn really needs (a model, an environment, a reconciled working directory) is p3's explicit admission check, as p2's whenRegistered and its harness prerequisites are today.

Slice 7 brings reload and rollout, and with them the cases where a provider disappears on purpose. Today's design handles them with their own mechanisms: gone when a type is removed, a final contract_mismatch when a version is dropped, updating with a deadline during a rollout. Under the model all of them are one thing: a request becomes unbound with a reason, and the event that fixes the reason wakes it.

A type removed, and served again

A reload that removes a type ends its objects as today: natives close with reason end, callers of running calls are rejected at once, handlers drain. What changes is what happens to the requests that pointed at those objects.

• Over a link, the provider sends failed { waiting, not_served } on the bound hold. A failed on a bound hold unbinds it (Fable: one message, one rule; the consumer applies it as today's #startOver plus failed). The provider detaches the hold's sources and drops its unsent pending ops and any queued bound. Two things it must not do (Sol): free the ack slots of bound and state messages already sent, which stay counted until their ack or the link's loss, or resend calls, which fail and free their slots once.
• On the same host, a Binding whose target ended by removal becomes unbound and accepts a second bind. Its member sources re-bind by name (one frame from the last value, as on a restart today), keyed pins re-pin, parked calls flush or reject, presence lists it again. This is the one genuinely new piece of machinery in the model (Fable, Sol): today bind runs once per binding, and the ended object is forgotten.

When a later commit serves the name again, the publication wakes every request indexed under it, on every host that holds one, and they bind as if nothing had happened.

A version no longer accepted

A reload can also keep the type and stop accepting an old version (it drops accepts[1]). Draft 1 ended the provider object then; Sol and Astra caught it: the object, its documents, its jobs and its holders on the current version are fine. Only the requests on version 1 become unbound version. The object's own plugin reload still restarts it if it has natives (§21), as for any reload.

A type that moved

A plugin can move a type from the worker to the server by changing its hostAddress. A consumer's request carries the address its own code computed, so the provider appearing on the server cannot wake it: the request is not waiting there. The old host answers not_served; the consumer's own reload, which brings the new hostAddress, makes a new request. The model adds no redirect: moving state between hosts is a deliberate migration, not something Chord guesses.

Rollouts across hosts

A rollout installs a revision on the server first, then on the workers, then on the tabs (design §21). Between those installs, hosts run different code. The model needs only one rule for that: each host knows its own install, and nothing more.

• A provider host that is installing keeps holds that do not fit its current code as unbound installing: the consumer sees loading, its calls park. When the install ends, by its commit or by its rejection, the host re-evaluates them against the code it now runs (Astra, Sol: a rejected install must not leave them asleep).
• A provider host that is queued but not installing yet answers a mismatch with failed { waiting, version } until its install commits and wakes the request. That is a visible blip of at most one install; Opus judged it acceptable, and avoiding it would need revision fields in every answer.
• Installs never wait for activations. An install that waited for its objects to go live would deadlock a rollout that runs in the other order: the worker's objects wait for the server's new types, the server's install waits for the worker.
• A host whose own install was rejected fails its own requests at once with the reason (design §21).

Old calls

Calls that were running when the reload came follow §21 unchanged: a pure swap lets them finish on their old handles; a native restart drains them first; a removal rejects their callers at once and drains their handlers. Chord never resends a call.

A provider that never appears keeps its dependents parked, and that is visible: they say what they wait for. A cycle is different: A waits for B, B for A, every provider exists, and still neither can go live first. Today Chord has two detectors and a deadline. On one host, self.get follows the waiting edges of activating objects. Across hosts, a hold carries the activation chain it was made in, and a provider refuses a hold whose chain contains the object being activated. The gap is documented (design §6): when A on the server and B on a worker start at the same moment, the holds carry [A] and [B], neither finds the other, and both fail at the 60-second deadline. The model removes the deadline, so the gap must close.

Two answers

The owner decided this gap once already. On 2026-10-24, after the slice 4b reviews, he made simultaneous starts across hosts "a documented limitation: they time out transient and retry; no probe message." That decision assumed the activation deadline. The model removes the deadline for dependency waits, so the decision needs one of two continuations, and this one is his (Owner decision 6):

• (A) The 4b decision, narrowed. One deadline stays: an attempt parked on a dependency held over a link, whose target attempt is known and still activating or parked, fails transient after its readyTimeout and retries with backoff; its next attempt usually starts after the other side, and the activation chain in its hold finds the cycle. Working it through showed the catch. A target that is parked is the common case of a chain across hosts waiting for a missing plugin: a tab's view on a worker object that waits for an uninstalled type. Those dependents would time out and poll again, as today, so "local = remote" would stop at the link. Narrowing the deadline to targets that are loading avoids the polling but misses a real ring: A and B on two hosts wait on each other, and B also on a missing X. B is failed { waiting }, so A is too; when X appears, both stay failed { waiting } on each other, with no deadline to break it and no chain to see it. Worse (Fable, round 6): an object's activation chain is fixed when it is created and its instance id survives retries, so a retried attempt sends the same hold with the same chain; two simultaneous starts time out and retry in lockstep and are never found. The deadline would poll without finding what it is for.
• (B) The probe (recommended, pending review) described in the rest of this chapter: no deadline at all, one new message kind, and the most intricate rules in the model. Five review rounds found a counterexample in each of the first four drafts; the version below answers all of them, with one choice left in rule 5. Slice 7 would prove it with tests before the old deadline goes.

The rest of the chapter describes (B): it is the answer that keeps one rule on both sides of a link, and its review history shows what a complete answer takes.

Why a growing chain is not enough

Draft 1 proposed letting chains grow: an activating object that receives a hold with a chain sends the grown chain on to its own dependencies. Astra and Sol showed two flaws. Chains are cut at 32 entries today, so a ring of 33 objects started at once is never found: the chain that reaches each object is always missing that object's own id. And a chain records ancestry, not the current wait graph: once A stops waiting for B, B's chain still names A, and a later wait of B on A looks like a cycle that is not there.

(B) The probe

The model uses an edge-chasing probe (the idea of Chandy, Misra and Haas), for the rings that cross a link; on one host the self.get walk stays, synchronous and exact, as today (Opus). Five rounds of review shaped it; the rules below are the result.

1. Attempts, edges, tokens. Every attempt has its own id, minted per attempt: a retry or a reload is a new attempt (today the id is per instance and survives retries). A wait edge runs from a parked attempt to the activating or parked attempt it waits for, through a bound request. Unbound waits and registry reads are never edges: they are not deadlocks, they end when a provider appears. Every edge carries an edge token: a number from a counter the attempt keeps, never reused, replaced by a fresh one on any interruption or change of that edge (Astra, Sol: two requests to one object are two edges): a new target attempt (also when a local target retries without a re-bind), any loading on a bound or pending hold (a relay re-holding upstream included), an unbinding, a rebinding, a re-hold after a reconnect. An attempt is parked for one interval only (once past its dependency check it never parks again), and attempt ids are never reused. A provider tells its consumers which attempt they wait for on every answer that is not bound: loading { hold, attempt }, and a waiting failed { hold, cause, attempt }.

2. A search per edge change. Whenever a parked attempt gets a new edge, or a new token on one, it starts a search: probe { kind: "search", round, initiator, trail }, with the next number of a counter the attempt keeps, its own attempt id, and the trail of (attempt, edge token) hops crossed so far, starting with its own. A ring closes at its last edge, and that edge's source starts the search that finds it (Sol's simplification after Astra's counterexample: a ring that forms only after a reconnect, with unchanged attempts, is otherwise missed). Searches are coalesced per batch. On the same host a probe is a call on the target attempt, forwarded through a queue rather than recursion; over a link it is a new message, probe { hold, to, ... }, consumer to provider, relayed by hold id with the origin. Probes are honoured on parent and route links and dropped on child links (accept), whatever trusted says (Opus): a tab learns attempt ids from loading and could otherwise break an object with a forged probe, while a worker whose transport is untrusted must still take part. Clients serve no remote types, so no real cycle runs through one.

3. Forwarding. An attempt that receives a search drops it if to is not its current attempt or if it is not parked. If the initiator is itself, the search came back. If the attempt is already in the trail, it drops it: a ring that does not contain the initiator is found by its own members' searches (Opus). Otherwise it forwards it along every wait edge, appending itself and the edge's token to the trail, but only if its round number is higher than the one it stored for that initiator; then it stores it. A late, older round is dropped even if this attempt never saw it: its initiator has moved on (Astra, Opus). The seen map holds one number per initiator, up to 256 initiators, and goes with the attempt.

4. The check. The initiator accepts a returned search while it is still parked, whatever round it carries (Astra: a re-search must not invalidate an older search still under way); the check decides. It verifies its own hop, then sends a probe { kind: "check", round, trail } along the recorded trail: each hop passes it on only if it is still that attempt, still parked, still holding the recorded edge token, pointing at the next hop's attempt. The check follows the trail by position, ignores the seen map and dies on any mismatch. When it returns, the initiator verifies its own hop once more. If the check comes back, the initiator fails broken invalid/cycle, naming the path from the trail, and today's propagation breaks the other activating objects on the ring and the dependents off it.

5. No silent loss. Astra found the last hole: a search can reach an attempt first by a shortcut and be dropped there when it arrives again along the ring itself; if the shortcut breaks before the check, the check dies and nothing is left to find the ring. Round 6 tried dead notices sent back to the initiator. Sol and Astra showed that reliable notices need recovery state per search that the seen map's eviction may not drop, and that a long- parked attempt would otherwise keep for every initiator that ever passed: a leak, unless every search gets a full lifecycle with completion and cancellation. So rule 5 is a choice, part of Owner decision 6:

   • (B1) Re-search with backoff (recommended). An attempt parked on a remote attempt starts a fresh search again after a backoff, 1 second doubling to 60, reset by an edge change, whether it shows loading or failed { waiting }; the timer stops when the attempt leaves parking. No dead messages and no recovery state; eviction only costs work; a new search starts within one backoff period, so every stable ring that crosses a link is eventually found (no wall-clock bound: delivery is only fair). The timer runs as long as the attempt stays parked on a remote attempt: a view on a worker object that waits for a missing plugin re-searches every minute until a reload (Fable). The timer sends probes only: it never fails an object, never re-holds, never polls a provider. Its cost is one probe per parked remote dependent per period, which dies at the leaves of the downstream wait graph.
   • (B2) Events only. Every search is owned until it settles: branches report completion or abort along their trails, a dropped probe answers dead { initiator, round } by a reverse route, edges remember the searches they carry until those settle, and an initiator that ends or moves on cancels its old search. Complete without any timer, bounded by the searches in flight, and the most intricate protocol in Chord; not yet specified to the reviewers' satisfaction.

   Sol's correctness reference, enumerating every simple trail without dedupe, never suppresses a ring copy, but its work is exponential on chains of diamonds.

Why a reported ring existed

Draft 4 confirmed a cycle with a second, independent round. Sol showed a schedule in which two rounds pass through two different stale paths, each of them half replaced by reloads, and together report a ring that never existed at any moment (/tmp/model/sol-probe4.log). The check closes that: it walks the very path the search recorded and demands that every edge still carry the token it had when the search crossed it. A token changes on every interruption and is never reused, and an attempt is parked for one interval only, so an edge cannot vanish and come back unnoticed (Fable and Opus checked the argument in round 5). Every edge of the trail therefore existed from the moment the search crossed it until the moment the check crossed it; the search crossed all of them before the check began, so when the check began, every edge of the ring existed at once. In Sol's schedule the check dies at B, whose edge now points at another attempt.

Why every ring is found

Under an eventually stable wait graph and fair delivery (endless edge churn can keep invalidating searches), and with rule 5's (B1) or (B2) for a search suppressed behind a path that broke, a ring of parked attempts is closed by its last edge. When that edge appears, its source starts a search; every other edge of the ring exists at that moment, and every attempt on the ring waits, directly or not, on the source, so none of them can go live before the search and its check come back. Rings of any length are found, through local and remote edges alike. On a graph without cycles, searches die at the leaves; on a diamond, the seen map drops the second arrival.

What it does not promise

• A ring broken up just after. A ring that existed when the check began may be broken up by a reload, a retry, an unbinding or a revocation a moment later; it is still reported, because it did exist. The objects it breaks recover as every broken object does, through ref.retry() or a reload of their plugin.
• Linear work under every schedule. With more than 256 initiators passing one attempt at once, an evicted entry lets a search be forwarded again, so in an adversarial schedule the work can grow with the number of simple paths (Astra, Sol); never endlessly, since a search never revisits an attempt already in its trail. The seen map's memory stays bounded. Each edge change costs one search that crosses each downstream edge once, and one check per returned search; with (B1), every attempt parked on a remote attempt adds one search per backoff period, also while an acyclic chain only waits for a missing plugin.
• Constant message size. A probe carries its trail, so it grows with the length of the path it crossed; a search that returns carries a trail as long as its ring. That is the price of the check; chains were cut at 32, trails are not, because the trail is the proof.

Objects park; callers do not. A caller is code that wants an answer: a method that needs a reference now, a tool that runs inside a turn, a tab that wants to render. The model keeps their deadlines and gives them one rule.

host.hold

host.hold returns a reference at once and never rejects; only invalid params throw, also before load. That was already the design; the model removes today's inconsistency: a missing local type throws after load but fails the reference before it. Now a missing local type gives loading before the publication and failed { waiting } after it, and the reference binds when a provider appears. A UI that wants to wait for something that may never come holds it and shows its state.

host.get, ctx.get, host.registry

The getters resolve when the reference is live. While it is loading, or failed { transient } (its object's own retry is under way), they wait, bounded by their readyTimeout. On failed { waiting } or failed { broken } they reject at once. On success, rejection or timeout their temporary wait goes; a rejected getter releases its request. host.registry returns the RegistryValue, whose watches and observers are owned as they are today; it has no release().

Opus's case decided the recommendation. A Durable tool runs chord((ctx) => ctx.get(SharingView, { session }), ctx) while sharing is not installed. If getters waited through waiting, the tool, and with it the agent's turn, would hang for 60 seconds and then fail; a call on the same reference would fail at once. With the rule above, the getter and the call give the same answer at the same moment. The rule has a cost Opus named: a dependent whose only blocker is an object recovering by itself (an SSH environment coming back, transient with its own backoff) is waiting, so a getter on the dependent rejects at once. Code that wants to ride that out holds the reference instead of getting it.

Calls

Calls on a loading reference park in order, each bounded by the reference's readyTimeout from the moment it was made (never renewed by a reconnect or a reload). Calls on a failed reference reject at once with the cause. A call already sent when its link drops, or when its object ends, fails and is never resent; its outcome is unknown, and idempotency is the app's (a requestId, as p2's chat does).

The rule in one table

A registry is host-local: its contributions are in-process values, often natives. Slice 8 made self.registry(R) a dependency that waits for a value. The model keeps that and folds it into the one resolver.

A reader's request

A reader asks for R at the version its own bundle was built against. The request is bound while R is served and has a usable value at that version: composed, and for an older reader mapped back by the provider's accepts[old].value. Otherwise it is unbound: not_served (no plugin serves R here), version (the provider does not accept the reader's version, or the reader is newer), compose (R is served, but its first composition, or this version's mapping, threw), or loading before the publication. The reader is woken at every transition of the value at its version to usable. S2's broken for a newer reader and S3's backoff go; so does #valued, the latch that woke readers only at the very first good value.

A registry waits for a value, never for a particular contribution: an empty table composes. "Wait until model X is there" is the app's admission check, not a registry rule; Durable's own "model unavailable" wait covers the harness.

Versions inside one host

Draft 1 claimed that a registry's provider and its contributors always run the same version, because a host installs a revision atomically. Astra corrected it: a revision is a set of plugin bundles, and a reload of the plugin that owns the registry leaves every other plugin's contributors and readers on the version they were built against. So the provider's adapters do real work inside one host: accepts[old].contribution maps an older contribution, accepts[old]. value maps the composition back for an older reader. A contribution without an adapter is left out and reported; a reader without one is waiting with version.

The last good value, and natives

Slice 8 decided that a throwing compose keeps the last good composition, so an extension point stays available while its owner fixes a bug. Astra found the case where that hands out something dead: the harness contributes its native H; a reader is live; the harness ends; the next composition throws for an unrelated reason; .value still returns the composition that contains the closed H.

The model narrows the rule: .value keeps the last good composition only while every contribution it was built from is still in the table. When one of them leaves (its contributor ended or was reloaded), the last good value is dropped and .value throws until compose succeeds again. And compose represents a missing contributor as a value (absent), never by throwing.

A parked object and an unbound request are resources: they hold memory, they may keep a worker process alive, and they act for a principal. The model says how each of those works while nothing is bound.

Keep-alive and presence

A worker stays alive while host.activity shows work: references held over links, calls, jobs, lingering objects. A request that arrived over a link counts once in host.activity.references from its arrival to its end, bound or unbound. Without that, a session whose tab waits for a plugin that is not installed would see its worker stopped every idle period (five minutes in p2) and restarted by the next re-hold, forever (Opus). Presence is different: host.references lists only bound references, so "who is looking at these notes" counts viewers, not waiting requests.

Revocation

Revocation ends the requests of a revoked principal, bound and unbound, at every hop. A guest whose grant is revoked while their tab waits for a missing plugin does not get a reference later when the plugin comes back: the request is gone, and nothing revives an ended request (no publication, no Retry, no new grant). A refused request (no authority) is never indexed in the first place.

gone

gone remains for one thing: revocation. A provider host that closes closes its links and sends nothing (today's #close); its consumers see a link drop, loading, and hold again when the host comes back. A reload that removes a type sends failed { waiting } instead of gone (chapter VII).

Parked objects and their jobs

A parked object with params lives while it is referenced, like any object; when its last holder releases it, it ends and releases its requests, so a parked chain goes from the top down. A host-lifetime object parks until its plugin is removed or the host closes. Persisted job runs of a parked host-lifetime object are loaded with its documents, before it parks; run and finish start only once it is live, and the run count keeps the object as today.

The owner expected the model to remove almost every timeout, "except maybe readyTimeout". That is what it does for dependencies. Every remaining timer bounds something no event can end: a caller's patience, an object's own code, a silent transport, a process that may start this time.

So readyTimeout stays, but its meaning narrows to two things: how long a caller waits, and how long an object's own activation steps may take. Waiting for someone else never counts against it.

The rules of the earlier chapters meet in one story. Mario opens session S1 on his phone; the server S has the catalog and the search feed; the worker W for S1 has not started. W's plugin set has core, models, codemode, notes and search, but not sharing, which was removed last night; the notes view still asks for it. Later in the day a rollout brings sharing back, with a new contract.

What did not happen is the point. Nothing waited for a deadline; nothing retried on a timer; no reference ended because a plugin was missing; no host waited for another host's activations; and every waiting object said what it was waiting for.

These scenarios, from Astra, follow p2's real hosts: the server alone, workers started by a tab or by another worker, web tabs, the TUI, restarts in the middle. Each row says what the model does, with the barrier in both shapes where they differ, and what today's code does. The pattern across all of them: publication never waits for activation, so dependency traffic between hosts always moves; what differs between (a) and (b) is only when base code is told that the first pass is over, and neither shape promises every tool before the first turn.

The Rule column cites sections of the working document, reproduced in appendix C.

Fable's scenarios use p2's names: Catalog and Hosts (the sessions plugin, on the server), Sessions (on the server, called from worker tools), SessionTransfer (a worker type the server calls for a fork), Notes { session } (a worker type a tab holds), NoteStore (local on the worker), ForwardStore (ports, on the worker) and Forwards (radius, on the server), and Harness (host-lifetime, on the worker). S is the server, W1 the worker of session S1, T a web tab. The pattern: a request waits where something is under way and answers where nothing is; nothing a holder does is needed to recover; and an ended holder leaves nothing behind in any index.

The Rule column cites sections of the working document, reproduced in appendix C.

Opus's scenarios cover the provider side: plugins that are missing, arrive by a reload, are removed or break; versions that fit through accepts or do not; registries with missing providers, skewed versions and last good values; self.follow over a harness that restarts; and reloads of an object's own code. The pattern: what used to be broken or polled becomes waiting, woken by the one event that can fix it, and an object's own code is still the only thing that breaks it.

The Rule column cites sections of the working document, reproduced in appendix C.

Sol's scenarios cover the windows in which hosts run different code: a server facet ahead of its worker facet and the reverse, tabs older or newer than the server, installs that are queued, staged or rejected, a type moved between host kinds; then chains across three hosts, diamonds and rings, the probe's own corner cases and a forged probe. Row 20 is a case round 3 found against the previous draft; the rule that fixes it is in chapter VIII. The pattern: a version that does not fit is a request waiting for a publication, never an error that ends it; an install answers only for its own host; and a cycle is found by the attempt whose edge closed it.

The Rule column cites sections of the working document, reproduced in appendix C.