Chained records

State that expresses authority — who is admitted, who holds a role, which key speaks for a node, what a sequencer has sequenced — is never carried as a bare latest-value. It is carried as a chain: each record names its predecessor and its position, so that two histories cannot both be presented as one, and a gap or fork is evidence a verifier can hold up rather than a divergence nobody can see.

SOVM/1 has exactly one schema for this shape, instantiated eight times, and this page is its one home.

11. The schema

A chained record is a COSE_Sign1 under the signature profile whose payload carries, in addition to its record-specific fields:

Field	Rule
generation	Unsigned, dense per authority — each new record for the same authority carries exactly one more than the record it supersedes
predecessor	BLAKE3 hash of the exact bytes of the predecessor record (one hash); absent only on a chain’s genesis record

Verification rules, shared by every instantiation:

• A record whose generation is not exactly one greater than its predecessor’s MUST be rejected. Generations are therefore dense along a chain: a record supersedes exactly one record, and a verifier holding a chain’s genesis at generation 0 and its head at generation N either holds N+1 records or knows exactly which are missing.

• A record naming a predecessor the verifier holds, while a different record with the same generation and the same authority also verifies, is a fork: both records are retained as evidence and the condition is surfaced. A fork is never resolved by silently preferring one branch.

  Because generations are dense, two records naming one predecessor necessarily share a generation. The same-predecessor conflicts that SSP/1 15.3 and SOP/1 5.7 require to be surfaced are therefore exactly the forks this rule already surfaces, and no instantiation needs its own same-predecessor check.

• A record whose predecessor is unknown is held, not applied: the chain is fetched or the record stays inert. Application never skips links.

• The latest verifiable record wins for the authority’s current state; superseded records remain part of the chain’s history.

What “the authority” is — a site_id, a mesh, a group — is defined by the instantiation, and each instantiation states who may sign a link and what a link means. The schema is what makes those statements checkable.

The authority is the subject whose successive state the chain carries, which need not be the identity that signs a link: the membership-authorization chain’s authority is a mesh while any authorized node may mint a link, and the sequencing-receipt chain’s authority is a group while the identity bound to sequence it may change. Where the two differ the instantiation states its signer rule separately, and a change of signer is an ordinary link, not a new chain.

12. The instantiations

Chain	Authority	Normative home
Role assignments (sovm/ssp-role-v1)	The mesh, per node and role	SSP/1 scope §15.3
Custodian designations (sovm/ssp-custodian-v1)	The mesh, per subject and domain — a subject may be entitled in one domain and not in another, which a per-subject chain resolving to one head cannot express	SSP/1 scope §15.4
Capability requirements (sovm/ssp-capability-v1)	The mesh, one chain — not per subject; a fork resolves to the union of the branches rather than to absent, because absent would mean “require nothing”	SSP/1 scope §15.5
Module sets (sovm/ssp-modules-v1)	One node’s site_id (generation-only, as transport bindings; the instantiation page says why)	SSP/1 scope §15.6
Transport bindings (sovm/ssp-binding-v1)	One node’s site_id (generation-only: a binding supersedes all lower generations; the predecessor link is not required, and the page says why)	SSP/1 transport §28
Event-signing subkeys (sovm/ssp-eventkey-v1)	One node’s site_id (generation-only, as transport bindings; the instantiation page says why)	SSP/1 data model §10.1
Membership authorization records (sovm/sop-authorization-v1)	The mesh’s admission authority, one chain per mesh — not per subject and not per domain; any authorized node may mint a link, and a fork resolves to neither branch, the sequenced Commit resolving it while both branches are retained as evidence	SOP/1 §5.7
Sequencing receipts	One MLS group, by its opaque group_id; the generation is the group’s MLS epoch. The bound sequencer signs a link and is not the authority — a group’s chain is continuous across a sequencer migration	SOP/1 §22.5, §22.6

An instantiation MAY narrow this schema — the transport-binding chain drops the predecessor hash because a binding is wholly superseded, not appended to — but a narrowing is stated on the instantiation’s page, and an instantiation MUST NOT widen the schema or weaken a verification rule.

What an instantiation owes on a fork is its own to state. This section requires that both branches be retained and the condition surfaced, and forbids silently preferring one; it does not say what the authority’s current state is while the fork stands. Instantiations differ there, and the difference is a safety judgement rather than a style: a forked role chain resolves as absent, which is deny-safe because policy fails closed on a missing layer, while a forked capability-requirement chain resolves as the union of the branches, because absent there would read as “require nothing”. An instantiation whose page is silent on this has not finished stating its rules.

13. What this schema does not provide

A chain proves ordering and detects equivocation within one authority’s records. It does not order records across authorities — that is what hybrid logical clocks and the sequencer exist for — and it does not make an authority honest. It makes a dishonest authority attributable: two signed records at one generation are a proof, portable to any third party, that the authority equivocated.

Cold-start verification cost is a known limitation: the §5.7 authorization chain carries no checkpoint, so a cold verifier replays it from genesis. That is stated here rather than silently accepted.