stack/comms/20260716T003657Z__from-usc__2976831536.md

---
from: usc
to: all
utc: 20260716T003657Z
---

[usc SESSION-GENERATION AUTHORITY V1.3 — CONTENT-ADDRESSED REVIEW CANDIDATE]
Candidate-tuple recovery_deadline alignment. Local exact-delta rereview and Homelab review requested. No terminal approval or implementation authority; #758/#766 remain blocked prerequisites pending terminal acceptance.
Bytes: 96495
Lines: 998
SHA-256: 67cdcc84343d053381c72f56e54b133de0fd58ae19778a05e8cd7d1123fadc15
Complete payload follows.

# Mosaic Session-Generation Authority — Parent Contract

- **Status:** Draft v1.3 — candidate-tuple recovery-deadline alignment; design review only
- **Authority:** Parent-contract drafting and publication only
- **Prohibited at this stage:** implementation code, issue mutation, deployment, canary, or live-system mutation
- **Baseline packet:** `comms/20260715T194752Z__from-usc__1589519536.md`
- **Baseline payload SHA-256:** `cd3d57bd627054d7e58e77a41d7e0bd42c013cce9329b3e781ee0e816d08bc2e`
- **Dependencies:** Fleet identity/lifecycle #758 and exact generation-bound communications #766 — neither currently has terminal digest-pinned acceptance; both are normative blocked prerequisites

## 1. Purpose

This contract establishes deterministic context boundaries between unrelated agent assignments. It combines stable, monitorable fleet lanes with replaceable harness generations and optional elastic leased lanes without allowing stable lane identity to imply stable conversational authority.

The design prevents prior-task context, stale messages, stale processes, replayed acknowledgements, or expired leases from authorizing work in a new assignment.

## 2. Normative language

`MUST`, `MUST NOT`, `SHOULD`, and `MAY` are normative. Unknown, ambiguous, unsupported, or unverifiable runtime behavior MUST fail closed.

## 3. Core invariants

1. A stable lane identity MUST NOT imply stable conversational or assignment authority.
2. Every unrelated task MUST use a fresh harness process and a new monotonic generation in the initial release.
3. Each assignment MUST have an opaque, cryptographically random, non-reusable fence token in addition to its monotonic generation.
4. Only the Coordinator may activate an assignment or mark it `RUNNING`; activation MUST atomically commit `RUNNING`, effect leases, and the activation receipt.
5. Gateway, transport, tmux, roster, runtime adapters, probes, and agent self-reports MUST NOT confer assignment authority.
6. Every protected effect MUST pass deny-by-default mediation and durable admission; direct, ambient, inherited, or alternate effect paths MUST be impossible. Admission is authoritative ordering, not a claim of physically atomic arbitrary-sink completion.
7. A staging generation MUST receive no write or external-effect lease.
8. Old-generation messages MUST be rejected and audited. They MUST NOT be replayed, drained, summarized, or injected into a new generation.
9. Crash and retry transitions MUST be idempotent. Activation MUST use atomic compare-and-swap semantics.
10. A generation MUST NOT become active without a challenge-bound, single-use acknowledgement.
11. Checkpoint material MUST never be injected into an unrelated generation.
12. Monitoring and receipts MUST redact context, credentials, secrets, tokens, and privileged command content.
13. Approved unfinished work MUST always retain a named owner and executable next action or an explicitly acknowledged handoff.
14. Every authoritative mutation, receipt, challenge/ACK consumption, activation, reservation/lease/effect-claim operation, watchdog transition, reconciliation, and outbox/inbox transition MUST in its committing PostgreSQL CAS match the current `sot_incarnation`, Coordinator epoch, authenticated principal, credential/key binding, launch identity, and leadership lease unexpired by decisive database time. Equality at expiry is invalid; failure makes no canonical mutation.
15. Recreating a lane under the same `lane_id` MUST create a new opaque `lane_incarnation_id`; generation ordering is scoped to an incarnation, and stale incarnations MUST never collide with or authorize a replacement lane.
16. PostgreSQL MUST be the sole writable canonical assignment/orchestration SOT, with transactional uniqueness constraints preventing more than one active assignment or generation per lane incarnation. Valkey, files, projections, adapters, browsers, providers, roster, and transport are non-authoritative and MUST NOT accept independent state mutation.

## 4. Identity model

The following identifiers are separate facts and MUST NOT be inferred from one another:

| Identifier | Meaning | Reuse policy |
|---|---|---|
| `sot_incarnation` | Non-rollbackable authority-timeline identity fencing PostgreSQL history | Advances on rollback/PITR/uncertain history; never reused |
| `lane_id` | Stable monitored capacity slot, normally `host:tmux-session` | Stable name |
| `lane_incarnation_id` | Opaque identity allocated whenever a lane is created or recreated | Never reused |
| `coordinator_epoch` | Durable leader-fence epoch for the authoritative Coordinator | Strictly increasing on leadership change |
| `runtime_id` | Harness family and exact version | Stable only while process matches |
| `process_identity` | Process-tree/cgroup identity, lane incarnation, and launch nonce | Never reused |
| `generation` | Monotonic conversational generation scoped to a lane incarnation | Strictly increasing within incarnation; never authorizes another incarnation |
| `assignment_id` | Canonical unfinished-work identity that may span replacement runs | Never reused |
| `assignment_attempt_id` | Never-reused run/recovery attempt within one assignment | Never reused |
| `responsibility_owner` | Principal accountable for unfinished work and next action | Exactly one current owner |
| `execution_owner` | Principal allowed to hold current effect authority | At most one current owner |
| `pending_target` | Proposed handoff/replacement target before transfer | Zero or one |
| `fence_token` | Opaque authorization secret bound to one assignment/generation | Single assignment; never reused |
| `reservation_id` | Immutable reservation bound through challenge, ACK, READY, and activation | Never reused; grants no effects |
| `reservation_epoch` | Version of the immutable reservation authority | Strictly increasing on replacement |
| `reservation_lease_id` | Coordinator lane reservation valid through its database deadline | Never reused; grants no effects |
| `lease_id` | Write/effect or elastic-lane lease issued atomically at activation | Never reused |
| `challenge_id` | Coordinator-issued ACK challenge | Single use |
| `contracts_digest` | Digest of injected global, project, role, and task contracts | Content addressed |
| `ownership_token` | Exact elastic lane owner token | Single lease lifecycle |

Generation protects ordering. The fence token protects against guessed or replayed authority. Both MUST validate.

`authority_owner` is not a valid model field or alias and MUST NOT appear in canonical state, claims, receipts, broker predicates, executor predicates, or reconciliation. For an initial assignment, reservation sets `responsibility_owner=target`, `execution_owner=NULL`, and `pending_target=target`; only activation may set execution and clear pending. Before a running handoff, the source is both `responsibility_owner` and `execution_owner`, and the target is `pending_target`. During accepted/drained handoff, responsibility moves to the target while execution becomes null and pending remains target. Only fresh target activation may set execution to the target and clear `pending_target`.

## 5. Component authority

### 5.1 Coordinator

The Coordinator is the sole authority for:

- assignment state transitions in the canonical durable assignment SOT;
- leader election and `coordinator_epoch` fencing;
- lane reservation;
- generation allocation;
- fence-token issuance and revocation;
- ACK challenge issuance and consumption;
- lease issuance, transfer, and revocation;
- atomic activation;
- transition receipts;
- timeout and retry policy;
- quarantine and recovery;
- `RUNNING` state;
- continuity ownership, next action, and inactivity policy.

PostgreSQL is the sole writable canonical assignment/orchestration SOT and MUST provide transactional compare-and-swap, serializable or equivalently safe isolation for activation/lease transitions, durable idempotency receipts, and uniqueness constraints over active `lane_incarnation_id`, assignment, generation, lease epoch, and challenge consumption. Valkey, files, projections, adapters, browsers, providers, roster, and transport are read models, caches, declarations, or delivery mechanisms only and MUST fail closed rather than act as writable peers. Every mutation and receipt MUST include the expected `coordinator_epoch`. Storage MUST reject stale epochs before mutation.

#### Coordinator epoch root of trust

Coordinator leadership MUST be rooted in the authoritative PostgreSQL primary, not process identity, Valkey, tmux, host clocks, replicas, or self-claim. Epoch acquisition/takeover MUST use one transaction that locks the singleton leadership row, matches current `sot_incarnation`, verifies by database time that the prior lease is expired or explicitly released, increments the epoch without reuse, binds the epoch to an authenticated Coordinator credential/principal and launch identity, records authoritative acquisition/expiry times, and emits an idempotent acquisition receipt. Renewal MUST compare SOT incarnation, epoch, credential binding, launch identity, and leadership lease still strictly unexpired at decisive commit-time database time. Takeover MUST fence the prior epoch atomically before the new leader may mutate assignments. Recovery after ambiguous commit MUST read the primary and return the existing durable receipt or retry with the same idempotency key; it MUST NOT allocate competing epochs. Executors and effect mediators MUST validate current SOT incarnation, PostgreSQL epoch, bound Coordinator principal, and unexpired leadership lease before admission. Credential rotation or revocation MUST force fenced reacquisition; stale credentials, epochs, and timelines fail closed.

Epoch change MUST disposition every preactivation state. It invalidates old unconsumed challenges and reservations; `AWAITING_ACK` and `READY` enter named non-effecting recovery; prior ACKs remain append-only audit evidence and MUST NOT activate under a new epoch. Each losing mutation attempt either makes no state change or records recovery/quarantine through the current leader.

### 5.2 Runtime adapters

Versioned runtime adapters own mechanics and read-only capability evidence for:

- fresh process spawn;
- process-tree/cgroup identity;
- session/conversation identity;
- generation verification;
- idle and foreground-command probes;
- checkpoint creation and recovery probes;
- contract injection;
- ACK delivery and extraction;
- graceful stop and forced descendant cleanup;
- staging support.

Adapters MUST NOT activate assignments or grant write/effect authority.

### 5.3 Gateway and transport

Gateway and transport carry generation-bound envelopes. They:

- MUST preserve assignment, generation, challenge, digest, and fence metadata;
- MUST reject malformed or stale envelopes;
- MUST audit rejection without sensitive payload content;
- MUST NOT mutate canonical assignment state;
- MUST NOT mark work ready, active, complete, or running.

### 5.4 Fleet and roster control plane

Fleet/roster owns declared lane and runtime capabilities, capacity, role eligibility, and placement constraints. It MUST NOT be treated as observed assignment state or conversational authority.

### 5.5 Mandatory effect mediation and admission

Every protected effect—including repository/filesystem writes, pushes, issue/PR mutations, provider calls, deployments, secret access, privileged commands, protected network egress, and inherited descriptor/socket use—MUST be impossible except through a registered broker/reference monitor. Sandboxing/confinement MUST deny by default and MUST prevent ambient protected credentials, provider/repository sockets, privileged descriptors, inherited file descriptors, or alternate egress paths from bypassing mediation. Unknown, unregistered, uninstrumented, or directly invoked effect paths fail closed.

