diff --git a/docs/requirements/onboarding-wizard.md b/docs/requirements/onboarding-wizard.md index 4d1fed64..6b2c68cc 100644 --- a/docs/requirements/onboarding-wizard.md +++ b/docs/requirements/onboarding-wizard.md @@ -191,7 +191,9 @@ recorded, concurrent successions serialize on the epoch record, the change is one audited epoch-record mutation, and recorded fence rows immutably retain their original actor. The seed-boundary gate and the origination rule read the epoch record's current designation, so a -banned or deleted origin no longer strands the unoriginated suffix — +banned origin — identity §7.1's sole unavailability state; deletion +does not exist under identity §7.3 — no longer strands the +unoriginated suffix — the successor resumes and completes it with no factory reset and no new epoch, restoring D4 re-runnability and §4.4's strand-nothing rule (NEW-11; witnesses §6.7: succession recovery, origin-available refusal, @@ -227,7 +229,55 @@ succession appears in the §1.1 composed-surface inventory and the §7.8 mapping amendment (NEW-15). Witnesses §6.7: the succession two-world control, tenant-unprivileged successor completion, post-succession grant-revocation re-succession, repeat succession, and empty-prefix -succession. +succession. (Revision 12 removes the conferral and the _unable_ +disjunct introduced here; it closes the same findings without them.) + +Revision 12 (sol re-review 10: NEW-12/NEW-13/NEW-14 residuals, NEW-16, +NEW-17): succession is reduced to a pure designation transfer and the +canonical seed tuples become fully epoch-derived, superseding revision +9's prefix-derived tuple set. Canonical seed payloads and scopes now +contain **no generated id and no account identifier**: a child +position references its parent by epoch-scoped canonical seed role, +resolved to the actual row server-side at execution +(canonical-reference resolution, §4.3), and position 1 carries no +initial-owner field — the ordinary top-level command's default (the +creator names itself, contract 2 §4.3) binds the initial `owner` to +the acting designation as a recorded outcome, never as payload +content. The full canonical seed tuple set is therefore +fence-independent and byte-stable absolutely: every client — fresh, +resuming, or a successor — derives identical bytes from the epoch id, +the immutable provenance, and the fixed example set alone, so a +replay after succession compares equal against every committed digest +and the historical-payload gap is closed (NEW-13). Succession itself +now writes exactly the designation update and its single audit event +— **no grant is conferred** — and condition (a) collapses to identity +§7.1 unavailability alone: the _unable_ disjunct and the +conferred-grant clause are removed, so the command reads identity, +platform-eligibility, and epoch-record state only, writes nothing +conditional, and is world-independent unconditionally — no allowed +grant transition, including an origin revoking its own position-1 +`owner` grant, can make its outcome or observables differ (NEW-12) — +and a platform admin can never parlay succession into authority over +an existing seed company: after full completion, succeeding confers +nothing at all (NEW-16). The origination authority succession +transfers is **designation-derived**: for exactly the fresh +origination of an unoriginated canonical seed position, the +hierarchy-authority component of fresh-mutation authorization is +satisfied by the current designation itself — a disclosed, scoped +amendment to contract 2 §4's evaluation (§7 item 12) conferring no +read authority, no replay authority, no standing grant, and nothing +outside the canonical seed key set — so a successor completes the +suffix by direct in-order origination, never replaying the committed +prefix, and the revocation lock that motivated the _unable_ disjunct +cannot arise (completion authority never depends on a revocable +grant). §6.1 gains the closed succession-write inventory and its +no-seed-input static assertion (NEW-17), and the Revision-10 +paragraph's origin-loss vocabulary is corrected to the banned state +identity actually defines (NEW-14). §6.7 reworked: the two-world +control now asserts equal event content, an empty grant-table delta, +and a full-command timing bound; new self-revocation two-world +refusal, designation-derived completion, post-completion +harmlessness, and post-succession replay witnesses. Scope: the Gateway-backed product onboarding wizard. Out of scope: the host-local install wizard (`mosaic wizard`, which drives host install and @@ -282,9 +332,14 @@ through the extensibility rule §2.4). (§3.1–§3.6) bind, with this contract's single change extending the epoch-closing command to carry the §3.3 value set inside the same transaction — and the **§7 item 12 seed-origin succession command** - (§4.3), one mutating epoch-record command with its conferred-grant - clause. Beyond those two amendments, nothing is added to identity - §3, and no undisclosed authority exists; both surfaces appear in + (§4.3), one mutating epoch-record command whose closed write set + is the designation update and its single audit event. Beyond those + two amendments, nothing is added to identity §3; the one further + disclosed authorization amendment is §7 item 12's + **designation-derived origination authority** — a scoped change to + contract 2 §4's evaluation for canonical seed origination only, + conferring no grant and no read authority — and no undisclosed + authority exists; all three surfaces appear in the §1.1 composed-family inventory, the §7.8 mapping amendment, and §6.1's inventories, so the D8 mapping and authorization-parity witnesses cannot omit them. @@ -448,29 +503,34 @@ the named authority: sequence is derived entirely from canonical state: the seed parameter the finalize command recorded (the company name, read from the `bootstrap.seed-company-name` settings value, §3.1) and - the fixed example set (§4.3). A resumed run — including a fresh - client holding none of the original run's transient state — - reconstructs the same ordered sequence and the same deterministic - §4.3 keys from that canonical state alone, prefix-wise: each - position's scope and payload derive from the committed - predecessors' recorded outcomes, so the run walks the order and - never precomputes a tuple past the next unrecorded position - (§4.3 shared-declaration boundary). Because the seed + the fixed example set (§4.3). **Canonical seed tuples are fully + epoch-derived and account-free.** No canonical seed payload or + scope contains a generated id or an account identifier: a child + position references its parent by the epoch-scoped canonical seed + role ("the seed company of this epoch", "the seed estate of this + epoch"), which the command layer resolves to the actual canonical + row server-side at execution (§4.3 canonical-reference + resolution), and position 1 carries no initial-owner field — it + takes the ordinary top-level command's default, the creator + naming itself (contract 2 §4.3), so the initial `owner` binding + is a property of the recorded outcome (the acting designation at + origination time), never of payload bytes. A resumed run — + including a fresh client holding none of the original run's + transient state, and a §4.3 successor holding no authority over + any committed record — reconstructs the same ordered sequence, + the same deterministic §4.3 keys, and byte-identical payloads + from the epoch id, the immutable seed parameter, and the fixed + example set alone, reading no recorded outcome. Because the seed parameter is immutable (§3.1), the re-derived sequence is - byte-stable across every re-run and resume **under an unchanged - seed-origin designation**: the same keys carry the same payload - digests, so already-committed mutations replay (recorded - outcomes) rather than collide, regardless of any hierarchy rename - performed since. Where a payload field names the acting seed - origin — position 1's initial-owner field below — the derivation - reads the epoch record's **current designation at origination - time**: a committed position's tuple is pinned by its recorded - outcome and fence digest forever (replays compare against the - recorded digest, never a re-derived one), while an unrecorded - position's derived tuple names the current designation, so a §4.3 - succession changes derived payloads only for positions not yet - originated and can never collide a committed row — and, because every seed - submission declares §4.3's `shared` replay mode, they replay for + **byte-stable absolutely** — across every re-run, resume, and + §4.3 succession: the same keys carry the same payload digests + whoever derives them, so already-committed mutations replay + (recorded outcomes) rather than collide, regardless of any + hierarchy rename performed since, and a replay after succession + compares equal against every committed digest by construction — + no payload ever named the origin. Because every seed + submission declares §4.3's `shared` replay mode, committed + positions replay for whichever currently eligible admin holding §4.3 target-result read authority on the recorded seed targets performs the re-run, not only the actor the fence rows record. The §4.3 fence, not the @@ -480,18 +540,22 @@ the named authority: The first company is created by the ordinary top-level company command under §5.2's eligibility policy, with the epoch's §4.3 seed-origin account — the account the designation names at - origination time, initially the new admin — as actor, naming that - same account as initial `owner` in the same audited operation - (contract 2 §4.3): the initial-owner field is bound to the current - designation, not to the historical first admin; the §4.3 seed-boundary gate reserves + origination time, initially the new admin — as actor; the + command's default names the actor as initial `owner` in the same + audited operation (contract 2 §4.3), so the owner binding follows + the acting designation through the outcome, not through any + payload field; the §4.3 seed-boundary gate reserves origination of the canonical seed tuples to the epoch's current seed-origin account — initially this admin, thereafter changed only by §4.3 seed-origin succession — while the same command outside the canonical seed key set follows §5.2 unchanged. The initial estate, initial project, and initial workspace with seeded example data (D4, D11) follow through hierarchy - commands (contract 1 §5.1) under the admin's `owner` authority - (contract 2 §4.3). Seeded examples are ordinary workspace content + commands (contract 1 §5.1) under the parent-`owner` authority + contract 2 §4.3 requires — for canonical seed origination, + satisfied by the §4.3 designation-derived authority, which the + original admin holds as designation exactly as a successor + would. Seeded examples are ordinary workspace content created by ordinary commands, attributable in audit to the acting admin, carrying the run's trace correlation ids (contract 5 §4.3) and the §4.3 idempotency keys. @@ -587,35 +651,38 @@ collects no sensitive category, so v1 ships no custody surface. refused with a single bounded conflict error (contract 5 §4.2); it executes nothing and discloses nothing of the recorded outcome. - - **Shared-declaration boundary.** `shared` is a server-verified, - seed-only policy, never a caller privilege. The boundary has a - fence-independent part and a prefix-derived part. The - **canonical seed key set** — the (operation identifier, key) - pairs of §3.4's ordered seed sequence — is derived from the - epoch id and the fixed seed-role list alone: the keys are - deterministic and depend on no generated id, so membership is - decidable before any seed mutation has run and without - consulting the fence table. The full **canonical seed tuple - set** is prefix-derived, because later seed tuples embed - generated ids: the tuple at seed position k — its - authorization scope and payload digest — is derived from the - epoch id, the immutable `bootstrap.seed-company-name` - provenance, the fixed example set, and the canonical recorded - outcomes of positions 1 through k−1 (the ids the committed - predecessor fence rows reference). At any canonical state - exactly these members are derivable: every committed-prefix - tuple (read back from its fence row) and the next unrecorded - tuple in order. Before the first company exists, the derivable - set is exactly the seed-company tuple. A fresh client derives - the same way — §3.4's derivation is this walk: submit the - sequence in order, learning each generated id from the - returned recorded outcome or the submission's own execution, - never precomputing a tuple past the next position. A - submission declaring `shared` whose (operation, key) is - outside the canonical seed key set, whose tuple does not equal - its position's derived tuple, or whose position lies past the - next unrecorded position (out of order) is refused with a - single bounded refusal (contract 5 §4.2 validation class) that + - **Shared-declaration boundary and canonical-reference + resolution.** `shared` is a server-verified, seed-only policy, + never a caller privilege. The whole boundary is + fence-independent. The **canonical seed key set** — the + (operation identifier, key) pairs of §3.4's ordered seed + sequence — is derived from the epoch id and the fixed + seed-role list alone: the keys are deterministic and depend on + no generated id, so membership is decidable before any seed + mutation has run and without consulting the fence table. The + full **canonical seed tuple set** — every position's + authorization scope and payload digest — is likewise derived + from the epoch id, the immutable `bootstrap.seed-company-name` + provenance, and the fixed example set alone: no canonical seed + payload or scope contains a generated id or an account + identifier (§3.4). Where a child position must name its + parent, the payload carries the parent's **epoch-scoped + canonical seed role** ("the seed company of this epoch"), and + the command layer resolves that reference to the actual + canonical row server-side at execution — **canonical-reference + resolution**, available to exactly the canonical seed tuples + and nothing else, with the resolved rows recorded in the + position's outcome. Every tuple is therefore derivable at any + canonical state by any party from canonical settings state + alone, but **origination stays in order**: a canonical + position is originated only when every predecessor is + committed, and resolution of a reference to an uncommitted + predecessor fails closed. A submission declaring `shared` + whose (operation, key) is outside the canonical seed key set + or whose tuple does not equal its position's derived tuple — + and any origination submission for a position past the next + unrecorded one (out of order) — is refused with a single + bounded refusal (contract 5 §4.2 validation class) that executes nothing and records no fence row. No other operation can carry a shared declaration, so no shared fence row can exist outside the seed sequence — the seed-only rule is @@ -649,9 +716,18 @@ collects no sensitive category, so v1 ships no custody surface. top-level seed-company key. **Origination.** A seed fence row not yet recorded is originated only by the seed-origin account executing its seed mutation in order, passing the full - fresh-mutation authorization for that seed command (§5.2 - eligibility plus the hierarchy authority the command itself - requires); a refused submission records no row (no-error + fresh-mutation authorization for that seed command — §5.2 + eligibility and identity §7.1 eligibility evaluated fresh + against the submitter, with the hierarchy-authority component + satisfied by the **designation-derived authority**: for + exactly the fresh origination of a currently-unoriginated + canonical seed position, the current designation itself + satisfies the parent-`owner` (or top-level) authority contract + 2 §4 requires, a disclosed scoped amendment (§7 item 12) that + confers no read authority, no replay authority, no standing + grant, no authority over any committed record, and nothing + outside the canonical seed key set — evaluated per submission, + writes nothing; a refused submission records no row (no-error replay below). The recorded actor of every shared row is therefore the account that was the epoch's seed-origin at that position's origination, authorized for the mutation the row @@ -661,80 +737,83 @@ collects no sensitive category, so v1 ships no custody surface. does not strand the epoch (D4, §4.4). The designation changes through exactly one mutating command, an amendment to identity §3's epoch surface disclosed in §7 item 12: a platform admin - submits succession naming itself the epoch's seed-origin. The - command's outcome is **world-independent by construction**: - the submitter-side condition (b) is evaluated against - identity, platform-eligibility, and epoch-record state alone — - never against fence rows, recorded outcomes, the committed - prefix, or any grant attached to a seed record — and the - origin-side condition (a)'s only seed-scope input is the - origin's seed-completion authority, whose recorded-world - component is exactly the authority origination and succession - themselves confer (below), so in any two worlds differing only - in seed existence every condition evaluates identically and - succession carries no existence oracle; the evaluation - consults no fence row, so its timing is fence-independent too - (witness §6.7 two-world control). **Seed-completion authority** means: §5.2 top-level - create eligibility (the full fresh-mutation authorization - position 1 requires) plus, for an account currently designated - while position 1 stands originated, the position-1 - initial-owner authority on the seed company — exactly the - authority whose origination self-confers it (§3.4). The - command succeeds only when BOTH: (a) the current seed-origin - account is **unavailable or unable** — it fails identity - §7.1's account-unavailability predicate (today exactly the + submits succession naming itself the epoch's seed-origin. + Succession is a **pure designation transfer**. It reads + identity state, platform eligibility, and the epoch record + only — never fence rows, recorded outcomes, grant rows, or + hierarchy records — and its complete write set is the epoch + record's designation update plus one audit event (closed + inventory, §6.1). It confers no grant of any kind. The command + succeeds only when BOTH: (a) the current seed-origin account + is **unavailable** — it fails identity §7.1's + account-unavailability predicate (today exactly the better-auth ban; §5.2 records that no separate deactivated - state exists and identity §7.3 defers hard deletion), or it - lacks seed-completion authority — succession while the current - origin is both available and able is refused; and (b) the - submitter is an identity-§7.1-eligible platform admin holding - §5.2 top-level create eligibility. Condition (b) references no - seed record and no prefix: a tenant-unprivileged platform - admin passes or fails it identically whether or not any seed - position is committed. Any future contract adding an - account-removal or account-disable mechanism MUST extend - identity §7.1's single unavailability predicate to cover it - and MUST preserve the epoch record's designation as a stable - reference across it (a retained identifier or tombstone — - never a cascade that rewrites or nulls the designation outside - this command). A submission failing either condition is - refused with the same single constant-shape bounded conflict - as the seed-boundary gate, byte-shape-identical whichever - condition failed and whether any seed fence exists, executes - nothing, and appends no event. Successful succession, in one - transaction, updates the designation in the epoch record, - **confers on the successor the position-1 initial-owner - authority on the seed company where position 1 stands - originated** — no more than originating position 1 from an - empty prefix would have self-conferred (§3.4), so succession - escalates nothing beyond the origination role it transfers — - and appends exactly one ordinary mutation audit event - recording the prior designation, the new designation, the - acting principal, and the conferred grant where one was - written; it rewrites no fence row and no recorded outcome — - rows already recorded immutably retain their original actor. - Every successful successor therefore holds seed-completion - authority at commit: a read-only or tenant-unprivileged - capture that strands the suffix cannot exist, and if a later - designation loses that authority while staying - identity-eligible, the _unable_ disjunct of condition (a) - makes re-succession available — succession is repeatable - across successive origin losses, by inability as well as by - unavailability (witnesses §6.7). Concurrent successions - serialize on the epoch record: exactly one submitter commits - and becomes the seed-origin, and the loser, re-evaluated - against the committed winner, fails condition (a) — the - now-current origin is identity-eligible and, holding the - just-conferred seed-completion authority, able — and receives - the constant-shape refusal. The seed-boundary gate and the - origination rule always read the epoch record's current - designation: after succession the successor originates the - remaining suffix in order under its own full fresh-mutation - authorization (supplied by the conferred authority plus its - own eligibility), and the fence rows it originates record the - successor. Factory reset (§4.2) remains the only path to a new - epoch; it is never required to complete an interrupted seed - sequence. + state exists and identity §7.3 defers hard deletion) — and no + other origin-side condition exists: the origin's grant state + is never read, so no allowed grant change (including an origin + revoking its own position-1 `owner` grant) can make + succession's outcome differ between two worlds whose identity, + platform, and epoch state agree; and (b) the submitter is an + identity-§7.1-eligible platform admin holding §5.2 top-level + create eligibility. Condition (b) references no seed record + and no prefix: a tenant-unprivileged platform admin passes or + fails it identically whether or not any seed position is + committed. Because no input and no write depends on seed + state, the command's observables — response bytes, event count + and content, grant-table state — and its timing are identical + across any two worlds whose identity, platform, and epoch + state agree, whatever seed state either holds: succession + carries no existence oracle, unconditionally (witness §6.7 + two-world controls, self-revocation pair included). Any future + contract adding an account-removal or account-disable + mechanism MUST extend identity §7.1's single unavailability + predicate to cover it and MUST preserve the epoch record's + designation as a stable reference across it (a retained + identifier or tombstone — never a cascade that rewrites or + nulls the designation outside this command). A submission + failing either condition is refused with the same single + constant-shape bounded conflict as the seed-boundary gate, + byte-shape-identical whichever condition failed and whether + any seed fence exists, executes nothing, and appends no event. + Successful succession, in one transaction, updates the + designation in the epoch record and appends exactly one + ordinary mutation audit event recording the prior designation, + the new designation, and the acting principal — nothing else; + it writes no grant, rewrites no fence row and no recorded + outcome — rows already recorded immutably retain their + original actor. What succession transfers is the origination + role alone: the §4.3 designation-derived authority to + originate the unoriginated suffix, and nothing else. Because + that authority derives from the designation itself, never from + a revocable grant, no inability state exists — a designation + that lost every grant still completes the suffix — and + succession over a fully completed sequence is harmless by + construction: there is nothing left to originate, so the + successor gains no authority over any existing record. A + successor who originates position 1 becomes the seed company's + initial owner exactly as any §5.2-eligible creator of a + top-level company would (contract 2 §4.3 default) — an + authority §5.2 already grants, not an escalation. Succession + recovers **seed-sequence completion**, never tenant ownership: + recovering ownership of an existing company whose owners are + all unavailable is an account-administration surface of the + identity and RBAC contracts, expressly out of this contract's + scope. Concurrent successions serialize on the epoch record: + exactly one submitter commits and becomes the seed-origin, and + the loser, re-evaluated against the committed winner, fails + condition (a) — the now-current origin is identity-eligible — + and receives the constant-shape refusal. The seed-boundary + gate and the origination rule always read the epoch record's + current designation: after succession the successor originates + the remaining suffix in order under its own full + fresh-mutation authorization (§4.3 designation-derived + authority plus its own eligibility), deriving every tuple from + canonical settings state alone — no replay of any committed + position is needed or implied — and the fence rows it + originates record the successor. Succession is repeatable + across successive origin losses. Factory reset (§4.2) remains + the only path to a new epoch; it is never required to complete + an interrupted seed sequence. - **No error replay.** The fence row commits only with its mutation, so only committed outcomes are ever recorded. A failed or refused submission records no fence row; a retry executes @@ -797,14 +876,18 @@ collects no sensitive category, so v1 ships no custody surface. only the remainder executes, without duplication and without compensating rollback of completed commands. There is no wizard-level transaction spanning steps. Loss of the seed-origin - account mid-sequence — by unavailability (identity §7.1) or by - loss of seed-completion authority — is likewise recoverable - without a new epoch: §4.3 seed-origin succession designates an - eligible successor, confers the position-1 authority where the - seed company exists, and the resumed run completes the remaining - suffix under the successor; succession is repeatable, so - interrupted runs strand nothing even across successive origin - losses. + account mid-sequence — identity §7.1 unavailability — is likewise + recoverable without a new epoch: §4.3 seed-origin succession + designates an eligible successor, and the resumed run completes + the remaining suffix under the successor's designation-derived + authority, deriving every tuple from canonical settings state + alone — no grant is conferred and no committed position is + replayed. Succession is repeatable, so interrupted runs strand + nothing even across successive origin losses. Origination + authority is designation-derived (§4.3), never grant-dependent, + so no revocation — including an origin revoking its own + position-1 `owner` grant — can strand the suffix while the + origin remains available. ## 5. Seeding authority (resolves contract 2 review NEW-1) @@ -829,8 +912,11 @@ collects no sensitive category, so v1 ships no custody surface. is required. Until that ruling, deny-by-default holds (contract 2 §3.1): no implicit creation authority exists. 3. Child-node creation inside the wizard (estate, project, workspace - under the seeded company) follows contract 2 §4.3 unchanged: parent - `owner` authority, no automatic grant needed. + under the seeded company) follows contract 2 §4.3: parent + `owner` authority, no automatic grant needed — for canonical seed + origination, the parent-authority component is satisfied by the + §4.3 designation-derived authority (§7 item 12); outside the + canonical seed key set the rule is unchanged. ## 6. Verification requirements @@ -853,7 +939,17 @@ Binding on the implementing PRs: write, and the applicable JIT writes, nothing else; each internal write is asserted to invoke the owning command family's ordinary write implementation (no parallel write path); and the handler is - asserted refused once the epoch has completed (identity §3.4). Wizard modules appear in no + asserted refused once the epoch has completed (identity §3.4). + **Succession-write inventory:** the §4.3 succession handler's + internal write set is statically enumerated and asserted equal, in + both directions, to: the epoch record's designation update plus + its single audit event (and the audit family's required outbox + record where one exists) — no `hierarchy_grants` write, no + fence-table write, no settings write, no hierarchy or content + write, nothing else; and the handler is statically asserted to + read no fence table, no recorded outcome, no grant table, and no + hierarchy record — its inputs are identity state, platform + eligibility, and the epoch record only (§4.3). Wizard modules appear in no class-table writer allowlist (contract 1 §6.3b) and hold no direct database or filesystem access (static assertion, plus a runtime probe that a wizard-context filesystem/database access attempt is @@ -1030,14 +1126,13 @@ Binding on the implementing PRs: canonical seed tuple set, submitted with `shared` declared by an actor fully authorized for the mutation — is refused with the §4.3 validation refusal, executes nothing, and records no fence - row (asserted absent); an **out-of-order shared declaration** — + row (asserted absent); an **out-of-order origination** — with the seed prefix committed through position k, the - seed-origin account submits the position k+2 tuple (past the - next unrecorded position), constructed by the test harness from - ids it obtained out of band — and is refused with the §4.3 - validation refusal, executes nothing, and records no fence row, - proving the prefix-aware derivation rejects positions the - canonical walk cannot yet derive; an **unrecorded-seed-key + seed-origin account submits the position k+2 canonical tuple + (past the next unrecorded position) — and is refused with the + §4.3 validation refusal, executes nothing, and records no fence + row, proving in-order origination is enforced even though every + tuple is derivable at any state; an **unrecorded-seed-key race** in two variants — (child variant) with one child seed tuple deliberately left unrecorded, an actor lacking that seed command's hierarchy authority races the seed-origin account's @@ -1070,71 +1165,104 @@ Binding on the implementing PRs: the recorded outcome — proving actor equality is never a substitute for live target-result read authority on any replay mode; **seed-origin succession witnesses (§4.3, NEW-11 through - NEW-14):** a **succession recovery** — the seed-origin account + NEW-17):** a **succession recovery** — the seed-origin account commits a proper seed prefix and is then banned (identity §7.1); an eligible platform admin holding §5.2 top-level create eligibility submits succession, the epoch record's designation changes to the successor with exactly one mutation audit event - recording the prior designation, the new designation, the acting - principal, and the conferred position-1 grant, and the - successor's resumed run replays the committed prefix (its access - attributed by §4.3 replay access events, its read authority - supplied by the conferred grant) and originates the remaining - suffix in order — the new fence rows record the successor, the + recording the prior designation, the new designation, and the + acting principal — asserted to write no grant row and touch no + fence row — and the successor's resumed run derives the + remaining tuples from canonical settings state alone and + originates the suffix in order, never submitting a committed + position: zero replay access events name the successor, zero + grant rows name the successor, the mutation count equals exactly + the suffix length, the new fence rows record the successor, the pre-succession rows immutably retain the original origin, and the full seed set completes with no factory reset and no new epoch; an **origin-available succession refusal** — the same eligible admin submits succession while the current origin - remains §7.1-eligible and holds seed-completion authority — is - refused with the single constant-shape bounded conflict - (asserted byte-shape-identical to the collision refusal), - changes no epoch record, and appends no audit event; a - **succession two-world control (NEW-12)** — the SAME - identity-eligible, §5.2-create-eligible platform admin holding - no grant on any seed record submits succession in two prepared - worlds with the current origin banned in both: one where a - proper seed prefix stands committed and one freshly finalized - epoch with no position committed — and in BOTH worlds the - command succeeds, the designation changes to the submitter, and - exactly one succession audit event appends, with the response - asserted equal in shape and error/success class across the - worlds and the evaluation asserted within a fence-independent - timing bound (it consults no fence row); the control is repeated + remains §7.1-eligible — is refused with the single + constant-shape bounded conflict (asserted byte-shape-identical + to the collision refusal), changes no epoch record, and appends + no audit event; a **succession two-world control (NEW-12)** — + the SAME identity-eligible, §5.2-create-eligible platform admin + holding no grant on any seed record submits succession in two + prepared worlds with the current origin banned in both: one + where a proper seed prefix stands committed and one freshly + finalized epoch with no position committed — and in BOTH worlds + the command succeeds, the designation changes to the submitter, + and exactly one succession audit event appends, with the worlds + asserted equal in response bytes (modulo run-scoped + identifiers), in audit event content (the same field set and + classes, no seed reference and no grant reference in either), + and in grant-table delta (empty in both), and the full command + execution asserted within a fence-independent timing bound (it + consults no fence row and no grant row); the control is repeated with a submitter failing condition (b) — refused byte-shape-identically in both worlds, no record change, no - event in either — proving succession's outcome is a function of - fence-independent inputs only; a **tenant-unprivileged successor - completion (NEW-13)** — the successor of the two-world control's - recorded world, who held no seed-record authority before - succeeding, completes the entire remaining suffix using only the - conferred position-1 authority plus its own eligibility, proving - no read-only capture can strand the suffix; a **post-succession - grant-revocation re-succession (NEW-13)** — after an A→B - succession and further committed progress, B's conferred - position-1 authority is revoked while B remains - identity-eligible; an eligible, §5.2-create-eligible admin C - submits succession and succeeds through condition (a)'s _unable_ - disjunct, receives the conferred authority, and completes the - suffix — no factory reset, exactly one audit event for C's - succession; a **repeat succession (NEW-14)** — A is banned, B - succeeds and commits further prefix, B is then banned, C - succeeds and completes the suffix: each succession appends - exactly one event, every fence row records its true originator - (A's rows, B's rows, C's rows), and the seed set completes; an - **empty-prefix succession (NEW-13)** — the origin is banned - after finalize but before any seed position commits; the - successor succeeds (condition (b) evaluated with no seed record - in existence), originates the ENTIRE sequence, and position 1's - committed payload names the successor as initial owner — - asserting §3.4's derivation reads the current designation for - unrecorded positions; a **succession race** — with the origin - banned, two eligible, §5.2-create-eligible admins submit - succession concurrently: the epoch record serializes them, - exactly one commits and becomes the designated origin with one - audit event and the conferred authority, the loser receives the - constant-shape refusal (re-evaluated: the now-current origin is - eligible and able), and the seed sequence completes exactly once - under the winner; a submission that failed before commit + event in either — proving succession's outcome and observables + are a function of identity, platform, and epoch state only; a + **self-revocation two-world refusal (NEW-12)** — world U holds a + freshly finalized epoch with no seed position committed; in + world R the origin A originates position 1 (the outcome names A + initial owner by the contract 2 §4.3 default) and then, still + eligible, revokes its own `owner` grant on the seed company + (RBAC §4.1 authorizes it); identity, platform, and epoch state + now agree across U and R; an eligible platform admin B submits + succession in both worlds and is refused byte-shape-identically + in BOTH (the origin is available; grant state is not an input), + with no event and no record change in either — proving no + allowed grant change opens succession or leaks seed state; a + **designation-derived completion (NEW-12/NEW-13)** — origin A + originates a prefix, revokes its own position-1 `owner` grant, + and resumes: every remaining origination succeeds under the + designation-derived authority, zero new grant rows are written + beyond each command's own §5.2/§4.3 defaults, and the seed set + completes — proving completion never depends on a revocable + grant; a **tenant-unprivileged successor completion (NEW-13)** — + the successor of the two-world control's recorded world, who + held no seed-record authority before succeeding and receives + none by succeeding, completes the entire remaining suffix by + direct in-order origination using only the designation-derived + authority plus its own eligibility; a subsequent read attempt by + that successor against a committed pre-succession seed record is + refused — proving succession recovers completion without + conferring read or tenant authority; a **post-completion + harmlessness control (NEW-16)** — with the seed sequence fully + complete, the origin is banned and an eligible platform admin B + submits succession: it succeeds with exactly one audit event, + zero grant rows written, and zero hierarchy or content + mutations; B's subsequent attempts to read the seed company, its + children, or their content are refused — proving succession over + a completed sequence confers nothing; a **post-succession replay + (NEW-13)** — after an A→B succession, an admin holding explicit + target-result read authority on the recorded seed targets + derives position 1's tuple afresh from canonical settings state: + the derived payload is asserted byte-identical to the committed + one (digest equality — no payload field ever named the origin) + and the submission replays, returning the recorded outcome; a + **repeat succession (NEW-14)** — A is banned, B succeeds and + commits further prefix, B is then banned, C succeeds and + completes the suffix: each succession appends exactly one event, + every fence row records its true originator (A's rows, B's rows, + C's rows), and the seed set completes; an **empty-prefix + succession (NEW-13)** — the origin is banned after finalize but + before any seed position commits; the successor succeeds + (condition (b) evaluated with no seed record in existence) and + originates the ENTIRE sequence: position 1's committed payload + is asserted byte-identical to a control derivation performed + before the succession (digest equality — the payload names no + account), and the recorded outcome and its same-operation + initial `owner` grant name the successor — asserting the owner + binding follows the acting designation through the outcome, not + the payload; a **succession race** — with the origin banned, two + eligible, §5.2-create-eligible admins submit succession + concurrently: the epoch record serializes them, exactly one + commits and becomes the designated origin with one audit event, + the loser receives the constant-shape refusal (re-evaluated: the + now-current origin is identity-eligible), and the seed sequence + completes exactly once under the winner; a submission that failed before commit leaves no fence row and its retry executes; two concurrent resumed runs executing the seed sequence yield exactly one seed set — per key, exactly one mutation and one mutation audit event exist, and @@ -1221,14 +1349,18 @@ contracts and are not additions: actor-bound row additionally requires recorded-actor equality — never as a substitute for target-result authority — and a declared-mode mismatch is a collision. Including - the **shared-declaration boundary**: `shared` is server-verified - against the epoch's canonical seed key set (fence-independent, - derived from the epoch id and the fixed seed-role list) and its - prefix-derived canonical seed tuple set — each position's scope - and digest derived from the committed predecessors' recorded - outcomes — with a shared declaration outside the key set, off - its position's derived tuple, or past the next unrecorded - position refused recording nothing (§4.3). Including the + the **shared-declaration boundary and canonical-reference + resolution**: `shared` is server-verified against the epoch's + canonical seed key set and its canonical seed tuple set, both + fully derived from the epoch id, the immutable seed-parameter + provenance, and the fixed example set alone — no canonical seed + payload or scope contains a generated id or an account + identifier; child positions reference parents by epoch-scoped + canonical seed role, resolved to canonical rows server-side at + execution, available to exactly the canonical seed tuples — with + a shared declaration outside the key set or off its position's + derived tuple, and any origination past the next unrecorded + position (out of order), refused recording nothing (§4.3). Including the **seed-boundary gate**: the epoch's seed-origin designation initially names the first admin the finalize transaction created and changes only through item 12's succession command; @@ -1240,7 +1372,9 @@ contracts and are not additions: worlds are indistinguishable to the refused submitter — and origination of a missing seed fence is reserved to the seed-origin account passing the full fresh-mutation - authorization for that seed command (§4.3). Including the **replay access event**: a + authorization for that seed command, its hierarchy-authority + component satisfied by item 12's designation-derived authority + (§4.3). Including the **replay access event**: a distinct non-mutation audit event class, appended on every shared replay, recording the accessing actor, the current request's correlation ids, and the fence row returned — the @@ -1292,32 +1426,47 @@ contracts and are not additions: provenance for §3.4's derivation; the current company name lives on the company row and changes only through the ordinary hierarchy rename (§3.1, witnesses §6.3). -12. The **seed-origin succession command** (§4.3) — an amendment to - identity §3's epoch surface, proposed and ratified here, - severable: one mutating command that redesignates the epoch's - seed-origin to the submitter, valid only while the current - origin is **unavailable or unable** — it fails identity §7.1's +12. The **seed-origin succession command and the + designation-derived origination authority** (§4.3) — two + coupled amendments, proposed and ratified here, severable + together. First, an amendment to identity §3's epoch surface: + one mutating command that redesignates the epoch's seed-origin + to the submitter, valid only while the current origin is + **unavailable** — it fails identity §7.1's account-unavailability predicate (today exactly the better-auth ban; future removal or disable contracts must extend that one - predicate and preserve the designation, §4.3) or lacks - seed-completion authority — and the submitter is an - identity-§7.1-eligible platform admin holding §5.2 top-level - create eligibility, a condition evaluated against identity, - platform-eligibility, and epoch-record state only, never - against fence rows or seed-record grants, so its outcome and - timing are fence-independent (no existence oracle). Refusals - are the constant-shape §4.3 conflict regardless of which - condition failed; success is one audited epoch-record write - serialized on the epoch record that also confers, in the same - transaction and audit event, the position-1 initial-owner - authority on the seed company where position 1 has originated - — exactly the authority position-1 origination itself confers — - so every successor holds seed-completion authority at commit; - the command is repeatable (a later unavailable-or-unable + predicate and preserve the designation, §4.3) — and the + submitter is an identity-§7.1-eligible platform admin holding + §5.2 top-level create eligibility; both conditions are + evaluated against identity, platform-eligibility, and + epoch-record state only, never against fence rows, recorded + outcomes, grant rows, or hierarchy records, so the command's + outcome, observables, and timing are world-independent + unconditionally (no existence oracle). Refusals are the + constant-shape §4.3 conflict regardless of which condition + failed; success is one audited epoch-record write serialized on + the epoch record, whose closed write set (§6.1) is the + designation update plus its single audit event — it confers no + grant of any kind and grants no tenant authority; ownership + recovery for existing records is expressly out of scope + (§4.3). The command is repeatable (a later unavailable successor is succeeded the same way), and recorded fence rows - are never rewritten. Without this amendment a banned - seed-origin account strands the unoriginated seed suffix, - contradicting PRD D4's no-lock-in requirement (§4.4). + are never rewritten. Second, a scoped amendment to contract 2 + §4's authorization evaluation: the **designation-derived + origination authority** — for exactly the fresh origination of + a currently-unoriginated canonical seed position, the epoch + record's current designation itself satisfies the + parent-`owner` (or top-level) hierarchy-authority component of + fresh-mutation authorization; it confers no read authority, no + replay authority, no standing grant, no authority over any + committed record, and nothing outside the canonical seed key + set, is evaluated per submission, and writes nothing; every + other authorization component (§5.2 eligibility, identity §7.1 + eligibility) is evaluated fresh and unchanged. Together these + make origin loss recoverable with no escalation surface: + without them a banned seed-origin account strands the + unoriginated seed suffix, contradicting PRD D4's no-lock-in + requirement (§4.4). ## Ruling request