computedriven computedriven/docs/placement-activation-model.md
R6.1 closed F87: the transport may copy the bytes, the transfer authority is consumed once, and the frozen R0.8 layer supplies that authority. Its crash battery then found a sta…

R6.2 placement-activation model — written before the mechanism

R6.1 closed F87: the transport may copy the bytes, the transfer authority is consumed once, and the frozen R0.8 layer supplies that authority. Its crash battery then found a state the model could only name and never continue from: a claimant that dies after its claim is recorded leaves the placement saying resident on a floor that holds nothing, and the model refuses every continuation because it cannot tell that history from one in which the holder installed, acted, and died. GPT's ruling on R6.1 turns that into the next round:

Exclusive claim is not permission to execute. Two histories that require different legal futures may not share a stored state.

This document fixes the vocabulary R6.1 got wrong, introduces the two things the crash windows showed are missing — a floor incarnation and an activation barrier — and states, before anything is built, how both are encoded on the frozen substrate, which recoveries become legal, and what falsifies it.

0. Standing rulings adopted from R6.1 (permanent)

  • physical core ≠ floor ≠ Carrier ≠ Locus;

  • relocating a Locus is not Carrier succession and does not advance its

lifecycle generation;

  • transport delivery ≠ transfer authority;

  • transfer authority is coherent per Locus / per placement lineage —

never one system-wide serialization point; disjoint Loci stay independently movable;

  • per-core floors share no mutable semantic state;

  • R0.8 is the durable / fork-refusal substrate of placement authority.

"Placement is lifecycle one rung up" was experimentally sufficient for R6.1 and is not canonized: this round determines the minimal placement algebra the crash windows require.

1. Vocabulary, corrected

R6.1's RESIDENT(F) did two jobs: the authoritative holder assignment and the physical presence of state on F. The battery caught it doing the first without the second twice (a source after MOVE_OUT, a claimant after a recorded claim). Split them:

authority-side phase (what the placement lineage knows)     materialization (what the floor holds)
  ACTIVE(F, I)      this incarnation may execute L             INSTALLED | NOT_INSTALLED | UNKNOWN (floor dead)
  CLAIMED(F, I, m)  transfer m consumed by (F, I); no execution authority yet
  IN_TRANSFER(m)    relinquished; one admissible claim outstanding

RESIDENT is retired. R6.1's RESIDENT_HOLDER_UNINSTALLED was the observed predecessor of `CLAIMED_UNINSTALLED`, which this round makes a real, distinguishable, recoverable state. whereis(L) answers a phase; the harness reports materialization beside it, never inside it.

2. Floor incarnation

FloorId              the stable execution-domain identity          F1
FloorIncarnationId   one concrete live incarnation of that floor    I17, then I18 after a restart

Distinct from the CPU core, the CarrierId and the LocusId. A claim belongs to (F, I), never to F: a restarted floor is (F1, I18) and cannot inherit (F1, I17)'s unfinished claim by carrying the same stable id. Carrier identity is untouched and still not bound to a floor or a core.

In the harness an incarnation is one floor process: the supervisor (the harness) mints the incarnation id at BOOT and is the only party that can say the incarnation has ended.

3. The activation barrier

ACTIVE(source, Is)
   │ source quiesced: MOVE_OUT (the floor holds nothing); execution authority revoked
   ▼
IN_TRANSFER(m)
   │ destination consumes the transfer authority              — CLAIM   (durable)
   ▼
CLAIMED(dest, Id, m)
   │ bytes installed on the floor, DORMANT                     — INSTALL (local)
   │ execution authority recorded for (dest, Id)               — ACTIVATE (durable)
   ▼
ACTIVE(dest, Id)
   │ the floor's ACTIVATE op lifts the dormancy               — only now do ordinary transitions run

Runnable(L, F, I) = Installed(L, F, I) ∧ ActivePlacement(L, F, I), and for every L, Σ Runnable ≤ 1. The floor half is made structural in the move profile: MOVE_IN installs a slot dormant, and every op on a dormant slot except STATE and ACTIVATE is refused BAD DORMANT. The floor cannot check the durable record — it has no store — so the sequence is still the agent's discipline, but "installed ≠ runnable" is now a state the floor holds and refuses from, not a comment in a harness.

The floor half lives in its own measurement feature, moveact, on top of move, so the image R6 measured stays byte-identical and the retained R6 and R6.1 batteries run on it unchanged; the battery asserts that identity against R6's receipt.