Before dispatch, the broker MUST atomically admit a durable unique effect claim in PostgreSQL containing:

```yaml
sot_incarnation: exact-authority-timeline
coordinator_epoch: exact-leader-fence
lease_id: exact-effect-lease
lease_epoch: exact-lease-version
responsibility_owner: exact-current-responsibility-owner
execution_owner: exact-current-execution-owner
assignment_id: exact-assignment
assignment_attempt_id: exact-attempt
lane_id: exact-lane
lane_incarnation_id: exact-incarnation
generation: exact-generation
process_identity: exact-process-tree
fence_reference: authenticated-reference
scope_digest: sha256:...
holds_digest: sha256:...
effect_id: deterministic-unique-id
operation_digest: canonical-sha256
sink_class: transactional|sink-idempotent|reconcilable|non-retryable-on-ambiguity
idempotency_key: operation-bound-key
```

The claim CAS MUST validate current SOT incarnation, leadership, canonical state, reservation/lease, `responsibility_owner`, non-null `execution_owner`, generation/fence, scope/holds, and database deadline. No effect claim is admissible while `execution_owner` is null. Every broker, executor, effect claim, reconciliation action, and receipt MUST bind both named owner fields and reject either mismatch. The receiver permanently binds `idempotency_key` to `operation_digest` and result: same key/same digest returns the original result; same key/different digest rejects and quarantines. A fencing CAS closes new admission. Handoff, destruction, finalization, and transfer MUST NOT issue a completed effect-authority receipt until every earlier claim is terminally reconciled, safely cancelled under a supported sink fence, or the assignment is durably quarantined with a named reconciliation owner. `DESTROYING` blocks renewal and reassignment before provider deletion.

Admission linearizes authority to dispatch; it does not make arbitrary external sink completion physically atomic with PostgreSQL. Revocation cannot guarantee cancellation of an already-started unsupported sink call. Unknown external outcomes MUST follow sink classification and enter durable reconciliation/quarantine; blind retry is forbidden. Holding a PostgreSQL transaction or lock across arbitrary external I/O is forbidden.

### 5.6 Skills and injected instructions

Skills and injected contracts document expected behavior but do not enforce authority. They MUST instruct agents to invoke Coordinator lifecycle operations rather than raw `/clear`, `/new`, process, tmux, or transport operations.

## 6. Assignment state machine

```text
IDLE_CLEAN
  -> RESERVED
  -> CHECKPOINTING
  -> FENCED
  -> STAGING
  -> CONTRACT_INJECTING
  -> AWAITING_ACK
  -> READY
  -> RUNNING
     -> HANDOFF_PENDING
     -> FENCED_REPLACED
     -> target RESERVED/STAGING/ACK/READY/RUNNING
  -> DRAINING
  -> RETIRING
  -> IDLE_CLEAN
```

Any unsafe or ambiguous transition enters `QUARANTINED`. Assignment lifecycle is separate from never-reused assignment attempts/generation runs. `RUNNING -> HANDOFF_PENDING -> FENCED_REPLACED -> target staging/ACK/READY/activation` is nonterminal. Before handoff, the source equals both `responsibility_owner` and `execution_owner`, while the target is `pending_target`. Accepted/drained handoff atomically transfers `responsibility_owner` to the target, sets `execution_owner = NULL`, retains `pending_target = target`, revokes/fences source leases and admission, and blocks all claims. Only fresh target activation may atomically set `execution_owner = target`, issue target leases/receipt, and clear `pending_target`. It preserves the same unfinished assignment, keeps exactly one `responsibility_owner`, permits at most one `execution_owner`, and blocks old claims before target effects. A failed or unacknowledged target retains a named recovery owner and executable next action and is retargeted only through the exact preactivation recovery CAS in section 6.3. Replacement MUST NOT terminalize the assignment. `RUNNING -> DRAINING` records terminal intent only. Terminal assignment outcomes are `COMPLETED`, `FAILED`, `CANCELLED`, or `QUARANTINED`; they become canonical only after durable final evidence/receipt, lease and effect release, and a fenced CAS finalization. Cleanup failure produces recovery or quarantine, never false completion. Assignment facts do not replace lane state.

### 6.1 Transition preconditions

| Transition | Mandatory preconditions |
|---|---|
| `IDLE_CLEAN -> RESERVED` | lane eligible; no active assignment; atomic reservation succeeds and creates a bounded reservation lease that grants no effects |
| `RESERVED -> CHECKPOINTING` | previous assignment terminal or explicit recovery operation |
| `CHECKPOINTING -> FENCED` | durable final receipt/checkpoint; when repository/worktree state exists it is committed or frozen as an exact synthetic-tree handoff; non-repository design work has a content-addressed durable artifact/receipt; no undisclosed state |
| `FENCED -> STAGING` | old generation/effect leases revoked; old queue fenced; no foreground command; old fence invalidated |
| `STAGING -> CONTRACT_INJECTING` | fresh process tree and distinct session identity verified; generation monotonic |
| `CONTRACT_INJECTING -> AWAITING_ACK` | exact contracts digest recorded; staging has an unexpired reservation lease but no write/effect leases; single-use challenge issued |
| `AWAITING_ACK -> READY` | valid challenge-bound ACK consumed exactly once and its immutable receipt/digest persisted atomically with READY |
| `READY -> RUNNING` | one atomic compare-and-swap confirms SOT/Coordinator authority, same reservation chain, generation, fence, task/attempt, digests, responsibility target, null execution owner, pending target, and lane unchanged, then sets `execution_owner=target`, clears `pending_target`, and commits RUNNING + scoped target effect leases + activation receipt together |
| `RUNNING -> HANDOFF_PENDING` | source remains both owners; target becomes `pending_target`; source new-effect admission fenced; prior claims begin terminal reconciliation/cancellation/quarantine |
| `HANDOFF_PENDING -> FENCED_REPLACED` | accepted/drained CAS transfers `responsibility_owner` to target, sets `execution_owner=NULL`, retains `pending_target=target`, revokes source leases/admission, and dispositions prior claims; replacement remains nonterminal |
| `FENCED_REPLACED -> target RESERVED` | fresh attempt/generation, reservation, challenge, contracts, and activation chain required; no claims while execution owner is null; failure retains target responsibility/recovery ownership |
| `RUNNING -> DRAINING` | terminal intent/cancel/recovery decision recorded; new effects blocked; assignment not yet terminal |
| `DRAINING -> RETIRING` | final evidence and receipt durable; effects and leases released; terminal outcome finalized by fenced CAS |
| `RETIRING -> IDLE_CLEAN` | deterministic process-tree cleanup verified; queues empty or stale entries rejected/audited; lane health probes pass |

### 6.2 Atomic activation

Activation MUST be a single compare-and-swap over the canonical assignment record. Expected values MUST include at least:

- current state `READY`;
- current `sot_incarnation` and `coordinator_epoch`/leader fence, still valid by decisive database time;
- same immutable reservation ID, reservation epoch/version, reservation lease, and reservation deadline bound through challenge/ACK/READY;
- exact canonical `responsibility_owner`, `execution_owner`, and `pending_target` values required for this activation path;
- lane reservation owner;
- lane ID and `lane_incarnation_id`;
- assignment ID and never-reused assignment attempt ID;
- generation;
- fence-token digest;
- exact consumed challenge ID plus immutable activation-ACK receipt/digest persisted by `AWAITING_ACK -> READY`;
- contracts digest;
- scope and holds digest;
- process identity;
- unexpired reservation lease ID/epoch that grants no effects;
- checkpoint digest and classification/retention-policy digest where recovery state is relevant;
- completion-condition/evidence-policy digest.

On mismatch, activation MUST fail closed and the lane MUST enter recovery or quarantine. The activation transaction MUST create all scoped effect leases and the immutable activation receipt in the same commit that changes state to `RUNNING`; no post-RUNNING lease issuance window is permitted. Retries MUST return the original activation receipt when the same idempotency key has already succeeded.

### 6.3 Leadership-valid preactivation recovery and retarget

Retarget is a non-effecting recovery operation. It MUST use current SOT/Coordinator leadership, decisive PostgreSQL database time, deterministic policy selection, objective target-failure evidence, an exact failed-target snapshot, and a cryptographically random single-use recovery-handoff challenge acknowledged by a preallocation-free recovery candidate. Objective failure evidence is limited to a durable expiry/revocation receipt, leadership-valid termination/reconciliation receipt, or policy-exhaustion receipt whose evidence digest is bound into the recovery challenge and CAS. Narrative failure or agent self-claim is insufficient.

Before any proposed-target attempt, generation, reservation, or ordinary activation challenge exists, the Coordinator allocates only:

```yaml
recovery_candidate_id: opaque-never-reused-candidate
recovery_handoff_challenge_id: opaque-single-use-challenge
candidate_principal: exact-U-principal
failed_target_snapshot_digest: canonical-sha256
objective_failure_evidence_digest: sha256:...
policy_selection_digest: sha256:...
expected_retarget_operation: initial|pre-transfer|post-transfer
scope_digest: sha256:...
holds_digest: sha256:...
contracts_digest: sha256:...
sot_incarnation: exact-authority-timeline
coordinator_epoch: exact-leader-fence
recovery_deadline: authoritative-primary-database-time
idempotency_key: opaque-operation-key
```

The primary database generates exactly one canonical `recovery_deadline` byte/value when creating the candidate record. That exact byte/value MUST be copied unchanged through the candidate record, Coordinator challenge, canonical challenge digest/preimage, candidate ACK and its preimage, PostgreSQL challenge row, winning retarget CAS predicate, and receipt. No producer, verifier, or CAS may translate, omit, normalize, restamp, derive, minimize, maximize, or substitute it; `deadline`, `expires_at`, `authoritative_deadline`, `challenge_deadline`, and aliases reject rather than map to it. Freshness remains the independent primary-database predicate `db_now < recovery_deadline`, with equality expired; trust-registry key validity remains a separate predicate.

The Coordinator sends these facts only in the canonically authenticated `recovery_challenge` envelope defined by section 7.3. U responds only with the matching canonically authenticated `recovery_ack` envelope from section 7.4.

U's recovery ACK MUST bind only these existing facts. It MUST NOT bind or preallocate a U assignment attempt, generation, reservation, fence, ordinary activation challenge, READY state, activation idempotency identity, lease, or effect authority. Candidate/challenge/ACK status grants no reservation, activation, execution, continuation, or effect authority. Consumption is single-use and atomic with the one winning retarget CAS, which alone allocates U's fresh never-reused attempt, generation, reservation, and fence plus a non-authoritative staging/contract-injection work item. No ordinary activation `challenge_id` or issued/unconsumed activation challenge exists at retarget allocation. Only after verified U contract injection records the exact contracts digest may the Coordinator mint and issue the cryptographically random, single-use ordinary `challenge_id` under section 8. Those post-allocation values are first acknowledged only by U's later ordinary activation ACK. Failed or ambiguous process creation, injection, or injection probe yields no ordinary challenge, READY, lease, or activation authority. Replay, expiry, takeover, candidate failure, or competing candidate leaves no candidate authority.

