mosaicstack/stack
20
0
Fork 1
Code Issues 335 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
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