R6.3 durable Locus history model — written before the mechanism

R6.2 closed history A and isolated the last semantic hole of the same-host multicore model. A holder that is durably ACTIVE(F, I) executes transitions on L, and then F dies. The placement authority knows that (F, I) was active; it does not know the last committed Locus state. The transfer capsule holds the pre-activation state, and the R6.2 U9 control showed what replaying it does: AUTH W1 goes 1 → 0, a stale prefix resurrected. The floor is in-memory; R0.8's store is the control plane's; R3 egress exports evidence, not state. GPT's ruling on R6.2 makes that the round:

Execution authority is not durable recoverable history. After any semantic transition whose success has become externally final, the exact authoritative successor Locus state must be reconstructible after the active holder incarnation dies.

This document fixes the vocabulary (one new sequence, named for its domain), states the commit protocol and every crash window with its named outcome, states the recovery composition through the accepted R6.1/R6.2 placement path, names two realizations and does not choose between them until the battery has, and lists what falsifies it.

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

• phase ≠ materialization; IN_TRANSFER / CLAIMED(F, I) / ACTIVE(F, I)

are the placement-domain semantics, realized as a projection over R0.8's possession and authority families — no new durable placement field, and "placement is lifecycle one rung up" is not canonized;

• physical core ≠ floor ≠ FloorIncarnation ≠ Carrier ≠ Locus. A floor

incarnation is the identity of one execution-domain lifetime, not another Carrier, however the substrate happens to store its 16 bytes;

• claim ≠ activation ≠ runnable; `Runnable(L, F, I) = Installed ∧

ActivePlacement`, Σ ≤ 1;

• positive finality only: silence, timeouts and unreachability are not

death;

• once execution authority is durably activated, recovery must assume the

incarnation may have produced post-transfer history unless another authoritative mechanism proves otherwise (ACTIVE_NEVER_RAN is history B by name, U11);

• transport delivery ≠ transfer authority; transfer authority is coherent

per Locus; relocation does not advance L's lifecycle generation;

• R3: a transition establishes truth, evidence describes truth.

LifecycleEgressV1 is a public projection and is never a recovery checkpoint. This round must not make evidence authoritative.

1. Vocabulary — one new sequence, named for its domain

Five counters already exist and each means something different. The round adds one and refuses to let it be confused with the others:

LSR n     "durable successor number n of this Locus's semantic history"

• LSR 0 is the durable state established when L's history begins under

this mechanism (at genesis, or when a recovered/transferred state is installed and activated).

• A semantic mutation is a floor op in is_mutation (ATTACH, DETACH,

FINALIZE, GRANT, REVOKE, SUSPEND, RECOVER) that the floor accepted (status OK). It mints exactly one successor. A refused or bad op mints nothing: L did not change. Queries (STATE, AUTH) mint nothing. Placement operations (claim, activate, relinquish, re-issue, MOVE_OUT/MOVE_IN) mint nothing: they move the same bytes, they do not change L.

• LSR ≠ transitions: GRANT and REVOKE advance the LSR (authority is

semantic state) and leave transitions alone. LSR ≠ generation: an ATTACH advances the LSR and not the generation. Both are measured.

The durable successor — a successor row, not a "checkpoint". The R6.2 ruling floated LocusStateCheckpointV1; the survey (§10) found the word already means three incompatible things — ARIES's fuzzy marker, SQLite's WAL-to-database transfer, event sourcing's derived state snapshot — so this round says successor row (S snapshot / J journal), base for the snapshot a journal replays from, and history for the chain:

row(L, n)  =  kind ∈ {S snapshot, J journal}
              bytes         S: the floor's 317-byte record (CDMV/1: 8-byte header, 176-byte core, 133-byte authority row)
                            J: the 48-byte command with its slot byte set to 0 (a history is not a slot) ‖ the outcome frame
                               re-encoded from its parsed fields (status, code, possession, auth, generation, fence, transitions)
              prev          d(L, n-1)
              digest        d(L, n) = sha256("cd-lsr/1" ‖ L ‖ n ‖ d(L, n-1) ‖ kind ‖ bytes)
              writer        (F, I) that committed it