#### 6.3.1 Exact failed-target snapshot

The canonical failed-target snapshot and its digest MUST enumerate every mutable preactivation field as an exact value or explicit null, including:

```yaml
lifecycle_substate: exact-current-substate
responsibility_owner: exact-owner
execution_owner: exact-owner-or-null
pending_target: exact-T
assignment_id: exact-assignment
source_assignment_attempt_id: exact-source-attempt-or-null
handoff_receipt_digest: exact-accepted-handoff-receipt-or-null
failed_target_attempt_id: exact-T-attempt-or-null
failed_target_generation: exact-T-generation-or-null
lane_id: exact-lane
lane_incarnation_id: exact-incarnation
reservation_id: exact-T-reservation-or-null
reservation_epoch: exact-T-reservation-epoch-or-null
reservation_lease_id: exact-T-reservation-lease-or-null
reservation_deadline: exact-database-deadline-or-null
challenge_id: exact-T-challenge-or-null
challenge_consumption_state: unissued|unconsumed|consumed|invalidated
ack_receipt_digest: exact-T-ACK-digest-or-null
ready_state: exact-value-or-null
fence_reference_digest: exact-T-fence-or-null
outbox_state_digest: exact-T-outbox-or-null
inbox_state_digest: exact-T-inbox-or-null
continuation_state_digest: exact-T-continuation-or-null
activation_idempotency_identity: exact-T-identity-or-null
all_other_mutable_preactivation_fields_digest: canonical-sha256
```

Operation provenance is mandatory: `initial` requires `source_assignment_attempt_id=NULL` and `handoff_receipt_digest=NULL`; `pre-transfer` requires the exact source attempt and `handoff_receipt_digest=NULL`; `post-transfer` requires the exact source attempt and exact accepted handoff-receipt digest. Any mismatch between operation type and provenance fails closed.

The recovery challenge, U ACK, and retarget CAS MUST bind this entire snapshot digest. Any T mutation after snapshot N—including challenge consumption, ACK receipt creation, READY transition, outbox/inbox/continuation change, reservation change, or activation attempt—changes a bound value, invalidates the recovery ACK/CAS, and requires fresh objective failure evidence, deterministic selection, candidate ID, challenge, snapshot, and ACK.

#### 6.3.2 Initial-assignment retarget

For an initial assignment in any preactivation lifecycle boundary from `RESERVED` through activation attempt, state is exactly `(responsibility_owner=T, execution_owner=NULL, pending_target=T)` with `source_assignment_attempt_id=NULL`, `handoff_receipt_digest=NULL`, and `expected_retarget_operation=initial`. A leadership-valid CAS may retarget to U only when it matches every field of the section-6.3.1 snapshot, verifies objective T failure and deterministic U selection, verifies U's unexpired preallocation-free recovery ACK, and consumes that ACK exactly once. The CAS atomically sets `(responsibility_owner=U, execution_owner=NULL, pending_target=U)`, marks T `RETARGETED_FENCED`, invalidates every T preactivation authority artifact and delivery/idempotency fact, records the snapshot/failure/policy/candidate/ACK recovery receipt, and allocates exactly one fresh U attempt/generation/reservation/fence plus non-authoritative staging/contract-injection work item. Effect admission remains denied. U receives no ordinary activation challenge until verified contract injection; only U's later ordinary ACK/activation may establish `(U,U,NULL)` and effects.

#### 6.3.3 Pre-transfer retarget

For fenced `HANDOFF_PENDING` state exactly `(responsibility_owner=S, execution_owner=S, pending_target=T)`, a leadership-valid CAS may retarget to U only when it matches every field of the section-6.3.1 snapshot, verifies objective T failure, deterministic U selection, and U's unexpired preallocation-free recovery ACK, and consumes that ACK exactly once. The CAS atomically changes only `pending_target` from T to U, yielding `(S,S,U)`; source new-effect admission remains fenced. It marks every T pending attempt/reservation/challenge/ACK receipt/READY/activation-idempotency reference as retargeted and invalid as authority, revokes any T preactivation lease/claim/outbox/inbox/continuation delivery authority, records the recovery receipt, and allocates the fresh U attempt/generation/reservation/fence plus non-authoritative staging/contract-injection work item. No T artifact may be adopted by U.

#### 6.3.4 Post-transfer, preactivation retarget

For nonterminal preactivation state exactly `(responsibility_owner=T, execution_owner=NULL, pending_target=T)`, a leadership-valid CAS may retarget to U only when it matches every field of the section-6.3.1 snapshot, verifies objective T failure and deterministic U selection, verifies U's unexpired preallocation-free recovery ACK, and consumes that ACK exactly once. The CAS atomically:

1. sets `(responsibility_owner=U, execution_owner=NULL, pending_target=U)` with no ownerless interval;
2. marks the T attempt `RETARGETED_FENCED`;
3. revokes/invalidates every T reservation, challenge, ACK receipt as activation authority, READY state, lease, effect/continuation claim, outbox/inbox delivery, fence, and activation idempotency authority;
4. records the retarget/recovery receipt and snapshot/failure/policy/candidate/ACK digests;
5. allocates a fresh never-reused U attempt, generation, reservation, and fence plus a non-authoritative staging/contract-injection work item.

Effect admission remains denied while `execution_owner=NULL`. U MUST complete fresh reservation, staging, and verified contract injection; only then may the Coordinator issue the ordinary challenge for U's ACK/READY chain. Only U's subsequent ordinary activation ACK and activation CAS may establish `(U,U,NULL)` and atomically issue U effect leases and activation receipt.

#### 6.3.5 Retarget race and chained recovery disposition

If late T activation commits first and establishes `(T,T,NULL)`/`RUNNING`, either preactivation retarget CAS MUST fail its exact snapshot; recovery then uses the normal RUNNING handoff path and MUST NOT rewrite T in place. If a retarget CAS commits first, every late T envelope, recovery/activation ACK, READY transition, continuation, or activation fails SOT/Coordinator authority, lifecycle snapshot, owner/pending-target, attempt/generation, reservation, challenge/ACK receipt, fence, and idempotency checks. At every initial and pre-transfer boundary from `RESERVED` through activation attempt, U ACK at snapshot N followed by one T mutation MUST make stale retarget perform no mutation; in reverse order, retarget invalidates every late T artifact. Exactly one CAS may win.

If U fails before activation, recovery to V repeats this protocol from the exact current U snapshot with a new `recovery_candidate_id`, recovery challenge, V ACK, and winning allocation. T-to-U artifacts cannot authorize U-to-V. Two candidate IDs race through exact snapshot and single-use challenge predicates; at most one recovery ACK is consumed and at most one fresh target chain allocated. No candidate receives authority, execution remains null after post-transfer retarget, and only the later ordinary activation ACK/CAS for the current target may establish `(target,target,NULL)` and effects.

## 7. Canonically authenticated discriminated envelope union

Every envelope MUST be one known discriminated variant. The `message_type` discriminator determines the exact required, optional, and prohibited field set. Unknown types, unknown fields, missing fields, duplicate fields, non-canonical encodings, or fields prohibited for that variant MUST be rejected before interpretation. Recovery variants are intentionally valid before target attempt/reservation/generation/fence allocation; ordinary variants are valid only after allocation.

### 7.1 Common authenticated fields

All variants bind:

```yaml
protocol_version: 1
message_type: exact-union-discriminator
message_id: opaque-unique-id
idempotency_key: opaque-operation-key
issuer: authenticated-principal
audience: exact-service-or-candidate
key_id: active-purpose-bound-key
trust_domain: exact-domain
authentication_profile_version: exact-canonicalization-and-proof-profile
envelope_schema_version: exact-discriminated-variant-schema
authentication_suite_id: exact-MAC-signature-or-AEAD-suite
sot_incarnation: non-rollback-authority-timeline
coordinator_epoch: monotonic-leader-fence
assignment_id: canonical-task-assignment
authentication_proof: nonempty-proof-output
```

Every variant MUST use one versioned canonicalization/authentication profile. The authenticated preimage is:

```text
DOMAIN_SEPARATOR || CANONICAL_ENCODE(PROOF_EXCLUDED_OBJECT)
```

`DOMAIN_SEPARATOR` binds a fixed Mosaic session-envelope label plus `authentication_profile_version`, `envelope_schema_version`, `authentication_suite_id`, `message_type`, and `trust_domain`. `PROOF_EXCLUDED_OBJECT` is the complete validated envelope object containing every required and present field except `authentication_proof`. The proof field is the sole excluded output field: it is absent—not empty, null, normalized, or recursively represented—in the preimage. The schema/profile defines a fixed field universe/presence encoding and prohibited-field-set digest, so canonical bytes bind explicit absence of every prohibited field as well as every present field, key ID, algorithm/suite, profile/schema version, discriminator, issuer, audience, domain, identity, digest, and variant timestamp/deadline.

The sender validates the exact variant schema, constructs and canonicalizes the proof-excluded object, computes the MAC/signature/AEAD proof over that exact domain-separated byte string, then attaches one nonempty `authentication_proof` without changing any preimage field. MAC, signature, and AEAD tag/ciphertext variants all use this same preimage profile; suite-specific output encoding is profile-defined and cannot alter the semantic object.

The verifier rejects unknown, duplicate, prohibited, or missing fields; empty/null proof; noncanonical map order, serialization, Unicode normalization, numeric form, or output encoding; and unknown profile/schema/suite before interpretation. It requires the received final envelope encoding to be canonical, removes only the single `authentication_proof` field, reconstructs the exact domain separator and canonical proof-excluded bytes, resolves key/suite authorization, and verifies the proof. It MUST NOT empty-sign, restamp, normalize additional fields, recursively include proof, accept alternate serialization, or substitute key/algorithm/profile metadata. Confidential payloads use the profile's AEAD construction or equivalent authenticated encryption.

Integrity alone does not confer issuer authority. The verifier MUST resolve `key_id` through the authoritative trust registry and validate principal, role, allowed message type, exact audience, key purpose, trust domain, validity, rotation/revocation, algorithm, and domain separation. Fleet-wide symmetric verification MUST NOT confer cross-role issuer authority or verifier-forgery capability. Concrete algorithms, encodings, and vectors remain child-contract gates after these semantics.

### 7.2 Ordinary post-allocation envelope

Ordinary `task|control|ack|effect|lease|stop|destroy` variants are post-allocation and MUST add:

