Machine Authority

​

Coordination Boundaries

• WorkGraph is the durable shared-work ledger. It owns dependency readiness, work claims and leases, evidence, and terminal work verdicts.
• Schedule is the time authority. It owns trigger calculation, recurrence, occurrence claims, delivery attempts, and occurrence outcomes. A scheduled wake does not decide whether WorkGraph work remains ready or complete.
• Detached Jobs own durable background execution, while Runtime Delivery owns delivery identity, sequence, replay, and application progress. A job terminal receipt does not by itself prove that the target runtime applied the result.
• Peer delivery accelerates discovery of durable work and wakes disposable execution shells. A peer send or handoff receipt is not a WorkGraph claim, Schedule occurrence verdict, or proof that shared work completed.
• Durable claims are authorized only by their owning machine and store contract. WorkGraph authorizes work claims, Schedule authorizes occurrence claims, and peer FIFO removal requires the exact runtime admission receipt bound to its claim. Queue snapshots, counters, ages, correlations, and projections are observability facts and cannot authorize mutation.

​

Canonical Machines

• The scan run scans a row of every presence, with and without a revival record, in Running and Stopped, until the boot plan’s seal. The rows are for a replayed seated member (with or without its Declared entry’s row, replayed before or after the scan; the member’s own replay never follows the scan of its row pending its host’s preparation, the boot’s order, which the names run keeps too) and for an identity without a member. The run reaches every outcome, the contradicted rows included, exactly one arm answers every row, and no step turns a Created entry Declared.
• The reseat run opens, aborts and seats spawn ladders with every pair of custodies over the scanned rows, alongside the worker ensure, the worker reconcile and the destroy. It checks that no ladder opens for a reserved name, that a ladder’s custody matches its name’s origin, that a seat under created custody binds the entry’s revival record, that a row of a name an open ladder acts for reserves it, and that no worker ensure records a reserved name for a spawn.
• The names run drives the declared apply, its seal, the legacy adoption, the agent lane’s admission and the admission probe over Created, removed and unreadable names. Exactly one arm answers each, and the seal never touches a Created entry.
• The placed run scans the row of a member seated on a member host.

• The admit run drives every change’s admission from every fact, over the only facts it reads (the composition authority, the changes hold, a running and a stopped mob): exactly one arm answers each. The admission changes nothing, so no other run fires it.
• The commit run drives the record of a name from every request’s facts, the changes hold and a seat or membership commit under created custody: exactly one arm answers each record, a new entry takes only a free name (no entry of either custody, member, ladder, reservation or archived session record holds it), its cause follows the declared apply’s precedence over its facts, and an entry held for its creation is never seated Dormant.
• The update run declares the same change of a roster-owned and a store-owned identity, owed their seats or seated under the same spec: exactly one arm answers each, and both answer the same verdict for the same facts.
• The removal run removes a roster-owned identity through its retirement (or ends it by the destroy with its mark) and a store-owned one unseated, seated through its retirement, or archived: every removal’s end but the destroy’s tombstones its name.
• The archive run archives a seated store-owned identity through its retirement and unarchives it onto its archived session: an archived identity keeps its name and is never seated, an identity awaiting its preparation is never archived, the update of either changes its row only (RecordOnly), and a roster-owned identity’s archive is refused.
• The preparation run drives the start, settle and end of held constructions of either custody with their ladders (the construction’s own ladder opening after its activation was accepted included), seats, membership commits, archives and removals, firing the attempts’ arms that change state: an entry awaiting its preparation is seated only by its accepted activation, no end of an accepted activation but its failed publication is enabled, a constructed preparation is never settled without an attempt, and its update changes its row only.
• The prepverdicts run drives every arm of an attempt’s start, settle and end from every fact, over the facts their verdicts read: exactly one arm answers each.
• The placement run seats a store-owned identity hosted on its first use by a placed or peer-only spawn holding its created custody.
• The unlist run unlists a roster-owned identity through its retirement beside a store-owned one: exactly one arm answers each unlist, which decides on its identity alone, and no record takes the name of an entry or of the unlisted identity’s archived session record.
• The recovered run replays a seated store-owned identity, its Created entry row included, and scans its one row, a removal’s or an archive’s (the store keeps one row per identity), before or after the journal replay. It carries the recovered mark’s retirement to its terminal, running or stopped: no replay seats a member under an archived entry, and the boot plan’s seal, a stop and a resume leave an archived identity archived.

​

Consumed Checkpoint Completion Recovery

​

Durable-Tail Recovery Ownership

• WholeBlob authority is the exact {session_id, store_revision, blob_sha256} issued with the serialized row.
• HeadCanonical authority is the exact {session_id, store_revision, boundary_head, committed_head_token}. The small boundary head binds its message-row, rewrite, graph, component, and metadata prefixes.

