Field Record No. 5 · The Operator Signed the Specification's Lawful Successor

Record class: Specification-lineage record. Presentation revision 3: terminology and claim-boundary corrections applied per review; revisions 1 and 2 preserved byte-exact in this archive; underlying record bytes unchanged. Lineage scope: this page demonstrates the signed lineage through v0.9; later signed successions extend that lineage through v1.3. Current review status: this record accurately describes the v0.9 amendment as sealed on July 16, 2026. Fifth cross-model review has since accepted REG-75 and REG-76: the revocation rule requires treatment of uncertain compromise windows, and the key-material definition requires narrower naming or broader scope. These findings do not rewrite this historical record; they are registered for a future signed succession.

What happened

Governed AI Development's formal specification is frozen: no one, including its authors, may edit it in place. Amendments arrive only as successions — signed delta records that bind the new document's digest and chain to the previous amendment. Succession 3, sealed July 16, rested four debts the project's own register had carried for days:

REG-14 · key lifecycle. Rotation and revocation now have design-level rules: supersession only by a signed lifecycle entry naming both key ids; revocation is forward-looking, so a revoked principal's past signatures remain valid for the records they signed.

REG-37 · verification is a read. One sentence with teeth: verifying under a public key crosses no signing boundary. The succession verifier immediately used the ruling to start cryptographically verifying the genesis exhibit's signature instead of merely recording it.

REG-38 · what key material is. Now normative: a value is key material iff it parses as a private key or derives a public key the tree trusts. Pattern-matching on length or encoding is not a conforming check, because a secret scalar has no detectable shape.

REG-39 · when a probe counts. A planted-defect probe counts as fired only if it spawned, exited nonzero, and produced output. Adopted in the spec and in every checker in the repository.

The ceremony itself ran as a governed plan under the reference stack, with an approval gate that stopped the run until the operator's logged authorization named the ceremony node, and a signature performed with an authority key that never entered the repository. The proof of that last claim is not a promise: the derive-based checker born two nodes earlier swept the succession directory after signing. 17 files, 149 candidates, 0 findings.

The part worth reading

Getting here consumed four frozen plans in one arc — and zero edits to any of them. The first plan demanded a verification that its own first node made impossible (mid-ceremony, the lineage verifier is supposed to fail: the document is deliberately ahead of the sealed record). The executor refused to fake it, refused to waive it, and stopped. The second plan hit a gate the product could not honor: the two-channel irreversible approval's secret is deferred in the shipping product, so the gate was unpassable as authored. The plan was superseded to match the gate to the channel the product honors, with the gap recorded, rather than pretending a channel existed. The third plan's exit check overreached its own jurisdiction — it demanded an append-only register and a signed record body satisfy a style rule that only ever governed the spec — and the executor declined to break a signature to satisfy a checkbox.

Every one of those stops is in the register with its author named. The lineage that resulted is sealed, signed, and boring to verify — which is the point.

The full technical record, including the ceremony's mechanics and the commands to re-verify it, is below.

The lineage, as a stranger verifies it

Clone the repository, install, and run:

node tools/succession-verify.mjs --strict

Expected final line, quoted from the run this record describes:

succession:verify passed (3 record(s); lineage sealed at succession-3)

What that one line recomputes: every succession record discovered from the directory, every signature verified under the operator authority public key, each record's predecessor digest matched against the document the previous record sealed, and the latest record's successor digest matched against the v0.9 document on disk, byte for byte. The genesis is disclosed, never softened: v0.6 did not authorize its own amendment, and succession 1 carries a dev-signed exhibit saying exactly that — whose signature, since this ceremony's REG-37 adoption, is verified rather than merely displayed.

The ceremony, step by step, from the run

1 · Premise audit. The delta directory holds exactly successions 1 and 2; the strict verifier fails naming the unsealed v0.9 document (the honest mid-succession state this ceremony exists to cure); the authority private key's path is outside the repository, and finding any private material inside the tree is a stop, not a workaround.

2 · The gate. The run halts at awaiting_approval. It proceeds only on the operator's logged authorization naming the ceremony node — recorded verbatim, with the authorizer, in the chained audit log.

3 · The delta record. Built by a per-succession builder following the succession-2 shape: it binds the v0.9 spec digest and the amended files' digests, cites the register entries this ceremony rests, and chain-links to succession 2 by derivation — the predecessor digest is recomputed from the repository's own history and required to match, never copied on faith.

4 · The signature. The operator's Ed25519 authority key, read from its custody path outside the repository, verified to derive the committed public half before it signed, never printed, never copied. The human act at the center of the machine's ceremony.

5 · The sweep. Immediately after signing, the REG-38 checker swept the succession directory: 0 findings. Its own probe, run alongside, planted a freshly generated private key, the fixture authority's bare seed, and an HMAC chain key — and caught all three, each naming the clause that caught it, with a random negative control passing clean.

6 · The exit gate. Recorded green with figures computed by the tools, not recited: 11/11 checkers, 11/11 probes fired, gate at 18 checks, evaluator 30/30.

Four plans, zero edits: the stops, named

This section exists because the archive's rule is that defects are evidence. All four authoring defects below belong to the advisory layer that wrote the plans, and all four were caught by the machinery before they could corrupt a record.

REG-50 · the unsatisfiable invariant. Plan one demanded the lineage verify strict before the ceremony sealed it — an invariant modeled against the launch tree that the plan's own first node lawfully falsified. The executor ran its baseline first, found the demand impossible before touching anything, and stopped. The successor asserts the truth instead: mid-ceremony, strict must fail, naming the unsealed document.

REG-51 · the gate the product could not honor. The ceremony node was authored irreversible, requiring an out-of-band secret the shipping product defers and no surface supplies. Unpassable by construction. The successor matched the gate to the honored channel — the operator's logged, node-naming authorization — and recorded the gap as product work, with the custody rule the incident taught: the operator always holds a readable copy of any secret a verifier holds opaquely.

REG-52 · the check that overreached. The exit plan's style check swept an append-only register and a signed record body — artifacts whose only path to satisfaction is rewriting history or breaking the operator's signature. The executor refused both. The corrected check governs exactly what the rule ever governed: the specification, which was already clean.

And the register grew. Six new entries in one day, each naming its author. The fail-closed claim is not marketing here; it is the operating history of the people and tools that built this, preserved because a record that only remembers its successes is not a record.

What this record proves, and what it does not

It proves: the specification's amendment path works under governance, three times running; a signed, chain-linked lineage, re-verifiable by another party, exists from v0.6's disclosed genesis to v0.9; four governance rules moved from register debt to normative text; and the key-hygiene rule was enforced, by derivation, on the very act that sealed it.

It does not prove: that the amendments are correct (Propositions and Claims, per the spec's own header, until independent formal and cryptographic review completes); that the reference tooling is conformant (bundle conformance is per-record; constructor and operational conformance require their own assessment, never pedigree); or that the ceremony's approval gate is as strong as designed — the two-channel form awaits its product wiring, and this archive says so out loud.