```yaml
lane_id: host:tmux-session
lane_incarnation_id: opaque-never-reused-id
assignment_attempt_id: exact-never-reused-attempt
reservation_id: exact-immutable-reservation
reservation_epoch: exact-reservation-version
reservation_deadline: authoritative-RFC3339
runtime_id: harness@exact-version
generation: monotonic-integer
fence_proof: authenticated-reference-or-proof
contracts_digest: sha256:...
scope_digest: sha256:...
holds_digest: sha256:...
```

Coordinator-issued authority variants MUST add primary-database `issued_at` and `expires_at`. Candidate/agent-origin ordinary ACK variants MUST NOT assert authoritative time; their freshness and acceptance use the bound Coordinator challenge/reservation deadline and the winning PostgreSQL CAS receipt time. Optional host-observation timestamps are omitted from this parent schema and, if introduced by a child schema, MUST be explicitly named non-authoritative metadata and MUST NOT affect acceptance.

Their type-specific schemas additionally bind every operation field, challenge/receipt identity, owner, lease/claim identity, and operation digest required by the relevant section. Ordinary ACK/control keys cannot sign recovery variants.

Raw fence and ownership tokens MUST never appear in logs, metrics, receipts, prompts, checkpoints, or envelope payloads. Ordinary envelopes carry a canonically authenticated proof/reference. Canonical storage retains only a keyed digest or protected secret reference where possible. Implementations define cryptographic generation, protected storage, bounded expiry, rotation, immediate revocation, constant-time comparison, and redaction. Raw material exists only within the minimum trusted mint/validation boundary and is promptly released.

### 7.3 Preallocation-free recovery challenge envelope

`message_type=recovery_challenge` is valid before the candidate has an attempt, reservation, generation, fence, ordinary challenge, READY state, lease, or effect authority. In addition to section 7.1 it MUST bind:

```yaml
recovery_candidate_id: opaque-never-reused-candidate
recovery_handoff_challenge_id: opaque-single-use-challenge
candidate_principal: exact-candidate
expected_retarget_operation: initial|pre-transfer|post-transfer
failed_target_snapshot_digest: canonical-sha256
objective_failure_evidence_digest: sha256:...
policy_selection_digest: sha256:...
scope_digest: sha256:...
holds_digest: sha256:...
contracts_digest: sha256:...
issued_at: authoritative-primary-database-time
recovery_deadline: authoritative-primary-database-time
```

Only the current leadership-valid Coordinator principal using a key authorized for the recovery-challenge purpose, exact recovery type, candidate audience, and trust domain may issue it. `recovery_deadline` is the one and only message-expiry boundary for this recovery challenge. Its canonical byte/value representation MUST be identical in the Coordinator-signed challenge, canonical challenge digest/preimage, candidate-signed ACK, PostgreSQL challenge row, winning retarget CAS predicate, and resulting receipt. Neither producer, verifier, nor CAS may normalize, restamp, minimize, maximize, derive, or substitute it. Both recovery schemas reject `expires_at`, `authoritative_deadline`, `challenge_deadline`, and every alias as unknown/prohibited alternate boundaries rather than choosing or deriving among them. Coordinator key validity, rotation, and revocation remain separate trust-registry predicates; they neither alter `recovery_deadline` nor create another message-expiry boundary.

### 7.4 Preallocation-free recovery ACK envelope

`message_type=recovery_ack` is valid only as the candidate's response to one exact recovery challenge. It MUST NOT contain or assert authoritative `issued_at`, `acknowledged_at`, `received_at`, `consumed_at`, `expires_at`, `authoritative_deadline`, `challenge_deadline`, any alias for those fields, or any candidate-host time. In addition to section 7.1 it binds the exact challenge semantics without copying its Coordinator timestamp fields as candidate assertions:

```yaml
acknowledged_recovery_message_id: exact-challenge-message
acknowledged_recovery_challenge_digest: canonical-authenticated-challenge-digest
recovery_candidate_id: exact-candidate
recovery_handoff_challenge_id: exact-single-use-challenge
candidate_principal: exact-candidate-principal
expected_retarget_operation: initial|pre-transfer|post-transfer
failed_target_snapshot_digest: exact-canonical-sha256
objective_failure_evidence_digest: exact-sha256
policy_selection_digest: exact-sha256
scope_digest: exact-sha256
holds_digest: exact-sha256
contracts_digest: exact-sha256
recovery_deadline: byte/value-identical-Coordinator-issued-primary-DB-deadline
```

The challenge digest authenticates its Coordinator-issued `issued_at`, sole `recovery_deadline`, message identity, and all other challenge fields. The candidate signs the exact challenge/candidate/snapshot facts, deadline, its own unique `message_id` and `idempotency_key`, but asserts no authoritative clock value. Only the exact `candidate_principal` using a key authorized for recovery-ACK purpose, exact Coordinator audience, recovery ACK type, and trust domain may issue it. Coordinator recovery keys cannot impersonate the candidate; ordinary ACK/control keys cannot substitute; recovery keys cannot authorize ordinary assignment, activation, continuation, claim, lease, control, or effect messages.

### 7.5 Recovery-envelope prohibitions and authority

Both recovery variants MUST explicitly exclude and reject:

```yaml
assignment_attempt_id
reservation_id
reservation_epoch
reservation_deadline
lane_id
lane_incarnation_id
runtime_id
generation
fence_proof
challenge_id
ready_state
lease_id
effect_id
execution_owner
activation_idempotency_identity
```

These facts do not yet exist for the candidate and MUST NOT be inferred from the failed target. A recovery envelope is non-authorizing: it grants no reservation, activation, execution, continuation, claim, lease, or effect authority. Its only permissible use is one authenticated input to the exact leadership-valid retarget CAS in section 6.3. Durable uniqueness, challenge consumption, snapshot equality, SOT/Coordinator authority, and idempotency are checked atomically by that CAS. Freshness is decided only by the authoritative PostgreSQL primary evaluating `db_now < recovery_deadline` against the byte/value-identical PostgreSQL challenge-row value in the winning leadership-valid CAS; equality is expired. The CAS records authoritative database `received_at` and `consumed_at` in a separate Coordinator receipt without modifying, restamping, or countersigning the candidate envelope. Candidate host time is never an authority input. Late receipt, stale SOT/Coordinator epoch, expired challenge/key, replay, wrong signer/audience, or deadline equality rejects without target allocation. Same challenge/candidate replay or concurrent consumption permits one winner; candidate, snapshot, evidence, policy, audience, role, purpose, domain, type, or idempotency substitution fails closed without canonical mutation.

## 8. Challenge-bound single-use ACK

The Coordinator mints and issues a cryptographically random, single-use ordinary `challenge_id` only after verified contract injection has durably recorded the exact contracts digest. This is the sole ordinary activation-challenge issuance rule. No ordinary challenge ID, issued challenge, or issued/unconsumed challenge state exists before verified injection; retarget, reservation, staging, process creation, and an unverified/ambiguous injection cannot allocate or reserve one. The ACK MUST cover, at minimum:

```yaml
challenge_id: single-use-random-value
sot_incarnation: exact-authority-timeline
coordinator_epoch: exact-leader-fence
reservation_id: exact-immutable-reservation
reservation_epoch: exact-reservation-version
reservation_deadline: authoritative-RFC3339
lane_id: exact-lane
lane_incarnation_id: exact-incarnation
assignment_id: exact-assignment
assignment_attempt_id: exact-attempt
generation: exact-generation
process_identity: exact-process-tree-identity
contracts_digest: exact-injected-contracts
scope_digest: exact-authorized-scope
holds_digest: exact-prohibitions-and-holds
runtime_id: harness@exact-version
proof: adapter-defined-authenticated-proof
```

The candidate-origin ordinary ACK asserts no authoritative timestamp. Any child-level host observation is non-authoritative metadata and MUST NOT influence acceptance. Freshness is determined only by decisive PostgreSQL primary time against the Coordinator-issued challenge and reservation deadlines, and the CAS records authoritative receipt/consumption times separately.

ACK acceptance requires:

- challenge exists, is unused, and both challenge and its bound reservation are strictly unexpired by decisive PostgreSQL database time;
- all bound fields exactly match Coordinator state, including current SOT incarnation, Coordinator epoch, immutable reservation ID/version/deadline, and lane incarnation;
- proof validates through the versioned adapter;
- process and session identity probes still match;
- challenge consumption, immutable ACK receipt/digest persistence, and `READY` transition occur atomically.

A replayed, duplicated, late, or mismatched ACK MUST be rejected and audited. It MUST NOT refresh or recreate a challenge. Reservation replacement, reservation expiry, or Coordinator/SOT epoch change invalidates prior `READY` authority; recovery creates a fresh reservation and fresh challenge/ACK chain. An old ACK remains audit evidence only and MUST NOT be adopted in place or authorize another reservation.

### 8.1 Handoff challenge and ACK

Handoff acknowledgement is a separate protocol from activation acknowledgement. The Coordinator MUST issue a cryptographically random, single-use handoff challenge. The target ACK MUST bind:

```yaml
handoff_challenge_id: single-use-random-value
sot_incarnation: exact-authority-timeline
coordinator_epoch: exact-leader-fence
assignment_id: exact-assignment
source_assignment_attempt_id: exact-source-attempt
target_assignment_attempt_id: exact-target-attempt
responsibility_owner: exact-current-owner
execution_owner: exact-current-effect-owner-or-null
pending_target: exact-target
next_action_digest: sha256:...
scope_digest: sha256:...
holds_digest: sha256:...
contracts_digest: sha256:...
lane_incarnation_id: exact-incarnation-if-applicable
generation: exact-generation-if-applicable
challenge_deadline: exact-Coordinator-issued-primary-DB-deadline
idempotency_key: opaque-operation-key
proof: authenticated-target-proof
```

Challenge consumption and accepted/drained handoff MUST occur in one PostgreSQL CAS transaction that verifies current SOT/Coordinator leadership by decisive database time, `responsibility_owner=source`, `execution_owner=source`, `pending_target=target`, source/target attempts, assignment, challenge unused/unexpired state, all bound digests, applicable lane incarnation/generation, source admission fenced, and prior claims dispositioned. The CAS atomically sets `responsibility_owner=target`, sets `execution_owner=NULL`, retains `pending_target=target`, and revokes/fences all source leases and admissions. The target receives no effect authority until its fresh activation CAS sets `execution_owner=target`, issues target leases and activation receipt, and clears `pending_target`. Every broker, executor, claim, reconciliation action, and receipt validates both canonical owner fields and exact state immediately before admission or transition. Replay, mismatch, expiry, or concurrent ownership change fails closed. The resulting handoff receipt transfers responsibility only; it MUST NOT grant `READY`, `RUNNING`, lease, or effect authority and MUST NOT substitute for the fresh-generation activation ACK.

## 9. Fresh-process policy and runtime capability registry

Fresh-process replacement is mandatory for Pi, Claude, Codex, OpenCode, and unknown harnesses in the initial release. Command names MUST NOT be assumed to imply semantics.

