{"body":{"CONSEQUENCES":{"severed_couplings":[{"coupling":"The coupling between the fail-closed candidacy promise and the prose that carried it. v1.2 stated that absence of sufficient bound evidence means a node is not a candidate and 'routes to retry or the breaker rules' — but Algorithm 1 gave the excluded nodes no algorithmic route: C_s was derived, its members verified, and the complement N_s minus C_s simply fell out of the algorithm's text, so the promise was narrated beside the algorithm rather than performed by it, and a literal implementation could leave an unevidenced node in limbo with no transition at all.","id":"REG-64 item i (the narrated-promise coupling)","re_derived_by_decision":"The route is RE-DERIVED as governed failure resolution, and the derivation is the decision: exclusion from candidacy is a FAILURE with a named reason, never a silent skip and never a pass-by-default; the transitions available to an excluded node are exactly the existing table's (retry, trip, halt, or succession), so no new failure vocabulary is minted; and the branch lives in Algorithm 1 itself, so transition completeness over the whole commissioned set is now a property of the algorithm's text, checkable by reading it, not a property of the prose around it.","severed_by":"The U_s branch: U_s = N_s minus C_s is computed explicitly, and every member's status is set FAILED with reason insufficient_bound_evidence, entering retry, trip, halt, or succession logic per the existing transition table."},{"coupling":"The coupling between C_s membership and an evidence standard the profile never stated. v1.2's derivation was engine-owned and fail-closed, but 'sufficient bound evidence' had no normative minimum anywhere: Profile One defined no floor, so two conforming constructors could disagree about what evidence confers candidacy, and the engine-log sentence left open whether unbound log events could feed the derivation.","id":"REG-64 items ii and the binding clarification (the unstated-sufficiency coupling)","re_derived_by_decision":"The standard is RE-DERIVED at two levels by decision: the MINIMUMS are the specification's (tool-agnostic, in Profile One), while the CONCRETE PROCEDURE is each constructor's, published and hash-identified so it can be inspected rather than trusted — the same structure-is-not-history division the derived-attribution mechanism already carries. Meeting the minimums does not by itself confer candidacy; absence of sufficient bound evidence still fails closed into the U_s branch. The alternative — the specification dictating one concrete procedure — was declined because it would bind every constructor to one engine's evidence shapes, exactly what a profile exists to avoid.","severed_by":"Option B: Profile One's Candidacy derivation minimums section states the floor (an execution-result-bound artifact identifying the node and binding its claimed completion boundary, the subject artifacts, and the relevant portion of the session delta); each constructor MUST publish and hash-identify its concrete derivation procedure, assessed under CONSTRUCTOR conformance; and the binding sentence pins engine-log consumption to events included in, or cryptographically bound by, the execution_result or its listed output artifacts."},{"coupling":"Two couplings between the document and its own description of itself. (iii) v1.2's succession exits said 'terminate CONSTRUCT for predecessor P' while the sealing lines below were still P's to run: the text described a termination its own lifecycle contradicted. (iv) The sealed v1.2 called itself a draft in its header and footer while its history entry claimed the signed succession-6 record: the stamping habit wrote 'N draft' into every amendment before sealing, so every sealed version's bytes carried a self-description that its own sealing falsified.","id":"REG-64 items iii and iv (the self-description couplings)","re_derived_by_decision":"The mid-succession signal is RE-DERIVED onto the machinery that already carries it honestly: strict verification FAILS naming the unsealed document from the moment the amendment lands until the record beside it is signed, which is a COMPUTED signal no stamped label can contradict — the lineage says 'unsealed', not the document about itself. The termination semantics are re-derived onto labels the algorithm's own text scopes, so what a succession exit skips (the rest of the run loop) and what it can never skip (the SEALING section) is decided by control flow a reader can trace, not by a prose word ('terminate') whose scope the prior review guessed at. The register records both origins fairly: the 'terminate' wording came from the prior review's own suggestion, and the draft stamping was the advisory assistant's habit, its twenty-first authoring defect.","severed_by":"(iii) Labeled control flow: break RUN_LOOP out of the labeled run loop, landing in the labeled SEALING section whose comment states it ALWAYS runs as P's record lifecycle — checkpointing and export are never skipped by a succession exit. (iv) The draft label retired: the version line reads 'Version 1.3', the document ends 'End of v1.3.', and no future amendment stamps a draft label."}],"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":"9c31d03f9c29cbf1ab882eb966cfeec7b1a16e37f3f4d5a6907405c9ab975892","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.3 amends exactly one digest-frozen file: the specification itself (the version line with the draft label retired, Section 2's Algorithm 1 with the RUN_LOOP label, the U_s branch, the constructor-published candidacy comment, both labeled succession exits, and the labeled SEALING section, the rewritten Derived candidacy paragraph, Profile One's new Candidacy derivation minimums section, the new v1.3 history entry, and the closing line). The amendment's arc also touched the companion register (REG-63 and REG-64 appended; REG-64'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 the last two amendments define, and this run's own gated record is produced under it. Whether that record evaluates referee-valid with R7 evaluated (REG-59), and whether it evaluates cold from its own bundle (REG-63), are 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.2 (REG-64, July 17, four items and one binding clarification), arriving through the companion register, which remains the only channel through which this document learns that it must change. The register records fairly that item iii's 'terminate' wording originated in the prior review's own suggestion, adopted unexamined, and that item iv's draft stamping was the advisory assistant's own habit (its twenty-first authoring defect).","statement":"v1.3 is a TRANSITION-COMPLETENESS amendment, and its class is stated here so the boundary cannot be inflated by citation: Algorithm 1 gains the U_s branch (U_s = N_s minus C_s), so every commissioned node derived into NO candidacy has an algorithmic route — st(m) set to FAILED with reason insufficient_bound_evidence, entering retry, trip, halt, or succession per the existing transition table — making the fail-closed candidacy promise PERFORMED by the algorithm, never only narrated beside it (REG-64 item i); candidacy derivation is made CONSTRUCTOR-PUBLISHED under Profile One minimums (the review's Option B, item ii): Profile One's new Candidacy derivation minimums section states the minimum evidence requirements (an execution-result-bound artifact identifying the node and binding its claimed completion boundary, the subject artifacts, and the relevant portion of the session delta), and each constructor MUST publish and hash-identify its concrete derivation procedure, assessed under CONSTRUCTOR conformance; both succession exits become LABELED control flow (item iii): break RUN_LOOP out of the newly labeled RUN_LOOP, landing in the newly labeled SEALING section that ALWAYS runs as the predecessor's record lifecycle, replacing v1.2's 'terminate CONSTRUCT' wording, which contradicted the sealing lifecycle that must still run; the draft label is retired from the header and end label (item iv): the sealed v1.2 self-described as a draft while its history claimed the signed succession-6 record, because the amendment habit stamped every version 'N draft' before sealing — the label is removed and the habit retired, since the unsealed lineage already communicates mid-succession status and a sealed document never calls itself a draft; and one binding clarification is pinned: engine-log events MAY be consumed by candidacy derivation only where they are included in, or cryptographically bound by, the session's execution_result or its listed output artifacts. NO conformance requirement was weakened — every existing R-condition and predicate stands as strong or stronger, exactly as REG-64's closure records."},"authority":{"executor_role":"The executor authored this text and computed these figures under the succession-7 arc's nodes (the v1.3 text by s7-01; this record by s7-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 s7 run (s7-01), against the tree this ceremony seals","change":"Four changes. (1) The run loop is LABELED RUN_LOOP, and both succession exits — the no-ready-work site and the per-candidate succession site — become 'SUCCEED(P); break RUN_LOOP': labeled control flow that leaves the run loop as a whole, never an inner loop a reader could scope to, with control landing in the SEALING section below. (2) The SEALING section is itself LABELED and its comment states that it ALWAYS runs: every exit from RUN_LOOP, including break RUN_LOOP at a succession exit, lands there, so checkpointing and export are never skipped by a succession exit. (3) The U_s branch is added after candidacy derivation: U_s = N_s minus C_s, the commissioned nodes derived into no candidacy; each member's status is set FAILED with reason insufficient_bound_evidence and enters retry, trip, halt, or succession logic per the existing transition table — the fail-closed promise PERFORMED by the algorithm, never only narrated beside it. (4) The candidacy derivation comment is recast: the derivation procedure is CONSTRUCTOR-PUBLISHED — Profile One defines the minimum requirements, and each constructor MUST publish and hash-identify its concrete derivation procedure, assessed under CONSTRUCTOR conformance.","section":"Section 2, Algorithm 1 (CONSTRUCT): the RUN_LOOP label, the U_s branch, the constructor-published candidacy comment, both succession exits, and the SEALING label","why":"External review of the sealed v1.2 found REG-64 items i and iii: nodes excluded from C_s had NO algorithmic route (the fail-closed promise lived in prose beside the algorithm, not in the algorithm), and v1.2's own 'SUCCEED then terminate CONSTRUCT' wording contradicted the sealing lifecycle that must still run after a succession exit — a contradiction whose wording, the register records fairly, originated in the prior review's own suggestion and was adopted unexamined. Labeled control flow states the exit's target exactly; the U_s branch closes the transition table over the whole commissioned set."},{"authored_by":"the s7 run (s7-01), against the tree this ceremony seals","change":"Three changes inside the existing paragraph. (1) The fail-closed sentence now names its performer: candidacy fails closed (I5), and Algorithm 1's U_s branch PERFORMS that promise rather than narrating it — a commissioned node lacking sufficient bound evidence after a completed session receives no verification credit and enters governed failure resolution, routed with reason insufficient_bound_evidence, never to verification. (2) The derivation procedure sentence is recast from 'defined by Profile One' to CONSTRUCTOR-PUBLISHED: Profile One defines the minimum requirements (an execution-result-bound artifact identifying the node and binding its claimed completion boundary, the subject artifacts, and the relevant portion of the session delta), and each constructor MUST publish and hash-identify its concrete derivation procedure, assessed under CONSTRUCTOR conformance. (3) One binding sentence is appended: engine-log events MAY be consumed by candidacy derivation only where they are included in, or cryptographically bound by, the session's execution_result or its listed output artifacts.","section":"Section 2, the Derived candidacy paragraph (REG-61)","why":"REG-64 items i and ii and the binding clarification: the paragraph promised fail-closed candidacy without an algorithmic performer, left 'sufficient bound evidence' without stated minimums, and left the engine-log consumption unbounded — an implementation could have fed candidacy from log events nothing integrity-bound. The rewrite names the performer, states the minimums' home, and pins the binding condition."},{"authored_by":"the s7 run (s7-01), against the tree this ceremony seals","change":"One passage added: Profile One defines the minimum requirements for verification-candidate derivation, never the concrete procedure — an execution-result-bound artifact identifying the node and binding its claimed completion boundary, the subject artifacts, and the relevant portion of the session delta. Each constructor MUST publish and hash-identify its concrete derivation procedure, and the published procedure is assessed under CONSTRUCTOR conformance. Meeting the minimums does not by itself confer candidacy: absence of sufficient bound evidence still fails closed, per Algorithm 1's U_s branch.","section":"Profile One (Section 14), new 'Candidacy derivation minimums (REG-64, Option B)' passage","why":"REG-64 item ii: Profile One never defined what evidence suffices for C_s membership, so 'sufficient bound evidence' had no normative floor. The review's Option B was adopted: minimums in Profile One, the concrete procedure published and hash-identified by each constructor, conformance assessed at the constructor level — which keeps the specification tool-agnostic while making every constructor's derivation inspectable."},{"authored_by":"the s7 run (s7-01), against the tree this ceremony seals","change":"The version line reads 'Version 1.3 · Atlas North Institute · July 2026' — the draft label is RETIRED, not merely updated; one v1.3 entry is appended to the version history naming succession 7 and its signed record at succession/delta/succession-7.json; the document ends 'End of v1.3.' All earlier history entries' facts stand intact.","section":"Version line, version history, closing line","why":"REG-64 item iv: the sealed v1.2 self-described as a draft in its header and footer while its history claimed the signed succession-6 record, because the amendment habit stamped every version 'N draft' before sealing (the advisory assistant's twenty-first authoring defect, its author named in the register). The label is removed and the habit retired: the unsealed lineage already communicates mid-succession status — strict verification FAILS naming the unsealed document until the record beside it exists — and a sealed document never calls itself a draft. 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":"All four items performed, plus the clarification: (i) Algorithm 1's U_s branch — U_s = N_s minus C_s, each member's status set FAILED with reason insufficient_bound_evidence, entering retry, trip, halt, or succession per the existing transition table, so a commissioned node lacking sufficient bound evidence after a completed session receives no verification credit and enters governed failure resolution; (ii) the review's Option B — Profile One's new Candidacy derivation minimums section states the minimum requirements (an execution-result-bound artifact identifying the node and binding its claimed completion boundary, the subject artifacts, and the relevant portion of the session delta), and each constructor MUST publish and hash-identify its concrete derivation procedure, assessed under CONSTRUCTOR conformance; meeting the minimums does not by itself confer candidacy — absence of sufficient bound evidence still fails closed; (iii) labeled control flow — the run loop is labeled RUN_LOOP, both succession exits are break RUN_LOOP, and control lands in the labeled SEALING section, which ALWAYS runs as the predecessor's record lifecycle: checkpointing and export are never skipped by a succession exit; (iv) the version line reads 'Version 1.3' with no draft label, the document ends 'End of v1.3.', and the stamping habit is retired — the unsealed lineage already communicates mid-succession status; and the binding clarification is pinned in the Derived candidacy paragraph: engine-log events MAY be consumed by candidacy derivation only where they are included in, or cryptographically bound by, the session's execution_result or its listed output artifacts. No conformance requirement was weakened and no new witness entry type minted, so no sealed record is retroactively orphaned.","id":"REG-64","status":"CLOSED by succession 7 (this record), per the register's own entry","what_was_discharged":"External review of the sealed v1.2 found four items: (i) TRANSITION COMPLETENESS — nodes excluded from C_s had no algorithmic route, so the fail-closed promise was narrated beside the algorithm rather than performed by it; (ii) CANDIDACY PROCEDURE — Profile One never defined what evidence suffices for C_s membership; (iii) v1.2's own clarification 'SUCCEED then terminate CONSTRUCT' contradicted the sealing lifecycle that must still run (the wording originated in the prior review's suggestion, adopted unexamined — recorded fairly in the register); (iv) RELEASE-STATE CONTRADICTION — the sealed v1.2 self-described as a draft in its header and footer while its history claimed the signed succession-6 record, the advisory assistant's draft-stamping habit (twenty-first authoring defect). Plus one binding clarification: the conditions under which engine-log events may inform candidacy were unstated."}],"cited_rulings_not_discharged_here":[{"id":"REG-63","status":"OPEN as Wave 10; the finding this ceremony's record class must answer cold","why_cited":"Run 33 — succession 6's own ceremony run — evaluated INVALID on cold evaluation for two reasons this register entry carries: the envelope export predated the gate plane and shipped only the engine public key, so the typed approval's principal signature was unverifiable by any cold verifier (the gated record class could not be independently judged from its own bundle); and the remediation path recorded attempt-2 verdicts inside a still-open session. The sealed succession-6 work itself was unaffected and cold-verified. The Wave 10 work (the gate principal's public key in the envelope export; the verdict pen refusing verdicts for open sessions, with a probe replaying run 33's entries) is the engine's, and the entry closes with a gated live record the evaluator accepts cold from its own bundle — this run is that attempt, and the acceptance judgment happens over the finished record after this delta seals."},{"id":"REG-59","status":"OPEN; the gate this ceremony ran under, its closure judged over this run's finished record","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 — succession 6 was the first attempt and run 33's cold evaluation surfaced REG-63 instead; this run is the second 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.3 discharges exactly one register entry: REG-64, closed by this succession's performance of all four items and the binding clarification. The register's own entry records the closure as 'CLOSED by succession 7, which performed all four items and the binding clarification'; 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 second fully gated ceremony under protocol mode. 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; REG-63 closes when a gated live record is accepted COLD from its own bundle — run 33 (succession 6's ceremony) proved the gated record class could not be, because the envelope export predated the gate plane and shipped only the engine public key, and because the remediation path recorded mid-session verdicts. This run is the attempt at both: whether its finished record evaluates referee-valid with R7 evaluated, and whether it does so cold from its own bundle under the Wave 10 export, are 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.2'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 7 is NOT genesis and claims no genesis exception. It is the sixth 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, v1.2, and into the v1.3 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.3 amends no tool and weakens no conformance requirement; its changes are the U_s branch, the constructor-published candidacy with Profile One's minimums, the labeled RUN_LOOP and SEALING control flow, the retired draft label, the pinned engine-log binding, the version line, the v1.3 history entry, 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.2 and v1.3 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":"2d59dc815c59b025a7a28c7d56d0c075a9fd0119407cae9d9a62e4e99130f793","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-7.mjs","predecessor_manifest":{"commit":"f4cc4febcf1b49eb2151749b574f84e1fd71e523","digest":"f7d91dd5a13f0ae88d9506ccf0c2afea436296a751fc0316be0e1ea18f0a9f3e","provenance":"Succession 6's manifest, whose bytes this succession's manifest replaces at the same path. The blob at commit f4cc4febcf1b49eb2151749b574f84e1fd71e523 was hashed and required to equal the digest succession-6.json cites BEFORE this record was written, proving these are the bytes succession 6 signed over and that they had not moved since (they landed at the s6-02 commit and stand unchanged at this pin, whose one later append touched only the register). NOT recomputable from this tree once replaced: recoverable from the commit that landed them, exactly as v1.2's spec bytes are recoverable from theirs. tools/succession-verify.mjs reports succession 6's cited manifest digest as RECORDED, NOT VERIFIED now that succession 6 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-7.mjs and VACUOUS BY CONSTRUCTION: succession 6'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-63's Wave 10 export and verdict-pen work, 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":"9c31d03f9c29cbf1ab882eb966cfeec7b1a16e37f3f4d5a6907405c9ab975892"},"predecessor_record":{"path":"succession/delta/succession-6.json","provenance":"sha256 of succession-6.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":"cbcfc855bfff9e5602015f78fd15457b95c72f2c40c8b079e0ffe61c29098298"},"predecessor_spec_digest":{"commit":"f4cc4febcf1b49eb2151749b574f84e1fd71e523","digest":"cf00d60828596354f6694f19fa8b1e64988af52a7343c524faf8159a03a2d4f4","provenance":"succession 6's successor digest, read from succession/delta/succession-6.json rather than transcribed, which is what makes the chain continuous by derivation instead of by assertion. Those bytes are the blob at commit f4cc4febcf1b49eb2151749b574f84e1fd71e523, the last committed tree in which this document was v1.2 (the commit that landed REG-63's and REG-64's register appends; the v1.3 text landed in s7-01's commit 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.2's bytes left it with v1.3'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.2"},"record":{"cited_by":"docs/gad-spec-register.md","lives_at":"succession/delta/succession-7.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 fail-closed candidacy promise this very amendment makes the algorithm PERFORM through the U_s branch (REG-64'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. REG-63's second finding (mid-session verdicts in run 33's remediation path) makes the placement of those verdicts a live question this run's own record answers, one way or the other, when it is cold-evaluated. Producing this record under that choreography is an instance of the ruling — and of the derive-based, now U_s-completed candidacy this lineage's last two amendments define — 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 seventh record that rule applies to."},"succession_number":7,"successor_does_not_claim":{"not_claimed":["GENERAL IMPLEMENTATION CONFORMANCE. The narrowed sentences v1.2 landed stand: 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.3 in general; in particular, no constructor is claimed to have PUBLISHED its derivation procedure yet, and the constructor-published rule this amendment states is exactly the kind of obligation only constructor-level inspection can attest.","RATIFICATION OF v1.3 ITSELF. v1.0 was ratified by Trial 0; v1.3, like v1.1 and v1.2 before it, is an amendment of the ratified text that no trial has evaluated. The draft label was retired by this amendment (REG-64 item iv) because the unsealed lineage already communicates mid-succession status and a sealed document never calls itself a draft — retiring the label asserts NOTHING about ratification, and 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-63 CLOSED. Run 33's cold evaluation found the gated record class unverifiable from its own bundle (the export gap) and mid-session verdicts in the remediation path. The Wave 10 work is the engine's, and the entry closes with a gated live record the evaluator accepts COLD from its own bundle — whether THIS run's finished record is that record is the evaluator's cold judgment after this delta seals, not this record's claim.","THAT REG-59 CLOSED. This ceremony ran GATED on the typed gate plane — the second to do so — 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; 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 6 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, and succession 1's genesis disclosure is neither softened nor restated.","FINALITY. v1.3 is 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 seven before it did. Retiring the draft label retires a false self-description, not the lineage's openness.","THAT THE GENESIS PROBLEM IS SOLVED. Succession 1 disclosed it; this is the sixth 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.3 completes the transition table Algorithm 1's candidacy promise depended on, states candidacy's evidence minimums and publication rule, makes the succession exits' control flow explicit, retires a self-description the sealing falsified, pins the engine-log binding, and nothing else."},"successor_spec_digest":{"digest":"9c31d03f9c29cbf1ab882eb966cfeec7b1a16e37f3f4d5a6907405c9ab975892","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.3"}},"signature":"5cba928eaf1ec3399670d6e1ffe92a3f55aa0dad0cb9c7f932bc5ec3a7176652c7b724e46cf832370e61afcc0ab0b56221a0dc047b7de4404cb6899e62a0bb02"}