Contention is re-asked, never counted. Every durable step opens the placement's incarnation lock for milliseconds; a claim or activation that meets CONTENDED — another incarnation's claim or activation in flight — is retried by the agent. A refusal is a refusal only when R0.8 answered from committed state.

4. Encoding on the frozen substrate — the hypothesis to falsify

R0.8 keeps two families per lineage and they are exactly the two facts the barrier separates:

placement factR0.8 familytransition
claim / holderlifecycleattach(carrier = F‖I) req=claim:<m>
execution authorityauthorityworker inc-<I> <id> req=reg:<I> then grant inc-<I> req=activate:<m>
quiesceauthorityrevoke inc-<I> req=quiesce:<m>
relinquish (take)lifecycledetach req=take:<m>
reassign after a dead pre-activation claimant (take, re-issued)lifecyclefinalize F‖I <gen> supervisor req=take:<m'> — LossBasis::SupervisorAttestation, R0.8's own "the supervisor attests the carrier is gone"

So the hypothesis: R0.4's separation of possession from authority, frozen in R0.8, already is the claim/activation split one rung up. The stored state distinguishes the two crash histories without a new field — CLAIMED = attached to (F, I) with authority inc-I = none; ACTIVE = attached with authority inc-I = some. The sufficiency test (§7) is what decides whether that holds or whether placement needs a field of its own. Whichever way it falls, the durability machinery is reused, not duplicated.

Three things the adapter must supply because the substrate does not, and which the receipt must say are the adapter's: the substrate enforces none of the barrier rules — cd-core's finalize_loss checks generation and carrier and will finalize an ACTIVE holder; a grant appends evidence unconditionally; the floor's ACTIVATE checks only that the slot is used. So (1) activation is witness-gated: an agent may not activate for an incarnation the supervisor has reaped (F107), and activate takes the supervisor's witness; (2) activation binds to the current claim, not to ledger membership: the ledger remembers every claim an incarnation ever made on a lineage, so the capsule carries the placement generation of its take and an activation is refused unless the placement is at that generation with this holder's claim on record; (3) replays are classified from the ledger, not from revision distance — activation adds revisions of its own, so "one past the transfer" no longer means consumed. The incarnation worker is registered at the claim, so an activation's only mutation is the grant, and the fault points measured during ACTIVATE are on the grant.

The capsule now carries the take's exact request words (detach … or finalize … supervisor …) so the ledger probe re-submits precisely the take it names; the probe stays side-effect-free on a vacant placement (finalize on a vacant placement is refused NotAttached and moves nothing — measured before this was written).

5. Recovery, by history