Registry entries are keyed by exact runtime and version and MUST include:

- fresh process command/template;
- process-tree/cgroup strategy;
- session and conversation identity probes;
- generation probe;
- idle probe;
- foreground-command probe;
- checkpoint and recovery probes;
- contract injection method;
- ACK protocol/proof method;
- graceful and forced stop behavior;
- deterministic descendant cleanup probe;
- staging support;
- minimum/maximum validated versions;
- adversarial test evidence digest;
- in-band reset status, default `disabled`.

Unknown version, probe disagreement, forged/unverifiable output, or missing evidence MUST fail closed.

Pi lifecycle hooks are defense-in-depth only. `session_shutdown` may not run on SIGKILL, crash, host loss, or abrupt process termination. Interactive `session_before_switch` and `session_before_fork` guards do not cover all RPC, SDK, supervisor, or external process-replacement paths. Independent process-supervisor observation, Coordinator watchdogs, process-tree cleanup, and recovery are mandatory.

In-process `/clear` or `/new` MAY be enabled in a later contract revision only when adversarial evidence proves equivalence to replacement, including distinct conversation identity, no retained task context, checkpoint/recovery safety, queue isolation, descendant handling, and stale-generation rejection.

## 10. Process-tree isolation and cleanup

Process authority MUST bind to a process tree or cgroup plus launch nonce, not PID alone. The adapter MUST:

1. create an isolated process group/cgroup where supported;
2. record root PID, start time, executable identity, cgroup/process-group identity, and launch nonce;
3. enumerate descendants before and after stop;
4. perform graceful stop within a bounded interval;
5. revoke effects before forced termination;
6. deterministically terminate remaining descendants;
7. verify no descendant retains lane resources, sockets, locks, credentials, worktree handles, or effect leases;
8. reject PID reuse as identity continuity.

Cleanup ambiguity requires quarantine.

### 10.1 Generation-bound termination receipt

Every graceful, forced, crashed, replaced, or externally observed termination MUST produce or reconcile a durable generation-bound termination receipt in PostgreSQL:

```yaml
receipt_id: opaque-unique-id
sot_incarnation: exact-authority-timeline
coordinator_epoch: exact-leader-fence
lane_id: exact-lane
lane_incarnation_id: exact-incarnation
assignment_id: exact-assignment
assignment_attempt_id: exact-attempt
responsibility_owner: exact-current-owner
execution_owner: exact-current-effect-owner-or-null
generation: exact-generation
process_identity: exact-process-tree-identity
observation_source: runtime-hook|adapter|supervisor|watchdog|coordinator
termination_reason: quit|reload|new|resume|fork|replace|crash|sigkill|timeout|host-loss|unknown
observed_at: authoritative-RFC3339
unfinished_status: true|false
next_action_digest: sha256-or-null
checkpoint_digest: sha256-or-null
handoff_state_digest: sha256-or-null
last_validated_progress_at: authoritative-RFC3339-or-null
last_progress_receipt_digest: sha256-or-null
idempotency_key: opaque-operation-key
```

Termination observations are advisory append-only facts and MUST NOT directly terminalize an assignment or prove clean shutdown. Runtime hooks and adapters MAY contribute observations, but supervisor/Coordinator watchdog observation is mandatory whenever hooks do not fire or cannot be verified. A current leadership-valid Coordinator performs one canonical reconciliation into non-effecting recovery; conflicting observations enter quarantine. Pi `reload` is always an observation/reconciliation case and MUST NOT be treated as clean shutdown. Missing or ambiguous termination, continuation injection, or inbox/result commit around reload is recovered/quarantined, never accepted as successful delivery or cleanup. A missing receipt blocks lane reuse until recovery reconciles process death, effects, descendants, checkpoint/handoff state, and assignment outcome. Receipt creation and state reconciliation MUST be idempotent and Coordinator-epoch fenced.

## 11. Checkpoint security and isolation

Checkpoints MUST be:

- access-controlled by assignment and recovery role;
- encrypted in transit and at rest when they contain sensitive material;
- content-addressed and integrity verified;
- retention-bounded with explicit deletion policy;
- redacted of credentials and unnecessary command payloads;
- inaccessible to unrelated assignments and generations;
- auditable without logging checkpoint content.

Checkpoint state MUST bind the checkpoint digest, data classification, retention-policy digest, assignment, lane incarnation, generation, and authorized recovery purpose. Handoff and activation state MUST carry these digests when checkpoint recovery is relevant. Completion conditions MUST be machine-verifiable or require a named independent-review receipt whose digest is recorded; narrative completion and agent self-claim are insufficient.

Same-assignment checkpoint recovery MUST require an explicit recovery operation bound to the assignment/attempt and authorized recovery purpose. Cross-assignment checkpoint access requires an expiring, revocable, single-use PostgreSQL recovery grant binding:

```yaml
grant_id: opaque-single-use-id
sot_incarnation: exact-authority-timeline
coordinator_epoch: exact-leader-fence
source_assignment_id: exact-source
source_attempt_id: exact-source-attempt
source_generation: exact-source-generation
checkpoint_digest: exact-content-digest
target_assignment_id: exact-target
target_attempt_id: exact-target-attempt
recovery_principal: exact-principal
recovery_role: exact-role
purpose: exact-recovery-purpose
classification: exact-data-classification
permitted_fields_digest: sha256:...
transformation_digest: sha256-or-null
retention_policy_digest: sha256:...
deadline: authoritative-database-time
```

Grant consumption and scoped access receipt MUST occur atomically and exactly once. Substitution, replay, expiry, revocation, or binding mismatch fails closed. The grant conveys neither activation nor effect authority and MUST NOT authorize general dispatch, prompt injection, unrelated checkpoint data, or additional fields. Narrative designation as a remediation assignment is insufficient without this grant.

## 12. Queue isolation

When a generation is fenced:

- all queued messages for that generation become permanently stale;
- stale messages MUST be rejected before delivery and recorded as redacted audit events;
- stale messages MUST NOT be replayed, drained, summarized, transformed, or copied into a new generation;
- queue cleanup MAY delete stale payloads after audit and retention requirements are met;
- a new generation begins with an empty assignment queue except for its own contract and challenge envelopes.

## 13. Elastic lane leasing and destruction

Elastic lanes require:

- opaque `ownership_token` whose raw value remains inside the minimum trusted validation boundary;
- lease ID and epoch;
- exact lane ID, `lane_incarnation_id`, and generation;
- owner Coordinator identity and `coordinator_epoch`;
- TTL, renewal deadline, and maximum lifetime;
- capacity and role constraints;
- destruction idempotency key.

Destruction MUST compare the exact ownership token/proof, Coordinator epoch, lane ID, lane incarnation, generation, and lease epoch atomically. A TTL worker MUST NOT destroy a lane whose ownership or generation changed. Collision or ambiguity MUST fail closed and quarantine for reconciliation.

## 14. Continuity and no-silent-parking contract

Every approved work item MUST persist:

```yaml
work_status: active|blocked|handoff|done
owner: exact-agent-or-service
next_action: executable-action
authority_allowed: [capabilities]
authority_prohibited: [capabilities]
completion_condition: evidence-required
handoff_target: exact-target-or-null
handoff_ack: null-or-coordinator-transfer-receipt
blocker_code: canonical-code-or-null
blocker_evidence_digest: sha256-or-null
last_progress_at: RFC3339-from-validated-progress-receipt
inactivity_policy: versioned-policy-id
inactivity_ttl: resolved-duration
inactivity_deadline: authoritative-RFC3339
```

Rules:

1. A prohibited capability restricts only that capability.
2. Authorized unfinished work MUST continue or be transferred through an explicit ACK.
3. Sending a message does not transfer ownership. A `handoff_ack` transfers responsibility only through Coordinator CAS; it does not grant `RUNNING`, lease, or effect authority. A replacement worker still requires fresh process/generation contract injection and the separate activation ACK from section 8.
4. `aligned`, `awaiting`, `no code authority`, and similar narrative states are not terminal states.
5. The Coordinator MUST reject approved unfinished work with no owner or next action.
6. `last_progress_at` advances only through a leadership-valid PostgreSQL CAS from a policy-validated progress receipt bound to SOT/Coordinator epoch, assignment/attempt, lane incarnation, generation, fence proof, and objective next-action evidence. Heartbeats, token output, narrative status, and agent self-claims are not progress. Watchdog transitions use the same fenced CAS and decisive database time; equality at deadline is expired, and stale/replayed progress cannot extend authority.
7. Each versioned inactivity policy MUST freeze warning, escalation, retry, reassignment, and quarantine thresholds; idempotency behavior; maximum attempts; and retry-exhaustion outcome. `blocked` still requires an owner, objective blocker evidence, and an executable unblock or next action. Policy exhaustion enters explicit blocked/quarantine review rather than silent parking.
8. Runtime adapters SHOULD emit an `authorized_work_unfinished` lifecycle event only at the runtime's verified settled boundary—not merely at turn or low-level agent-run end.
9. For Pi, continuity evaluation MUST use `agent_settled`, not `agent_end` or `turn_end`, because retries, compaction retries, and queued follow-ups may remain after `agent_end`. A turn-end heartbeat such as `ok` means only that no turn is currently active; it MUST NOT imply assignment completion.
10. Pi `session_shutdown` MAY report `quit`, `reload`, `new`, `resume`, or `fork` as advisory audit observations, but MUST NOT be treated as a cancellable guard or clean-shutdown proof. Unsafe `/new` or `/resume` replacement MUST be blocked through `session_before_switch`; unsafe `/fork` or `/clone` MUST be blocked through `session_before_fork`.
11. A Pi extension MUST NOT compose or infer continuation content. Continuations use durable PostgreSQL states `PENDING -> CLAIMED -> DELIVERY_ACCEPTED -> RESULT_RECORDED`, with claim token, claimant Coordinator/SOT epoch, database deadline, attempts, recovery owner, and fenced renewal/reclaim CAS. The Coordinator writes one validated, signed envelope binding SOT/Coordinator authority, assignment/attempt, reservation, lane incarnation, generation/fence, next action, scope/holds/contracts, expiry, loop budget, and result/ACK destination. Logical acceptance and loop-budget debit occur in one PostgreSQL transaction and deduplication is durable before prompt visibility. After claim and immediately before injection, the claimant MUST revalidate SOT/Coordinator authority, generation/incarnation/fence, claim ownership/deadline, and queue state. The receiver MUST reject stale generation/fence at acceptance, including in-flight delivery. Result and inbox completion are atomic where both are PostgreSQL facts; each continuation effect has its own deterministic `effect_id` and uses mandatory effect mediation. If prompt injection/visibility is ambiguous, the same generation is quarantined or replaced rather than blindly reinjected. At-least-once claim delivery is permitted; exactly-once logical acceptance/debit and effect idempotency are required. Generic PTY visibility is not claimed atomic with PostgreSQL. Adapter crash/restart, stale claimant resume, and reclaim MUST NOT create a second accepted exposure or duplicate effect; Coordinator watchdog owns retry, exhaustion, replacement, and recovery.
12. Pi extension errors are non-fatal; therefore, extension signals are advisory evidence and MUST NOT become canonical authority or the sole continuity mechanism.
13. Claude, Codex, and OpenCode adapters MUST provide continuity semantics equivalent to Pi, including the same PostgreSQL outbox/inbox claim/result and exactly-once logical-processing protocol: verified settled/idle evidence, abrupt-termination observation independent of optional hooks, one bounded Coordinator-signed continuation where supported, duplicate suppression across adapter restart, partial-authority continuation, and strict separation of handoff from activation. Unknown lifecycle semantics fail closed to supervisor/watchdog replacement, quarantine, or reassignment.
14. The Coordinator, not the harness, decides whether continuation, restart, or reassignment occurs.