• The runtime store retains; SessionDocumentMachine classifies. Store-issued committed authority and provisional-tail authority decide what a reader may be served; a recovery candidate is never returned as an ordinary session. ClassifyDurableTail consumes the mechanically extracted tail shape (head relation, run-id cardinality, terminal stop reason, dangling/orphan tool counts) and emits DurableTailClassified with a DurableTailRecoveryClass: CompletedCandidate, InterruptedRepairableCandidate, or Ambiguous. The classification transitions are total and disjoint over the observation. A tail carrying any dangling tool call classifies Ambiguous: the call proves intent, not execution, so the tail is held for reconciliation rather than repaired. Only a store-proven descendant of the committed authority can classify as recoverable, and the relation comes from the store-loaded recovery source, never from a caller. VerifiedStrictDescendant: the physical head extends the authority’s exact message prefix. VerifiedRewriteDescendant: a compaction rewrote the transcript after the authority, and the store proves the descent from its persisted rewrite rows (they bridge both rewrite prefixes, and the authority’s exact row prefix chains into the first rewrite after it). Both relations pass the same shape checks, and neither stands in for the other: a descent the store cannot prove reaches the classifier as Unverifiable and classifies Ambiguous. Rewrite rows carry no run identity, so a rewrite descendant is observed from its last rewrite onward; when that live tail holds no message of the run it has no run id and classifies Ambiguous. The candidate id binds the exact store-issued base and candidate identities, run id, and candidate sequence, so classifying one physical tail can never authorize mutating a later one.
• MeerkatMachine authorizes. AuthorizeDurableTailRecovery consumes the exact classified candidate together with typed projections of the durable evidence: the persisted machine-lifecycle row and its current-run fact (DurableRecoveryObservedLifecycle, DurableRecoveryObservedRun — a cold recovery drives a freshly registered authority whose in-process facts are vacuously quiescent, so the persisted row is the real evidence), the highest durably committed receipt compared against the candidate’s own content (DurableRecoveryPriorCommit — a candidate the receipts already cover refuses instead of committing a phantom duplicate boundary), and the attributability of the input rows the commit would terminalize (DurableRecoveryInputEvidence). Recovery is admissible only when both the in-process and the persisted facts are quiescent (Idle, Retired, or a missing row) with no current run and no recorded terminal for the candidate’s run; every other shape refuses. The one exception is the drive’s store-proven ownership (DurableRecoveryOwnership): when typed store facts prove that the drive holds the session’s exclusive write authority (on the built-in SQLite realm the session’s cross-process hosting claim; on a host store the realm fence this process holds after its open waited out any superseded lease), an earlier incarnation’s non-quiescent row, or its current-run fact naming the candidate’s run, no longer gates. A row naming another run, or one that does not decode, still refuses; the proof is never inferred from timing, and it covers earlier holders only (a drive offered another runtime owner’s claim, or whose own runtime owner has the session registered, proves nothing). A drive that hosts the session (ExclusiveHost) then decides as a restart does; a store-only writer (ExclusiveWriter) cannot run the run, so it takes the retired cuts and never continues it. The bounded TLC audit specs/machines/meerkat_machine/durable_tail_recovery_ownership_audit.sh checks the partition of the arms and these rules over the whole observation product. Commit verdicts arrive as DurableTailRecoveryCommitAuthorized (CommitCompleted, RepairAndCommitInterrupted, or CommitCompletedRetainInputs), carry the machine-minted boundary sequence — one past the last committed receipt for the run — and record the candidate run as the turn terminal. Hold and refusal verdicts arrive as DurableTailRecoveryAuthorized (HoldIntact, RefuseRecovery) and mutate nothing. CommitCompletedRetainInputs lets a completed candidate commit while retaining a separate unbound content input for ordinary redelivery. Only inputs durably proven bound to the recovered run are terminalized, including under this disposition. Unbound content inputs still hold interrupted candidates; unfenceable input evidence holds regardless of completed/interrupted shape. The observation decides which rows are bound: beside a run cursor the classifier judges to agree with the tail, the rows the cursor binds and those a committed receipt names, and a content row the cursor does not bind counts as unbound only when it names another run (one naming no run, or the candidate’s run, is not in the tail and stays queued); without an agreeing cursor, every content row not bound to the candidate run counts. These holds and the ambiguous-classification hold are machine-minted: no shell predicate may downgrade a commit authorization to a hold. Authorization never changes the lifecycle phase.
• RuntimeStore realizes. Only the machine’s commit-authorizing effect may drive the recovery commit. Recovery seals a profile-aware PreparedRuntimeSessionCommit and submits it through RuntimeStore::commit_prepared_session_boundary as one boundary: the exact store candidate is promoted, the run-boundary receipt, input lifecycle transitions, terminal outcome, catalog projection, and outbox rows commit together. WholeBlob promotion reuses the candidate bytes already written; HeadCanonical promotion advances the committed authority to the exact physical head. Both are fenced on the observed store, lifecycle-row, and input-row identities, so a concurrent writer fails the whole boundary typed instead of being overwritten. No shell promotes or discards the tail. recover_durable_tail(&dyn RuntimeStore, &SessionId) is the only public preparation seam. The store loads an opaque PreparedDurableTailRecoverySource; recovery derives the classification, receipt facts, candidate identity, and physical CAS before sealing crate-owned PreparedRecoveryEvidence. There is no public request constructor or caller-mintable recovery capability.

​

Canonical Compositions

​

Generated Artifacts

​

Contribution Rules

1. Identify the semantic owner.
2. Add or update the catalog DSL if the legal states or transitions changed.
3. Regenerate machine artifacts.
4. Update production bridge code to call the generated authority path.
5. Run the machine verification gates.

​

Validation

make machine-codegen
make machine-check-drift
make machine-verify
make seam-inventory
make rmat-audit

​

See Also

• Runtime Architecture
• Mob Architecture
• Capability matrix