head(L)    =  (n, d(L, n)) of the newest COMMITTED row
bound(L)   =  the one holder incarnation whose commits the history accepts (see below)

The digest chain binds every successor to the Locus and to its predecessor, so rollback (an older row presented as head), fork (two successors for one predecessor), and substitution (another Locus's row, or a row whose bytes were edited) are refusable and refused by the store.

The chain does not fence a late writer; the binding does. W3 (§2.1) leaves a living agent of a dead floor holding S'. If the supervisor recovers L from head = S onto F2 and that agent then commits its S' as n+1 before F2's first commit, the chain accepts it (prev matches) and F2 is now running a stale prefix — detected at F2's next commit as fork, but detected is not prevented. So the history carries bound(L): at recovery the supervisor binds the history to no one (the dead incarnation's agent is fenced), and the new holder binds itself when its durable activation lands. A commit from any other writer is refused wrong-writer. This is the R6.2 incarnation rule one rung down, and the Kafka producer-epoch separation the survey names: a sequence check refuses the wrong position; an epoch refuses the wrong writer. Both are needed and a control shows the chain alone is not enough.

This material is internal and authority-bearing. The 317-byte record carries the admission with the world mark (R6 found this; R6.1 unclaimed it). It is recovery material for a trusted local durability service and never egress. LifecycleEgressV1 (52 B, public, mark-free by E0624) remains the public observation; the two are different objects with different audiences and this document keeps them apart by name.

2. The commit protocol — success is not final before its successor is durable

caller ──op──► agent ──op──► floor(F, I)          ACCEPT      S → S' in RAM; the outcome frame says OK
                       ◄── outcome ──
               agent ──EXPORT(slot)──► floor        ESTABLISH   the floor hands S' out (317 B); the slot is unchanged
                       ◄── record S' ──
               agent ──commit(L, n+1, S')──► history            reserve · write · COMMIT · ack
                       ◄── COMMITTED(n+1, d) ──
caller ◄──SUCCESS──                                 FINAL       only now

The rule: a SUCCESS may not become externally final before the successor state required to recover that success is durable. A refusal is final at once: nothing changed, recovery at S is recovery at the truth. A query is never durable and never needs to be.

The agent sends at most one un-durable mutation at a time on a Locus: after ACCEPT it does not send the next mutation until COMMITTED. The floor cannot enforce this (it has no store) — it is the agent's discipline, said here as R6.2 said the same about dormancy, and measured by a control.

2.1 Every crash window, named

Three parties can die: the floor incarnation (the holder), the durability service, the agent. What decides the outcome is who holds S' when the death happens, not the order of steps alone: once the agent holds the exported successor, the holder's death cannot retract it — the agent commits it and the success is final. For each window: the durable state, whether the op applied to L's authoritative history, what a recovering floor reconstructs, what the caller may know, and whether evidence may have escaped (when the R3 egress profile is on).

W2 and A+F are the windows the rule exists for: the floor said OK, the successor was never durable, and the truth that will be recovered is S. That is correct, not a loss — the caller holds NOT_APPLIED (W2) or INDETERMINATE (A+F) and a retry against S is a retry against the truth. A2 is the unavoidable ambiguity R0.8 also has (its acked = 0): the truth is S' and the caller does not know it; the vocabulary is INDETERMINATE, never a guess.

A1 is the state this round has to name that R6.2 did not have: `DURABLE_LAG(1)` — the holder is exactly one committed-in-RAM successor ahead of the durable history. The successor agent reconciles by EXPORTing the living floor and comparing to head(L): equal bytes → in sync; different → commit the floor's state as LSR n+1 (the floor is the ACTIVE holder; what it holds is L's truth, not yet durable) and report the op INDETERMINATE. The lag is at most one because of the one-un-durable-mutation discipline; a control breaks the discipline and shows the history cannot tell a lag of two from a lag of one (the snapshot has no count of its own, and transitions does not count GRANT).

No window may create two durable successors at one LSR, and no window may create a head without a row: reserve, write and COMMIT are one transaction under the store's write lock, the writer binding and the head are re-read inside it, and the committed mark must land on the row this transaction reserved. (The first cut had three phases in three transactions; the adversarial review drove two service processes against one file and produced a head pointing at a row a concurrent open had cancelled, with the committer answering ok — a SUCCESS with nothing durable, the F108 shape from the inside. Fixed before the official run; recorded here because the construction, not the review, is what now rules it out.)

W3 has two sub-rows against a concurrent recovery. The agent that holds S' commits either before the supervisor's fence — its row is on the chain, recovery reads it, SUCCESS (W3a) — or after it — refused wrong-writer, the agent answers NOT_DURABLE and poisons itself, recovery read S, and S is the truth (W3b). Both orderings are legal and named; the second is H7's "before the claim" arm. NOT_DURABLE is therefore part of the caller vocabulary: the floor accepted, the history refused this writer; nothing you were told is final.

3. Recovery composition — history B, through the accepted path

ACTIVE(F1, I17), floor dead, positive finality (the supervisor reaped it)
   │
   │  supervisor reads head(L) = (n, d): the row must be COMMITTED, the chain must re-hash, the record's Locus must be L
   ▼
S' = row(L, n).bytes                        (A: the snapshot is S')
   = replay(checkpoint, journal) on an executor   (B)
   │
   │  reissue-from-history:  finalize F1‖I17 <gen> supervisor req=take:<m'>   with payload S'
   │  m' = sha256("cd-transfer/2" ‖ L ‖ F1‖I17 ‖ to ‖ rev ‖ take_words ‖ S')[:16]  -- bound to S', not to the transfer's S
   ▼