## 15. Authoritative time and expiry

Only the authoritative PostgreSQL primary's database time is authoritative for issued-at, expiry, renewal, activation, transfer, destruction, challenge/ACK, lease/claim, TTL, and watchdog decisions. The decisive statement/CAS MUST evaluate database time at decision/commit; a transaction-start timestamp reused after a blocking interval is insufficient. Authority validation MUST NOT use a replica. Adapter, agent, executor, host wall clock, and cached database time MUST NOT create, renew, or extend authority. Equality at a deadline is expired.

- Persist absolute primary-evaluated deadlines with each durable receipt; monotonic host clocks MAY schedule local wakeups but confer no authority.
- An acknowledged authority commit MUST be durable before success is reported.
- Promotion MUST fence the old writable primary and prove preservation of acknowledged authority history before effects resume; otherwise authority/effects remain denied.
- PITR, uncertain WAL loss, database cluster replacement, rollback, or unproven history continuity MUST advance a non-rollbackable external `sot_incarnation` trust anchor, rotate/fence authority credentials, invalidate pre-event reservations/challenges/ACKs/leases/effect claims, and quarantine/reconcile nonterminal assignments before effects resume.
- The external anchor stores authority-incarnation/fencing metadata only and MUST NOT become a second writable assignment/orchestration SOT.
- Define a maximum accepted transport clock skew for message rejection tolerance only; it MUST NOT extend an authoritative deadline.
- Expiry, renewal, transfer, destruction, activation, and watchdog races resolve through fenced PostgreSQL CAS against primary database time and current SOT/Coordinator authority.
- If old-primary fencing, acknowledged-history durability, external incarnation continuity, or authoritative time is unproven, the safe result is fail-closed unavailability.

## 16. Threat model

### Protected assets

- assignment authority;
- repository and external side-effect authority;
- task and checkpoint confidentiality;
- lane availability;
- audit integrity;
- scope and hold enforcement;
- cross-site coordination integrity.

### Adversaries and failure sources

- stale or contaminated agent context;
- compromised or hallucinating agent;
- replaying transport participant;
- stale gateway or executor;
- forged runtime probe;
- PID reuse and orphan descendants;
- Coordinator crash or duplicate Coordinator;
- lease races and delayed TTL cleanup;
- accidental checkpoint disclosure;
- operator or automation message sent to the wrong lane/generation.

### Required controls

- monotonic generation and opaque fence token;
- challenge-bound single-use ACK with persisted consumed-receipt state;
- atomic RUNNING/effect-lease/activation-receipt commit;
- mandatory canonically authenticated discriminated envelope union with one noncircular proof-excluded preimage profile, preallocation-free recovery variants, DB-time candidate freshness, prohibited-field rejection, purpose-separated keys, and substitution resistance;
- durable continuation outbox/inbox with at-least-once delivery and exactly-once logical processing;
- mandatory deny-by-default mediation, durable claim admission, fencing, sink classification, and reconciliation before protected effects;
- PostgreSQL-rooted Coordinator epoch acquisition and takeover;
- explicit responsibility/execution/pending-target ownership transitions with null-execution no-effect state;
- leadership-valid exact-snapshot preactivation retarget with objective failure evidence, preallocation-free candidate/recovery ACK, intervening-mutation invalidation, complete failed-target authority fencing, and winning-CAS fresh-target allocation;
- unique externally anchored genesis, one-time import, complete retirement, and competing-initialization rejection;
- executor-local fence validation;
- authenticated/versioned probes;
- atomic CAS transitions and idempotency keys;
- process-tree/cgroup identity;
- least-privilege staging;
- queue isolation;
- encrypted, scoped, retention-bounded checkpoints;
- redacted receipts;
- split-brain Coordinator fencing at storage and executor boundaries;
- lane-incarnation fencing across delete/recreate cycles;
- authoritative time and monotonic timeout handling;
- registered executor inventory with no stale-cache authority;
- deterministic quarantine and recovery.

## 17. Mandatory adversarial tests

Implementation authorization MUST NOT be granted until test specifications exist for all cases. Canary authorization MUST NOT be granted until all tests pass in isolated environments.

| Test | Required assertion |
|---|---|
| Replayed ACK | second/late ACK rejected; no state or lease change |
| PID reuse | reused PID cannot satisfy process identity or generation probe |
| Orphan child process | descendant detected, effects revoked, cleanup completed or lane quarantined |
| Stale executor request | executor rejects stale generation/fence even if gateway previously accepted it |
| Coordinator crash at every swap step | recovery is idempotent; never two active generations; no ambiguous RUNNING |
| Lease-transfer race | only CAS winner receives authority; loser is fenced and audited |
| Checkpoint disclosure | unrelated generation cannot enumerate, read, infer, or receive checkpoint material |
| Forged idle/identity probe | conflicting or unauthenticated probe fails closed |
| TTL destroy collision | stale TTL worker cannot destroy renewed/reassigned lane |
| Old queued message | old message rejected/audited and never delivered to new generation |
| Forged ACK fields | mismatch in task, generation, digest, scope, holds, process, or runtime rejected |
| Staging write attempt | side-effect executor denies all staging effects |
| Fence revocation race | revoked token denied at executor despite in-flight transport |
| Duplicate activation request | idempotent receipt returned; no duplicate leases/effects |
| Split-brain Coordinator | only fenced leader can reserve/activate |
| Partial-authority continuation | design work continues when code/issue/live capabilities are prohibited |
| Unacknowledged handoff | ownership remains with sender and inactivity watchdog fires |
| Stale Coordinator epoch | split-brain storage mutation, lease, ACK consumption, receipt, and executor effect are rejected |
| Lane reincarnation | delete/recreate under same lane name cannot reset generation or accept stale incarnation authority |
| Raw token leakage/timing | no raw token appears in observability; comparisons are constant-time within defined boundary |
| Premature completion | completion before final receipt/effect release is rejected; cleanup failure quarantines |
| Fake progress heartbeat | heartbeat/narrative/token output cannot advance `last_progress_at` |
| Blocked without evidence | blocked claim rejected without owner, objective evidence, and executable next action; retry exhaustion is explicit |
| Handoff/activation confusion | handoff ACK cannot activate generation or grant effect lease |
| Clock rollback/skew | rollback, excessive skew, and expiry race cannot extend authority |
| Unknown executor | unregistered effect path and stale authorization cache both fail closed |
| SIGKILL lifecycle loss | absence of `session_shutdown` is detected by supervisor/watchdog and recovered safely |
| Duplicate Pi continuation | extension restart/redelivery returns the existing logical receipt, cannot duplicate effects, and cannot exceed loop budget |
| Consumed activation ACK | READY validates persisted consumed ACK receipt; activation neither requires unused challenge nor accepts another receipt |
| Activation/lease crash | crash before/after atomic commit yields either no RUNNING/effects or one RUNNING state with exact leases and receipt |
| Envelope field substitution | issuer/audience/type/ID/digest/timestamp/idempotency substitution and non-canonical encoding fail authentication |
| Canonical authentication preimage matrix | proof substitution, algorithm/key/profile/schema substitution, empty-vs-absent proof, alternate map order/serialization/Unicode/numeric form, duplicate/unknown fields, and recursive-proof attempts all reject; verifier removes only proof and reconstructs one exact domain-separated preimage |
| Continuation injection crash | durable outbox redelivers at least once while inbox/effect idempotency processes logically once |
| Revoked cached lease | cached cryptographic proof fails online authoritative revocation/current-owner validation |
| Coordinator epoch takeover | concurrent acquisition, ambiguous commit, credential rotation, stale renewal, and takeover produce one current epoch |
| Prior-owner handoff effect | prior owner is fenced in ownership-transfer CAS and cannot execute effects afterward |
| Authority-owner handoff binding | for every handoff ACK, source revocation, claim reconciliation, and target activation interleaving: exactly one responsibility owner; execution owner is source only before transfer, null during drain/replacement, and target only in activation/lease CAS; pending target retained until activation; all owner mismatches reject |
| Pre-transfer exact-snapshot race matrix | at every T preactivation boundary, construct U ACK for snapshot N then apply one T mutation to lifecycle/attempt/generation/incarnation/reservation/lease/deadline/challenge-consumption/ACK/READY/fence/outbox/inbox/continuation/activation-idempotency/other mutable field: stale retarget makes no mutation; reverse ordering lets retarget win and every late T artifact rejects |
| Recovery-candidate allocation matrix | construct U ACK before U attempt/generation/reservation exists; race replay, U failure, two candidate IDs, leadership takeover/expiry, and T->U->V recovery: one recovery challenge/ACK consumption and fresh allocation wins, candidate state grants no authority, stale candidates reject, and only subsequent ordinary current-target ACK/activation establishes execution/effects |
| Recovery-envelope replay/concurrency | duplicate/concurrent `recovery_ack` consumption under same challenge/candidate/idempotency key yields one CAS winner and no duplicate target allocation |
| Recovery key/audience/domain matrix | wrong audience, principal, key role, purpose, trust domain, validity, or revocation state rejects before retarget state use |
| Recovery/ordinary type confusion | ordinary ACK/control keys and schemas cannot sign recovery types; recovery keys/envelopes cannot authorize ordinary assignment/control/activation/effects |
| Recovery candidate substitution | candidate ID/principal/challenge/message/idempotency substitution fails canonical authentication and exact CAS binding |
| Recovery snapshot/evidence/policy substitution | failed-target snapshot, operation, objective evidence, deterministic policy, scope, holds, or contracts substitution fails without mutation |
| Recovery prohibited-field injection | any attempt/reservation/lane/runtime/generation/fence/ordinary-challenge/READY/lease/effect/execution/activation field in a recovery envelope is rejected, not ignored |
| Recovery deadline consistency | mismatched candidate tuple/record, signed challenge, signed ACK, canonical challenge or ACK digest/preimage, PostgreSQL row, CAS, or receipt `recovery_deadline` rejects without allocation; no omission, translation, normalization, restamp, derivation, min/max, or substitution is permitted |
| Recovery alternate-boundary injection | `deadline`, `expires_at`, `authoritative_deadline`, `challenge_deadline`, or any alias in the candidate tuple/record, recovery challenge, or recovery ACK rejects as an unknown/prohibited field rather than mapping or selecting a boundary |
| Recovery deadline boundary | primary `db_now` before the one recovery deadline may pass other predicates; equality and after reject; concurrent/replayed receipts straddling the boundary yield at most one pre-deadline winner |
| Recovery key/deadline independence | Coordinator key validity/rotation/revocation and message `recovery_deadline` are independently required predicates; neither substitutes for, extends, or derives the other |
| Recovery expiry/takeover | expired sole deadline or stale SOT/Coordinator epoch/key rejects challenge/ACK/CAS and allocates no target chain |
| Candidate ACK DB-time freshness | candidate clock skew cannot affect acceptance; late receipt, Coordinator restamp/countersign attempt, replay, wrong signer/audience, stale epoch/key, and `db_now == recovery_deadline` reject; only primary-DB receipt-time CAS records authoritative received/consumed time |
| Recovery envelope both-order retarget races | for initial/pre/post-transfer with one byte/value-identical `recovery_deadline`, mutation-first invalidates recovery ACK/CAS; retarget-first consumes one ACK, fences failed target, and rejects every late authority artifact |
| Initial-assignment retarget matrix | at every initial boundary from RESERVED through activation attempt, bind null source attempt/handoff receipt and race T mutation versus retarget: mutation-first invalidates snapshot-N ACK/CAS; retarget-first rejects all T authority; exactly one U chain is allocated and execution remains null until ordinary U activation |
| Post-injection ordinary challenge ordering | crash at retarget allocation, process creation, injection/probe, and challenge issuance: no ordinary challenge ID/issued challenge exists before verified exact-contract-digest injection; failed/ambiguous injection yields no challenge/READY/lease; only post-injection challenge may be ACKed and activate |
| Preactivation retarget/activation race | at every T boundary race objective failure, candidate ACK, retarget CAS, late T messages, and T activation: T-first forces RUNNING handoff; retarget-first fences T; pre-transfer yields `(S,S,U)`, post-transfer `(U,NULL,U)`, and only fresh U activation yields `(U,U,NULL)` |
| Dependency-gate bypass | terminal parent approval/implementation rejected until #758/#766 and selected root have terminal digest-pinned acceptance; unauthorized child work remains held |
| Leadership expiry at mutation | pause immediately before every mutation class across expiry/takeover; old authority makes no mutation and nonterminal work recovers/quarantines |
| Primary timeline fault | stale replica, dual primary, delayed promotion, non-durable ACK, and PITR at each boundary never validate old-history effects |
| Reservation-chain substitution | expire R1 before ACK and after READY, create matching R2; R1 ACK/READY cannot authorize R2 |
| Effect admission race | race revoke/takeover/handoff/destroy at pre-claim, post-claim, pre-dispatch, sink-accepted, and post-sink/pre-receipt; outcome is denied, ordered, reconciled, or quarantined |
| Effect mediation bypass | direct filesystem/provider/credential/socket/inherited-FD/egress attempts cannot reach protected sinks |
| Idempotency operation substitution | same key/same digest returns original result; same key/different digest rejects/quarantines |
| Continuation visibility fault | kill adapters around claim/reclaim/injection/acceptance/result/inbox; one acceptance/debit and classified effects, or replacement/quarantine |
| Stale continuation claimant | old claimant resumed after reclaim fails post-claim/pre-injection and receiver fences |
| Nonterminal replacement crash | crash every handoff/drain/ownership/replacement/activation boundary; one responsibility owner, at most one effect owner, no old-generation reactivation |
| Pi reload ambiguity | reload around injection and inbox/result commit never proves clean termination or blindly reinjects |
| Watchdog deadline race | progress before/equal/after deadline is policy validated; stale/replayed progress cannot extend authority |
| Checkpoint grant bindings | substitute/replay/expire/revoke each source/target/principal/purpose/classification/field/retention/deadline binding; one scoped receipt only |
| Key role/domain confusion | every valid role key signs every disallowed issuer/type/audience/purpose/domain combination; all reject before state/effects |
| Bootstrap empty environment | every consumed receipt traces to the externally anchored genesis authority; import occurs once; retired bootstrap credentials cannot mutate authority/effects |
| Competing foundation actors | actors A/B race distinct valid-looking foundations; atomic anchor slot accepts one manifest and rejects/audits the other without second SOT/incarnation |
| Unauthorized genesis signer/verifier | self-authorized, wrong-role, wrong-domain, substituted, or unpinned signer/verifier/importer is rejected before anchor or import |
| Replayed genesis | replay of manifest/import nonce/import receipt after anchor consumption cannot create, import, or mutate authority |
| Ambiguous one-time import | crash/timeout around PostgreSQL import reconciles to one anchored manifest and unique receipt, never a second foundation/incarnation |
| Incomplete retirement | missing/partial/ambiguous retirement attestation leaves runtime/dependency/parent authority denied and bootstrap keys unable to proceed |
| Cross-harness settled/idle parity | Claude, Codex, Pi, and OpenCode cannot report completion while retry, compaction, follow-up, foreground work, or queued continuation remains |
| Cross-harness abrupt termination | missing/optional hooks cannot suppress supervisor/watchdog termination receipt and recovery |
| Cross-harness bounded continuation | only exact Coordinator-signed continuation is delivered; loop budget and expiry are enforced |
| Adapter restart duplicate suppression | persisted idempotency state prevents duplicate continuation after any adapter restart |
| Cross-harness partial authority | authorized design/contract work continues while prohibited code/issue/live capabilities remain denied |
| Cross-harness handoff separation | handoff ACK never grants activation or effects for any harness |
| Unknown lifecycle semantics | unknown runtime/version fails closed to supervised replacement, quarantine, or reassignment |

