{"body":{"CONSEQUENCES":{"severed_couplings":[{"coupling":"The coupling between the verification candidate set C_s and a submitted_for_verification record the formal system never defines. v1.1's session-scoped rewrite derived candidacy 'from the chain's own entries' — but the entry it named appears in no object definition, no issuer table, no schema, no condition R1 through R9, and no published witness including run 20's, so the derivation was anchored to a type that exists only in the algorithm's prose, and a literal conforming implementation computed C_s = ∅.","id":"REG-61 (the undefined-entry-type coupling)","re_derived_by_decision":"Candidacy is RE-DERIVED, not abandoned, and the derivation is the decision: every candidate MUST belong to the commissioned node set N_s; the derivation input MUST be integrity-bound by the session's execution_result — evidence the result does not bind is not input; attribution of the evidence to a node is classed proxy when the session covered multiple nodes, through the derived-attribution mechanism; ABSENCE of sufficient bound evidence means the node is not a candidate — candidacy fails closed (I5), and an unevidenced node routes to retry or the breaker rules, never to verification; and the derivation procedure is defined by Profile One and inspected under CONSTRUCTOR conformance, per this document's own rule that structure is not history. No new mandatory witness entry type is minted, so no sealed record is retroactively orphaned.","severed_by":"The derive-based rewrite: C_s ← ENGINE.derive_verification_candidates(N_s, execution_result, bound_output_artifacts(execution_result)), and the derived-attribution paragraph recast so the engine-log events recording claiming, submission, and verification passes are exactly that — engine-log events the derivation MAY consume, never formal witness entry types the evaluator sees or requires."},{"coupling":"The coupling between the sentence 'conformance is demonstrated per-record, permanently' and the three conformance levels Section 11 actually defines. Written at v1.1 to bound Trial 0's results, the unqualified sentence silently flattened bundle, constructor, and operational conformance into one word, so a reader could take a passing record as speaking for the constructor or its operation — the exact inflation the per-record rule exists to forbid.","id":"the flattened-conformance coupling","re_derived_by_decision":"The boundary is re-derived as the SAME one Trial 0's ratification manifest, Section 12A's original closing sentence, and successions 4 and 5's successor_does_not_claim already carry — now stated inside the document's own conformance sentences so it cannot be inflated by citing the sentence without its context. The grandfathering sentence stands: conferring conformance on the tooling that produced a passing record would be exactly the counterfeit this specification defines.","severed_by":"The narrowing in the header status paragraph and Section 12A: BUNDLE conformance is demonstrated per-record, permanently; CONSTRUCTOR and OPERATIONAL conformance require their own inspection and audit under Section 11's three levels; and no passing record confers either on the tooling that produced it."}],"statement":"What this amendment SEVERS, as distinct from what it invalidates. An invalidated artifact is regenerated from its sources; a severed coupling must be RE-DERIVED BY A DECISION, and the decision is named here rather than left for an implementer to infer."},"amended_files":{"files":[{"digest":"cf00d60828596354f6694f19fa8b1e64988af52a7343c524faf8159a03a2d4f4","path":"docs/gad-formal-spec.md"}],"statement":"The files this succession amended, each digest hashed from the bytes on disk at build time, never transcribed. v1.2 amends exactly one digest-frozen file: the specification itself (the header status sentence, Section 2's Algorithm 1 with its derived-attribution paragraph and the new Derived candidacy paragraph, the Executor exit object definition, Section 12A's reference-implementation passage, the version line, the reworked v1.0 and v1.1 history entries plus the new v1.2 entry, and the closing line). The amendment's arc also touched the companion register (REG-60, REG-61, and REG-62 appended; REG-61's status line moved to CLOSED by this succession, no other entry touched); the register is cited by identifier throughout this record and deliberately NOT by digest: it is the append-only companion whose next append is this very record's citation, and a digest here would freeze the document this record exists to be cited by."},"amendment_class":{"demonstrated_by":"The engine's candidate derivation and the supervisor's between-sessions verifier operate the derivation this amendment defines, and this run's own gated record is produced under it. Whether that record evaluates referee-valid with R7 evaluated is REG-59's closure question, judged over the record after this ceremony seals, and not claimed here (see successor_does_not_claim).","found_by":"external review of the sealed v1.1 (REG-61, July 16, which also confirmed the v1.1 session-scoped rewrite's substance), arriving through the companion register, which remains the only channel through which this document learns that it must change.","statement":"v1.2 is a TYPE-COMPLETENESS amendment, and its class is stated here so the boundary cannot be inflated by citation: the verification candidate set C_s is made derive-based and fail-closed, discharging REG-61 (v1.1 defined C_s by a submitted_for_verification record the formal system never defines; v1.2 derives C_s by the engine — ENGINE.derive_verification_candidates over the commissioned node set N_s, the session's execution_result, and the executor output artifacts that execution_result binds by digest — under five normative requirements in the new Derived candidacy section, minting no new witness entry type, so no sealed record is retroactively orphaned; the former submitted_for_verification, claimed, and verify_pass mentions are recast as engine-log events the derivation MAY consume, never witness entry types the evaluator sees); the version history's succession numbering is made explicit (v1.0 is succession 4, v1.1 is succession 5, v1.2 is succession 6, each entry citing its signed record file); the conformance sentence is narrowed in the header and Section 12A to BUNDLE conformance per-record, with CONSTRUCTOR and OPERATIONAL conformance requiring their own inspection and audit under Section 11's three levels; three clarifications land (the session object constructed explicitly before dispatch; succession termination explicit and total at both SUCCEED sites; completed defined to necessarily imply exit code zero); and NO conformance requirement was weakened — every existing R-condition and predicate stands as strong or stronger, exactly as REG-61's closure records."},"authority":{"executor_role":"The executor authored this text and computed these figures under the succession-6 arc's nodes (the v1.2 text by s6-01; this record by s6-02), and applied the operator's key to the canonical body at the operator's direction. It did not authorize the succession. The authority is the operator's, recorded here by name, exercised by commissioning the plan, by the GATE ceremony that released this node (the logged authorization naming the node AND the out-of-band approval file carrying the secret the executor structurally cannot forge — REG-51's surface, both channels the operator's own act), and by holding the signing key outside this repository where only the operator controls it. Authoring and computing are not authorizing (succession 1's division, RUL-11's ratification).","named_authority":"Brandon King","performed_by_executor":false,"role":"the operator","rule":"The authority is the operator, named in the record. No other party MAY perform a specification succession; in particular the executor of a governed run MUST NOT perform one, and a ruling recorded in the companion register is not itself an amendment of this document (spec Section 15, Authority)."},"changed":[{"authored_by":"the s6 run (s6-01), against the tree this ceremony seals","change":"The conformance sentence is narrowed: 'conformance is demonstrated per-record, permanently' becomes 'BUNDLE conformance is demonstrated per-record, permanently, while CONSTRUCTOR conformance and OPERATIONAL conformance require their own inspection and audit under Section 11's three levels, and no passing record confers either on the tooling that produced it.' The rest of the paragraph stands.","section":"Header status paragraph (the companion line under the version line)","why":"The unqualified sentence flattened Section 11's three conformance levels into one, letting a reader take a passing record as speaking for the constructor or its operation. The narrowing states in the document's own status sentence the boundary Trial 0's ratification and Section 12A already drew (REG-61's companion finding)."},{"authored_by":"the s6 run (s6-01), against the tree this ceremony seals","change":"Four changes. (1) The verification candidate set is made derive-based and fail-closed, discharging REG-61: C_s ← ENGINE.derive_verification_candidates(N_s, execution_result, bound_output_artifacts(execution_result)), with a new Derived candidacy paragraph carrying five normative requirements (candidates from N_s only; derivation input integrity-bound by the execution_result; proxy attribution on multi-node sessions; absence of sufficient bound evidence means not a candidate, fail closed, routing to retry or the breaker rules and never to verification; the procedure defined by Profile One and inspected under constructor conformance) and the derived-attribution paragraph recast so the engine-log events recording claiming, submission, and verification passes are inputs the derivation MAY consume, never witness entry types. (2) The session object is constructed explicitly BEFORE dispatch, as the object the dispatch commissions, SUPERVISE_EXECUTOR supervises, and the exit and result attach to. (3) Succession termination is made explicit and total at both SUCCEED sites: SUCCEED(P), THEN the run loop for the predecessor P terminates as a whole, never a bare break a reader could scope to an inner loop, with the sealing and export lines running as P's record lifecycle. (4) The failed-session condition and the exit comment state that completed NECESSARILY implies exit code zero, making the status test total over exit codes (I5).","section":"Section 2, Algorithm 1 (CONSTRUCT), its derived-attribution paragraph, and the new Derived candidacy paragraph","why":"External review of the sealed v1.1 found REG-61: v1.1's C_s depended on a submitted_for_verification record appearing in no object definition, no issuer table, no schema, no condition, and no published witness, so a literal conforming implementation computed an empty candidate set. The rewrite defines candidacy over evidence the formal system actually carries; the three companion clarifications close the smaller ambiguities the same review named. No conformance requirement is weakened, and no new witness entry type is minted, so no sealed record is retroactively orphaned."},{"authored_by":"the s6 run (s6-01), against the tree this ceremony seals","change":"One sentence added: 'status = completed NECESSARILY implies exit_code = 0: an exit reporting completed with a nonzero exit code is malformed, never completed, which makes a status test against completed total over exit codes (I5).'","section":"Section 8 object definitions, Executor exit","why":"The status enum and the exit code were separately recorded with their consistency left implicit, so a status test against completed was not demonstrably total over exit codes. Stating the implication makes the malformed case explicit and the test total (REG-61's companion finding)."},{"authored_by":"the s6 run (s6-01), against the tree this ceremony seals","change":"The conformance sentence is narrowed in parallel with the header: 'those are demonstrated per-record, permanently, and no record confers conformance on the tooling that produced it' becomes 'BUNDLE conformance is demonstrated per-record, permanently; CONSTRUCTOR and OPERATIONAL conformance require their own inspection and audit under Section 11's three levels, and no passing record confers either on the tooling that produced it.' The grandfathering sentence stands unchanged.","section":"Section 12A, 'On the reference implementation'","why":"Same defect as the header, second instance: the passage flattened the three conformance levels. The correction names them, so the passage can neither understate the record nor inflate it."},{"authored_by":"the s6 run (s6-01), against the tree this ceremony seals","change":"The version line reads 'Version 1.2 draft · Atlas North Institute · July 2026'; the v1.0 and v1.1 history entries are reworked to name their successions explicitly (v1.0 is succession 4 with its signed record at succession/delta/succession-4.json; v1.1 is succession 5 with its signed record at succession/delta/succession-5.json — their substance unchanged); one v1.2 entry is appended naming succession 6 and its signed record at succession/delta/succession-6.json; the document ends 'End of v1.2 draft.' All earlier history entries' facts stand intact.","section":"Version line, version history, closing line","why":"The history named successions 1 through 3 explicitly but recorded v1.0 and v1.1 without their succession numbers or record files, leaving the lineage's own numbering implicit in its most recent entries (REG-61's companion finding). The header, history, and closing line are part of the bytes the successor digest freezes and must agree with each other and with the record beside them (REG-35's discipline applied to both ends of the document)."}],"discharges":{"by_this_amendment":[{"how":"C_s is DERIVED BY THE ENGINE, after the session closes, from the closed session's integrity-bound evidence: ENGINE.derive_verification_candidates over the commissioned node set N_s, the session's execution_result, and the executor output artifacts that execution_result binds by digest. Five requirements are normative in the new Derived candidacy section: every candidate MUST belong to N_s; the derivation input MUST be integrity-bound by the execution_result; attribution is classed proxy when the session covered multiple nodes; ABSENCE of sufficient bound evidence means the node is not a candidate — candidacy fails closed (I5), routing the unevidenced node to retry or the breaker rules, never to verification; and the derivation procedure is defined by Profile One and inspected under CONSTRUCTOR conformance. The former submitted_for_verification, claimed, and verify_pass mentions are recast as engine-log events the derivation MAY consume — never formal witness entry types the evaluator sees or requires — so no new mandatory entry is minted and no sealed record is retroactively orphaned. The same review's four companion findings land beside it: explicit succession numbering in the version history, the narrowed bundle-conformance sentence, the explicitly constructed session object, total succession termination, and completed implying exit code zero. No conformance requirement was weakened.","id":"REG-61","status":"CLOSED by succession 6 (this record), per the register's own entry","what_was_discharged":"Algorithm 1 as amended at v1.1 defined the verification candidate set C_s by a submitted_for_verification record that the formal system never defines: the entry type appears in no object definition, no issuer table, no schema, no condition R1 through R9, and no published witness including run 20's — so a literal conforming implementation computes an empty candidate set. Found by external review of the sealed v1.1, which otherwise confirmed the session-scoped rewrite's substance."}],"cited_rulings_not_discharged_here":[{"id":"REG-59","status":"OPEN; the gate this ceremony finally ran under","why_cited":"The typed gate plane REG-59 registered as unwired is the plane this node's gate ran on: typed gate_request and approval appended by the supervisor's principal pen, ordered before the withheld terminal, alongside the REG-51 approval-secret surface. The entry closes when a gated ceremony produces a live record the evaluator accepts with R7 evaluated — this run is that attempt, and the acceptance judgment happens over the record after this delta seals, so the closure is the register's to record, not this record's to claim."},{"id":"REG-62","status":"OPEN as a register ruling plus product work; its interim doctrine applied by this plan","why_cited":"A gated node with dependents cannot yet yield a valid record under whole-remaining-plan commissioning (the flagged RUL-8 question, proven by Wave 9's probe). This plan applied the interim doctrine exactly: the gated node is LAST, no dependents sit behind the gate, and the whole-referee exit is folded into the gated node's own checks. The ruling on commissioned sets excluding gate-blocked dependents remains the register's to land and is not made here."},{"id":"REG-60","status":"OPEN as engine work","why_cited":"Run 30's first verification attempt recorded mixed-outcome pass verdicts without probe bindings; the engine fix (binding probe artifacts identically on mixed-outcome and clean attempts) and its closing probe are engine work in atlas-orchestrator, registered open and not performed by this succession."},{"id":"REG-54","status":"OPEN; the referee's ruling this choreography obeys","why_cited":"Verification belongs between sessions, in nobody's session — the placement the session-scoped Algorithm 1 states and the choreography this record was produced under. The entry's own closure condition is the register's to judge, not this record's to claim."},{"id":"REG-48","status":"OPEN; ruling RESTED with its July 16 precision amendment","why_cited":"Verification is post-quiescence by the specification's semantics; this record was produced under the between-sessions choreography (see session_choreography). The entry closes only when a live-choreography record evaluates fully referee-valid, which this record does not claim (see successor_does_not_claim)."},{"id":"REG-56","status":"OPEN as product work (Wave 8)","why_cited":"A completed run must be inert. This run obeys the interim procedural rule (no sessions after the run's final verification lines); the engine-level refusal of dispatch over a terminal-carrying witness remains product work and is not claimed here."}],"statement":"v1.2 discharges exactly one register entry: REG-61, closed by this succession's derive-based C_s rewrite. The register's own entry records the closure as 'CLOSED by succession 6, the derive-based C_s rewrite in the v1.2 amendment'; this record is that succession, and the citation below is the discharge. Every other ruling this ceremony operates under is cited beside it with its register status, none of them discharged here."},"gate_channel":{"rule":"The Wave 9 typed gate plane, wired: this ceremony's node is GATED, the first fully gated ceremony under protocol mode — exactly the ceremony succession 5's record forecast when it proceeded gateless under REG-59 and named succession 6's as the first gated one. The node is the plan's FINAL node per REG-62's interim doctrine: gated nodes are placed LAST, with no dependents behind the gate, the whole-referee exit folded into the gated node's own checks, because a gated node with dependents cannot yet yield a valid record under whole-remaining-plan commissioning (the flagged RUL-8 question REG-62 records).","what_happened":"The operator's one ceremony released this node through BOTH channels at awaiting_approval: the logged authorization naming this node, and the out-of-band approval file carrying the secret the executor structurally cannot forge (REG-51's surface). The typed gate_request and approval are appended by the supervisor's principal pen, ordered AFTER this node's between-sessions verdicts and BEFORE the run's withheld terminal, relayed from the operator's ceremony. The signature over this record remains the ceremony's substance, exactly as it was for every predecessor: the operator's human act with the authority key, performed through the established signing flow, the key verified to derive the committed public half before it signed, key material never entering this repository.","what_this_makes_possible":"REG-59 closes when a gated ceremony produces a live record the evaluator accepts with R7 evaluated. This run is that ceremony's ATTEMPT: whether its finished record evaluates referee-valid with R7 evaluated is judged over the record AFTER this delta seals — the register's judgment, not this record's claim (see successor_does_not_claim). REG-62's ruling on commissioned sets excluding gate-blocked dependents likewise remains the register's to land; this plan merely obeyed the interim doctrine."},"genesis_disclosure":{"predecessor_authorization":"v1.1's Section 15 defines the only ceremony by which this document changes, and this succession is performed under it: object identified by byte digest, authority the named operator, record a signed sidecar the register cites, delta carrying the seven mandatory items, numbered in sequence from 1.","predecessor_authorized_this_amendment":true,"statement":"Succession 6 is NOT genesis and claims no genesis exception. It is the fifth specification succession governed by a rule that predates it: Section 15's ceremony was introduced by v0.7 and carried intact through v0.8, v0.9, v1.0, v1.1, and into the v1.2 text this record seals. Succession 1's disclosure is not softened, removed, or restated here: it remains true of succession 1, and every succession after it being ordinary is exactly what it predicted.","this_is_genesis":false},"invalidated_artifacts":{"classes":[],"classes_note":"COMPUTED ZERO classes: v1.2 amends no tool and weakens no conformance requirement; its changes are the derive-based C_s, the explicit succession numbering, the narrowed conformance sentence, three clarifications, the version line, the history entries, the closing line, and this arc's register movements. The zero is grounded in the manifest's amendment_diff (the set of paths changed between the pinned v1.1 and v1.2 commits, required to name nothing but the two governed documents), not asserted. What this succession replaces is the invalidation manifest itself, exactly as every succession before it did.","manifest_digest":"f7d91dd5a13f0ae88d9506ccf0c2afea436296a751fc0316be0e1ea18f0a9f3e","manifest_path":"succession/manifest/invalidation-manifest.json","named_by":"class, with the cited digest of a manifest COMPUTED from the tree by succession/manifest/build-manifest-6.mjs","predecessor_manifest":{"commit":"26e5f9529119c99bc38d21420d512756d2ec2b3d","digest":"2773c36b99ca7acc9156a44621529751a2df0a552bb50d40ff7926737c4e29c4","provenance":"Succession 5's manifest, whose bytes this succession's manifest replaces at the same path. The blob at commit 26e5f9529119c99bc38d21420d512756d2ec2b3d was hashed and required to equal the digest succession-5.json cites BEFORE this record was written, proving these are the bytes succession 5 signed over and that they had not moved since (they landed at the s5-02 commit and stand unchanged at this pin, whose later appends touched only the register). NOT recomputable from this tree once replaced: recoverable from the commit that landed them, exactly as v1.1's spec bytes are recoverable from theirs. tools/succession-verify.mjs reports succession 5's cited manifest digest as RECORDED, NOT VERIFIED now that succession 5 is no longer the latest record (REG-33's lineage rule).","recomputable_from_this_tree":false},"predecessor_members_comparison":{"members_moved":0,"members_recorded":0,"note":"Computed by build-manifest-6.mjs and VACUOUS BY CONSTRUCTION: succession 5's manifest recorded zero members (its classes were themselves a computed zero), so there was nothing to re-hash. Stated honestly rather than dressed up as evidence; the load-bearing grounding is the manifest's amendment_diff beside it."},"rule":"The manifest MUST be computed and MUST NOT be a hand-typed list: such a list is stale the moment any of its members moves, and a recited figure is not a computed one.","scope_note":"gad-protocol only. atlas-orchestrator and waypoint are NAMED in the manifest, with a stated reason, and are NOT read, NOT hashed, and NOT touched: a graph that amended the specification and its constructor in one run would be the constructor editing its own referee. They are judged against this successor by their own governed runs — and REG-60's engine fix and REG-62's commissioning work are theirs to build, not this run's."},"object":{"document":"docs/gad-formal-spec.md","identified_by":"byte digest of the frozen text, never by version label alone: a label is not an identity (spec Section 15, Object)","successor_digest":"cf00d60828596354f6694f19fa8b1e64988af52a7343c524faf8159a03a2d4f4"},"predecessor_record":{"path":"succession/delta/succession-5.json","provenance":"sha256 of succession-5.json's bytes on disk at build time — the record-level chain link, computed and never transcribed. The lineage's continuity is verified by tools/succession-verify.mjs over the spec digests (each predecessor digest equal to the prior successor digest); this figure additionally binds WHICH record bytes this succession chained from.","record_digest":"0587d3ab171691ec53cd9ce3a6b3b29c85dc91df6e200ff0499f4c2e3eaccd6b"},"predecessor_spec_digest":{"commit":"26e5f9529119c99bc38d21420d512756d2ec2b3d","digest":"86c8ea8c37bcb4243112032dd5f0016d4815eaca367371b051112936a14a05ab","provenance":"succession 5's successor digest, read from succession/delta/succession-5.json rather than transcribed, which is what makes the chain continuous by derivation instead of by assertion. Those bytes are the blob at commit 26e5f9529119c99bc38d21420d512756d2ec2b3d, the last committed tree in which this document was v1.1 (the commit that landed REG-62's register append; the v1.2 text landed in s6-01's two commits after it); that blob was hashed and required to equal this figure before this record was written. NOT recomputable from this tree's working document: v1.1's bytes left it with v1.2's landing, and tools/succession-verify.mjs reports this figure as RECORDED, NOT VERIFIED rather than implying it rechecked it (REG-33's lineage rule).","recomputable_from_this_tree":false,"version_label":"1.1"},"record":{"cited_by":"docs/gad-spec-register.md","lives_at":"succession/delta/succession-6.json","rule":"The record of a specification succession lives in gad-protocol as a signed sidecar beside this document, and the companion specification register cites it. The register remains the channel through which this document learns that it must change; the succession is how it changes.","verified_by":"tools/succession-verify.mjs"},"record_type":"gad-spec-succession-delta","session_choreography":{"rule":"REG-48 (ruling rested July 16, 2026, with its precision amendment) and REG-54 (the referee's own ruling): verification is post-quiescence by the specification's semantics, and it belongs BETWEEN sessions, in nobody's session, exactly where the session-scoped Algorithm 1 places it — the algorithm whose verification candidate set this very amendment makes derive-based and fail-closed (REG-61's discharge).","what_happened":"This record was built and signed inside a session with BETWEEN-SESSIONS verification: the executor claimed and submitted the ceremony node and exited; the recorded verdicts are the supervisor's, computed after quiescence over the captured delta, each verdict lying strictly between its node's execution_result and that node's next dispatch. Because this node is GATED, the typed gate entries land after those verdicts and before the run's withheld terminal. Producing this record under that choreography is an instance of the ruling — and of the derive-based candidacy this very amendment seals — not the referee-valid live-choreography evaluation REG-48's entry still awaits (see successor_does_not_claim)."},"signature_scope":{"construction":"SIGN_x(obj) = {body: obj, signature: sig_x(canon(obj))}; the signature covers the canonical body and is never a member of it.","key":"the operator authority key (RUL-9, RUL-11 clause 2); public half committed at succession/keys/operator-pubkey.json, private half never in this repository","what_this_signature_ATTESTS":"that this delta's text and figures are the ones bound at signing time, and that they have not moved since; that the party who bound them holds a key whose private half has never entered this repository and which names an authority; and that the key was verified to DERIVE the committed public half before it signed (REG-38's derive-based standard, normative since v0.9, applied to its own signing moment). REG-38's checker is run over succession/ after signing and its computed zero is recorded in the exit-gate record beside this ceremony.","what_this_signature_DOES_NOT_ATTEST":"any registry identity beyond the named authority's custody of the key, and no claim that any implementation conforms to the successor. REG-14's key lifecycle design is normative text (v0.9, Profile One) but its implementation remains post-v1.0 and the register entry stays OPEN tracking it; until that implementation lands, a compromised key is handled by succession, not in-place revocation — the interim rule, stated in the specification rather than improvised at the incident. This is the sixth record that rule applies to."},"succession_number":6,"successor_does_not_claim":{"not_claimed":["GENERAL IMPLEMENTATION CONFORMANCE. The narrowed sentences state it in the document's own text now: record-level Trial 0 results establish BUNDLE conformance per-record, permanently; CONSTRUCTOR and OPERATIONAL conformance require their own inspection and audit under Section 11's three levels, and no passing record confers either on the tooling that produced it. No implementation — not the evaluator, not the engine, not the product — is claimed to conform to v1.2 in general.","RATIFICATION OF v1.2 ITSELF. v1.0 was ratified by Trial 0; v1.2, like v1.1 before it, is an amendment of the ratified text that no trial has evaluated, and its version line says 'draft' for exactly that reason. Nothing here extends Trial 0's ratification forward onto bytes the trial never saw.","THAT INDEPENDENT REVIEW HAPPENED. Phase 5's independent formal and cryptographic review is pending, and this succession did not perform it. Section 1's results remain Propositions and Claims, not Theorems, until it completes; until then GAD is a ratified implementation specification, not an independently validated standard.","THAT REG-59 CLOSED. This ceremony ran GATED on the typed gate plane — the very record class REG-59's closure names — but the entry closes only when the evaluator ACCEPTS the live record with R7 evaluated, a judgment made over the finished record after this delta seals. This record states the attempt and claims nothing about its verdict.","THAT R7 EVALUATED NON-VACUOUSLY. The typed gate_request and approval land after this node's between-sessions verdicts and before the run's withheld terminal; whether R7 evaluates non-vacuously over the finished record is the evaluator's finding over that record, not this record's claim.","THAT REG-60 CLOSED. The mixed-outcome probe-binding defect run 30 surfaced remains open engine work; its closing probe and the live failed-then-passed record its closure demands do not exist yet, and this succession did not build them.","THAT REG-62's RULING LANDED. This plan applied the interim doctrine (the gated node LAST, no dependents behind the gate); the ruling on commissioned sets excluding gate-blocked dependents, and the product work proving it, remain the register's and the engine's respectively.","THAT REG-54 OR REG-48 CLOSED. This record was produced under the between-sessions choreography those entries govern, and the derive-based candidacy now states its inputs exactly; but each entry's closure condition is the register's to judge over the records it names, not this record's to claim by having obeyed it.","THAT REG-14 IS IMPLEMENTED. The key lifecycle v0.9 designed (signed lifecycle entries, key_id supersession, forward-looking revocation) still has NO implementation; it remains post-v1.0 by the ruling itself, and the register entry stays OPEN tracking it.","THAT REG-29's GENERATOR HALF CLOSED. The nine invalid fixtures still have no generator, exactly as successions 2 through 5 disclosed; the blessing stands and the generator remains future work.","THAT REG-56's PRODUCT FIX EXISTS. This run obeys the interim procedural rule (a completed run is inert; no sessions after the final verification lines); the engine-level refusal of dispatch over a terminal-carrying witness remains Wave 8 product work.","ANY AUTHORITY OVER THE HISTORICAL RECORDS. Nothing recorded before this succession is reissued, recomputed, or re-read. Every prior version's history entry stands intact as fact (the v1.0 and v1.1 entries were reworked to name their successions, their substance unchanged), and succession 1's genesis disclosure is neither softened nor restated.","FINALITY. v1.2 is an amendment draft, not the specification's last word: per the stewardship rule, further revisions arrive from concrete implementation findings through the companion register and Section 15's ceremony, exactly as the six before it did.","THAT THE GENESIS PROBLEM IS SOLVED. Succession 1 disclosed it; this is the fifth succession that does not face it, which is not the same as solving it."],"statement":"The successor does not claim what follows, and says so here rather than leaving the boundary to be inferred from silence. v1.2 completes the type system Algorithm 1's candidacy depended on, narrows one conformance sentence to what Section 11 actually defines, and clarifies three smaller points, and nothing else."},"successor_spec_digest":{"digest":"cf00d60828596354f6694f19fa8b1e64988af52a7343c524faf8159a03a2d4f4","provenance":"sha256 of docs/gad-formal-spec.md as it stands in this tree, recomputed by tools/succession-verify.mjs against the bytes on disk. The version label is PARSED from that same document's header at build time, never recited, so the label cannot contradict the digest beside it (REG-35).","recomputable_from_this_tree":true,"version_label":"1.2"}},"signature":"0498ce9943254a0eeaf119d08aba22d54e20f75f31c1d494f504a3a25e6af5d0d4d9bb1ac48b336694648184ad88439050fd9090fd494a4a99284f885f8ad700"}