mosaicstack/stack
21
0
Fork 1
Code Issues 336 Pull Requests 13 Actions Packages Projects Releases 15 Wiki Activity

contract 7 rev 12: pure designation transfer, epoch-derived account-free seed tuples, designation-derived origination authority
ci/woodpecker/pr/ci Pipeline was successful
Details

Browse Source 
Answers sol re-review 10 (NEW-12/NEW-13/NEW-14 residuals, NEW-16, NEW-17):

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