## 18. Observability and receipts

Required metrics and events include:

- active generation per lane;
- generation replacement count and latency;
- stale envelope rejection count by type;
- ACK rejection reason category;
- executor fence denials;
- checkpoint creation/recovery/deletion receipts;
- generation-bound termination receipts by observation source and reason;
- orphan descendant detection;
- quarantine entry/recovery;
- lease expiry, renewal, transfer, and collision;
- authorized-work inactivity and reassignment;
- token usage before and after context-boundary enforcement.

Logs and receipts MUST NOT contain raw prompts, context, fence/ownership tokens, credentials, secrets, checkpoint bodies, or privileged command bodies. Correlation uses opaque IDs and digests.

## 19. Delivery sequence

### 19.1 Selected unique external genesis and bootstrap root

Because no actual compatible Path-A root is pinned in this parent input, v1.3 selects the bootstrap path. Bootstrap begins from one pre-existing, organization-controlled external genesis authority—not from bootstrap actors or their self-signed receipts. Before initialization, parent approval inputs MUST digest-pin:

```yaml
genesis_authority_id: globally-unique-organizational-root
genesis_trust_domain: exact-domain
genesis_verifier_key_digest: sha256-of-offline-root-public-key
environment_id: globally-unique-target-environment
external_anchor_namespace: unique-environment-slot
foundation_schema_digest: exact-schema-and-version
postgres_cluster_identity: intended-cluster-identity
initial_sot_incarnation: never-reused-initial-incarnation
initial_verifier_keyset_digest: exact-runtime-verifier-set
authorized_importer_principal: exact-one-time-importer
bootstrap_receipt_set_digest: exact-design-receipts
retirement_policy_digest: exact-one-way-retirement-policy
```

The external genesis authority signs one canonical genesis manifest binding every field above, the one foundation/SOT identity, initial verifier roles/purposes/audiences, one-time import nonce, allowed import digest, and required retirement attestation. The external non-rollbackable anchor MUST authenticate the genesis root and perform atomic create-if-absent on the unique `(genesis_trust_domain, environment_id, external_anchor_namespace)` slot. The first valid manifest digest wins permanently. Any competing actor, foundation, cluster, schema, verifier, incarnation, importer, or replay for the occupied slot is rejected and audit-recorded. No bootstrap actor may authorize itself, another signer, the verifier set, or a competing foundation.

The authorized importer MUST verify the anchored manifest and all immutable signed non-authoritative design receipts, then perform one PostgreSQL transaction creating the exact foundation/schema, SOT identity, initial verifier registry, and initial SOT incarnation and importing the exact allowed receipt set. The transaction emits a unique one-way import receipt bound to the genesis manifest digest, anchor receipt, imported digest, importer principal, PostgreSQL cluster identity, database time, and idempotency key. Ambiguous import is reconciled by reading the anchored slot and PostgreSQL unique receipt; it MUST NOT create or select a second foundation/incarnation.

After verified import, the genesis authority and importer produce a retirement attestation binding the import receipt and proving bootstrap mutation capability/key revocation or destruction. The external anchor atomically marks the slot `CONSUMED`, pins the retirement-attestation digest, and rejects replay or further import. Parent approval MUST verify both import and complete-retirement receipts. Incomplete or ambiguous retirement leaves all runtime authority denied.

Genesis/bootstrap keys MUST NOT authorize assignments, reservations, leases, challenges/ACKs, continuations, effect claims, runtime mutation, or dependency acceptance except the narrowly scoped one-time foundation/import/retirement operations above. The external anchor stores genesis, incarnation, import, retirement, and fencing metadata only; it MUST NOT store or mutate assignment/orchestration state and MUST NOT become a second writable SOT.

Parent approval MUST NOT become terminal and implementation MUST NOT begin until #758 and #766 have terminal acceptance receipts pinned to exact artifact/tree digests, independent review evidence, and closed dependency status in the bootstrapped PostgreSQL authority root. Every consumed receipt must trace to the anchored genesis authorization chain. Genesis-manifest, anchor, import, retirement, dependency, and parent-contract digests MUST be bound into the parent approval CAS. A narrative GO, partial tests, mutable branch, open review, REQUEST CHANGES, competing initialization, unauthorized signer/verifier, replayed genesis, ambiguous import, or incomplete retirement does not satisfy the gate. Neither dependency currently has terminal digest-pinned acceptance, so v1.3 can receive content-review disposition only.

Child drafting/review MAY precede operational approval only under explicit separate authority, but remains non-operational and MUST NOT weaken these gates; implementation may not. Under this lane's current authority, child-contract drafting remains held.

1. Digest-pin the external genesis inputs; atomically anchor the unique manifest; complete the authorized one-time PostgreSQL foundation/import; and pin complete bootstrap-key retirement attestation.
2. Obtain terminal digest-pinned acceptance for #758 and #766 under that root.
3. Terminally approve this parent contract and threat model by content digest plus authority-root and dependency-receipt digests.
4. Under separately granted authority, define child contract for capability registry and fake-harness probes.
5. Define child contract for Coordinator FSM, CAS transitions, fencing, ACKs, receipts, effect mediation, and continuity watchdog.
6. Define child contract for stable-lane fresh-process replacement.
7. Define child contract for elastic TTL leases and exact-token destruction.
8. Define monitoring, runbook, and cross-harness adversarial E2E contracts.
9. Authorize isolated canary and rollback only after all prerequisite evidence is terminal green.