historyphase after the deathlegal continuation
A. claimant dies after CLAIM (± INSTALL), before ACTIVATECLAIMED(F, I, m), authority noneafter positive finality of I, the supervisor re-issues the transfer: finalize F‖I … supervisor req=take:<m'> → IN_TRANSFER(m'); the same payload bytes (any copy) bind to m' and one incarnation claims them. Legal because I never had execution authority: nothing it could have done to L exists
B. holder dies after ACTIVATEACTIVE(F, I), floor deadthe transfer capsule is never replayed. Recovery needs the holder's durable Locus state, and that does not exist in this stack: the floor is in-memory and R3 egress exports evidence, not state. Named dependency: a floor-side durable Locus history. This round stops there and does not weaken the rule
C. claimant is paused, delayed, unreachableCLAIMED or ACTIVEno reassignment. No timeout, missed heartbeat or silence is a death. Only the supervisor's positive witness — the process has exited and been reaped — ends an incarnation
D. a finalized incarnation's agent resumes and tries to ACTIVATEwhatever the lineage now saysrefused: the holder is no longer (F, I)
E. F restarts as (F, I') and presents I's claimCLAIMED(F, I, m)refused: I' ≠ I
F. the durable ACTIVATE landed and the floor died before lifting dormancyACTIVE(F, I), floor deadACTIVE_NEVER_RAN: by the record indistinguishable from B and treated as B, conservatively — the capsule is not replayed, re-issue is refused by name
G. a CLAIMED holder wants to give L upCLAIMED(F, I, m)not a relinquish: a claim is completed by activation or ended by the claimant's death (NOT_ACTIVE); the floor likewise refuses MOVE_OUT of a dormant slot

6. Falsifiers

  • F97 a claimant that died before ACTIVATE cannot be safely reassigned

after positive finality, or can be reassigned without it.

  • F98 a paused or delayed claimant is reassigned (silence read as

death).

  • F99 a finalized incarnation activates, or a restarted floor inherits

its predecessor's claim.

  • F100 an incarnation that installed but never activated gets a

semantic operation accepted (floor or authority side).

  • F101 after ACTIVATE and one transition, the transfer capsule replays.

  • F102 a duplicate capsule racing claim/activation yields two ACTIVE

incarnations.

  • F103 an activation for Locus A activates B, or a stale activation

for move N activates move N+1.

  • F104 a crash at a claim or activation boundary has no named state

or no legal continuation.

  • F105 two placement histories with different legal futures map to one

stored state (the sufficiency test, §7).

  • F106 the negative controls stop reproducing: no barrier ⇒ a dead

claimant's payload executes twice; floor id without incarnation ⇒ a zombie inherits a claim.

  • F107 an agent activates for an incarnation the supervisor has

reaped, or an activation for an earlier claim of the same incarnation activates the current one.

  • F86 (kept) the move profile leaks into the production image.

7. The state-sufficiency test

If two placement histories map to the same stored state, every future legal or refused operation must be the same.

Primary falsifier: the pre-activation crash (A) and the post-activation crash (B). Under the encoding of §4 they must read as different stored states and admit different continuations; the battery also runs the control in which activation is not recorded (R6.1's mapping) and shows the two histories collapse — that collapse is the evidence that placement needs the authority family, i.e. a phase beyond possession.

8. Predictions, before the battery

  • The §4 encoding distinguishes A from B in the stored state; the control

without activation records does not.

  • A reassigns exactly once after positive finality; the old capsule and

the re-issued capsule are two authorities for one payload, the first consumed by the dead claim, the second by the new one.

  • Pausing the claimant with SIGSTOP leaves poll() unfinished; every

recovery attempt is refused; SIGCONT lets the claimant activate normally.

  • finalize … supervisor is refused NotAttached on a vacant placement

and already-applied on replay; as a re-issuing take it advances the placement generation by one.

  • The floor refuses BAD DORMANT for ATTACH, DETACH, GRANT, REVOKE, AUTH,

SUSPEND, RECOVER, FINALIZE on an installed-not-activated slot, answers STATE, and behaves exactly as before after ACTIVATE; the production image is byte-identical.

  • B stops on the named dependency; no recovery is attempted.

9. Adjudicated (2026-09-05) — what stands, what was amended

R6.2 was accepted. Standing after the ruling:

  • phase ≠ materialization, FloorIncarnationId, claim ≠ activation ≠

runnable, positive finality only: accepted permanently.

  • **The encoding (§4) is accepted as implementation, with one precise

interpretation:** the R0.8 lifecycle and authority families are a sufficient durable realization of the tested placement claim/activation algebra. Placement remains its own semantic domain and API — claim / activate / quiesce / reissue / phase — and the adapter lowers those into attach / grant / revoke / finalize. The substrate's words are encoding details: do not expose placement.carrier = F‖I or placement.worker = inc-I as ComputeDriven semantics, and do not canonize "a FloorIncarnation is a Carrier" merely because the substrate stores its 16 bytes in a column historically named carrier.

  • No new durable `placement_phase` field under current evidence: a

third stored fact would create its own consistency problem (lifecycle says attached, authority says none, the field says ACTIVE — which wins?). Added only if a future state-sufficiency falsifier requires it.

  • The wording "placement literally is lifecycle one rung up" is

rejected; "the possession/authority decomposition is a sufficient durable realization of the placement algebra" is the sentence that stands.

  • The adapter boundary is load-bearing and stays: R0.8 does not enforce

the placement protocol (activation on the current claim, the live witness, ledger-classified replays, dormancy until the durable activation) — R0.8 semantics ≠ placement semantics even though R0.8 primitives suffice to implement placement semantics.

  • History A (§5): closed. History B: the real open dependency, and

the next round — docs/durable-locus-history-model.md (R6.3). U11's ACTIVE_NEVER_RAN boundary stands as the conservative rule: once execution authority is durably activated, recovery assumes post-transfer history may exist unless another authoritative mechanism proves otherwise.

  • Not a hot-context concern: the frozen cd-durable authority history is a

growing evidence vector, so placement is not limited to four activations; durable placement-history compaction is a future storage matter, not a reason to add bytes to the 309-byte hot Locus state.

Open in the interactive atlas