IN_TRANSFER(m')
   │  (F2, I') claims m'            -- CLAIM, durable
   │  MOVE_IN S' on F2, DORMANT      -- INSTALL
   │  grant inc-I' req=activate:m'   -- ACTIVATE, durable, witness-gated
   │  floor ACTIVATE                 -- only now runnable
   ▼
ACTIVE(F2, I'),  L at S',  LSR n continues from n

What this preserves:

• the original transfer capsule stays consumed — its payload is S and

its move id binds S; presented anywhere it is ALREADY_CONSUMED / STALE_TRANSFER (R6.2 U5, unchanged);

• recovered bytes are not runnable because they were reconstructed —

they pass claim → dormant install → the install gate → durable activation → floor ACTIVATE exactly as a transfer does (F119). The install gate runs on the dormant slot: the new holder's EXPORT must be byte-identical to head(L) or nothing is activated (INSTALLED_NOT_HEAD, the placement stays CLAIMED). The review found the first cut ran this check after the floor's ACTIVATE — a detector, not a gate, with the wrong bytes runnable in the interval; the gate now precedes the durable activation, and the writer binding follows it. Under a journal the gate needs a full replay at every activation (§4);

• R6.2's `ACTIVE_HOLDER_DEAD` refusal stands for a placement whose

Locus has no durable history, or whose head does not verify; the refusal now names what is missing (no durable history, chain broken, wrong Locus) instead of the dependency;

• an installed-not-activated recovery is history A — if (F2, I')

dies after claiming m' and before activating, R6.2's re-issue applies to m' (the payload is S' again, from the history, not from any capsule).

Recovery parity, measured for every recovered Locus: STATE (possession, generation, fence, transitions) and AUTH for every worker the history touched equal the last acknowledged state of the dead holder; and the recovered floor's EXPORT is byte-identical to head(L).bytes (A).

4. Two realizations, compared by the battery before one is chosen

The battery runs history-B recovery under both, with the same falsifiers and the same parity checks, and records durable bytes, commit latency and recovery time at journal lengths 1, 50 and 500. The choice is made in the EXECUTED record from those numbers and from one structural fact the table already shows: B needs a place where L's transitions run that is neither the dead holder nor the new one. This stack has no such place; the battery's B-executor is a plain floor that installs the checkpoint, ACTIVATEs it locally with no durable activation, and replays — which is precisely Runnable without ActivePlacement. If B is chosen, that executor needs its own name and rules; the model predicts A.

5. The floor's part, and its limit

The floor gains one read, in a measurement feature movehist on top of moveact: EXPORT(slot) (op 33) writes the same 317-byte record MOVE_OUT would write, and does not take the slot — L stays where it is, in whatever possession, dormant or not. It is refused BAD SLOT_UNUSED on an empty slot. It adds no per-Locus state, no hot-path work, no persistence code, no syscalls beyond the write of the record. Production image byte-identical (F86); the R6 move image and the R6.2 moveact image byte-identical to their receipts (asserted by the battery).

What the floor still cannot do, said now: it cannot know whether its successor was committed, so it cannot refuse the next mutation while one is un-durable (the agent's discipline, §2), and it cannot tell EXPORT's reader from anyone else (the record carries the mark; the reader is the trusted service, by construction of the harness). Both are unclaims. Two more, from the review: the agent's death in the battery is an exception raised in the harness process, not a process death, and the "slow agent" of H7 is the harness holding S' in memory; and the §2.1 evidence column is reasoned from the R3 profile's ordering (emit_detach runs before the outcome frame is written) and measured only for the DETACH of H6.

6. The durability service

tools/r63_history.py: a trusted local process over SQLite (journal_mode=WAL, synchronous=FULL, busy_timeout 5 s), one file per Locus history, speaking stdin/stdout JSON like the frozen cd-durable does, with three named steps inside one write transaction so its windows are real and killable by --crash-at:

BEGIN IMMEDIATE          re-read bound(L) and head(L) under the write lock
reserve(L, n, prev)      INSERT pending row                       -- crash: after-reserve     → rolled back, open reports clean
write(bytes, digest)     UPDATE bytes                             -- crash: after-write       → rolled back, open reports clean
commit                   UPDATE committed=1 (this row, rowcount 1); advance head; COMMIT   -- crash: before-commit / after-commit
ack                      UPDATE acked=1 (a second transaction)   -- crash: after-ack

Two fsync'd transactions per mutation, not one: the commit and the ack.

bind(writer) sets bound(L) durably (the supervisor at recovery, the activated holder afterwards). Refusals, by name: fork (a successor for a predecessor that is not the head), rollback (an n ≤ head with other bytes), gap (an n > head + 1), wrong-locus (the record's Locus at offset 16 ≠ L), wrong-writer (the committer is not bound(L)), contended / busy (another writer holds the lock or reserved this n), cancelled (the row this transaction reserved is gone — unreachable by construction, kept as a named refusal), chain-broken and head-behind (at open: a stored row whose digest does not re-hash; a head that is not the newest committed row — a substituted or rolled-back file); already-applied (the same (n, digest) re-committed — the idempotent retry, answered from committed state before the writer check, so a fenced writer's retry of a row that is durable is told so, and acknowledged).

bound(L) lives in the file beside the chain and is not itself chained: a whole-file rollback rolls the binding back with the state (H3x), and an edit to it is not detected at open. Named beside the missing anchor; not closed here.

The store lives on a real filesystem, not tmpfs, and the battery records which. The crash model is process death — the service, the floor and the agent are killed at named points and the on-disk file is re-opened — not power loss: no page-cache drop, no reordering, no fsync-error injection. The survey's fsyncgate and Pillai findings are why that is said as an unclaim and not assumed away. At open the service reports what it found and did: clean, unused-reservation-cancelled, pending-write-discarded, committed-unacknowledged n.

7. Falsifiers

• F108 a SUCCESS is externally final before the successor state that

recovers it is durable (the control: ack-before-commit, floor dies → the caller holds SUCCESS and recovery yields S).

• F109 after an acknowledged success and the holder's death, the

recovered state differs from S' in possession, generation, fence, transitions, or any AUTH answer.

• F110 recovery replays the original transfer capsule, or a stale

prefix: after a recovery the old capsule claims anywhere.

• F111 an older committed row substituted for the head is accepted as

the recovery state.

• F112 two successors for one predecessor LSR are both accepted.

• F113 Locus A's checkpoint is installed as Locus B.

• F114 the authority working set is omitted from the durable

representation and recovery still reads as correct (control: the row bytes zeroed → AUTH W1 1 → 0).

• F115 lifecycle/fencing state is omitted and recovery still reads as

correct (control: the pre-FINALIZE core with the post-FINALIZE row → the stale epoch is accepted again).

• F116 evidence egress is treated as proof of durability (control: the

caller acked on the R3 frame's arrival; floor dies before COMMIT; recovery yields S).

• F117 a crash window in §2.1 has no named durable state, applied

verdict, reconstructed state and caller knowledge.

• F118 state sufficiency: two histories that map to the same durable

recovery state admit different legal or refused futures (the R6.2 criterion, applied with transitions that change authority, generation and fence separately).

• F119 reconstructed bytes become runnable without passing claim →

dormant install → durable activation → floor ACTIVATE.

• F120 a refused or bad op mints an LSR; or the LSR is conflated with

generation, transitions, placement generation, R0.8 revision or the egress sequence (measured separately: a GRANT advances LSR and not transitions; a relocation advances placement generation and not LSR).

• F121 the durable lag exceeds one under the discipline; or the

reconciliation of a lag of one commits anything but the living floor's own EXPORT.

• F122 a commit by an agent of an incarnation that is no longer the

holder is accepted after recovery has begun (control: chain only, no binding → the recovered floor runs a stale prefix and finds out at its next commit).

• F86 kept; the R6 and R6.2 images byte-identical to their receipts.

8. The state-sufficiency test, for the durable state

If two Locus histories map to the same durable recovery state, every future legal or refused behavior must be equivalent.

Applied with three histories that each change one dimension the record holds — a GRANT (authority), a DETACH (generation), a FINALIZE with a fencing epoch (fence) — recovered and then probed with the op that only the true successor refuses or accepts (an AUTH read; an attach at the old generation; a FINALIZE at the old epoch). The three controls of F114/F115 are what a superficially small checkpoint gets wrong.

9. Predictions, before the battery

1. Under A and under B, history B recovers: after ACTIVATE, k mutations

across authority/generation/fence, and the holder's death, a new incarnation reaches S' with STATE and AUTH parity and the old capsule ALREADY_CONSUMED everywhere.

2. Every window in §2.1 lands where the table says; W2/W3 recover S with

the caller un-answered; W4 recovers S' with INDETERMINATE; H2 discards; H3 reports the unacknowledged row and the retry is already-applied.

3. The store refuses fork, rollback, wrong-locus, chain-broken

with those names; a substituted older row is not the head.

4. The three omission controls each recover a wrong state; the

ack-before-commit control leaves the caller holding a SUCCESS for a state that does not exist; the egress control does the same.

5. LSR advances on GRANT (transitions does not), on ATTACH (generation

does not), not on a refusal, not on a relocation (placement generation does).

6. A and B both pass; A's recovery is O(1) and B's grows with the

journal; B needs the executor named in §4. A is chosen unless the numbers say otherwise.

7. F86 holds; the R6 and R6.2 images are byte-identical.

10. Precedent — the same boundary, elsewhere (surveyed before the battery)

Read for what each system decided about the successor/journal question and the acknowledgement window; none is this design.

• ARIES (Mohan et al., TODS 1992, doi 10.1145/128765.128770): the

write-ahead rule and force-at-commit; the LSN is the sequence; page_LSN is the idempotency test replay needs. It is realization B, and exists because forcing whole pages per commit was too expensive — an argument that is absent at 317 bytes.

• Raft §8 / Ongaro's dissertation §6.3: an entry is committed when

durable on a quorum, before the client is answered; a leader that dies between commit and reply leaves the client to retry — "at-least-once" unless a session table (client id, serial, saved response) is itself part of the replicated state. Our INDETERMINATE is that window, named; making it answerable would need the same durable dedup table. Not built.

• Redis (persistence doc): appendfsync always — "a single write and a

single fsync (before sending the replies)" — is §2's rule verbatim; RDB is snapshot-with-a-loss-window; since 7.0 the AOF is a base + increments. Scripts replicate their effects, not their text, because scripts are not deterministic — journal the successor, not the command, when in doubt.

• SQLite WAL: synchronous=FULL syncs the WAL at every commit; its

"checkpoint" is the WAL→database transfer, which is why this round does not use the word for a state row.

• Event sourcing (Fowler; Akka snapshots; EventStoreDB expectedVersion):

journal authoritative, snapshot derived; a conditional write naming the expected predecessor version is fork refusal per stream; an idempotent retry of that write needs a stable record identity and the version check.

• Schneider 1990 (state-machine replication) and Azure Durable Functions'

determinism constraints: B is sound only if S → S' is a pure function of (S, journaled input). The floor's dispatch is that function today (the R6 S8 commutation), and the battery checks every replayed frame against the journaled one (H1, H10: zero divergences) — the property is measured, not assumed.

• Orleans JournaledGrain: "wait for ConfirmEvents" before acting on a

raised event; LogStorage (B) and StateStorage (A) behind one confirmed-before-ack contract — an existence proof that the A/B choice can sit below a fixed contract.

• Kafka KIP-98: the broker refuses a sequence that is not last+1 (our

chain), and bumps a producer epoch on re-incarnation so a zombie's late writes are refused (our bound writer). Two mechanisms, both needed: F122.

• Gray 1978 ("Notes on Data Base Operating Systems" §5.8): the high-water

mark is the LSR; redo/undo must be idempotent; and "one should not send a recoverable message before it is logged" — §2's rule stated for the acknowledgement itself.

• fsyncgate (PostgreSQL 2018) and Pillai et al. (OSDI 2014): a retried

fsync can report success for data that never reached disk; 60 crash-consistency vulnerabilities across 11 mature applications; ordering and atomicity are per-filesystem facts. This is why §6 says the crash model is process death and the store's filesystem is recorded, and why the service never retries a failed fsync (SQLite surfaces it as an error and the commit is refused).

11. Adjudicated (2026-09-05) — what stands, what was qualified

R6.3 was accepted as executed; R6 is not freeze-ready because H3x is a demonstrated anti-rollback hole. Standing after the ruling:

• History-B recovery invariant: accepted. `Locus State Revision`:

accepted permanently — H0 separates it from lifecycle generation, transition count, placement generation, R0.8 revision and the egress sequence. `successor row`: accepted vocabulary (not "checkpoint").

• Realization A, successor snapshot rows, is selected for the current

architecture. Journal/replay is retained as an experimental alternative, not current architecture: it would need a pure, non-authoritative reducer that cannot emit effects, become a Carrier, mint evidence, gain placement authority or become runnable in the operational sense — an abstraction this stack does not have. Do not build a privileged replay executor.

• The writer binding is load-bearing. Standing rule: *a durable

successor is admissible only from the incarnation currently bound as writer for that Locus history.* The chain answers where in history; the binding answers who may advance it. The binding must itself be protected by the external anchor (R6.4): today it lives beside the history and rolls back with it.

• Crash-window vocabulary accepted — `NOT_APPLIED / SUCCESS /

NOT_DURABLE / INDETERMINATE / DURABLE_LAG(1) — with one qualification: **NOT_APPLIED` means "absent from the authoritative recoverable Locus history", not "no transient execution or observation ever occurred."** W2 executes in volatile floor state and may emit R3 evidence before the floor dies (H6); durable recovery correctly returns S. Never paraphrase it as "nothing happened anywhere". Compatible with R3: evidence describes an observation; it does not establish durability.

• `DURABLE_LAG(1)` is conditional: valid under the single-outstanding-

successor discipline (H9 shows the history cannot tell lag 1 from lag 2 when the discipline is broken), not an inherent property. Structural backpressure (a floor that blocks the next mutation while a successor is un-durable) is deferred and is not R6.4's.

• H3x is a real safety gap and the next round: **R6.4 — Durable History

Anchor and Anti-Rollback**, docs/history-anchor-model.md. A self-consistent Locus history ≠ the current Locus history — the R0.8 distinction rediscovered one layer up; reuse R0.8's trust shape (a deployment-controlled anchor committing to the semantic head, exact pending-successor authorization, crash reconciliation that never lets the store teach the anchor), not its lifecycle domain; anchor the canonical head, never the database file's bytes.

• The retained R6.1 T2 rule is to be repaired (spontaneous CONTENDED in a

free race is diagnostic, not pass/fail; the forced-lock control carries the non-vacuity), with the accepted R6.1 receipt preserved unchanged.