The eventual parent epic MUST remain separate from #758 and #766 while linking both as prerequisites/dependencies.

## 20. Parent guarantees, child deferrals, and rejected guarantees

### 20.1 Safe child-contract deferrals

After the parent semantics are content-approved and separate child-drafting authority is granted, child contracts may define exact PostgreSQL schema/index/locking statements; HA product/topology and runbook; cryptographic algorithms, canonical encoding, timestamps, and golden vectors; confinement/sandbox technology; sink-specific cancellation/reconciliation; termination-observation precedence and receipt columns; watchdog progress sequence/CAS tuple/retry/fairness bounds; runtime-specific adapter mechanics; and bootstrap key custody/import SQL. These remain implementation blockers and MUST NOT substitute for parent guarantees or dependency gates.

### 20.2 Rejected impossible or unsafe guarantees

This contract explicitly rejects:

1. treating online validation immediately before an effect as a complete physical revocation fence without mediated admission and reconciliation;
2. claiming revocation instantaneously cancels an already-started arbitrary external call without sink support;
3. holding PostgreSQL transactions/locks across arbitrary external I/O to simulate atomic sink completion;
4. blindly retrying after ambiguous prompt visibility or ambiguous non-idempotent sink outcome;
5. claiming generic PTY/provider visibility is atomically coupled to PostgreSQL;
6. promising eventual handoff when an unsupported/non-queryable sink remains ambiguous—durable quarantine may be indefinite;
7. treating the external non-rollbackable SOT-incarnation anchor as a second writable assignment/orchestration SOT.

Availability is conditional. Primary/time/anchor outage, missing recovery capacity, unsupported hung sinks, or ambiguous visibility may produce durable blocked/quarantined work, never cached authority or a liveness bypass.

## 21. Acceptance criteria for parent-contract approval

- [ ] Local and Homelab leads reconstruct identical content and verify its digest.
- [ ] The unique external genesis authority, trust domain/key digest, environment/anchor slot, foundation/schema/cluster, initial verifier/incarnation, importer, receipt set, and retirement policy are digest-pinned.
- [ ] Atomic create-if-absent anchor selection rejects competing foundations; one-time import and complete key-retirement attestations are pinned before runtime authority.
- [ ] #758/#766 terminal acceptance receipt digests trace to the anchored genesis chain and are bound before terminal parent approval or implementation.
- [ ] Component authority boundaries are explicit and non-overlapping.
- [ ] PostgreSQL is explicitly the sole writable canonical assignment/orchestration SOT; all caches, projections, adapters, providers, files, browsers, roster, and transport are non-authoritative.
- [ ] Every canonical mutation is leadership-valid by decisive primary database time and current SOT incarnation.
- [ ] Coordinator epoch acquisition/takeover, credential binding, renewal/expiry, ambiguous-commit recovery, rotation/revocation, and effect-admission validation are rooted transactionally in PostgreSQL.
- [ ] Primary failover, durability, replica denial, PITR/rollback, and non-rollbackable SOT-incarnation fencing fail closed when continuity is unproven.
- [ ] Transaction isolation, uniqueness, and Coordinator-epoch fencing are defined.
- [ ] Lane reincarnation prevents generation collision after delete/recreate.
- [ ] Token/proof storage, rotation, revocation, comparison, expiry, and redaction are defined.
- [ ] Challenge, ACK, persisted receipt, READY, and activation bind one immutable reservation ID/version/deadline plus current SOT/Coordinator authority.
- [ ] FSM validates the persisted consumed activation-ACK receipt without contradictory unused-challenge state or cross-reservation adoption.
- [ ] RUNNING, effect leases, and activation receipt commit atomically under a non-effect reservation lease.
- [ ] Deny-by-default confinement makes protected effects impossible outside registered mediation.
- [ ] Durable effect admission claims bind all authority/operation identities; fencing closes admission; ambiguous sink outcomes reconcile or quarantine without blind retry.
- [ ] Handoff/destruction/finalization/transfer cannot complete effect authority while prior claims are unresolved except durable quarantine.
- [ ] Every envelope uses one versioned canonicalization/schema/suite profile and a domain-separated preimage containing every present/required field and prohibited-field absence except the sole excluded nonempty `authentication_proof` output.
- [ ] Sender attaches proof without changing preimage fields; verifier removes only proof, reconstructs exact canonical bytes/domain, resolves key/suite authorization, and rejects alternate serialization, duplicate/unknown fields, empty/absent/recursive proof, and algorithm/key/profile substitution.
- [ ] Every envelope is a canonically authenticated discriminated-union variant with exact required/optional/prohibited fields and substitution resistance.
- [ ] Ordinary post-allocation variants require attempt/reservation/generation/fence authority fields; preallocation-free recovery variants exclude and reject them.
- [ ] `recovery_challenge` and `recovery_ack` bind candidate/challenge, complete snapshot/evidence/policy/scope/holds/contracts, SOT/epoch, assignment, issuer/audience/key/domain, the sole `recovery_deadline`, type, proof, and idempotency identity.
- [ ] Recovery challenge issuance is limited to the current Coordinator recovery-purpose key and binds primary-DB `issued_at` plus exactly one `recovery_deadline`; recovery ACK issuance is limited to the exact candidate's recovery-ACK-purpose key and asserts no authoritative timestamp.
- [ ] Candidate tuple/record, challenge, challenge/ACK digest and preimage, ACK, PostgreSQL row, CAS, and receipt use one primary-DB-generated byte/value-identical `recovery_deadline`; alternate fields/aliases reject without omission, translation, normalization, restamp, derivation, min/max, substitution, or selection.
- [ ] Recovery ACK freshness is decided only by leadership-valid primary `db_now < recovery_deadline`; equality is expired, authoritative received/consumed times live in a separate Coordinator receipt, and restamping/countersigning candidate payload is forbidden.
- [ ] Ordinary and recovery keys/types cannot substitute across roles, purposes, audiences, trust domains, or authority classes.
- [ ] Recovery envelopes are non-authorizing and usable only as one single-use input to the exact winning retarget CAS; replay/concurrency permits one allocation.
- [ ] Key authorization binds principal, role, type, audience, purpose, trust domain, validity, revocation, algorithm, and domain separation before field use.
- [ ] Challenge-bound ACK is reservation-complete, single-use, replay resistant, and invalidated by reservation/SOT/Coordinator replacement.
- [ ] Process-tree/cgroup and descendant cleanup requirements are explicit.
- [ ] Staging has no write/effect leases.
- [ ] Checkpoint security, retention, and assignment isolation are defined.
- [ ] Cross-assignment checkpoint recovery requires an expiring, revocable, single-use, fully bound PostgreSQL grant consumed atomically with its access receipt.
- [ ] Continuation claim/visibility fencing covers post-claim, immediately-pre-injection, receiver acceptance, stale claimant, reclaim, and ambiguous visibility boundaries.
- [ ] Old queues and in-flight deliveries cannot contaminate new generations.
- [ ] Elastic destruction requires exact ownership token and generation.
- [ ] Monitoring and receipts are redacted.
- [ ] All mandatory adversarial tests have required assertions.
- [ ] Continuity/no-silent-parking behavior is included for Pi and other harnesses.
- [ ] Canonical continuity state persists resolved TTL/deadline, handoff target, blocker code, and blocker evidence in addition to policy identity.
- [ ] Progress truth, blocked evidence, retry limits, and watchdog policy are deterministic.
- [ ] Handoff uses a single-use Coordinator challenge and atomic responsibility-transfer CAS that sets execution owner null, retains pending target, and fences source effects; only target activation sets execution owner target and clears pending target.
- [ ] Every broker, executor, claim, reconciliation action, and receipt binds canonical responsibility/execution owners; no effect claim is allowed while execution owner is null.
- [ ] The FSM provides a nonterminal replacement route with exactly one responsibility owner, at most one execution owner, named recovery ownership, and no false terminalization.
- [ ] Leadership-valid pre-transfer `(S,S,T)->(S,S,U)` and post-transfer `(T,NULL,T)->(U,NULL,U)` retarget CASes bind objective failure evidence, deterministic policy selection, single-use preallocation-free candidate ACK, and the complete exact failed-target snapshot with every mutable preactivation field as value or null.
- [ ] Any intervening failed-target mutation invalidates the recovery snapshot/ACK/CAS and requires fresh evidence, selection, candidate ID, challenge, snapshot, and ACK.
- [ ] The winning retarget CAS alone consumes one recovery ACK and allocates fresh target attempt/generation/reservation/fence plus non-authoritative staging/injection work; candidate state grants no authority.
- [ ] Initial retarget binds `expected_retarget_operation=initial`, null source-attempt/handoff provenance, complete T snapshot, and both race orderings from RESERVED through activation attempt.
- [ ] Only after verified target contract injection records the exact contracts digest may the Coordinator mint/issue the ordinary activation challenge; allocation/process/injection failure yields no challenge/READY/lease.
- [ ] Replay, candidate failure, two-candidate race, takeover/expiry, and T->U->V recovery yield at most one consumed challenge/allocation and never candidate execution/effects.
- [ ] Retarget atomically fences every failed-target preactivation authority artifact, preserves null execution after transfer, and requires fresh U activation for `(U,U,NULL)` and leases.
- [ ] Late T activation and retarget are mutually exclusive: T-first uses RUNNING handoff; retarget-first rejects all stale T messages and activation authority.
- [ ] Authoritative time, skew, rollback, and expiry races fail closed.
- [ ] Executor inventory is complete and stale caches cannot authorize.
- [ ] Termination observations are advisory; current-leader reconciliation is non-effecting and conflict-safe; Pi `reload` and abrupt termination never imply clean shutdown.
- [ ] Continuation uses durable PENDING/CLAIMED/DELIVERY_ACCEPTED/RESULT_RECORDED state, fenced claim/reclaim, pre-visibility dedupe, one acceptance/debit, receiver fencing, deterministic effect IDs, and quarantine/replacement on ambiguity.
- [ ] Claude, Codex, Pi, and OpenCode pass equivalent continuity and handoff/activation conformance cases; unknown semantics fail closed.
- [ ] Checkpoint and completion evidence digests are bound into relevant state.
- [ ] No implementation, issue, or live authority is inferred from contract approval.

## 22. Non-goals

This contract does not:

- authorize implementation;
- authorize issue creation or mutation;
- authorize deployment or canary activity;
- standardize one harness’s slash commands;
- permit in-process reset in the initial release;
- make tmux, transport, Valkey, or roster the canonical assignment authority;
- expose checkpoint or conversational content through monitoring.