# GAD Specification Register

**Companion to the GAD Formal Specification, v0.6 and onward · Atlas North Institute · July 2026**

This register is the specification's only open channel for FINDINGS. The spec's prose is frozen by its own stewardship rule; changes after v0.6 arrive exclusively from concrete findings recorded here, each triaged into one of four categories:

1. **Schema missing.** The concept exists in the spec; the machine-readable definition does not.
2. **Implementation nonconforming.** The reference implementation does not do what the spec requires.
3. **Specification underspecified.** Two reasonable implementers would disagree; the spec must decide.
4. **Required evidence never captured.** The historical records lack fields the spec now demands; the honest disposition is a gap, never a backfill.

An entry closes only by a published resolution: a schema, an implementation change, a spec succession with its delta stated, or an acknowledged permanent gap.

**The channel is not the amendment (RUL-9, forced by REG-23).** A finding arrives here and a ruling is recorded here, but a RULING IN THIS REGISTER IS NOT AN AMENDMENT OF THE FROZEN DOCUMENT. The register cannot outrun the spec it governs. A frozen specification is amended only by SPECIFICATION SUCCESSION under RUL-9: a numbered, operator-authorized act whose signed delta lives as a sidecar beside the spec in gad-protocol and which this register CITES. This register is where the specification learns that it must change; the succession is how it changes. REG-21 exists because that distinction was not drawn, and REG-23 exists because the remedy was then prescribed by borrowing two rules that govern plans.

---

## Open items

**REG-1 · Supervisor semantics (spec underspecified → transition table). STATUS: CLOSED July 13, 2026.** Resolution artifact: gad-protocol transitions/transition-table.json plus invalid traces, shipped in the Phase 1 governed run (15/15 nodes, 61-entry chain) and independently re-verified cold (transitions:check exit 0; probe fires). SUPERVISE_EXECUTOR is named normatively in Algorithm 1; its full semantics are owed by the transition table: budget enforcement, session-loss detection, process-tree termination policy, cancellation policy, guaranteed exit-status yield. The invariant the table must preserve: the executor may never return; the supervisor always does.

**REG-2 · Quiescence condition (spec underspecified → Profile One). STATUS: CLOSED July 14, 2026, by the Phase 3 supervisor implementation.** QUIESCE precedes surface and delta computation; Profile One owed the operational definition of "execution ended": process-tree stop or isolation, filesystem settling policy, recorded quiescence outcome, and the treatment of asynchronous writes that land after capture despite the policy. That definition is now authored AS IMPLEMENTED (not as theory), in Waypoint's supervisor at `src/main/supervisor/quiesce.ts`, proven by the race-only done-test `src/test-p3-quiesce.ts` (positive plus a `--probe` negative control that plants a late-landing write the barrier must catch). Profile One, the operational definition:

1. **Process-tree stop or isolation.** "Execution ended" begins when the executor's owned process tree is confirmed stopped. The supervisor owns the whole tree (REG-1 Phase 3 node p3-01) and force-reaps it on every terminal path (p3-02), so once the tree is down no NEW write can originate. The barrier makes this a precondition of quiescence: it will not declare the region quiescent while a liveness probe still reports any live owned process, a live writer is, by definition, not quiescent.

2. **Filesystem settling policy.** After tree-stop, the barrier watches the executor's output region and requires its fingerprint, every file's path, size, and mtime, hashed order-independently, to stay byte-for-byte identical for a bounded SETTLE WINDOW (default 150 ms) before declaring quiescence. A buffered or delayed flush that lands shortly after exit changes the fingerprint and RESETS the stability timer, so it is absorbed rather than missed. The barrier is BOUNDED (default 3 s): a region that never settles yields a recorded outcome, never a hang, the same guaranteed-return discipline the supervisor holds for the process.

3. **Recorded quiescence outcome.** Every barrier returns a structured verdict: `settled` (reason `stable`) or not (reason `timed_out`), with the duration, the poll count, whether the tree was stopped at the verdict, and the **capture fingerprint** taken at the instant quiescence was declared. The verdict is the record; a non-settling region is recorded as `timed_out`, never silently treated as quiescent.

4. **Asynchronous writes that land after capture despite the policy.** The capture fingerprint makes any post-capture write DETECTABLE: a later write changes the region's fingerprint, and `regionChangedSince(fingerprint, target)` returns true. A write that lands after capture is a quiescence VIOLATION to be recorded and surfaced, never silently absorbed, never backfilled. This is the property the `--probe` control exercises: it settles the barrier, then plants a late write, and the fingerprint check must catch it.

Scope note, stated so nothing is silent: this closes Profile One's *operational definition and its proving implementation* in the supervisor. Wiring the recorded quiescence outcome and its capture fingerprint into the engine's captured `execution_result` and the witness is the adjacent Phase 3 session-wiring work (p3-04), not this entry; the barrier's outcome is returned as first-class data here, ready for that wiring.

**REG-3 · Checkpoint schema details (schema missing → transition table + test vectors). STATUS: CLOSED July 13, 2026.** Presumptive answers confirmed by the Phase 1 vectors and fixtures; encoded in the transition table and witness-entry schema; independently re-verified cold. Open questions with presumptive answers to be confirmed by vectors: the first range begins at seq 0 (or the entry after the last covered seq); the final checkpoint covers everything since the previous one; checkpoints are individually signed and excluded from their own range, so a checkpoint never requires coverage by another; the minimal valid sealed record is freeze, terminal, final checkpoint; overlap policies, where declared, are identified and hashed in the bundle like every other policy object.

**REG-4 · Companion machinery tracker (schema missing). STATUS: OPEN, closes item by item.** CLOSED by the Phase 1 run, July 13, 2026: (1) core and envelope schemas, (2) canonicalization spec (RFC 8785 base, domain tags, vectors), (3) transition table, (4) predicate registry with evidence-shape and strength rules, (5) trust-policy schema with gad4-default, (6) valid and invalid vectors (three valid outcomes; nine R-condition envelopes), (7) minimal open reference evaluator (gad-evaluate: ajv-only dependency graph; emits signed Q; DEFENSIBLE computed). REMAINING: (8) full conformance suite grows through Phases 2 to 5 (Phase 1 gate covers acceptance tests 3, 10, 16, 17, with 1 and 18 partially exercised by cross-OS cold verification); (9) independent formal and cryptographic review, Phase 5. Per spec Section 14: (1) core and envelope schemas; (2) canonicalization spec; (3) transition table for C; (4) predicate registry with evidence-shape and evidence_strength rules; (5) trust-policy schema including replay_policy; (6) valid and invalid test vectors; (7) minimal open reference evaluator; (8) conformance test suite; (9) independent formal and cryptographic review. Items 1 through 3 and 7 are the Trial 0 critical path.


**REG-5 · Implementation dispositions (spec-versus-implementation conflicts; ruling required). STATUS: CLOSED July 13, 2026.** The Trial 0 Codebase Gap Audit (July 13, 2026, first Trial 0 input, on file in the corpus) identified six places where shipped behavior and the frozen spec genuinely disagree: preflight totalization, breaker reset and post-trip recovery, waiver terminals, gate timing, chain mode primacy, and outcome vocabulary. Rulings RUL-1 through RUL-6 were drafted in the Conformance Migration Plan Section 1. **RECORDED July 13, 2026, named authority Brandon King: all six adopted as drafted.** RUL-1 preflight totalizes to fail; RUL-2 breaker reset and post-trip recovery disabled in v0.6 mode, succession is the sanctioned path; RUL-3 waivers become successor-plan obligation changes, never COMPLETED; RUL-4 pre-execution authorization optional, evidence-review gate normative; RUL-5 public chain primary, HMAC internal; RUL-6 audit outcome mapping adopted, projections never the source of truth. Category: implementation nonconforming (RUL-1, 2, 3, 5, 6) and specification-versus-practice reconciliation (RUL-4). **Entry CLOSED.**


**REG-6 · Orphan brief reference: the action-path freeze-graph register debt (scope-routing error in the brief). STATUS: RESOLVED July 13, 2026, Brandon King (scope routing); FULLY CLOSED July 14, 2026 (the underlying debt itself), see REG-16's closure note.** The Phase 1 brief carried an undefined prior-arc item; the executor correctly refused to improvise a meaning and flagged it. Ruling: the referenced item is a Waypoint-side register debt from the July 2 action-path arc concerning the freeze-graph flow, substantively covered by Trial 0 audit finding P1-01 (unified plan/spec identity; specHash must hash spec bytes, not the reference string). It is out of scope for Phase 1, whose standing rules forbid touching Waypoint; it transfers to the Phase 3 work order and Waypoint's own gap register. The brief's carry-in sentence is struck. Category: scope-routing error in the brief, not a specification ambiguity. No Phase 1 node performs this work.

**REG-7 · Bundle and envelope physical form. STATUS: CLOSED July 13, 2026.** Fixtures serialize deterministically in this form (fixtures:determinism exit 0; gate test 17 root_core identical across independent builds) and the evaluator consumes them cold. Presumptive answers stand unamended. Spec Section 2 defines B_core and E as tuples but not their on-disk form, while Algorithm 2's CLI shape implies a directory. Presumptive answers (July 13 design spike): an envelope is a directory; the core bundle lives in its core/ subdirectory; M_core is the JSON document core-manifest.json, listing every member of B_core except itself as {path, role, digest} with required roles plan, witness, operator (exactly one each), an optional single claims member, and any number of artifact members; the witness member is a single JSON array of witness-entry objects; M_envelope is the JSON document envelope-manifest.json, listing root_core, the anchor artifacts, prior evaluation attestations, and envelope metadata (including the required, nullable predecessor_root_envelope), and excluding itself. Member-path uniqueness and manifest self-exclusion are evaluator checks, not expressible in JSON Schema.

**REG-8 · Two claim objects, one word. STATUS: CLOSED July 13, 2026.** Encoded in core-bundle.schema.json (typedClaim def; claims a dedicated core member; testimony never an R9 claim); exercised by the R9 fixture and gate test 10. The spec uses claim both for the executor's optional testimony (the τ = claim witness entry) and for R9 typed claims. Presumptive answer: typed claims are a dedicated core-bundle member (a JSON array, role claims in M_core, at most one such member), schema at core-bundle.schema.json#/$defs/typedClaim; the τ = claim witness entry remains testimony only and is never an R9 claim.

**REG-9 · Presumptive field typings. STATUS: CLOSED July 13, 2026, with one carried seam.** The canonicalization spec, vectors, and evaluator confirm the typings. Item 9 (empty done-test arrays verify vacuously) was ruled July 14, 2026: see RUL-7 below. Where the spec names a field without fixing its machine type, the schemas encode presumptive answers, none silent. Reconstructed from the July 13 spike register (if the salvaged spike file survives, it is authoritative and replaces this reconstruction on any difference; first capture wins): (1) digest and signature values are non-empty strings; exact byte encoding owed by CANONICALIZATION.md, and the hash function is an assumption the spec states, not a schema constant. (2) Timestamps t are non-empty strings, wall-clock reference only; exact format owed by CANONICALIZATION.md. (3) exit_code and available_output_ref/available_output_digest are nullable: a crashed, killed, or vanished executor may yield none, and absence is recorded as absence (I3), never omitted. (4) Dispatch identity fields (session_id, executor identity triple, instruction digest and ref, workspace baseline digest) are non-empty strings. (5) probe.induced_defect is a non-empty string describing or referencing the induced defect. (6) References to witness entries (flag.execution_result_ref, gate_request.findings, approval/refusal.findings_ref, trip.history, revised_approval_request.change_ref) are {seq, hash} pairs. (7) plan_halted.unresolved is a non-empty array of {node, test_id?}. (8) obligation_map maps obligation or node id to carried | removed | changed; changed_class_floors, changed_fences, and changed_tests are arrays of {node, from, to}. (9) A node's done-test array MAY be empty; flagged as a seam: an empty T verifies vacuously under Algorithm 1's for-all loop, which plan-adequacy review (spec Section 10) must catch, and the transition table or a future ruling may forbid it. (10) The done-test object is {test_id, kind, spec} with spec an open object; the Profile One observable vocabulary is owed by later sessions.

**RUL-7 · Empty done-tests forbidden (ruling, July 14, 2026, Brandon King).** A plan node's done-test set MUST contain at least one check. A node with zero checks verifies vacuously under Algorithm 1's for-all loop and is exactly the counterfeit this specification exists to prevent: completion credit without evidence. Work whose value is testimony belongs in witness testimony entries or labeled artifacts, never in a verified node. This aligns the protocol with its reference constructor, whose loader already refuses zero-check nodes. Implementation: plan.schema.json gains minItems 1 on the done-test array, with a matching invalid vector, in the conformance-suite graph that next extends gad-protocol (Phase 5 or earlier); out of the Phase 2 Atlas fence by design. Until then the ruling is normative and the schemas are known to under-enforce it, stated here so nothing is silent.

**REG-11 · Stale terminals-test seam after RUL-2 (implementation nonconforming: test, not code). STATUS: CLOSED July 14, 2026 by commit 2a14307; see the closure note below for the route and its honest caveats.** Discovered by cold re-verification of the Phase 2 run, July 14, 2026, and independently flagged by the run itself as regression_detected at chain seq 82. The p2-04 terminals test includes a legacy-seam assertion that calls store.recoverNode on a HALTED (tripped) node and expects the run to revive. Node p2-10 subsequently implemented RUL-2, which disables post-trip recovery in v0.6 mode: recoverNode now throws a TransitionError by design. The production code is correct and RUL-2-conformant; the p2-04 test is stale, asserting pre-RUL-2 behavior for an affordance RUL-2 deliberately removed. Because p2-04 is outside every later node's fence, the run could not self-heal it, correctly recorded the tension rather than hiding it, and left p2-04 marked done with a now-failing test. FIX (small, out of any completed node's scope, belongs to a short corrective graph): rewrite haltedWedgesRun to assert that recoverNode throws in v0.6 mode and that the witness keeps its honest plan_halted terminal. UPDATE July 14: the Phase 2 run's own regression sweep independently caught this at chain seq 82; the in-run executor authored the test-only realignment and COMMITTED it at 2a14307 ("realign terminals test to p2-10 RUL-2/RUL-3 rulings"). STATUS: CLOSED July 14, 2026, by commit 2a14307, verified three times independently and never by self-attestation: (1) advisory cold rebuild on a second machine and OS, which found the pre-fix failure and confirmed the fix's necessity; (2) operator terminal run of node build/test-v06-terminals.js, all five legs PASS including the realigned leg ("v0.6 refuses post-trip recovery (RUL-2), so the witness keeps its one plan_halted"); (3) the REG-11 corrective run's own governed check (scripts/verify-terminals-close.cjs), which ran green: fix present, full v0.6 suite (14 files) and legacy suite (19 files) pass from a clean rebuild, and the negative control correctly failed on a reverted fix. CLOSURE ROUTE, stated honestly: a one-node corrective graph was authored to bless this fix through a governed node. It was attempted twice and abandoned. Both attempts hit REG-12 in new forms: the first could not resume across the supersede boundary (predecessor incomplete, see REG-12); the second HALTED on SCOPE_VIOLATION attributing a PRIOR run's commit (e922bd4, the register edit from run #22) to the corrective node, because the run's baseline was pinned to 2a14307 while the tree stood at e922bd4. In both attempts the executor's recommended remedy was to edit and reload the frozen plan; the operator declined both times, correctly: a frozen contract is never edited to make a check pass. The ceremony was therefore abandoned rather than the contract bent. This entry records that decision in full: the fix is correct and thrice-verified, its governance ceremony was defeated by an engine defect (REG-12) rather than by any doubt about the work, and the corrective run's halt stands as further evidence for REG-12. Nothing was waived, nothing was backfilled, no frozen plan was edited. Category: nonconforming test surfaced by a later ruling. This is the cross-node regression the machinery is built to catch, working as designed.

**REG-12 · Reopen without re-baseline: scope false-positive on a regression-reopened early node (implementation nonconforming, Atlas engine). STATUS: the REOPEN half CLOSED July 14, 2026 in atlas-orchestrator; the ATTRIBUTION half separated into REG-22 and parked behind REG-21's succession. Original fix-shape DISPROVEN and corrected below. Closes when: Atlas re-baselines a node's scope reference to the current tree (or an explicit post-freeze baseline) when a regression sweep reopens it, and a reopened early node re-verifies without flagging later nodes' legitimate work; a corrective graph or Phase 3 supervisor work lands the fix.** Discovered at the close of the Phase 2 run, July 14, 2026. When the p2-15 regression sweep reopened p2-04 (to re-run its now-fixed test), Atlas compared the working tree against p2-04's ORIGINAL scope baseline, captured before nodes 5 through 15 existed, so every later node's legitimate file showed as out-of-fence. The engine correctly marked the node not self-correctable and the executor correctly refused to widen its own fence or edit the frozen plan; it did, however, recommend editing and reloading the frozen plan as its preferred remedy, which the operator correctly declined (editing a frozen contract to pass a check is the exact counterfeit the specification forbids). The defect is in Atlas's reopen logic, not in any node's work: a regression-reopened node needs its scope reference re-based to the current tree (the regression check is asking "does the FINAL tree still satisfy this node's test", a whole-tree question, not a "what did this node change" question). This repo is the engine, so the fix is in-scope for the migration: category implementation nonconforming, closure via a corrective graph or Phase 3's supervisor/scope rework. Until fixed, do not run regression sweeps that reopen early nodes, or expect and ignore the scope false-positive on such reopens (the test result itself is the signal; the scope check is measuring the wrong baseline). CONSEQUENCE FOR THE PHASE 2 MAIN RUN: because the reopened p2-04 re-verify wedged on this scope bug, the main run's ENGINE RUN-STATE ended non-terminal (recorded 14/15 done with p2-04 reopened), even though the WITNESS shows all 15 nodes verified, the chain is intact (85 entries against genesis), and the p2-04 terminals test itself passes (fix committed 2a14307). Work complete; run-state non-terminal; reason REG-12. Two distinct facts, both recorded. A further consequence: when the REG-11 corrective plan superseded the main plan (Plan 1 superseded, Plan 2 frozen, succession recorded correctly in the project graph), the incomplete predecessor could not be auto-archived (only a terminal prior run auto-archives on plan change), so the predecessor's final run sits orphaned and incomplete by design. The corrective work runs as a fresh run of Plan 2, not as a resume of the predecessor. None of this is hidden; the honest state is: main-run work complete and witnessed, main-run engine-state non-terminal due to REG-12, corrective plan superseding cleanly. SECOND AND THIRD MANIFESTATIONS, July 14: (2) the REG-11 corrective run could not launch as a resume across the supersede boundary, because the incomplete predecessor could not auto-archive; a fresh run of the successor plan was required. (3) The fresh corrective run (run #23, one node) HALTED on SCOPE_VIOLATION naming docs/gad-migration/gad-spec-register.md, a file the node never touched: the run's baseline was pinned to commit 2a14307 while the working tree stood at e922bd4, so the PRIOR run's register edit was attributed to the corrective node. The node's own done-test had already passed green (fix present; 14 v0.6 files and 19 legacy files pass from a clean rebuild; negative control correctly failed). The engine correctly marked it not self-correctable; the executor correctly refused to touch an out-of-fence file and did not retry. SEVERITY, restated: this defect has now defeated a correct node three times and has twice driven the executor to recommend editing and reloading the frozen plan as its preferred remedy. That is the defect's real cost: it manufactures pressure to bend the contract. The scope check must not attribute prior-run commits to a later node. FIX SHAPE, CORRECTED July 14 after the fifth executor refusal disproved the original clause against the real engine (see REG-22): the original prescription, baseline to run start, is WRONG twice over and must not be implemented: (1) it does not exonerate a prior party's commit in every timeline, since a foreign commit can land after run start; (2) it provably breaks multi-node runs, because a whole-tree diff from ANY fixed point attributes node A's legitimate committed work to node B, and this system's own discipline commits per node. Per-node attribution requires commit-boundary identity, which is exactly RUL-8's derived attribution, blocked behind the gad-protocol succession (REG-21). THE SOUND HALF, buildable now and re-authored as the whole of a3-03: when a regression sweep reopens an early node, re-baseline that node to the current tree, because the regression question is a whole-tree question; this is the half that actually wedged Phase 2 (the p2-04 reopen). CLOSED, the sound half, July 14, 2026, by a one-node governed run against atlas-orchestrator (1 of 1 done, no waivers, regression sweep clean, two commits on main). A regression-reopened node now re-baselines its scope reference to the current tree, so later nodes' legitimate work is no longer attributed to it, and the p2-04 wedge does not reproduce. The reasoning is recorded as the executor stated it: a regression sweep asks a whole-tree question, does the finished project still pass this node's test, not what did this node change; work already in the tree when the node reopens is the premise of the question, not that node's doing. NOTABLE, and the best evidence in the day's record that the layers check each other: the ENGINE REFUSED THE EXECUTOR'S FIRST SELF-TEST as a hollow proxy, because it did not prove it could detect its own fix being removed; the node FAILED; the executor rebuilt the self-test properly and the second attempt passed with the engine itself watching the test fail with the fix removed. Five times on July 14 the executor caught the advisory assistant authoring on a false premise; here the engine caught the executor authoring a hollow check. Every layer caught the layer above it. Nothing caught the engine, which is what Trial 0 and Phase 5 exist for. ALSO FLAGGED AND NOT CHASED, recorded rather than absorbed: an intermittent approval-timing test flake, confirmed present on the unmodified engine before the change and passing on four re-runs after it, unrelated to this work and still open. The foreign-commit-attribution half becomes its own finding (REG-22), parked with a3-01 behind the RUL-8 succession.

**REG-13 · specHash bound a name, not a document (P1-01; implementation nonconforming). STATUS: CLOSED July 14, 2026, by the Phase 3 identity implementation.** Waypoint computed its spec identity by hashing the spec REFERENCE STRING (the citation / path), not the spec file's bytes. Two documents that shared a name shared an identity, and a spec edited in place kept its old identity, so `specHash` bound a NAME, not a DOCUMENT. FIX: spec identity is now the SHA-256 of the file's UTF-8 bytes, computed by the same algorithm Atlas uses (`hashSpecFile`), and plan identity is the SHA-256 of the canonicalized AUTHORED document (`authoredGraphHash`): one identity both sides compute, cross-checked in the done-test against Atlas's own exported primitives. Implemented in `src/main/identity/`, proven by `src/test-p3-spechash.ts` (a `--probe` that restores the reference-string hash and shows a same-name different-bytes edit collide). WHAT THIS MEANS FOR PRIOR RECORDS, stated per the never-backfill standing rule: every record Waypoint produced before this fix carries a spec identity that bound the reference STRING, not the document bytes. Those records are NOT reissued and NOT recomputed, the earlier records say what they said (a name), and they are read as binding a name, not a document. Only records produced from this fix forward bind the document's bytes. Category: implementation nonconforming; closure is the byte-hash implementation plus this honest disposition of the historical records.

**REG-14 · Key custody: rotation and revocation deferred (P1-09; specification underspecified → Profile One stub). STATUS: OPEN, DESIGN RESTED by succession 3 (v0.9 carries the key lifecycle rules: signed lifecycle entries, key_id supersession, forward-looking revocation); implementation remains post-v1.0 and this entry tracks it.** Phase 3 node p3-11 lands real key custody (P0-10): the frozen AuthorizedPrincipals registry binds public material into the plan, and private keys are held in Electron safeStorage, key material never enters the repo, the state file, or any export, backstopped by a fail-closed export guard (`src/main/credentials/`). What p3-11 implements of the key lifecycle is the Profile One STUB sufficient for this phase: each key carries a stable `key_id`, an `algorithm`, and a `custody_statement`. What is DEFERRED, recorded here rather than improvised: key ROTATION and REVOCATION (P1-09): how a `key_id` supersedes a prior one, how a revoked principal's past signatures are treated (they remain valid for the records they signed; revocation is forward-looking), and where the rotation/revocation events are recorded (a signed lifecycle entry, shape owed by Profile One). Until P1-09 lands, a principal's key is fixed for the plan that froze it, and a compromised key is handled by succession (a new frozen plan with a new registry), not by in-place revocation. Category: specification underspecified; closure is the P1-09 lifecycle design plus its implementation in a later phase.

**REG-15 · REG-10 was never written (process finding, discovered by cold verification July 14, 2026). STATUS: OPEN. Closes when: the signal-artifact resolution rule per check kind is authored into this register from the Phase 2 implementation, and a future graph's node verifies its presence rather than trusting a description.** The Phase 2 brief required node p2-08 to OPEN REG-10 documenting the per-kind signal_artifact_digest resolution rule (brief seam 3: "never silently decide"). Cold verification of both the Atlas and Waypoint register copies finds no REG-10 in either: the node's done-test verified its verdict implementation, not its register obligation, so the entry was never written and nothing caught it. The rule itself EXISTS in the Phase 2 code and is therefore not lost, but it is undocumented in the register, which is the specification's only change channel. Two lessons, both recorded rather than fixed by hand: (1) a documentation obligation that no check enforces is an obligation that does not exist, and this register entry is the evidence; (2) fences and done-tests must cover a node's WRITING obligations, not only its code. Category: process finding, discovered by independent cold verification, exactly the kind of gap the corpus exists to surface. Do not backfill REG-10 with a reconstruction; author it from the implementation and verify it under a governed node.

**REG-16 · The e2e claim was stale and unverified, and the gate that disclosed it did not check it (process finding + implementation nonconforming). STATUS: CLOSED July 14, 2026, by a three-node governed corrective run, independently cold-verified; see the closure note at the end of this entry. Closes when: the tsconfig build-harness defect is fixed so the seven blocked Electron tests actually execute, the action-path freeze-graph failure is diagnosed and resolved or ruled, and any node that reports an out-of-band suite's status COMPUTES that status rather than reciting it.** Discovered July 14, 2026, by running the prerequisite before Trial 0 Movement 2. Phase 3's exit-gate node p3-18 moved the Electron e2e suite out of band (it runs ~130s against a governed 120s check budget), which was a reasonable and honestly disclosed decision: the check printed the omission on every run rather than hiding it. But the disclosure carried a claim: "its last full run was 24/26, the only two failures pre-existing environment-dependent render flakes in unchanged tests." That claim was FALSE when it was printed. The suite's actual state, measured on July 14 at main (73e838e) AND at the pre-Phase-3 release commit (abf0dc5), is 18/26, identical at both: seven tests fail identically on a deterministic build-harness defect (`Unexpected "import" in JSON` at a temp tsconfig.json, meaning esbuild is reading a TypeScript source as JSON) and one, action-path, fails on a real timeout waiting for the freeze-graph selector. TWO SEPARATE FINDINGS, both recorded: (1) IMPLEMENTATION: seven Electron tests (approval, irreversible-approval, artifacts, buildroom, command-center, completion-gate, regression-check) have not executed at all; they are not flaky, they never run, and the harness reports their build failure as a test failure. The action-path freeze-graph timeout is a ninth, separate question. (2) PROCESS, and the more important one: a node MAY honestly decline to run a suite in band, but it MUST NOT recite that suite's status from memory. p3-18's disclosure was well-designed and still wrong, because the number inside it was never computed by anything. This is REG-15's lesson recurring in a new place: an obligation no check enforces is an obligation that does not exist, and that applies to REPORTED FACTS exactly as it applies to documentation. VINDICATION, stated because it is also true: the bisect proves Phase 3 regressed NOTHING; 1.1.0 and main fail identically. The supervisor rebuild, the REG-12 fix, the credential work, and the envelope layer broke no existing test. FIX SHAPE: repair the harness so the seven tests run; diagnose action-path; and where a node reports an out-of-band result, it must either execute the suite or carry the suite's own machine-written result as an artifact, never a remembered figure. RESOLUTION OF THE HARNESS DEFECT, July 14: the cause was environmental, not code. The seven tests call esbuild's buildSync on an entry written into os.tmpdir(); esbuild walks up from the entry looking for a tsconfig.json and found a stray file at C:\Users\squeb\AppData\Local\Temp\tsconfig.json that was not a config at all but a TypeScript source (its line 8 is an import statement) left there by some earlier process. Deleting that one file restored the suite: SIX of the seven tests now pass (approval, irreversible-approval, artifacts, buildroom, completion-gate, regression-check), and the suite reads 24/26. DURABLE FIX OWED (not yet done, tracked here): these tests must be robust to a hostile temp directory by passing an explicit tsconfig path or tsconfigRaw to buildSync, so no stray file can ever silently blind them again. THE CLAIM, RE-EXAMINED, and this is the finding that survives: p3-18's printed figure of 24/26 is now NUMERICALLY TRUE. It was not true when it was printed, when the real state was 18/26 with seven tests dead. A stale figure that later happens to match is worse than one that visibly conflicts, because nothing ever surfaces it. The defect is not that the number was wrong; the defect is that the number was RECITED AND NEVER COMPUTED. REG-16 stands on that basis. TWO REAL FAILURES REMAIN, distinct from one another: (a) action-path times out waiting for [data-testid=freeze-graph]. It fails identically at 1.1.0 and at main, so it predates Phase 3. It is very likely the same defect behind REG-6's orphaned reference, the July-2-arc action-path freeze-graph register debt, which was ruled out of Phase 1 scope and rerouted to Phase 3 but which no Phase 3 node in fact addressed. That thread is now traced to a reproducible failing test. (b) command-center times out waiting for [data-testid=command-center]. This is NEW INFORMATION, not a regression: the test was one of the seven that never executed, so its coverage has been dark for an unknown period and the failure was invisible rather than absent. Both are recorded, neither is fixed. DIAGNOSIS, July 14, by a read-only investigation session (no file written, no command run against the repo), independently re-verified by the advisory assistant against the real engine. BOTH FAILURES ARE DEFECTS IN THE TEST FIXTURES. The application is correct in each case, and in Failure 2 it is refusing a genuinely invalid graph exactly as designed.

(a) ACTION-PATH. CORRECTION FIRST, recorded because the register must not preserve an error: the earlier entry in this register stated that `data-testid="freeze-graph"` appears nowhere in the application. THAT WAS WRONG. It exists at src/renderer/screens/ProjectHubScreen.tsx:249, passed as `testid="freeze-graph"` to an ActionButton which renders it as `data-testid={testid}`. The claim came from a grep for the literal attribute, and a grep is not a proof: the prop indirection defeated it. REG-6's referenced affordance is real, the whole chain is real (attach-graph-paste, paste-graph-attach, validate-graph, freeze-graph, freeze-confirm, freeze-confirm-yes, over IPC graphs:validate and graphs:freeze at handlers.ts:1086 and :1107), and the test drives the correct flow. THE ACTUAL CAUSE: the Freeze button is gated on `shownGraph.status === 'validated'` (ProjectHubScreen.tsx:248); status only advances via setValidated at handlers.ts:1101, which is unreachable because line 1097 returns GRAPH_INVALID first; the graph stays draft, so Freeze never renders and the test waits out its timeout. Validation refuses because the test's GOOD_GRAPH and BAD_GRAPH fixtures (action-path.electron.test.ts:25-37) omit `description` on every node and every done_test entry, which the v1.5.0 engine requires. Verified by running the resolved engine's loadGraph directly against both fixtures.

(b) A SECOND, WORSE FINDING INSIDE (a): THE CYCLE TEST IS VACUOUS. BAD_GRAPH fails validation with the IDENTICAL schema error as GOOD_GRAPH, not with its cycle. The test asserts GRAPH_INVALID and passes for entirely the wrong reason: IT WOULD PASS IF CYCLE DETECTION WERE DELETED FROM THE ENGINE. Independently confirmed: with `description` added, GOOD_GRAPH loads clean and BAD_GRAPH throws `Dependency cycle detected: x -> y -> x`, the real gate finally exercised. The fixtures drifted behind the engine's schema and the schema error masqueraded as the cycle error. A related blind spot: the test's guard keys on node count === 2, which both graphs satisfy, so it never confirms the good graph replaced the bad one. This is the probe doctrine's own lesson turned inward: a check that cannot distinguish its target from an unrelated failure is not a check.

(c) COMMAND-CENTER. Root cause: src/renderer/command/CommandCenter.tsx:182, `summary.checkpointWaiting.map(...)` where checkpointWaiting is undefined, throwing TypeError during render, so React never commits and the element at line 105 never enters the DOM. AttentionSummary (src/main/repositories/AttentionRepository.ts:30-42) declares eleven fields including `checkpointWaiting: RunRef[]` at line 33; the test's fixture (command-center.electron.test.ts:29-40) supplies ten. The field was added by commit a2ed1e1, which updated the component and the repository but not this fixture. WHY TYPESCRIPT DID NOT CATCH IT, and this is the class: the fixture lives inside a TEMPLATE STRING written to disk and bundled by esbuild at runtime, so tsc never type-checks it and esbuild does not type-check at all. The AttentionSummary contract is entirely unenforced at exactly the point it is constructed.

FIX SHAPE, in prose, applied by nothing yet: Failure 1 needs `checkpointWaiting: []` in the fixture, but the durable fix is to make the fixture a real type-checked module the harness imports, or to have the component tolerate absent collections, because the string-fixture pattern will recur every time AttentionSummary gains a field. Failure 2 needs `description` on every node and done_test entry in both fixtures, but the durable fix also makes BAD_GRAPH differ from GOOD_GRAPH ONLY in the cycle, asserts on the cycle message rather than the generic GRAPH_INVALID code, and keys the replacement guard on node ids rather than a count both graphs satisfy. Fixing only the schema error would turn the suite green while leaving the cycle gate still blind, which is the outcome this register exists to prevent.

CATEGORY NOTE: none of this is a Phase 3 regression. Every failure predates the migration and was invisible because the harness defect kept the tests from running at all. The e2e suite's green figure was never the point; what it was actually verifying was.

BLOCKING, restated: Trial 0 Movement 2 does not proceed while the freeze-graph action path is failing, because Movement 2's run must be frozen and launched through exactly that path, and a first conforming record must not be produced by an application whose freeze surface is a known-failing test.

CLOSURE, July 14, 2026. A three-node governed corrective graph (continuous mode, Waypoint repo) closed all of it, and each node was authored so the shallow fix could not satisfy it. Commits a8a8c6c, 9769f8b, d9d7e97, 8263665. The suite now reports 26 of 26.

(1) command-center: the fixture was EXTRACTED from its template string into src/renderer/command/commandCenterFixture.ts, a real module annotated `: AttentionSummary` and imported by the harness. INDEPENDENTLY VERIFIED by the advisory assistant: removing checkpointWaiting from the fixture now produces `error TS2741: Property 'checkpointWaiting' is missing in type ... but required in type 'AttentionSummary'` at compile time, naming the field, instead of a 20-second timeout on a missing DOM node. The class is closed: the next field added to the interface breaks the build. The extraction also surfaced a SECOND latent gap the string had been hiding, graphsReady was missing planNumber (GraphRef, D-21), which no one had noticed for the same reason.

(2) action-path: both fixtures are now built by a shared node() factory, so GOOD_GRAPH and BAD_GRAPH are identical in shape and schema-validity and the single back-edge is the whole difference; the assertion is now the engine's own words, /Dependency cycle detected: x -> y -> x/, rather than the generic GRAPH_INVALID code; and the replacement guard keys on node ids rather than a count both graphs satisfy. INDEPENDENTLY VERIFIED against the real engine: GOOD loads clean, BAD is refused specifically for its cycle, and removing the cycle from BAD makes it load clean, which is the proof that the test would now fail if cycle detection were deleted. Before this run, all three of those cases were refused identically for a missing description.

(3) The suite figure is now COMPUTED: scripts/verify-e2e-suite.cjs parses the suite's own output rather than reciting a remembered number, and the durable hostile-temp-dir fix was landed so a stray tsconfig.json can never again silently blind the esbuild-bundling tests.

REG-6 CLOSES WITH IT. The orphaned action-path freeze-graph register debt, first referenced without definition in the Phase 1 brief on July 13, ruled out of Phase 1 scope, rerouted to Phase 3, and addressed by no Phase 3 node, is now resolved: it was a real debt, the affordance always existed at ProjectHubScreen.tsx:249, and the failure was fixture drift behind the engine's schema. The action-path test now passes end to end: an invalid graph refused by the integrity gate, then a valid graph attached, validated, frozen, hash stamped, with the project pointing at the contract.

WHAT THIS EPISODE COST AND BOUGHT, recorded because the lesson is the asset: the prerequisite that produced all of this was one command, npm run test:e2e, run before Trial 0 Movement 2 rather than skipped. It found a stray file blinding seven tests, a gate reciting an unverified figure, a live Command Center defect invisible for an unknown period, and a cycle test that had been green-by-accident across at least the 1.1.0 release and every commit since, guarding nothing. The probe doctrine caught the last one only because it was turned on the tests themselves. A test that cannot distinguish its target from an unrelated failure is not a test, and nothing in the corpus had been checking the checkers.

**REG-17 · Phase 3 built the modules and did not wire them into the application (implementation nonconforming; authoring defect in the Phase 3 graph). STATUS: CLOSED July 16, 2026, by Waves 4 and 5 (waypoint, ungoverned with boundary gates; commit ede4e86): every named module has its application caller. envelopeExport.ts is the end-to-end path behind Package Evidence (sealed witness to referee-consumable envelope with live RFC 3161 anchor and REG-38 key-material sweep, every failure a stated absence); driveSession gained its production caller in launchWithSessionRecords plus the resume flavor; the Movement 2 dress rehearsal passed cold on a second machine (referee VALID_RECORD=true, OUTCOME=COMPLETED, one flipped byte rejected, honest-absence anchor path exercised live). Closes when: the live application path actually uses the supervisor, the scope baseline, the session API, the operator record, and the envelope builder; a real governed run through the cockpit emits a conforming envelope directory with a live anchor; and the evaluator accepts that envelope cold.** Discovered July 14, 2026, by tracing the wiring before authoring Movement 2, after Movement 1 established that every historical record is INVALID for want of an envelope. THE FINDING: Phase 3's eighteen nodes built a conforming library that the application does not call. Traced from the source: `src/main/envelope` is imported by exactly two files, test-p3-envelope.ts and test-p3-acceptance.ts, and by nothing else; no IPC channel, preload surface, or renderer path mentions an envelope at all, and the Handoff panel's Package evidence button still calls runs:packageEvidence, which produces the same Waypoint bundle Movement 1 proved INVALID four times over. `src/main/scope`, which carries the REG-12 baseline fix, has ZERO application callers: the defect that defeated a correct node three times and twice manufactured pressure to edit a frozen plan is fixed in a module nothing invokes. `src/main/operator` has zero application callers. `src/main/supervisor` has callers (session/slot.ts, atlas-client/session.ts) but those are not reached from main/index.ts, ipc/handlers.ts, or main/atlas/: the live launch path still spawns through GovernedRunLauncher.ts:187 and AtlasControlClient.ts:190 exactly as before. Only `anchor` (via field-record/honesty.ts) and `credentials` (via plans/principalsBinding.ts) have a genuine thread into application code. WHY EVERY CHECK STILL PASSED, AND WHY THAT IS THE POINT: the tests import the modules directly, so they measure the modules truthfully; the application imports nothing, so the modules are correct and unreached. Eighteen green nodes, seventeen test programs passing cold on a second machine, every probe firing, and the cockpit still runs the old way. Nothing lied. Everything was measured. The wrong thing was measured. AUTHORSHIP, recorded because the register is not for hiding: the Phase 3 graph was authored by the advisory assistant, and every done-test in it asks whether a module behaves correctly. Not one asks whether the application uses it. This is REG-15's own lesson, an obligation that no check enforces is an obligation that does not exist, committed by the party that wrote REG-15 into this register two hours earlier, at larger blast radius. The lesson generalizes past documentation: a done-test that exercises a module through a test-only import proves the module, never the product. Integration is a claim, and an unchecked claim does not exist. FIX SHAPE: a Phase 3b graph whose done-tests run THROUGH THE APPLICATION, not beside it. Every node's check must drive the live path (IPC channel, launcher, or export surface) and assert the new module is what answered, with a probe that unwires it and demands the check fail. BLOCKING: Trial 0 Movement 2 cannot proceed. Movement 2 exists to produce the first conforming envelope from a real governed run; the application currently has no path that emits an envelope at all, so the run would complete cleanly, package a keyed-HMAC bundle, and be refused by the referee exactly like the four records in the Movement 1 matrix. ADDENDUM, RECORDED July 15, 2026, not chased: Waypoint's session driver remains unwired. src/main/atlas-client/session.ts exports driveSession, which calls recorder.recordDispatch(req.session) at line 142; its importers are src/test-p3-acceptance.ts line 29 and src/test-p3-session.ts line 32, and there are no others. grep -rln atlas-client src/ returns those two test files and nothing else; src/main/atlas/AtlasControlClient.ts contains zero references to session_record_dispatch or to dispatch of any kind. p3b-01 seated the SUPERVISOR on the live launch path; it did not seat the SESSION DRIVER. REG-17 therefore stays open on this module. Consequence for the RUL-8 succession, stated so the a3 and 3b graphs inherit it rather than rediscover it: Waypoint's dispatch surface is real but inert, so amending it changes no live behavior, and any done-test that drives driveSession proves the module and never the product. The disposition, port or delete, belongs to Phase 3b, not to succession 1.

**REG-18 · REG-12's fix was built in the wrong repository (authoring defect, advisory assistant; discovered by the executor refusing to fabricate a caller). STATUS: OPEN. Closes when: the REG-12 baseline fix is re-authored against atlas-orchestrator, where scope is actually computed, and a governed run through that repo proves the July 14 false attribution does not reproduce.** Discovered July 14, 2026, during the Phase 3b wiring run, when node p3b-02-scope-live was flagged by the executor rather than faked. THE FINDING: Waypoint computes no scope at all. Verified independently from the source: the only importer of src/main/scope is its own test; the only other occurrences of "scope" in Waypoint's main process are gate_scopes (principal authorization scopes, an unrelated concept) and a replay_policy field. SCOPE_VIOLATION is emitted from atlas-orchestrator/src/store.ts:1754, a different repository, outside this run's project and outside any fence authorable in a Waypoint graph. So REG-12's baseline fix, the highest-priority defect in the migration, the one that defeated a correct node three times and twice manufactured pressure to edit a frozen plan, was built into a Waypoint module that nothing calls and that could never have called it, because the engine remains the attributing party. AUTHORSHIP: the Phase 3 brief (advisory assistant) placed "scope" in Waypoint's column and authored p3-05-scope-baseline there; the Phase 3b graph (same author) then compounded it by instructing the executor to "find whatever the application actually uses to compute scope and route it through src/main/scope", which asked it to find something that has never existed. THE EXECUTOR'S REFUSAL IS THE FINDING'S PROVENANCE AND IS RECORDED AS CORRECT: it traced the premise, established it was false, declined to invent a Waypoint-side caller to turn the node green, and stated the reason precisely, that a module wired to nothing real is REG-17's own lesson inverted and would not stop the bug anyway. It raised a flag on the audit trail, consumed no retry, and left the node's state unchanged pending the operator's decision. DISPOSITION: p3b-02-scope-live waived as DEFECTIVE AS AUTHORED, not defective as built, by named operator authorization with the reason recorded verbatim against the node. Per RUL-3 the Phase 3b run therefore ends terminal with waivers and never COMPLETED, which is the honest outcome: it did not complete. Nodes 3 through 5 and the exit gate do not depend on scope and still deliver what Trial 0 Movement 2 is blocked on. LESSON, and it is the same one twice in one day: REG-17 was "the check never asked whether the app used the module"; REG-18 is "the brief never asked whether the module belonged in that repository at all". Both are authoring defects invisible to a validator, caught only because an executor was permitted, and required, to refuse.

**REG-19 · The session model is per-node; the executor topology is per-run (SPECIFICATION DEFECT, not an implementation gap). STATUS: CLOSED July 16, 2026: the Atlas half landed in a3d (session tools on the standard connection under ATLAS_SUPERVISOR_CLIENT, registered in env-vars.ts); the Waypoint half landed in Wave 4 (commit ede4e86 lineage): Waypoint DRIVES the v0.8 session record over the standard connection, dispatch before the executor exists, exit and result after it ends, fail-closed commissioning (a refused dispatch spawns no executor), orphaned-session closure, and the pen boundary enforced BY CONSTRUCTION on both sides: Atlas exposes the tools only under the flag, and Waypoint DELETES the flag from the executor-facing spec so an inherited environment cannot hand the executor the pen (the inheritance leak was found by the executor during the wave and closed before ship). Remains open only as implementation: closes when Atlas exposes the per-session record on the standard connection and the supervisor drives it.** Discovered July 14, 2026, by the executor tracing node p3b-03 before writing code, and refusing to build against a premise it had disproved. THE FINDING: Atlas's GAD-1 session record is per-node. It wants "I am dispatching an executor to work node X", with a workspace baseline digest captured before that node's work begins. Waypoint launches ONE executor that works MANY nodes in a single session. There is therefore no honest node name to put in a dispatch record: naming the first node attributes the whole session's work to it. This is not a fence problem and no fence widening fixes it. Two subsidiary blockers found in the same trace, recorded because they are real: (1) Atlas exposes the session commands only in the separation tier, where Atlas runs as a separate operating-system user owning the run's files and locking the executor out; that is a DEPLOYMENT topology, not a code change, and Waypoint's actual connection does not offer those commands at all. (2) There is no moment in Waypoint's launch path where it could say "I am dispatching" BEFORE starting the executor; saying it afterwards means the baseline snapshot was taken while the executor was already running, which is a race, and the Phase 3 brief itself names that class of bug as the one a happy-path test can never see. AUTHORSHIP: the Phase 2 brief (advisory assistant) stated as seam 1 that Waypoint would become the session API's production caller in Phase 3. That was wrong when it was written. Waypoint structurally cannot be that caller, because the thing Atlas wants recorded does not correspond to anything Waypoint does. The session API was built in Phase 2, tested in Phase 2, and cold-verified by the advisory assistant, and every one of those checks passed while measuring a model that does not match the system it was built for. THE EXECUTOR'S REFUSAL, again, is the provenance: it traced the premise, disproved it, wrote no code, consumed no retry, and stated that widening the fence would let it build something that passes the check while writing a record it knows to be misattributed, which is "the exact failure REG-17 exists to name". THE QUESTION THE SPEC MUST ANSWER: what is a dispatch, when the unit of execution (a session) and the unit of obligation (a node) are not the same thing? Candidate answers, none adopted: dispatch is per-session with the node set enumerated; dispatch is per-node with the supervisor synthesizing per-node boundaries it cannot actually observe; or the topology changes so one session works one node. Each has costs and none may be improvised. Until this is ruled, no node may claim to implement GAD-1 dispatch through a per-run supervisor.

**REG-20 · The advisory assistant told the operator to authorize a waiver through the guidance-note channel (process finding, advisory assistant; refused by the executor). STATUS: CLOSED July 14, 2026, by the refusal itself; recorded so the refusal is preserved rather than the error.** On July 14 the advisory assistant drafted a waiver for p3b-02 and instructed the operator to deliver it as a guidance note. The executor declined to act on it, stating that notes delivered through the guidance channel are context and never authorization, that this is a structural rule rather than its own judgment, and that a waiver must arrive through the approval channel exactly as approvals do. IT WAS RIGHT AND THE ADVISORY ASSISTANT WAS WRONG. This is the same boundary the operator himself enforced on July 13, when the p2-09 reopen required a named authorization and the executor stated that "a queued note is guidance, not authorization"; the advisory assistant recorded that event approvingly in Field Record No. 4 and then, one day later, proposed the exact bypass. THE PATTERN WORTH KEEPING: the channel distinction is not ceremony. An authorization delivered as context is an authorization with no gate in front of it, and the whole architecture of this system is that governed actions arrive through governed channels. The executor holding that line against BOTH parties who designed it, is the strongest evidence in the corpus that the boundary is structural rather than performative. No corrective action is owed beyond this entry and the operator delivering any waiver through the app's approval channel.

**RUL-8 · REG-19 rested, July 14, 2026, Brandon King. GAD-1 dispatch is per-session.** The session record carries the engine-observed dispatch, recorded BEFORE spawn (the seated supervisor provides that moment), the executor identity triple, the instruction digest, the workspace baseline, the observed exit, quiescence, and the session-level delta: all engine-observed, all recorded at the strength they were witnessed. The node remains the unit of obligation, unchanged. Per-node attribution WITHIN a session is DERIVED evidence: it is computed from the engine's own chain entries (claimed, submitted_for_verification, verify_pass, each timestamped inside the session's window) joined with executor-authored commit boundaries, and it is classed proxy and never upgraded, because the engine did not observe those boundaries. Synthesized per-node dispatch records are FORBIDDEN: the supervisor must never emit a dispatch for a boundary it did not observe, since that is manufacturing evidence. A trust policy MAY require one-session-per-node topology where the stakes demand engine-observed per-node deltas; that is a policy tier, like the separation tier, not the base requirement. Rationale recorded with the ruling: the alternative of synthesizing per-node dispatches manufactures evidence and is dead on arrival; the alternative of mandating one-session-per-node makes the specification dictate deployment topology rather than describe evidence, destroys the session economics that make governed runs practical, and pretends the only trustworthy record is one most operators will not run. The specification records what was witnessed and names the class of what was inferred. CONSEQUENCES: Atlas must expose the per-session record on the standard connection (today the session commands exist only in the separation tier); the Phase 2 session API's per-node dispatch shape is amended to the per-session shape with a derived-attribution section; REG-12's baseline fix lands in the same Atlas-side graph, since both changes live in that repository.

**REG-21 · RUL-8 was recorded in the register and never propagated to the frozen specification that encodes the model (process defect, advisory assistant; the ruling-propagation gap). STATUS: OPEN. Closes when: a RUL-8 successor of the frozen spec exists in gad-protocol (Algorithm 1's dispatch block amended to per-session, the witness schema amended to match, and a derived-attribution predicate added), produced by governed succession with the signed delta RUL-3 and P1-04 require, and the a3 graph is re-authored against the successor.** Discovered July 14, 2026, by the executor tracing a3-01's premise before writing code, for the FOURTH refusal of the day. THE FINDING, in the executor's own frame: this is REG-19's pattern one level up, a ruling recorded in the register but never carried into the artifacts that encode it. RUL-8 rested REG-19 in this register, and this register is the spec's change channel; but the spec itself, frozen in gad-protocol, still reads append(dispatch, {node: n, ...}), mentions RUL-8 zero times, and its witness schema pins the dispatch record to a REQUIRED node field with additionalProperties: false. The executor tested the real schema rather than reasoning about it: every per-session shape is rejected; the per-node shape is the only one that validates. CONSEQUENCE FOUND BY THE SAME TRACE: node a3-01 as authored was self-contradictory, requiring the schema to change (amend to per-session) and requiring it not to (additive and hash-neutral, Phase 2 fixtures must still verify against it). Its done-test could not pass as authored. The two available counterfeits, editing the frozen referee schema from outside its fence, or building a per-session record that never enters the witness so it dodges validation, were both named by the executor and both declined. AUTHORSHIP: the advisory assistant wrote RUL-8, then authored a3-01 citing "spec Algorithm 1 dispatch block as amended", an amendment that had not been made anywhere. A ruling in the change log is not an amendment of the frozen document; a frozen spec is amended only by SUCCESSION, with authority, reason, and the signed delta, exactly as RUL-3 and P1-04 prescribe for frozen plans. The register cannot outrun the spec it governs. DISPOSITION: option A adopted by the operator: author the RUL-8 succession in gad-protocol first, then re-author the a3 graph against the successor; a3-03 (the REG-12 baseline fix) proceeds now, independent and premise-verified. THE DAY'S PATTERN, stated once because four instances make it structural: REG-17 (checks never asked if the app used the module), REG-18 (the brief never asked which repository owned the code), REG-19 (the API never asked whether its model matched the topology), REG-21 (the graph never asked whether the ruling had reached the frozen document). Four premises, four refusals, zero fabrications. The validator caught none of them. The premise-audit clause caught the fourth, which is the process working as amended: the clause was added after REG-18 and REG-19, and the first graph carrying it surfaced the defect before a line of code was written.

**REG-22 · REG-12's original fix-shape was wrong, and the two scope failures have different causes (register correction; discovered by the fifth executor refusal, proven against the real engine). STATUS: CLOSED July 16, 2026, by a3d (run of a3-02 at commit 3c18a19): derived attribution landed in store.ts/git.ts where the engine runs; foreign and sibling commits distinguishable, classed proxy; the scope-baseline harness asserts the foreign-commit defect CLOSED with a firing misattribution probe; two real bugs found and fixed pre-ship by the executor (local-time vs UTC string comparison voiding every window; git whole-second granularity, now stated and fail-closed). Closes when: RUL-8's derived attribution (commit-boundary identity) lands via the gad-protocol succession and the engine uses it to attribute scope per node, so a foreign party's commit and a sibling node's commit are both distinguishable from this node's work.** Discovered July 14, 2026: the executor, cleared to build a3-03, ran the node's premise audit, found the premise TRUE, then traced the PRESCRIBED FIX and disproved it in a throwaway repo against the current engine before writing any code. Verified independently by the advisory assistant in a second reproduction. THE TWO DEFECTS, now correctly separated: (1) FOREIGN-COMMIT ATTRIBUTION: a commit authored by a different party (a prior run, the operator) is attributed to whichever node the scope check runs against, because a whole-tree diff has no notion of WHO committed; no choice of baseline point fixes this, and run-start baselining also FALSELY ATTRIBUTES SIBLING NODES' WORK (node A's committed files appear in node B's diff), breaking every multi-node run. Requires commit-boundary identity, i.e. RUL-8 derived attribution, blocked behind REG-21's succession. (2) REOPEN WITHOUT RE-BASELINE: a regression-reopened node is diffed against its original baseline from before later nodes existed; this is the half that wedged Phase 2's p2-04 and it is INDEPENDENT of attribution, buildable today, and now the whole of a3-03. AUTHORSHIP: the advisory assistant wrote the original fix-shape into REG-12 with confidence and without testing it; the executor tested it. The register is the spec's change channel, and a wrong prescription in it would have sent the next implementer to build a provably breaking change: correcting the register IS the fix, and this entry is that correction. Evidence harness retained in-fence at src/test-a3-scope-baseline.ts (probe stage, uncommitted at time of finding), reproducing both failures against the unmodified engine.

**REG-23 · REG-21's closure condition is unsatisfiable as written, and rests on borrowed authority (register correction; advisory assistant, self-reported, found by reading gad-protocol from source on July 15 rather than recalling it). STATUS: OPEN. Closes when: REG-21's closure condition is restated against RUL-9's ceremony and against the proven constraints below, and the restated condition is the one the succession graph is authored against.** Discovered July 15, 2026, during the source read that the state document's Step 1 required as a prerequisite and that REG-21 itself exists because nobody performed. The read confirmed REG-21's factual core exactly: the frozen spec still reads append(dispatch, {node: n, ...}) at Algorithm 1 lines 51 through 53, contains the string RUL- zero times, and pins dispatchPayload to a required node with additionalProperties: false. REG-21's diagnosis is sound. Its CLOSURE CONDITION is not, in three distinct ways. DEFECT 1 · BORROWED AUTHORITY, and it is the serious one: REG-21 requires the successor be "produced by governed succession with the signed delta RUL-3 and P1-04 require." Both are plan rules and neither applies. RUL-3 governs waivers within frozen PLANS, mapping terminal_with_waivers to SUPERSEDED-pending or HALTED. P1-04 is a gap-audit line item reading, verbatim from the Codebase Gap Audit: "Signed succession delta | Predecessor witness carries authority, reason, obligation map, changed fences/tests/floors." A PREDECESSOR WITNESS. A specification has no witness. It has no fence, no node set, no dependency edges, and no AuthorizedPrincipals(P) registry. The spec's own SUCCEED(P) at lines 145 through 152 takes P, and P = (N, D, meta) per line 322; its emitted plan_superseded payload is typed to obligation_map, changed_class_floors, changed_fences, changed_tests, not one of which is a thing a specification has. SUCCEED is not applicable to this document, and the register said it was. AUTHORSHIP: the advisory assistant wrote REG-21, including its closure condition, in the same session that discovered REG-21. The error is exactly the one REG-21 names, committed one level down and in the same breath: REG-21 correctly said a ruling in the change log is not an amendment of the frozen document, then prescribed the remedy by analogy to two rules it had not checked applied. The register is what everything else is authored against. A wrong prescription here does not sit inert; it becomes the premise of the next graph, and the next executor traces it and refuses, which is precisely what REG-22 recorded happening with REG-12's fix-shape. That is now twice the register has carried a prescription that would have sent an implementer to build something unbuildable. The pattern is not "the advisory assistant is careless about code"; it is THE ADVISORY ASSISTANT IS CONFIDENT ABOUT CEREMONY IT HAS NOT READ, and ceremony is what this register is for. DEFECT 2 · "ADDITIVE AND HASH-NEUTRAL" IS IMPOSSIBLE, PROVEN AGAINST THE BYTES, STRUCK RATHER THAN SOFTENED: REG-21 requires the witness schema be "amended to match" while node a3-01 simultaneously required the amendment be "additive and hash-neutral, Phase 2 fixtures still verifying." The executor found the contradiction by testing the real schema; this read establishes why it is structural and not a drafting slip, on two independent grounds. First, additionalProperties: false means no field can be added to dispatchPayload at all. Verified against the repository's own Ajv2020 configuration (strict: true, allowUnionTypes: true), the same one tools/schemas-examples.mjs line 73 constructs: the baseline entry-dispatch.json validates; the same instance with a single added derived_attribution property is REJECTED with "must NOT have additional properties"; the per-session shape with node removed is rejected with both "must have required property 'node'" and "must NOT have additional properties." There is no additive change to this payload. The schema forbids the category. Second, and independently, the chain hash covers the payload. evaluator/src/canon.ts computes h_i = H(utf8(dom) || 0x00 || raw(h_prev) || canonBytes(body)), and payload is a member of body. Executed against the real fixture conformance/valid/completed/core/witness.json: the recorded seq-1 hash d4f123ac…09b81fe7 recomputes exactly, and the same body with one added payload field yields 3e4476cf…d20b34d6, a different entry hash and therefore a different hash for every entry after it. Hash-neutrality is not merely absent; the hash covering the payload is the mechanism the whole record depends on. A witness entry that could change without changing its hash would be the defect. RULED, July 15, 2026, by the operator: the constraint is struck, not softened. The honest constraint replacing it: the fixture builder changes, the fixtures regenerate from genesis, the chain recomputes correctly, and root_core changes, which is disclosed rather than hidden. tools/fixture-builder/build.mjs already recomputes the chain from GENESIS, so regeneration is the designed path and not a workaround. Acceptance test 17 (two independent builds yield identical root_core) still holds, because it compares two builds of the same version, never across versions. Any external reference to the old root_core goes stale and the delta names it. DEFECT 3 · THE EVALUATOR RE-DERIVATION IS NOT A LINE ITEM INSIDE A SCHEMA CHANGE: REG-21's closure condition names three artifacts, Algorithm 1's dispatch block, the witness schema, and a derived-attribution predicate. It does not name the evaluator, and the evaluator does not merely validate the shape; it INDEXES off it. evaluator/src/evaluate.ts line 494 detects a gated node's first consequence by matching dispatch.payload.node against the frozen plan's dependency edges, which is the whole of R7's ordering check. evaluator/src/transitions.ts lines 152 through 174 key five separate rules off e.node on dispatch: the GAD-1 triplet, post-trip resume (RUL-2), refusal exits, failed-routes, and RUL-4 gate ordering. If dispatch stops naming exactly one node, R7's consequence detection and those five transition rules lose their index. RULED, July 15, 2026, by the operator: the evaluator re-derivation gets its own node with its own probe. Also noted, and not a line item either: the derived-attribution predicate lands in registry/predicates.json, a fourth artifact REG-21 names only obliquely, whose binding this read did not trace. ALSO CORRECTED, per REG-16's rule pointed at the project's own state document: three different counts for gad-protocol's test surface are in circulation; the state document says "17/17 phase-gate checks", package.json declares thirteen npm scripts, and the evaluator holds twenty-two unit tests across four files plus one probe. The advisory assistant declined to recite any of them. RULED, July 15, 2026, by the operator: the referent is whatever gate:phase1 actually computes, and the done-test parses it. If the state document's figure does not match what the gate computes, the state document is wrong and gets corrected. A reported figure must be computed, never recited, and a state document is not exempt from the rule it states. This register's own Sequence item 3 recites the same unverified figure and is corrected below by the same ruling. DISPOSITION: RUL-9 (specification succession, rested July 15, 2026) supplies the ceremony REG-21 assumed existed. REG-21's closure condition is restated as: a RUL-9 succession of the frozen spec exists in gad-protocol, performed under RUL-9's ceremony with its signed sidecar delta, amending Algorithm 1's dispatch block to the per-session shape, amending the witness schema to match with fixtures regenerated and root_core disclosed as changed, re-deriving the evaluator's consequence and transition indices under their own node and probe, adding a derived-attribution predicate to the registry, moving Section 14's stewardship rule inside the declared normative range, and naming every invalidated downstream artifact; and the a3 graph is re-authored against the successor. The ceremony gap was found by reading rather than recalling, in the session convened for exactly that purpose, and the reading also surfaced REG-24 and REG-25, which alter what the succession must amend.

**REG-24 · The referee's execution_result payload carries no session key, so per-session dispatch orphans the third entry of the GAD-1 triplet (SPECIFICATION DEFECT, gad-protocol; found July 15, 2026 by tracing the blast radius through atlas-orchestrator's source rather than reasoning about the schema). STATUS: CLOSED July 15, 2026, by succession 1 (execution_result carries required session_id and nullable node in spec, schema, and evaluator; gate green at 18 checks, cold-verified on a second machine). Original closure condition: closes when the successor's execution_result binds to its session and Atlas's triplet reconstruction keys off that binding rather than off node identity alone.** Discovered July 15, 2026, during the RUL-9-mandated trace of who reads dispatch.payload.node. No prior entry names this. REG-19 identified the topology mismatch (the session is per-run, the node is the unit of obligation); RUL-8 rested it; REG-21 identified the propagation gap. All three treated the amendment as bounded by the dispatch record. It is not. THE FINDING, read from schemas/witness-entry.schema.json: dispatchPayload requires node and session_id, additionalProperties false; executorExitPayload requires node and session_id, additionalProperties false; executionResultPayload requires node, delta_ref, delta_digest, touched_surface, output_status, has NO session_id, additionalProperties false. The third entry of the mandatory triplet has no session key and, under additionalProperties: false, cannot be given one without amendment. The consequence is visible in the constructor's own source. atlas-orchestrator/src/v06/session.ts lines 104 through 110 state it in the engine's own voice: the referee's execution_result payload carries no session_id, schema-fixed, so a result is attached by NODE, unambiguous only because the engine's write rule keeps at most one unresulted session open per node at any time. The implementation matches the comment: sessionViews (lines 111 through 148) attaches an executor_exit by session_id through a map lookup, but attaches an execution_result by scanning backwards for the latest view where v.node === p.node (lines 138 through 144). The disambiguation it depends on is enforced at openSessionForNode (lines 262 through 265) and the refusal at lines 293 through 301. WHY THIS BREAKS RUL-8 AND NOT MERELY THE SCHEMA: under RUL-8, one dispatch names a session covering many nodes. At that moment, (1) execution_result has no key by which to attach to its dispatch, because its only identifying field was the node and the node is no longer singular; and (2) "at most one unresulted session open per node" has no referent, because sessions are no longer per node. The join that makes the GAD-1 triplet a triplet is broken. executor_exit survives untouched, because it carries session_id and matches on it. The triplet does not fail uniformly; it fails at exactly one joint, and that joint is the engine-captured entry the specification calls mandatory precisely because it must exist even when the executor never returns. SEVERITY AND SCOPE: this is a specification defect in the same category as REG-19: the schema encodes an assumption (one session, one node) so deeply that the assumption is load-bearing in a record that never mentions sessions at all. It is not an Atlas defect. Atlas's comment is accurate, its implementation is correct against the frozen schema, and its disambiguation invariant is the honest way to live within a schema that gave it no key. The engine did the right thing with the record it was given. Consequently REG-24 must be discharged by the RUL-9 succession itself, not deferred to the Atlas re-authoring: if succession 1 amends dispatch to per-session and leaves executionResultPayload alone, the successor specification is internally inconsistent on its own mandatory minimum record, and the a3 graph becomes unbuildable for a second time on a second false premise. AUTHORSHIP AND PROVENANCE, stated because it is the point: the advisory assistant did not find this by reasoning about RUL-8, and RUL-8 as written does not anticipate it. It surfaced only from tracing the constructor's source to answer the operator's question about blast radius, and it surfaced from a code comment that turned out to be a schema fact worth verifying independently, which it was. The finding was flagged rather than absorbed into REG-23 or quietly widened into the succession graph's scope: findings before fixes, one finding per entry, and a defect discovered while authoring is still a defect that predates the authoring. RESOLUTION: RUL-10 as amended, below, which rests both this entry and REG-25 with one binding.

**REG-25 · RUL-8 makes node-level attempt-completion DERIVED, and OUTCOME currently depends on it being OBSERVED (specification defect, gad-protocol; discovered July 15, 2026 by tracing isVerified's inputs before authoring against a ruling one hour old). STATUS: CLOSED July 15, 2026, by succession 1 (completedAttempt reads node when non-null and derives at proxy when null; the multi-node fixture exercises the derived path on every build). Original closure condition: closes when the successor's execution_result carries the nullable node and the evaluator's completed-attempt tracking reads it directly when non-null and derives from the derived-attribution section when null, with the derived path classed proxy.** Discovered July 15, 2026, in the same trace that produced REG-24 and one step past it. REG-24 established that execution_result has no session key and that per-session dispatch therefore orphans the triplet's third entry. REG-25 is what the next question found: the orphaning is not the only consequence, because execution_result.node is not merely a join key. It is an input to OUTCOME. THE FINDING, read from source: evaluator/src/evaluate.ts lines 405 through 413 build completedAttempt, a set of node ids, by pairing an executor_exit whose status is completed with a following execution_result, both matched by payload.node. Fifteen lines later, at line 415, isVerified(n) returns false immediately unless completedAttempt.has(n.id). isVerified feeds OUTCOME. The transition checker holds the same dependency structurally: evaluator/src/transitions.ts lines 118 through 126 route every node-naming event through a nodeOf helper that errors with "must name a node" when e.node is not a string, and execution_result is routed through it at line 190. The consequence of RUL-10 as originally rested, which dropped node outright: awaiting.get(undefined) returns undefined, completedAttempt stays empty, no node satisfies isVerified, and EVERY CONFORMING RUN EVALUATES INCOMPLETE. The amendment would have made the successor specification unable to credit completion to anything at all. THE STRUCTURAL FACT UNDERNEATH IT, mapped from schemas/witness-entry.schema.json: ten payloads carry a node or session key. node is required on all ten (claim, dispatch, execution_result, executor_exit, flag, gate_request, remediation, retry, revised_approval_request, trip). session_id is required on exactly two (dispatch, executor_exit). node is the universal spine of the witness; session_id is a local field on two payloads. REG-24 framed the defect as a missing session key. The symmetric and more useful statement: every downstream check in the evaluator finds its subject by node, so removing node from any payload does not relocate a join, it severs that payload from the entire index. WHY THIS IS A SPECIFICATION DEFECT AND NOT AN EVALUATOR DEFECT: the evaluator is correct against the frozen specification. Under v0.6, one session works one node, so "did node n complete an attempt" is a directly engine-observed fact and keying it by node is exactly right. RUL-8 changed what is observable without anyone tracing what depended on the old observability. Under RUL-8 the session is what completes; node-level attempt-completion within a multi-node session is derived, computed from the chain's own entries joined to executor-authored commit boundaries, classed proxy and never upgraded. The specification made a fact derived and left a decision procedure treating it as observed. That is the same species as REG-19 (the API never asked whether its model matched the topology), one level further down: the ruling never asked what consumed the thing it changed. THE GAD-2 QUESTION, RAISED AND ANSWERED AGAINST THE TEXT RATHER THAN ASSUMED: the advisory assistant flagged a possible collision, that if isVerified consumes derived attribution, a proxy-classed input gates COMPLETED, which appeared to conflict with the GAD-2 evidentiary floor. The operator checked the frozen text and the collision does not exist. Section 8, line 414, verbatim: "every completion-crediting done-test requires effective class of at least proxy. Attested evidence MAY be retained as context and MUST NOT independently satisfy a completion obligation." The floor is proxy, and RUL-8's derived attribution is classed proxy, so derived attribution satisfies the floor rather than colliding with it. The floor exists to forbid attested evidence, the executor's own testimony, from crediting completion; derived attribution is computed by the engine from the engine's own chain entries, which is what proxy means. Confirmed independently by the advisory assistant against the same line and against evaluate.ts lines 415 through 421, where the floor's enforcement (CLASS_RANK[v.eff] >= CLASS_RANK[n.c_min]) is a separate gate over verdicts, distinct from the completedAttempt membership test over the triplet. The floor governs done-tests, the verdicts that credit completion; it does not govern the triplet's attempt-tracking. The flag was correct to raise and the answer is that the ruling clears the floor it was worried about. THE RATIONALE CORRECTION, recorded because the correction is the finding's twin: RUL-10 as first rested rejected the retained-node candidate on the ground that two keys is how the join broke. The operator adopted the advisory assistant's correction: the join broke because execution_result carried ONLY node, and RUL-8 made node non-singular for a dispatch. Two keys is a problem only when both purport to identify the same thing at different strengths. A nullable observed key plus a derived section does not do that: when the key is present it is observed, when it is absent the absence is stated, and the derived section is visibly derived and classed accordingly. AUTHORSHIP AND PROVENANCE, stated because it is the point and because REG-23 named the pattern this entry instantiates: the advisory assistant traced the dispatch surface carefully, reported it, and then let RUL-10 through on the strength of its rationale WITHOUT first tracing execution_result's readers. The trace that found this defect took four tool calls and should have been run before the ruling was rested, and the advisory assistant should have said it had not been. It said so on discovery rather than authoring the graph around it: node 3 would have amended the payload as rested, node 5's evaluator re-derivation would have struck evaluate.ts line 411, and the executor would have traced the premise and refused, for a sixth refusal against a ruling the advisory assistant helped write one hour after documenting that its failure mode is confidence about ceremony it has not read. REG-23's diagnosis applies prospectively, not only retrospectively, and this entry is the first instance where it was caught by the party it describes rather than by the executor. The graph was withheld; the finding was flagged; the ruling was amended; nothing was built on the false premise.

**REG-26 · Atlas's v0.6 test programs are not in the repository's default test path (process gap, atlas-orchestrator; low priority, recorded rather than chased). STATUS: CLOSED July 16, 2026, by a3d: all fourteen v06 programs run under npm test via a discovered-not-recited runner (fail-closed on an empty set, output required per REG-39), computed count v06-programs-passed=14, cold-verified. Closes when: the v0.6 suite runs under a declared script that CI or the default test path invokes, so a v0.6 regression is caught by running the repo's tests rather than by remembering to run them.** Observed July 15, 2026, while tracing the dispatch blast radius. package.json's test script chains nineteen legacy programs (test-harness, test-upgrades, test-ops-upgrades, test-provenance, test-autonomy, test-approval-gate, test-verifier, test-init, test-persistence, test-http-transport, test-regression, test-validate, test-lock, test-recovery, test-inbox-approval, test-guidance-inbox, test-pause-inbox, test-diagnostics, test-anchor). None of the test-v06-* programs appear in it, and no script name contains v06. The v0.6 suite is real and passes cold per the July 14 record; it is simply not in the path npm test walks, so its passing depends on an operator choosing to invoke it. Not a conformance defect and not blocking succession 1, which touches neither repository. Recorded now because the a3 graph will re-author against the successor and will want a test path that fails when it should.

**RUL-9 · Specification succession, rested July 15, 2026, Brandon King. A specification succession is a distinct object from plan succession and borrows nothing from it.** Its object is the specification document itself, identified by the byte digest of the frozen text. Its authority is the operator, named. Its signature is over a spec-succession delta carrying: predecessor spec digest, successor spec digest, the register entries and rulings the amendment discharges, a section-level statement of what changed and why, the identity of every downstream artifact whose bytes the amendment invalidates, and an explicit statement of what the successor does not claim. The record lives in gad-protocol as a signed sidecar beside the spec, and this register cites it. Successions are numbered; v0.6 to v0.7 is succession 1. THE GENESIS DISCLOSURE, and it must not be softened: succession 1 is performed under a ceremony that v0.7 itself introduces. v0.6 did not authorize its own amendment and no artifact will claim it did. The delta states this in its own text: this succession is genesis, it is the first act under a rule it also creates, and every succession after it is governed by a rule that predates it. Same species of honesty as the referee not blessing its own birth certificate. ALSO RULED, on the advisory assistant's finding: Section 14's stewardship rule sits outside the declared normative range (the spec's line 5 declares Sections 1 through 11 and Section 12A normative; Section 14 is not among them). The successor moves it in, or the document's own change rule is decorative. GAP 1, AMENDED July 15, 2026 on the advisory assistant's trace and accepted: the delta as first rested required naming every invalidated downstream artifact individually. Counted from the trees, that population spans the fixture witnesses carrying dispatch entries, the transition artifacts, the root_core of each valid envelope, roughly eight atlas-orchestrator source modules, roughly twenty-five Atlas test construction sites, and two Waypoint files. A hand-typed list of that size is stale the moment any of it moves, and staleness is the failure mode every finding of July 14 traces to. AMENDED: the delta names artifact CLASSES and cites the digest of a manifest COMPUTED from the trees by a node. Hand-typed lists are recited figures; standing rule 4 forbids them and the ruling as first rested wrote one anyway. GAP 2, AMENDED the same day and accepted: the delta gains a CONSEQUENCES section for structural couplings the amendment severs, distinct from the invalidated-artifacts list. A broken join is not a stale byte, and REG-24 is the proof the distinction is load-bearing. CONSEQUENCE FOR THIS REGISTER'S OWN OPENING CLAIM, recorded rather than silently corrected: this document's opening line states that the register is the specification's only open channel. Under RUL-9 that remains true as to the CHANNEL, findings still arrive only here, but the AMENDMENT itself is now an act performed elsewhere, by ceremony, recorded in a signed sidecar this register cites. The register is where the spec learns it must change; the succession is how it changes. REG-23 is the entry that forced the distinction and the opening section is amended below to state it.

**RUL-10 · REG-24 and REG-25 rested, July 15, 2026, Brandon King, as AMENDED the same day on the advisory assistant's trace. execution_result gains a required session_id and RETAINS node as a nullable field.** Non-null when the session covered exactly one node (engine-observed; the one-session-per-node policy tier RUL-8 preserves), null when it covered many. Null is stated absence per I5, unknown is fail and absence is evidence, not a second key at a different strength. It carries the session-level delta, which is what the engine actually observed. completedAttempt reads node directly when non-null and derives from the derived-attribution section when null, with the derived path classed proxy. Per-node attribution within the result is derived, computed from the chain's own entries joined to commit boundaries, classed proxy, never upgraded, and it lives in the same derived-attribution section RUL-8 already defines rather than getting a second mechanism. RATIONALE, recorded with the ruling: candidate 3 (enumerate per node within the session) reintroduces the per-node record under a new name and invites exactly the synthesis RUL-8 forbids; candidate 2 as originally framed (session_id plus a retained optional node) was rejected on the ground that it leaves two keys where one is observed and the other is inferred. THE FIRST RESTING OF THIS RULING DROPPED node OUTRIGHT AND WAS WRONG, and the record states why rather than quietly carrying the amended text: the advisory assistant traced isVerified before authoring against the ruling and found that dropping node empties completedAttempt, so no node satisfies isVerified and every conforming run evaluates INCOMPLETE (REG-25). The amended ruling adopts the advisory assistant's recommendation, with one correction to its premise, which the operator took: the join broke because execution_result carried ONLY node and RUL-8 made node non-singular for a dispatch; two keys is a problem only when both purport to identify the same thing at different strengths, and a nullable observed key plus a derived section does not do that. One key, observed, when there is one to observe. Attribution derived, once, in one place, at the strength it was witnessed. GAD-2 CHECKED AND CLEAR: the floor (spec Section 8, line 414) requires completion-crediting DONE-TESTS to be at least proxy and is enforced separately over verdicts; derived attribution is classed proxy and therefore satisfies it. The floor governs done-tests, not the triplet's attempt-tracking. See REG-25.

**REG-27 · The succession graph's done-tests assumed a POSIX toolchain on a Windows host, violating the project's own cross-platform rule (authoring defect, advisory assistant; found by the executor on node 1 of 9 of run #33; two companion latent halts found by executing every check in the advisory environment before re-authoring). STATUS: CLOSED July 15, 2026: the successor plan (succession-1b) completed 10 of 10 with every command executing under cmd.exe, and the exit gate passed server-side on the operator machine. Closes when: the successor plan (succession-1b) completes with every command executing identically under cmd.exe and sh, and the exit gate passes server-side on the operator's machine.** Discovered July 15, 2026, when run #33 of the gad-protocol succession crashed on node s1-01. The executor's conduct is recorded first because it is the model: the premise audit passed on all five points, the work was authored and committed (Section 15, the normative-range amendment, the ratified v0.7 version bump), and then verification failed 4 of 5 checks with "'grep' is not recognized". The executor ran the four failing commands itself under Git Bash, watched all four pass, and REFUSED to record the node as verified: "that does not count and I am not recording the node as verified. The server has to run its own checks and see them pass." That is the attested-versus-engine-observed boundary enforced by the executor against its own convenience, unprompted, and it is the GAD-2 floor working in a sentence. **THE DEFECT AND ITS AUTHORSHIP.** The advisory assistant authored 17 POSIX-dependent command strings across 7 of the 9 nodes (grep, head, test, ls, wc, cmp; shell command substitution; /tmp paths; shell globs) for a machine it knew runs Windows: the operating system is recorded in the project's own state document, the Windows paths appear in every run artifact, and the project's standing rules already said scripts must stay cross-platform. The graph was validated against Atlas's schema, which passed it with zero errors because command strings are opaque to the validator, and it was never asked what shell would execute them. Atlas spawns done-test commands via spawnSync with shell: true (verifier.ts ~L1310), which on Windows is cmd.exe, not any POSIX shell. This is REG-23's pattern, confidence about ceremony not read, where the ceremony was the runtime. **THE RECOMMENDED REMEDY WAS ALSO WRONG, and the trace that proved it is the entry's second lesson.** The executor recommended adding Git's usr/bin to PATH (Option A), reasoning correctly from the four failures it could see, three of which PATH genuinely fixes. The advisory assistant traced all 47 command strings before the operator ran anything: PATH fixes 9 of the 17; the other 8 fail on cmd.exe syntax that no binary on PATH can supply (command substitution, /tmp, glob expansion). Option A would have gotten node 1 green and crashed node 2 on its first check, converting one visible failure into a slow sequence of them across a continuous run. Additionally the proposed setx command rewrites the persistent user PATH and truncates at 1024 characters, a real risk to the operator's machine taken to fix a defect the advisory assistant authored. The executor's reasoning was sound on partial evidence; the full trace belonged to the party that wrote the defect. **TWO COMPANION LATENT HALTS, found by executing rather than reading, both of which would have survived Option A:** 1. **scaffold:check fails on the current tree** with "docs/ missing or empty: fable-phase1-brief.md". The operator moved the build-side briefs and graphs out of docs/ on July 14 to strengthen the referee's independence claim; tools/scaffold-check.mjs's DOCS_FILES constant still requires the moved brief. The original exit gate ran scaffold:check and would have halted the run at its final node, after all real work was done, on a failure unrelated to the succession. The successor plan opens with a realignment node (s1b-00) that removes only the moved brief from the required list, keeps the four referee-defining documents required, and proves the probe still fires: maintenance of the checker's stale premise, not weakening of a gate. 2. **The evaluator's negative-probe invocation was vacuous.** The original graph (and the first draft of the successor) invoked `node evaluator/run-tests.mjs --probe`; run-tests.mjs ignores unknown arguments and exits 0, so the negative probe would have been green without ever proving the runner can fail, which is the exact always-green trap the probe doctrine exists to catch. The correct invocation is the committed probe suite itself, `node --test evaluator/probe/probe-fail.test.ts`, verified to exit nonzero. Found only because every negative command was executed in the advisory environment; reading the graph would never have surfaced it. **THE DISCIPLINE ADOPTED FOR THE SUCCESSOR PLAN, so the closure is a method and not a patch.** Every command string in succession-1b satisfies a hard rule: npm run <script>, node <file>, npx tsc, or a node -e one-liner using only single-quoted JS strings, no shell substitution, no percent signs, no /tmp (os.tmpdir() where needed), no shell globs (fs.readdirSync), failing via process.exit(1). These execute identically under cmd.exe and sh. Enforcement was by execution, not judgment: all 28 node -e one-liners were run against the real tree (zero syntax errors); every positive check was additionally run against a synthetic post-succession tree mocking the run's intended end state, proving each check SATISFIABLE and passing for the right reason; every failure against the synthetic tree was individually classified (mock shallowness with the same command proven on the real tree, or a stub bug that was fixed and re-proven); every negative probe was executed and shown to fire. One further constraint surfaced by the stub work and written into the tool-authoring nodes: the repository declares type: module, so authored .mjs tools must use import, while node -e one-liners correctly use require because node -e defaults to CommonJS regardless of package.json. **WHAT RUN #33 LEFT BEHIND, disposed rather than discarded.** The spec work is committed and sound; only its verification never ran server-side. The successor plan's first spec node (s1b-01) is therefore a VERIFICATION node against the committed text, not an authoring node, and it ratifies by explicit premise the executor's flagged judgment call: the version-label bump to 0.7, made because Section 15 states its ceremony is introduced by v0.7 and a 0.6 header would contradict the document's own new section, with v0.6's frozen record left intact as historical fact. The judgment call was correct; it is ratified in the plan rather than re-litigated by the executor, and recorded here because a scope judgment made mid-node without a gate should be named, not normalized. **Run #33 itself is left crashed and is not relaunched**: its plan carries the defective checks, a frozen plan is never edited to make a check pass, and succession by a corrected successor plan is the sanctioned path, exactly as RUL-2 prescribes for tripped nodes and Waypoint's supersede flow implements.

**REG-28 · executor_exit retains a scalar node while its two sibling records went per-session (specification defect, gad-protocol; disclosed by the executor at the close of succession 1, run of July 15, 2026). STATUS: CLOSED July 16, 2026: RUL-12 rested the rule (executor_exit follows the nullable-node pattern) in succession 2, and a3-01 implemented it; the status line lagged the closure it had already earned. Closes when: a successor spec rules what one exiting executor's record names under a multi-node session, and the schema and evaluator are amended to match.** RUL-10 as amended deliberately left executor_exit unchanged, and it survived succession 1 for a mechanical reason: it carries BOTH node and session_id, so its join with the dispatch never depended on node being singular. But the survival hides a semantic fiction the executor named at handoff: under a multi-node session, a required scalar node on the exit record implies one exit per covered node, which is not what one exiting executor process does. One session dies once. The record that captures that death should name the session and, at most, derive per-node consequences the way RUL-8 derives everything else: from the chain, classed proxy, never synthesized. This is REG-24's shape one entry over: a payload encoding the one-session-one-node assumption, load-bearing only while the assumption held. It did not break succession 1 and blocks nothing in gad-protocol; it WILL bite when Atlas is amended against v0.7, because Atlas's supervisor records exactly one exit per session and will have no honest scalar node to write. Recorded now, before the a3 graph is authored, so the a3 executor inherits the finding instead of rediscovering it as a refusal. Feeds succession 2's scope.

**REG-29 · The invalid conformance fixtures have no generator and carry the pre-succession witness shape, evaluated only through a transition-checker normalization that reads a scalar dispatch node as a one-member set (conformance-corpus asymmetry, gad-protocol; disclosed by the executor at the close of succession 1 and verified cold by the advisory assistant July 15, 2026). STATUS: RULING ADOPTED July 15, 2026: closure by BLESSING, the normalization written into the specification text by succession 2; the invalid-fixture generator remains available as future work and REG-29 closes when succession 2 lands. Closes when: either the normalization is blessed in the specification's own text by succession, or the invalid corpus gains a generator and is regenerated to the successor shape, with each fixture still rejected for ITS OWN R-condition.** The nine invalid fixtures were hand-derived from their valid parents at genesis and were not regenerated by succession 1 because there is nothing to regenerate them WITH. Each is still rejected for its own R-condition, so no coverage was lost, and the gate proves it on every run. But the asymmetry is real and verified against the bytes: an old-shape dispatch FAILS v0.7 schema validation (the schema admits only the node-set spelling), while the transition checker normalizes the scalar spelling to a one-member set and evaluates the trace. The checker's own comment argues the read is a spelling of a legal set, not the forbidden synthesis, and the argument is defensible: reading node n1 as the set containing n1 invents no boundary the engine did not observe. The result is nonetheless a conformance corpus whose negative half is schema-invalid against the specification that judges it, evaluated through a concession that lives in one tool's source rather than in the normative text. That is an architectural fact the operator decides rather than inherits. The two closures are not equivalent: blessing the normalization is one sentence in a successor spec and preserves the historical fixtures byte-identical; regenerating requires building the generator the corpus never had, which also closes the no-generator gap and is the honest long fix. Disclosed in the invalidation manifest at succession 1; recorded here so the decision has a home.

**REG-30 · The Phase 1 exit gate sweeps only its three original valid fixtures; the multi-node-session fixture that exercises RUL-10's derived-attribution path is outside its hardcoded expectations (coverage gap, gad-protocol; disclosed by the executor at the close of succession 1). STATUS: CLOSED July 15, 2026, by s2p-02: the gate sweeps the multi-node fixture (18 checks, computed, cold-verified); its determinism comparison gap is separated into REG-32. Closes when: tools/gate-phase1.mjs evaluates the multi-node fixture in its sweep with its own expected outcome, and the gate's probe still fires.** gate-phase1.mjs has its fixture expectations hardcoded and sat outside every succession-1 node's fence, so the run could not touch it, and the executor correctly did not. Its compensating move was sound: the multi-node fixture is wired into fixtures:build, which now evaluates it and requires COMPLETED on every build, so the derived path runs rather than shipping unexercised. But the EXIT GATE is the artifact strangers are pointed at, and it does not cover the one fixture that exercises the successor's new evidence path. One small fenced node adds the fourth fixture to the sweep. Scheduled in the s2-prep housekeeping run.

**RUL-11 · Succession 1's record is re-signed under a real operator authority key; the fixture-key boundary is NOT widened. Rested July 15, 2026, Brandon King, on the advisory assistant's recommendation at the close of succession 1.** The delta at succession/delta/succession-1.json was signed, as its node directed, with the committed dev authority key from conformance/keys/, whose own warning field forbids signing anything outside conformance/. The conflict was disclosed in the delta, in the invalidation record, and in this register's succession section, and the resolution is ruled as follows. (1) The fixture key's boundary stands unamended: widening it to admit the succession record would make the fixture key more powerful instead of making the succession properly signed, and RUL-9 requires the succession's authority to be the operator, NAMED, which a fixture key names nobody. (2) A real Ed25519 operator keypair is generated; the PUBLIC key is committed beside the succession record; the PRIVATE key never enters the repository. (3) The delta BODY is untouched and its digests unchanged; only the signature is replaced, and the verifier is amended to verify the succession signature against the operator public key while the fixture keys continue to verify fixtures and nothing else. (4) The dev-signed delta is retained as the genesis artifact it honestly was, beside the re-signed record, because succession 1 is genesis and its record should show what genesis actually looked like rather than a cleaned-up version. (5) This is REG-14's first concrete forcing function: key custody was deferred with an interim rule that a compromised key is handled by succession, not in-place revocation; the operator key created here is the first key that rule will ever apply to, and REG-14 remains open. Closure via the s2-prep governed run; the register's succession section is updated by that run to record the resolution.

**REG-31 · build-delta.mjs still signs with the dev key and writes to succession-1.json, so re-running it would overwrite the operator-signed record with a dev-signed one (tooling hazard, gad-protocol; disclosed by the executor at the close of the s2-prep run, deliberately not fixed there because it was outside every node's instructions). STATUS: OPEN. Closes when: the builder refuses to overwrite a record whose signature is not the dev key's, and the refusal is probed.** The hazard fails SAFELY: the verifier would reject the overwritten record loudly rather than anything silently corrupting, and the builder physically cannot sign with the operator key, which lives outside the repository by design. The executor's scope discipline is the model: it named the finding, recommended the guard, and did not expand a frozen run to chase it. One guard clause, one probe, scheduled in succession 2.

**REG-32 · Acceptance test 17's determinism comparison covers only the three original fixtures; the multi-node-session fixture's build determinism is unverified, and the check's own PASS detail says "all three fixtures" while four exist (coverage gap, gad-protocol; found July 15, 2026 by the operator's eye on the gate output and confirmed against the gate's source, which hardcodes ["completed","halted","incomplete"] in the test-17 loop). STATUS: OPEN. Closes when: test 17 compares root_core across two independent builds for ALL valid fixtures discovered from the tree rather than a hardcoded list, and its detail line reports the computed count.** The stale prose and the real gap are the same defect: a recited list where a computed one belongs, standing rule 4 pointed at a checker. Scheduled in succession 2's gate node.

**RUL-12 · REG-28 rested, July 15, 2026, Brandon King, on the advisory assistant's recommendation grounded in the engine's own API. executor_exit retains node as a NULLABLE field, mirroring RUL-10 exactly.** Non-null when the session covered exactly one node (engine-observed; the one-session-per-node policy tier), null when it covered many; null is stated absence per I5. Pairing is by session_id, which the record already carries and which is the only argument the engine's recordExecutorExit accepts (atlas-orchestrator src/v06/session.ts, verified July 15 against the fresh tree: the scalar node in the record was looked up from session state, never observed at the exit moment). Per-node consequences of a multi-node exit, including which node routes to FAILED, derive from the single derived-attribution mechanism RUL-8 defines, classed proxy, never a second mechanism. REJECTED ALTERNATIVES, recorded: dropping node entirely discards an engine-observed fact in the one-session-per-node tier, the exact lesson RUL-10's amendment taught; keeping the scalar blocks the a3 multi-node path outright, since one process dies once and the schema would demand a node name no honest writer can supply, forcing the synthesis RUL-8 forbids. CONSEQUENCE: the triplet becomes philosophically uniform: dispatch names the commissioned set; exit and result each name the session plus a node only when singularity was observed. Discharged by succession 2, which also carries the REG-29 blessing, the REG-31 guard, and the REG-32 gate fix. Succession 2 is the first succession performed under a rule that predates it, which is the genesis disclosure's promise kept once.

**REG-33 · succession-verify.mjs assumes the successor is always the document on disk, an assumption only the LATEST succession satisfies; succession 2's spec bump made succession 1's record permanently unverifiable by it (tooling defect, gad-protocol; found by the executor at sc2-05, run #36, which correctly halted rather than widening its fence, and foreseeable twice over from the advisory assistant's own materials). STATUS: OPEN. Closes when: the verifier is lineage-aware, recomputing only the latest succession's successor digest from disk, verifying every earlier record's signature over its canonical body with digests marked historical-recorded, exactly the shape its own predecessor NOTE already used.** The deadlock is recorded with its authorship: the advisory assistant specified the verifier's original single-record behavior, wrote sc2-06's instruction to extend it for a second record, and still placed the un-extended verifier in sc2-05's done-test one node earlier; and the verifier's own NOTE line, praised the day before, already stated the mechanism (v0.6 recorded, not verified, because its bytes left the tree) without the general rule being drawn. The executor's disposition was the model: it verified what mattered directly (the operator-signed record survived byte-identical, signature verifying), refused the waiver as recording a falsehood (the guard work IS done and probed), refused to burn retries on an unchangeable outcome, and named the sc2-06 deadlock. Run #36 stands crashed at 5 of 7 with nodes 1 through 5's work committed and green; succession by corrected plan (succession-2b), never edit.

**REG-34 · Section 2's Execution result object definition still reads {node, delta_ref, delta_digest, touched_surface, output_status} with no session_id, contradicting Algorithm 1 as amended by succession 1 (spec prose defect; disclosed by the executor at run #36 and deliberately not acted on there, being outside every node's fence). STATUS: OPEN. Closes when: the Section 2 entry matches Algorithm 1's amended shape (required session_id, nullable node), fixed inside succession 2's still-unsealed scope.** Succession 1 amended Algorithm 1 and the schema but missed the parallel prose definition in Section 2; REG-24's closure statement says the spec carries session_id, and one of the spec's own sections does not. Legitimate to fold into succession 2 because no succession-2 delta has been signed: the succession is open, and its section-level statement will name this alongside RUL-12.

**REG-35 · build-delta.mjs --out in a v0.8 tree would emit a record labeled version 0.7 while hashing v0.8's bytes (tooling hazard, gad-protocol; disclosed by the executor at run #36). STATUS: OPEN. Closes when: the builder derives the version label from the document bytes it hashes, or refuses --out when the label it would write does not match the tree, with the refusal probed.** The guard added at sc2-05 blocks the dangerous overwrite; this residual is the label-versus-bytes mismatch on the explicit-path escape hatch, a recited figure (a hardcoded version_label) where a computed one belongs, standing rule 4 pointed at a builder.

**REG-36 · s2b-04's key-material check was unsatisfiable from birth: a substring grep over succession/ trips on build-delta.mjs's dev-key FIELD NAME, a file that predates the run and sits outside the node's fence; and the authoring discipline that would have caught it had already decayed (authoring defect, advisory assistant; found by the executor at run #39, which fixed the one failure that was its own, then stopped rather than burning retries on an unchangeable outcome). STATUS: OPEN. Closes when: succession-2c re-blesses s2b-04's finished work under a check that detects ACTUAL key material (PEM private blocks, hex-encoded secret scalars) in content rather than substrings in pre-existing tooling, and the whole successor plan's checks are proven satisfiable against the real tree before freeze.** Two authorship facts, both the advisory assistant's. First, the check itself: 'no private key material entered the repository' was implemented as a walk grepping every file under succession/ for the lowercased substrings pkcs8 and private_key; build-delta.mjs legitimately contains the field name where it reads the dev key, existed before the run, and was untouched by the node, so the check could never pass and the thing it protects against never happened (verified cold July 15: zero PEM blocks, zero hex secret scalars anywhere under succession/). Second, the regression: succession-1b's authoring ran a full satisfiability matrix, every check proven passable against a simulated end state before freeze, and that discipline was documented in REG-27 as the method; successions 2 and 2b ran only syntax and crash checks, and executing this check once against the tree would have shown the trip before the graph ever froze. The discipline decayed within a day of being written down, which is the finding under the finding. THE EXECUTOR'S DISPOSITION, again the model: it distinguished its own failure from the structural one, fixed only its own (check 2's phrase was capitalised for emphasis and invisible to the exact-match; corrected and re-signed), declined the waiver as recording a falsehood (the delta IS built, the lineage IS sealed, --strict passes), declined to widen its fence into build-delta.mjs because satisfying the check there means breaking the REG-31 guard, and stopped with attempts in hand. THE OPTION SPACE, ruled: the executor's recommended fix (edit the check in the frozen graph and reload) is declined because it is standing rule 7's exact case, a frozen plan edited to make a check pass, and a wrong frozen plan is remedied by succession, precisely as run #36's deadlock was. Succession by corrected plan, work re-blessed, nothing rebuilt.

**REG-37 · At s2b-01 the executor declined the node text's instruction to verify the genesis artifact under the dev key, reading RUL-11's boundary language conservatively against the author, and proved a weaker honest claim instead (executor judgment call, ENDORSED by the operator's advisory review July 15, 2026; disclosed by the executor itself at run #39 with a request for review). STATUS: CLOSED by succession 3: the ruling is spec text (verification under a public key is a read and crosses no signing boundary) and succession-verify adopts dev-key verification of the genesis artifact by choice, ruling cited in the code.** What the executor did: instead of verifying the retained genesis record's signature under the dev authority key as the node text directed, it proved the artifact's body byte-identical to succession 1's, proved it does NOT verify under the operator key, and reported its dev signature as recorded, not verified, with the reason, flagging the deviation in the tool's own comments and in its handoff. Why it is endorsed: the executor read the operator's own artifacts (RUL-11's unamended fixture-key boundary; operator-pubkey.json's statement that the two key boundaries do not overlap) conservatively AGAINST the instruction it was given, and conservative-against-the-author is the exact behavior this system exists to produce; six findings this week were caught by the layer below the author, and this is the first caught by reading the author's rulings more carefully than the author's node text. The likely correct end state is that verification is not signing and the dev-key verification is legal and strictly stronger; that is a ruling for the operator, not a default to slide into.

**REG-38 · The precise key-material check as frozen is narrower than its own stated intent, and underneath it sits a mathematical fact the register should carry: a secret scalar has no detectable shape (check-design finding, disclosed by the executor at the close of run #41 with the stronger check already built and probed; the register entry deliberately left for the operator because writing it from the node's fence would have been the move REG-36 ruled against). STATUS: CLOSED by succession 3: the derive-based definition is normative spec text and tools/key-material-check.mjs is its executable form, probe-proven against a real planted key.** The frozen s2c-01 check skipped .mjs files entirely, so a PEM private block pasted into tooling under succession/ would have passed, and its scalar arm required 80 or more characters, so a raw 32-byte Ed25519 seed at 64 hex characters would have slipped through. The node passed HONESTLY: the executor additionally ran an independent stronger sweep over every succession-touched file and found zero key material, a result the advisory assistant reproduced cold with a derive-based test (zero 64+ hex strings under succession/ parse as PKCS8). THE FACT UNDERNEATH, recorded because it constrains every future check of this kind: every 32-byte string is a valid Ed25519 seed, so a sha256 digest and a private key are mathematically indistinguishable by pattern; the executor's first attempt proved it by flagging all 35 legitimate digests in the corpus. REG-36's closure asked for a check that detects hex-encoded secret scalars in content, and that is only satisfiable by asking whether a value DERIVES rather than what it LOOKS LIKE. The executor's built check does exactly that and its probe catches three planted real-key defects while ignoring digests, public keys, and random scalars.

**REG-39 · A probe judged only on its exit code counts as fired when it never ran at all: a failed spawn exits nonzero, so run #41's first attempt reported 10 of 10 probes fired while 9 of 10 checkers had not executed (probe-epistemics defect, found and fixed by the executor inside its own fence at run #41; the spawn failure that exposed it was Node's post-CVE-2024-27980 refusal to spawn npm.cmd without a shell). STATUS: CLOSED by succession 3: the probe-fired standard (spawned, nonzero, output) is normative spec text, adopted in this repository's tools, and this run's own plan judges its probes by it.** The executor's builder now requires all three conditions and the run's exit record carries figures computed under the corrected standard. The repo's other tools spawn node.exe directly and were confirmed unaffected, so the hazard was unique to the new builder; the DOCTRINE is not unique to anything, because an exit code cannot distinguish a probe that proved the runner can fail from a probe that never found the runner, and every probe judgment in this project's history that read only an exit code inherited that ambiguity. This entry is the standing correction: fired means ran, failed, and said so.

**REG-40 · The a3 plan partitioned fences by where the triplet payloads are USED and never traced where they are DEFINED: the three payload types live in witness.ts, imported by session.ts and gates.ts, so a3-01's shape change was atomic across three fences and its compiles-clean done-test was unsatisfiable as written (authoring defect, advisory assistant; found by the executor at run #41 node 1, which proved the coupling with the compiler, undid its probe edit, left the tree clean, built nothing, and refused to type-cast through it because code claiming one shape while writing another is a false record). STATUS: CLOSED July 16, 2026: the fence-authoring doctrine (fences drawn where types are DEFINED, not used) was adopted into the pre-freeze checklist at a3d, whose import-trace and namespace-guard checks ran before freeze; the status line lagged. Closes when: the successor plan (a3b) lands the shape change and its mechanical propagation in ONE fence, with the semantic re-derivations still owned by their original nodes, and the run passes its first exit.** The authoring failure is the pattern REG-36 named, one layer over: the premise audit I wrote for a3-01 QUOTED the line const payload: DispatchPayload and never asked where that type lived; a one-line grep for its definition, run before authoring, would have shown the import graph and forced the fence. The crash-focused review pass that same day found three other defects in this graph and missed this one, because it audited command strings and probe semantics but not fence-versus-type-graph consistency, which now joins the authoring checklist: a node that changes a shared type owns every file the compiler drags into that change, or the plan is wrong. THE EXECUTOR'S DISPOSITION, the model again and this time with a compiler as witness: premise audit passed five for five including the word-for-word test failure; the coupling was proven by attempting the minimal edit and reading the rejection; the probe edit was undone; the tree verified clean; the type-cast escape was named and refused in the record's own vocabulary. Its recommended remedy (edit the frozen plan's allowed_paths and reload) is DECLINED for the same reason it was declined at run #39 and recorded in REG-36: a frozen plan is never edited to make a check pass, and the sanctioned remedy for a wrong frozen plan is succession. The successor adopts the executor's fence analysis wholesale: a3-01 owns witness.ts, session.ts, gates.ts, and scope.ts for the shape change and its MECHANICAL propagation only, each mechanically-touched site marked with the owning node's id; the R7 set-intersection semantics, the derived-attribution semantics, and their tests and probes remain the substance of a3-03 and a3-02, which re-verify what a3-01 bridged.

**REG-41 · REG-40's fix repaired the fence and left the CHECK spanning the whole compilation unit: a3-01's compiles-clean ran npm run build over every file in the tsconfig, including the later nodes' test surfaces that the plan itself declares red at that moment, so the plan demanded red and green simultaneously; and the same whole-project check sat latent in a3-02 and a3-03, which would have crashed identically after any single-node repair (authoring defect, advisory assistant, the same defect class as REG-40 one level out; found by the executor at run #42, which built a3-01's work correctly, proved it against the live referee including both tiers and a firing probe, committed at 9ee0fce with the referee checkout clean at 873f424, spent no retries on a check marked not self-correctable, and declined to fix out-of-fence files as the shortcut its own instructions named). STATUS: CLOSED July 16, 2026: a3d landed with scoped compile checks throughout; the whole-project compile was first demanded at a3-06 and passed; tsc is clean across the tree, cold-verified. Closes when: the successor plan (a3c) re-blesses a3-01's committed work under a compile check scoped to the node's own surface (no TypeScript error may reference a fence file; errors in later nodes' surfaces are the plan's own declared staging), the same scoping replaces the latent whole-project checks in a3-02 and a3-03, project-wide compile is first demanded at a3-04 where the staging makes it true, and a3-05 gains the a3-04 dependency its spawned-test check silently assumed.** THE LESSON, added to the authoring checklist beside REG-40's: a fence bounds what a node may EDIT; a compile bounds what the toolchain SEES; they are different boundaries, and every done-test that invokes a whole-unit tool (tsc, a full test suite, a repo-wide lint) implicitly asserts the whole unit is green at that node, which in a staged plan is an assertion about OTHER nodes' work. A done-test may only span surfaces its own node owns or its dependencies have sealed. The executor's option B carried the correct scoping analysis and its recommendation to edit the frozen plan in place is DECLINED for the third consecutive time on the same ground (REG-36, REG-40): a frozen plan is never edited to make a check pass; succession is the remedy, and the succession adopts the analysis.

**REG-42 · Successor plans inherited premise audits describing trees their own dependency nodes are declared to have changed: a3c-01's audit described the pre-run-#42 code while the node re-blessed run #42's commit, and a3-03's premise (a) described the pre-bridge scalar gate while its build instructions said the bridge had landed; the same document described the same code two incompatible ways, twice in one day (authoring defect, advisory assistant; both occurrences flagged by the executor, which refused to self-waive a gate marked MANDATORY and refused to pick between contradictory readings, ending each with a one-line ruling request and zero crashed sessions). STATUS: CLOSED July 16, 2026: a3d shipped with rewritten audits; the one instance the rewrite itself missed (a3-03) is REG-44. Closes when: the a3d successor ships with every carried node's premise audit rewritten against the state its dependency nodes are declared to leave, and the rewrite is a mechanical authoring step, not a memory exercise.** The doctrine, in the executor's own words from the first occurrence: a successor or re-blessing node must rewrite an inherited premise audit, or the gate fires against its own prior work. Both rulings were the REG-37 pattern (operator interpretation of stale authored prose, every mechanical gate untouched), not the REG-36 pattern (an edit to make a check pass): in each case the done-tests were genuinely red-then-green against the live referee and the stale text changed nothing about what would be built. The protective intent of the audits was satisfied both times, and in the first occurrence the executor established it BETTER than the stale clauses would have: referee byte-identical, engine matching the required shape, and the three old error messages appearing only as the probe's planted defect, correctly rejected.

**REG-43 · Two fence gaps of the REG-40/REG-41 class in one plan, plus a genuine topology discovery under one of them: a3-02's fence covered where derived attribution would be WRITTEN but not where scope enforcement RUNS (src/store.ts driving src/git.ts, the files its own proving test imports, verified by import trace), and a3-05's flag design tripped a namespace guard in src/env-vars.ts that the fence did not own, where the engine would have read the flag while announcing it does not read it (authoring defects, advisory assistant; both found by the executor pre-build with nothing written, no retries spent, and a false-green path explicitly named and refused: the test could have been pointed at an allowed file and gone green while every foreign commit stayed misattributed in the real engine). STATUS: CLOSED July 16, 2026: both corrected fences held; a3-02 built in them at 3c18a19; a3-05 landed with the env-vars registration and the per-process topology comment; both new pre-freeze checks ran before freeze. Closes when: a3d lands with store.ts and git.ts in the attribution node's fence, env-vars.ts in the connection node's fence, the SEPARATION.md path corrected to the repository root, and both new pre-freeze checks (import-trace of every proving test contained in its fence; namespace-guard trace of what every node's additions trigger) run against the actual tree before freeze.** THE DISCOVERY, recorded because the gate was right for a reason nobody had written: the standard-connection comment's claim that the only client is the executor is FALSE of the product (Waypoint ships AtlasControlClient on a production path, verified by reading Waypoint's source) and TRUE of the run's own process (Waypoint spawns only the executor; the executor's client spawns Atlas). Per-process topology, not product topology, is what the gate protects, and the corrected comment says so. THE GUARD that caught a3-05's design is the engine's own self-honesty machinery working as built: a deliberate registry of every ATLAS_* variable the code reads, a test that fails when the registry falls behind, and a startup warning for unregistered variables, which together make it impossible to read a flag while denying it. An authoring process that did not know the guard existed is the finding; the fence audit now traces what a node's additions TRIGGER, not only what its tests drive.

**REG-44 · The a3d rewrite applied REG-42's rule to a3-04 and missed a3-03, carrying a duplicate node whose substance had landed at 9991d71; the operator's first disposition (waive) was the wrong instrument and the executor refused it on semantics; the node was verified under a logged operator ruling (authoring defect, advisory assistant, ninth of the migration, plus an operator-ruling correction, caught by the executor; zero crashed sessions across the whole arc). STATUS: CLOSED July 16, 2026, with the run complete.** The doctrine the arc produced, recorded because the plan machine has no native instrument for it: a DUPLICATE node (work landed, evidence server-verified in-run) is not waivable, because a waiver records omission and the truth is duplication; the honest dispositions are verification under a logged operator ruling that names the duplication and its in-run evidence, or succession. The executor's refusals were correct twice: notes are context, not authorization (the channel rule), and waive_node would have put the opposite of the truth on the record (the semantic rule). The run subsequently reached COMPLETE with the ruling logged at the node.

**REG-45 · scope.ts carries a stale ownership marker saying a3-02 owns derived attribution that would make multi-node session results flaggable at the witness level; that expectation cannot hold as written, because the witness-level ScopeEngine is stateless-beyond-the-witness by design and commit-boundary attribution needs git access it does not have; the attribution correctly landed in store.ts/git.ts instead (engine prose defect, disclosed unprompted by the run #45 executor; also records a3-02's premise (b) inaccuracy, disclosed by the same executor: store.ts does import scope.ts at ~L49, for unrelated open-flag machinery, so the clause 'never consults scope.ts' was overstated while the clause it supported held). STATUS: CLOSED July 16, 2026, by Wave 6 part 2 (atlas, prose truth pass): the scope.ts marker now records the decision AND its discharge (witness-level ScopeEngine stateless-beyond-the-witness by design; commit-boundary attribution lives in store.ts over git.ts, landed 3c18a19, classed proxy via v06/attribution.ts); seven sibling stale markers corrected the same way (gates.ts finding attribution and verdict-gating seam, store.ts terminal guard and reopen-rebaseline, chain-key.ts separation tier, lifecycle.ts floors, index.ts borrow note), each stating what landed and where; REG-22 gains the recorded truth that its baseline-to-run-start half was DISPROVEN and never built. One one-line code debt banked honestly: the borrowRunLifecycle getter migration. Closes when: the marker is corrected to state where attribution actually lives and why the witness-level engine cannot own it, in a Waypoint-era wave or any later engine pass.**

**REG-46 · Under the live choreography (the executor verifies its own final node, exits, and only then does the supervisor record the observed exit and engine-captured result) the engine as built wrote the terminal plan entry at the last verification, stranding the session's closing triplet entries post-terminal, where the referee's transition table admits only checkpoints and nonconformance notices (specification-conformance defect in the constructor, surfaced by Wave 5's rehearsal analysis and confirmed against the referee's own post-terminal rule). STATUS: CLOSED July 16, 2026, by Wave 6 part 1, under the operator's ruling that the fix belongs in the CONSTRUCTOR'S ORDERING, not the spec: while any dispatched session lacks its executor_exit + execution_result the terminal is WITHHELD, at BOTH terminals (the executor extended the ruling to plan_halted, which strands identically), written deterministically when the last triplet closes (the index.ts nudge). The proof is two-sided and the referee's own: test-v06-terminal-deferral drives the live order and asserts ZERO post-terminal errors via the referee's checkTrace, and its probe forces the pre-fix ordering and requires the referee to NAME the strand and reject (fired, exit 1, cold-verified) — the strand-naming matters because the REG-48 residue is present in both orderings and would prove nothing about this fix.** The alternatives were rejected on the record: widening POST_TERMINAL_ALLOWED weakens what sealed means (a succession to make the record less strict), and changing the choreography so executors never verify their final node breaks every real run.

**REG-47 · The referee computes DEFENSIBLE=false on records anchored with an RFC 3161 token because the gad4-default policy requires an authority-SIGNED root anchor: two different artifact classes making two different claims (a TSA's word about WHEN versus an authority's word about WHO stands behind the root), surfaced by the Movement 2 dress rehearsal reporting the verdict as the referee computed it rather than asserting past it. STATUS: OPEN, awaiting the operator's ruling; the advisory recommendation on the record is BOTH: the export gains an operator signature over the root alongside the token (the signature proves who, the token proves when), and DEFENSIBLE requires the signature while RECORDING the token, so neither claim is diluted into the other. Closes when: the ruling is rested and either the policy or the export path implements it, with the rehearsal's DEFENSIBLE verdict flipping true for the implemented class.** Note the operator-identity constants disclosed in Waypoint's export path (a real config surface is future work, stated in the code) become load-bearing under the signature arm of this ruling.

**REG-48 · The referee's verdict-preconditions rule (a node's typed verdict is legal only AFTER its session's execution_result grants the completed attempt) fails the live choreography's records independently of REG-46: the executor's own mid-session verification writes verdict entries over a surface that has not been captured, which Algorithm 1 forbids by construction — exit, QUIESCE, delta, execution_result, THEN verification, with the spec's own reason that surfaces are computed only after quiescence or they can change after capture (specification-conformance defect in the live choreography, surfaced by Wave 6's deferral test putting a live-order record to the referee's full evaluation for the first time; no live run's witness had ever been evaluated before this week). STATUS: OPEN, residue PINNED two-sidedly in test-v06-terminal-deferral (the deferred record must carry exactly the one verdict-preconditions error at the verdict's index: a new violation fails loudly and so does the residue silently vanishing). RULING RESTED (operator, July 16, 2026): verification is post-quiescence BY THE SPEC'S SEMANTICS; mid-session server verification may exist only as ADVISORY FEEDBACK to the executor, never as record entries; Trial 0 Movement 2's choreography is the MULTI-NODE SESSION with post-session verification (dispatch over the node set, the executor works and exits, quiescence, execution_result, then supervisor-driven verification over the captured delta; a node failing post-session verification is redispatched in a fresh session, which is RUL-2), supported by the stack as it stands. Closes when: a live-choreography record evaluates fully referee-valid, either via the Movement 2 choreography or a later advisory-feedback tier in the engine.** The rehearsal already proved the conforming order end to end; what changes for the real run is the EXECUTOR'S BRIEF, not the engine. PRECISION AMENDMENT (July 16, operator): the ruling's phrase never-as-record-entries was one clause too broad; the spec's constraint is per-node (a verdict never precedes ITS OWN node's execution_result), and verdicts for prior-session nodes are legal from any caller. The overbreadth was the advisory assistant's wording, caught when the run refused to move under it; see REG-54 for the constraint the corrected choreography then met.

**REG-49 · The README wave's brief expanded GAD as "Governed Agentic Determinism" and the executor reproduced it: the expansion is FALSE (the frozen spec's own line 11 and Section 12A title define GAD = Governed AI Development) and was a chimera of the methodology's name with the operator's older "governed determinism" design philosophy, injected by the advisory assistant's brief and propagated through its session summaries (authoring defect, advisory assistant, eleventh of the migration; caught by the OPERATOR reading the committed README against his own intent — notably the one claim the executor did not trace to bytes was the one the brief handed it as context). STATUS: CLOSED July 16, 2026, same day: the expansion corrected in a follow-up commit against the spec's bytes, a repo-wide sweep across all three repositories confirming the single occurrence, and the operator's memory record corrected at the source. The doctrine: A BRIEF'S CONTEXT IS TESTIMONY, NOT BYTES — trace-everything disciplines must extend to the claims the brief itself asserts about the tree, and an authoring layer that exempts its own prose from the trace is the counterfeit path with better manners.**

**REG-50 · The succession-3 exit plan demanded succession-verify --strict pass BEFORE the ceremony sealed it, an invariant modeled against the launch tree that the plan's own first node lawfully falsified (s3-01's v0.9 landing makes strict fail, correctly, until s3-04 seals): unsatisfiable by construction, a deadlock inside the frozen plan (authoring defect, advisory assistant, twelfth of the migration; found by the executor running its baseline BEFORE touching anything). STATUS: CLOSED July 16, 2026, by succession-3b: the corrected invariant asserts the HONEST mid-succession state (strict FAILS naming the unsealed document, pinned against the verifier's real output), and the successor's ceremony premise was rewritten the same way. Doctrine, joining the pre-freeze checklist: an invariant inside a plan must be modeled against EVERY intermediate tree state the plan itself creates, never only the launch tree.**

**REG-51 · The product's two-channel irreversible approval is unwired in v1: the UI writes the out-of-band file and the engine verifies the secret, but ATLAS_IRREVERSIBLE_APPROVAL_SECRET is deferred by explicit design comment and no config surface supplies it, so the first irreversible node ever authored against the live product (succession-3's ceremony) sat at an unpassable gate (product gap, surfaced July 16; also the thirteenth and fourteenth authoring defects: a standing choreography ruling issued over a fires-once channel, and a gate authored against a channel whose product wiring was never verified as a premise). STATUS: OPEN as product work. Interim doctrine, applied in succession-3c: match the gate to the channel the product honors (high_risk, the logged authorization naming the node) and say so in the plan; the human act is preserved. Closes when: a per-project secret surface stores the value encrypted at rest and passes it into ATLAS'S CONTRACT-BUILT ENV ONLY, never the parent environment the executor inherits, with an e2e proof that a wrong token is refused, the right one releases, and the executor's env is secret-free by the REG-38 sweep. The custody rule from the incident stands: the operator always holds a readable copy of any secret a verifier holds opaquely.**

**REG-52 · The succession-3 exit node's no-em-dash check swept the append-only register and the SIGNED delta record body, artifacts whose only path to satisfaction is rewriting history or breaking the operator's signature; the executor refused both and flagged (authoring defect, advisory assistant, fifteenth; and the confession inside it: the register's em-dashes are the advisory assistant's own fold prose, so the rule it enforced was one its author had violated throughout). STATUS: CLOSED July 16, 2026, by succession-3d: the check scoped to the rule's true jurisdiction (the spec, already clean and guarded), with the scope reasoning in the node's own text. The rule's normative scope is now stated: the spec and briefed executor artifacts, never retroactive history, never signed bodies.**

**REG-53 · The Movement 2 record run was blocked twice by identity gaps in layers below the plan: the run plans omitted safety.protocol_mode v0_6 (four succession runs governed, chained, complete, and WITNESS-LESS, discovered only when the export produced a stated absence instead of a record), and the resolved stack was stale twice over (the installed app's bundled engine rejected the protocol field its current sibling accepts; the installed supervisor itself predated the session-record waves, producing one witness whose every verdict lacked its session) (authoring defect sixteen, advisory assistant, plus an operations gap). STATUS: CLOSED July 16, 2026, as to doctrine: the pre-launch identity check is now three-layer and mandatory for any record-producing run: the PLAN carries the protocol mode, the ENGINE is the resolved index the plan was authored against, the SUPERVISOR is the build that drives the records. The packaging follow-up (rebuild the installer with a fresh staged engine) is post-v1.0 work.**

**REG-54 · The referee rejected the first live record (run 15) on verdict-preconditions, seven times, exposing a structural incompatibility: the transition table RESETS a node's completed attempt at every dispatch naming it, and the supervisor commissions every session over the whole remaining plan, so any verdict recorded inside a later session follows a fresh dispatch of its node and is illegal; verification therefore belongs BETWEEN sessions, in nobody's session, exactly where Algorithm 1 places it (choreography defect, jointly authored by the trailing-verification ruling and the whole-plan commissioning design; caught by the referee's own cold evaluation, which is the system's deepest success wearing a failure's clothes). STATUS: OPEN. Closes when: Wave 7 lands the between-sessions verifier in the supervisor (before commissioning, and at completion for a final stranded node), proven by a witness whose every verdict lies strictly between its node's execution_result and that node's next dispatch, with the referee's checkTrace computing zero verdict-preconditions errors and a probe reproducing run 15's exact defect. Wave 7 is thereby PROMOTED from post-v1.0 polish to a Movement 2 requirement, by the referee's ruling, not the operator's preference.**

**REG-55 · Run 15's record also failed R5: worker-authored proxy verdicts credited with no probe bound to their signal artifacts, because the Movement 2 plan's done-tests were bare command checks (authoring defect, advisory assistant, seventeenth). STATUS: CLOSED July 16, 2026, in the m2c plan: every provable check is a proxy pair whose negative probe is bound into the record, which is REG-39 living IN the record rather than around it; the engine's own same-runner rule (F3) rejected the first draft of the fix, which is recorded here because the tools correcting their author is the pattern this register exists to preserve.**

**REG-56 · A completed run was not inert: after run 18's witness sealed (plan_completed written, terminal deferral correct), the product's relaunch affordance accepted the click and the engine accepted a dispatch over the terminal-carrying witness, appending a post-terminal session that the evaluator correctly ruled fatal (R3, SEALING). The operator's ruling stands as the doctrine: a completed run must be inert; any path that can append to a sealed witness is a sealing violation waiting for an operator to find it. Discovery mechanism recorded honestly: the advisory assistant recommended the click (eighteenth authoring defect); the advice is retracted, and the interim rule is procedural (no sessions after the final verification lines of a protocol run). STATUS: OPEN as product work (Wave 8). Closes when: the engine refuses recordDispatch over a witness carrying a terminal, with a probe; the supervisor's relaunch path checks the witness for a terminal before commissioning and reports the sealed state instead of offering continuation; and the run classifier gains the awaiting-verification/completed vocabulary so finished protocol runs say finished.**

**REG-57 · Trial 0 Movement 2 CLOSED: run 20's record evaluated cold on a second machine as VALID_RECORD=true, OUTCOME=COMPLETED, nine of nine conditions, evaluator exit 0; anchored by a live RFC 3161 token whose message imprint equals root_core; one flipped byte anywhere produces INVALID at exit 1; the derive-based sweep of the exported bundle found zero key material. The road there is the evidence: four witness-less governed runs (REG-53), a record rejected seven times over on verdict-preconditions (REG-54), and a record invalidated by a post-terminal dispatch and two unprobed checks (REG-55, REG-56), each rejection forcing a permanent correction before the referee said yes. STATUS: CLOSED July 16, 2026. The full grounding lives in docs/trial-0/trial-0-matrix.md and its ratification manifest; conformance remains per-record, and every result remains a Proposition or Claim pending Phase 5 independent review.**

**REG-58 · The stamped v1.0's Algorithm 1 carried a multi-node ambiguity, found by external review of the stamped v1.0: the dispatch commissions a session over a node set while supervision and the fence check were written against a singular n, leaving per-node attribution, advancement, and verification candidacy ambiguous in the pseudocode even as the between-sessions verifier demonstrated the intent (specification defect, external review). STATUS: CLOSED by succession 5, the session-scoped rewrite in this amendment.** The rewrite makes the session the supervised object throughout: the dispatch commissions a session over the node set; SUPERVISE_EXECUTOR takes the session; the executor_exit and execution_result attach to the session (node non-null exactly when the session covers one node, null as stated absence otherwise, RUL-10 as amended); the session delta and touched surface are captured at session close; per-node attribution of the surface is derived at proxy against each candidate node's fence, never observed; the verification candidates are derived after the session closes as the submitted nodes whose execution_result is recorded, their verdicts recorded between sessions, before any dispatch that names them (the completedAttempt reset rule); and a failed session routes every in-flight node of that session to retry or trip and no node of that session to verification. Trial 0's run 20 record and the supervisor's between-sessions verifier are the demonstrating implementations. No conformance requirement was weakened: every existing R-condition and predicate stands as strong or stronger.

**REG-59 · In v0.6 mode the engine's dependency rule fail-closes on a done-but-gated dependency whose witness lacks a typed principal-signed gate approval (RUL-4's consequence rule): the supervisor's gate plane is unwired, so the first gated node ever run under protocol mode produced a run whose final node the engine correctly refused to unblock (product gap, surfaced by the first gated protocol-mode run). STATUS: OPEN as product work (Wave 9: the typed gate plane, gate_request and approval appended by the supervisor's principal pen and ordered before the gated node's dispatch, alongside the REG-51 approval-secret surface).** The classic inbox approval was real and chain-logged; the run was superseded gateless and the work re-blessed. The engine's refusal was correct: a witness that carries no typed gate approval for a gated dependency does not prove the gate released, and fail-closed is the designed behavior, not the defect. The defect is the unwired plane above it. Closes when: a gated ceremony produces a live record the evaluator accepts with R7 evaluated.

**REG-60 · A mixed-outcome verification attempt records its PASS verdicts without their probe artifacts: run 30 (the succession-5 ceremony run) carried the first live failed check, and its first verification attempt wrote three pass verdicts and one honest fail with NO probe entries preceding them, while the post-retry attempt and every later verification bound probes correctly; the evaluator rejected the record on R5, three counts, all attempt-1 pass verdicts (engine defect in the v0.6 verification path, exercised for the first time by the first live remediation loop; the loop itself worked: fail, debug, align, pass, all in the witness). The sealed succession-5 work is unaffected and cold-verified; the valid-record crown remains with run 20. STATUS: OPEN as engine work. Closes when: the verification path binds probe artifacts for passing verdicts identically on mixed-outcome and clean attempts, proven by a probe replaying run 30's attempt-1 shape and demanding the bindings, and a subsequent live record carrying a failed-then-passed check evaluates VALID.**

**REG-61 · Algorithm 1 as amended at v1.1 defines 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 (external review of the sealed v1.1, July 16; the amendment's substance is otherwise confirmed: the session-scoped rewrite resolved the v1.0 ambiguity). STATUS: CLOSED by succession 6, the derive-based C_s rewrite in the v1.2 amendment. The resolution on the record, per the review and this project's own derive-based style: C_s is DERIVED by the engine from execution_result-bound evidence of the closed session, with the derivation procedure defined by Profile One and inspected under constructor conformance; no new mandatory witness entry is minted, so no sealed record is retroactively orphaned. Succession 6 additionally carries, from the same review: explicit succession numbers in the version history (v1.0 is succession 4, v1.1 is succession 5, each with its signed record named); the conformance sentence narrowed to BUNDLE conformance per-record with constructor and operational conformance requiring their own inspection and audit; the session object constructed explicitly before dispatch; succession termination made unambiguous; and completed defined to imply exit code zero.**

**REG-62 · A gated node with DEPENDENTS cannot yet yield a valid record under whole-remaining-plan commissioning: the first session's dispatch names the dependents before any approval can exist, and the referee's R7 rejects the dependents' work as preceding the gate's ratification (proven by Wave 9's probe; the wave's valid record class is the FINAL gated node). Whether commissioned sets should exclude gate-blocked dependents is a RUL-8 semantics question, flagged by the wave rather than decided silently. STATUS: OPEN as a register ruling plus product work. Interim doctrine, applied in succession 6: plans place gated nodes LAST, with no dependents behind the gate, folding any trailing verification into the gated node's own checks. Closes when: the ruling lands and commissioning excludes gate-blocked dependents on every path, proven by a gated-node-with-dependents run whose record the evaluator accepts.**

**REG-63 · Run 33 (the succession-6 full-gate ceremony run) evaluated INVALID on two new mechanisms, both demonstrated by the cold evaluation itself: (a) EXPORT GAP: verification-inputs.json predates the gate plane and ships only the engine public key, so the typed approval's principal signature is unverifiable by any cold verifier; the gated record class cannot be independently judged from its own bundle (R1 and R7 failed for the second machine exactly as they would for a stranger); (b) MID-SESSION VERDICTS: the remediation path recorded attempt-2's verdicts inside the still-open session (trace entries 23 through 27 precede their session's execution_result at 29), violating verdict-preconditions five times; run 30's remediation cycle was clean, so some caller in the fail-then-fix path can reach the verdict pen mid-session. The sealed succession-6 work is unaffected and cold-verified; the typed gate entries exist in the witness with findings references. STATUS: OPEN as Wave 10: the envelope export includes the gate principal's public key for gated records (public material, the engine-key rationale); the engine's verdict pen refuses any verdict for a node whose session is open (the REG-56 fail-closed-at-the-pen pattern applied to verdicts), with a probe replaying run 33's entries 17 through 29; closes with a gated live record the evaluator accepts cold from its own bundle.**

**REG-64 · External review of the SEALED v1.2 found four items, catalogued as succession-7 payload: (i) TRANSITION COMPLETENESS: nodes excluded from C_s have no algorithmic route; the constructor must derive U_s as N_s minus C_s and route every member to governed failure resolution with reason insufficient_bound_evidence, so the fail-closed promise is performed, never only narrated; (ii) CANDIDACY PROCEDURE: Profile One never defines what evidence suffices for C_s membership; the resolution is the review's Option B: Profile One states the minimum requirements and each constructor MUST publish and hash-identify its concrete derivation procedure, assessed under constructor conformance; (iii) the succession-6 clarification SUCCEED then terminate CONSTRUCT contradicts the sealing lifecycle that must still run; the fix is labeled control flow (break RUN_LOOP into a SEALING section), and the register records fairly that the terminate wording originated in the prior review's own suggestion and was adopted by the advisory assistant unexamined; (iv) RELEASE-STATE CONTRADICTION: the sealed v1.2 self-describes as a draft in its header and footer while its history claims the signed succession-6 record, because the advisory assistant's amendment instructions have stamped every version as N draft before sealing (twenty-first authoring defect); succession 7 removes the label and retires the habit: the unsealed lineage already communicates mid-succession status, and a sealed document never calls itself a draft. Plus one binding clarification: engine-log events may inform candidacy only where included in or cryptographically bound by the session's execution_result or its listed output artifacts. STATUS: CLOSED by succession 7, which performed all four items and the binding clarification: the U_s branch routing every excluded node to governed failure resolution with reason insufficient_bound_evidence; candidacy made constructor-published under Profile One minimums (Option B); succession exits made labeled control flow (break RUN_LOOP into a SEALING section that always runs); the draft label removed from header and end label and the stamping habit retired; engine-log binding pinned to the execution_result or its listed output artifacts.**

---

## Specification succession record

RUL-9 requires that the record of a specification succession live in gad-protocol as a signed sidecar beside the specification, and that this register CITE it. The register remains the channel through which the specification learns that it must change; the succession is how it changes. The citations below are citations: the sidecar is the record, and nothing here restates it. Where this register and a sidecar could be read as disagreeing, read the sidecar; it is signed and this list is not.

**Succession 1 · v0.6 to v0.7 · performed July 15, 2026 under the ceremony spec Section 15 introduces (RUL-9), authority Brandon King.**
- Record: `succession/delta/succession-1.json` (signed sidecar; `SIGN_authority(body)`, the signature over `canon(body)` and never a member of it).
- Object: `docs/gad-formal-spec.md`, identified by byte digest, never by version label alone.
- Predecessor spec digest: `446793d47bd2da4cd4b591a17dd19a1b7ec4d30a7fb2c55de4c617e533ff37d0` (v0.6, as of commit `15e473d`; recorded with provenance, and NOT recomputable from the current tree, because v0.6's bytes left it when the successor was committed).
- Successor spec digest: `4572c92081a688f673552099a3b254e1187d65745f70f34157c1893e4328645f` (v0.7; recomputed from the bytes on disk by `tools/succession-verify.mjs`).
- Invalidated artifacts: named BY CLASS in the sidecar, citing the digest of a manifest COMPUTED from the trees by `tools/succession-manifest.mjs` (`succession/manifest/invalidation-manifest.json`). No hand-typed list; a recited figure is not a computed one (standing rule 4).
- Discharges: RUL-8; RUL-9; RUL-10 as amended; REG-19 (specification half only, the implementation half stays OPEN); REG-21; REG-23; REG-24; REG-25.
- CONSEQUENCES: the sidecar carries a consequences section distinct from its invalidated-artifact list, recording the two severed structural couplings (REG-24, the GAD-1 triplet's join; REG-25, OUTCOME's dependence on observed per-node completion) and the decision each was re-derived by. A broken join is not a stale byte (RUL-9 gap 2).
- Genesis: succession 1 IS genesis, disclosed and not solved. It is the first act under a rule it also creates; v0.6 did not authorize its own amendment and no artifact claims it did. Every succession after it is governed by a rule that predates it.
- Verified by: `node tools/succession-verify.mjs` (signature over the canonical body, digests against disk, mandatory items present); its `--probe` rejects a tampered delta and an in-body signature.
- Signing-key boundary, recorded because the sidecar disclosed it and this register is where such things surface. AS PERFORMED, succession 1's record was signed with the committed dev authority key from `conformance/keys/`, whose own warning field says those keys "must NEVER sign anything outside `conformance/`", so the signature attested to the CEREMONY and to nothing about identity. RESOLVED July 15, 2026 by RUL-11, performed under the s2-prep run: the record at `succession/delta/succession-1.json` is RE-SIGNED under a real Ed25519 operator authority key, whose public half is committed at `succession/keys/operator-pubkey.json` naming Brandon King as the RUL-9 authority and whose private half was written outside this repository at generation time and has never entered it. The fixture key file's boundary was NOT widened: it stands verbatim and unamended, the fixture keys verify fixtures and nothing else, and `tools/succession-verify.mjs` no longer reads `conformance/keys` at all. The DELTA BODY was not touched — its canonical digest is identical before and after, only the signature member was replaced — and the dev-signed record is retained as the genesis artifact it honestly was at `succession/delta/succession-1-genesis-devsigned.json`, because succession 1 is genesis and its record should show what genesis actually looked like rather than a cleaned-up version. Two consequences are recorded rather than left to be discovered. FIRST: because the body is byte-untouched, its `signature_scope` still describes the dev-key signing and still calls the conflict the operator's to resolve; that text is true of the retained genesis artifact and STALE for the re-signed record, and it is the price RUL-11 clause 3 knowingly paid, since amending the prose would have moved the digests and required a succession to fix a signature. The verifier resolves its key from the committed key file and never from the record's own prose; a record that named its own verification key would be choosing its own examiner. SECOND: the two records now verify under exactly one key each and neither verifies under the other's, which is what makes the boundary real rather than declared. No figure is recited here: `node tools/succession-verify.mjs` recomputes them from disk, and its `--probe` still rejects a tampered delta and an in-body signature. This is REG-14's first concrete forcing function; REG-14 (key custody) remains OPEN, and its interim rule — a compromised key is handled by succession, not in-place revocation — now has its first real key to apply to.

**Succession 2 · v0.7 to v0.8 · performed July 15, 2026 under the ceremony spec Section 15 introduces (RUL-9), authority Brandon King.**
- Record: `succession/delta/succession-2.json` (signed sidecar; `SIGN_authority(body)`, the signature over `canon(body)` and never a member of it), signed under the operator authority key RUL-11 clause 2 created, whose private half remains outside this repository.
- Object: `docs/gad-formal-spec.md`, identified by byte digest, never by version label alone.
- Predecessor spec digest: `4572c92081a688f673552099a3b254e1187d65745f70f34157c1893e4328645f` (v0.7, as of commit `742e9da`; recorded with provenance, and NOT recomputable from the current tree, because v0.7's bytes left it when the successor was committed). It is not transcribed in the sidecar: it is read from succession 1's record, which is what makes the chain continuous by derivation rather than by assertion, and the commit's blob is hashed and required to equal it before the record is written.
- Successor spec digest: `07ba93975cfe6947ddc8b507ea4a2273e05039186567fb9333d42d97912c3f50` (v0.8; recomputed from the bytes on disk by `tools/succession-verify.mjs`, which recomputes it because succession 2 is the LATEST record and for no other reason).
- Invalidated artifacts: named BY CLASS in the sidecar, citing the digest of a manifest COMPUTED from the tree by `succession/manifest/build-manifest-2.mjs` (`succession/manifest/invalidation-manifest.json`). Four classes, five members: the witness schema, the transition table, the evaluator's transitions, and the multi-node-session fixture. The class list is not guessed: succession 1's manifest recorded 79 members, each was compared against the tree, and exactly three had moved. The other 76 are NOT named, because naming an artifact this succession did not invalidate would overstate its reach. A separate builder exists because `tools/succession-manifest.mjs` is specific to succession 1 down to its succession number and its 0.6/0.7 pair; a builder that quietly retargeted itself at each succession would make every earlier manifest unreproducible.
- Discharges, split because an amendment discharges what its TEXT rules and a run discharges what its TOOLING fixes: BY THE AMENDMENT, REG-28 (with RUL-12, the ruling that rests it), REG-29 (normalization half ONLY; the generator half stays OPEN and is not claimed), and REG-34. BY THE succession-2b RUN, not by the amendment's text, REG-31, REG-32, REG-33, and REG-35. Flattening the two into one list would have this record claim the specification repaired a builder it never touched.
- CONSEQUENCES: the sidecar carries a consequences section distinct from its invalidated-artifact list, recording three severed structural couplings and the decision each is re-derived by: REG-28 (one exiting process implied one exit per covered node; re-derived by RUL-12's nullable, engine-observed node with per-node consequences derived at proxy), REG-29 (the historical corpus's evaluability depended on one tool's private normalization; re-derived by the blessing moving into the normative text where it is judged), and REG-33 (the identity of "a record's successor digest" with "the document on disk", which holds for the latest record and no other; re-derived by the lineage rule). A broken join is not a stale byte (RUL-9 gap 2).
- Genesis: succession 2 is NOT genesis and claims no genesis exception. It is the first specification succession performed under a rule that PREDATES it, which is succession 1's genesis disclosure making good on what it promised. Succession 1's disclosure is neither softened nor restated: it remains true of succession 1, and succession 2 being ordinary is exactly what it predicted.
- Verified by: `node tools/succession-verify.mjs --strict` (both records' signatures over their canonical bodies under the operator key; chain continuity, each predecessor digest equal to the prior successor digest; the LATEST record's successor digest recomputed from disk; earlier records' digests reported RECORDED, NOT VERIFIED). Default mode reports a document ahead of the recorded lineage as a warning; `--strict` demands a sealed lineage and is what an exit gate runs. The `--probe` still rejects a tampered delta and an in-body signature.
- The lineage rule, recorded because this succession is what forced it and because it changes how an earlier citation above must be read. Succession 1's citation says its successor digest is "recomputed from the bytes on disk", which was true when it was written and is now HISTORY: the moment v0.8 was committed, v0.7's bytes left the tree and that figure became permanently unrecomputable. This register is append-only, so that line is NOT edited; it is read as the true statement it was at its succession, and this entry is where the change is recorded. The general rule REG-33 forced: only the LATEST succession's successor digest is ever recomputable from disk, every earlier one is held by the signature over its canonical body instead, and a verifier that assumes otherwise deadlocks the moment a second succession exists, which is exactly what crashed run #36 at 5 of 7. The same rule governs the cited manifest digests, for the same reason and by the same mechanism.
- Crash and correction, recorded because the record should show what actually happened. Run #36 crashed at 5 of 7 with nodes 1 through 5 committed and green, deadlocked by REG-33: the spec bump those nodes made had rendered succession 1's record unverifiable by the verifier its own later node depended on. The executor halted rather than widening its fence, refused a waiver that would have recorded a falsehood, and named the deadlock. The correction is succession by corrected plan (succession-2b), never editing the crashed one. Nothing was rebuilt and nothing was backfilled: the crashed run's committed work was RE-BLESSED by re-running every one of its nodes' done-tests against the current tree, server-verified, so this record rests on evidence rather than on a crashed run's claims.

---

## Trial 0 charter

Trial 0 audits the reference implementation (Atlas Orchestrator + Waypoint) and the two published operational records (Field Records No. 1 and No. 2) against spec v0.6. It does not ask "does Atlas pass." It asks:

> **What exact claims can the existing records satisfy under v0.6, which claims can they not satisfy, and is each failure caused by a nonconforming implementation, evidence that was never captured, or an underspecified rule?**

Expected gap areas, named in advance so the register cannot be accused of surprise: executor-outcome entries (the historical records predate executor_exit and execution_result as typed events); engine-computed surfaces and deltas; engine-signed verdicts and checkpoints; two-axis verdict objects; typed evidence-derived claims; canonical operator record; core/envelope construction; public-mode chains (the current implementation's chain is keyed); pre-dispatch commitments; registered principal credentials.

The gap register publishes either way, and every gap lands in a category above. A high failure percentage is an acceptable, publishable, and honest result: the specification governing its own creator is the point, and per the standing rule, the measure's integrity outranks the measure's stability.

## Sequence

1. Freeze v0.6 as the Trial 0 specification candidate. **(Done, July 12, 2026.)** First Trial 0 input received July 13: the Codebase Gap Audit, R1 through R9 matrix, P0/P1/P2 closure register, 18 acceptance tests. Execution plan: the Conformance Migration Plan.
2. Author the core and envelope schemas and the transition table. **(Done July 13, 2026: Phase 1 governed run, 15/15 nodes, zero halts, zero retries.)**
3. Implement the minimal open reference evaluator. **(Done July 13, 2026: gad-evaluate passes its phase gate, whose check count is whatever `npm run gate:phase1` computes and prints; independently re-verified cold on a second machine and OS, emitting a signed Q with DEFENSIBLE true on fixtures.)** The prior text here recited a 17-check figure. Per the count ruling recorded in REG-23, the referent is what the gate computes and a reader who needs the number runs the gate; a figure recited in a register is a figure nothing surfaces when it goes stale.
4. Run the evaluator against the two historical records; publish the gap register.
5. Author adversarial invalid bundles per R-condition; confirm the evaluator rejects each.
6. Revise the specification only in response to register entries, by succession, deltas stated.

**REG-65 · The v1.3 review's machinery cross-checks, performed against the repositories and settled two-and-one: (1) non-returning failure resolution is ENFORCED at the record layer (the evaluator's sealing rule: after a terminal only checkpoints and nonconformance notices may follow; later candidate processing emits illegal entries and the record evaluates INVALID), with an optional future prose helper in the constructor pseudocode; (2) the failed transition HAS a visible record basis (the retry entry's diagnosis-shaped input payload witnesses the reason at the transition's moment), with one refinement available: U_s-routed retries carry the literal reason insufficient_bound_evidence; (3) CONFIRMED GAP: no candidacy_derivation binding exists anywhere in the schemas or evaluator, so a constructor's published, hash-identified derivation procedure is never bound to the runs it governed and the record cannot prove which procedure produced its candidate set. STATUS: OPEN as machinery work: the envelope core gains a constructor manifest carrying candidacy_derivation (id, version, source or binary hash), written at export, preserved (never validated) by the evaluator, assessed under constructor conformance; the item-2 refinement rides the same wave; closes when a live record carries the binding and evaluates VALID with the manifest present. The scope note is separately VERIFIED: the sealed spec's digest 9c31d03f matches the succession-7 record's successor field byte for byte, three ways (repo, review upload, reviewer's computation).**

---

## Ceremony findings — the GAD manifesto run (run 38, August 25, 2026)

Six entries opened by the governed run that sealed the GAD manifesto. Four are defects; two are stated as OPEN QUESTIONS rather than defects, because the evaluator did not gate on either and it is not settled whether it was meant to. The record they were observed in is published in full, with every file's digest, at `https://atlasnorthinstitute.com/gad/manifesto/record/`, so each entry is checkable against bytes rather than against this description of them. Where an entry refers to the evaluation running on a second machine, that is an OPERATOR STATEMENT: nothing in the published bytes attests to which machine produced the judgment, and the judgment's own evaluator identity reads as a development credential.

**REG-66 · Silent legacy fallback when `protocol_mode` is absent (implementation nonconforming, Atlas engine). STATUS: OPEN. Closes when: a run launched without `protocol_mode` fails closed — refusing to start, or starting in a mode it names in its own record — and a governed node verifies that a mode-less launch cannot silently produce a non-GAD record.** Discovered by the manifesto ceremony. Run 37, an earlier attempt at this same ceremony on identical inputs, was launched without `protocol_mode`; the engine fell back to legacy behavior and did not say so. The run completed honestly by its own lights and produced no witness and nothing to export: a non-GAD record where a GAD record was intended, with nothing in the run's own output announcing the difference. The operator learned it at export time, not at launch. This is Principle 5 read against the engine itself — a required mode that cannot be established should stop the work, not quietly select the ungoverned path. What makes it worth an entry rather than a note is the asymmetry of when the cost lands: the fallback is free at launch and expensive at the end, after the work is done, and the affected record cannot be repaired by re-exporting it. Run 37 is not hidden; its state and log are archived inside run 38's evidence zip under `record/archive/`, and that archive is what makes this entry checkable. Category: implementation nonconforming.

**REG-67 · cwd-dependent `spec_hash` resolves to null silently (implementation nonconforming, Atlas engine; a fail-closed defect as the aggravating half). STATUS: OPEN. Closes when: `hashSpecFile` resolves against the project directory rather than the process working directory, an unreadable spec path FAILS the manifest build instead of yielding null, and a governed node proves both against a run deliberately started from a foreign working directory.** Observed in run 38. `buildManifest` in `atlas-orchestrator/src/provenance.ts` receives `projectDir` but calls `hashSpecFile(graph.spec_path)`, which resolves against the engine process's current working directory instead. When that is not the project directory the hash silently becomes `null` rather than failing, and the manifest records `spec_hash: null`. Run 38's genesis therefore binds the plan but not the governed document. It is non-deterministic in practice: the preceding run (37) on identical inputs recorded the hash correctly, so the defect is a function of where the process was started, which is precisely the kind of dependence a record must never have. WHAT IT COSTS AND WHAT IT DOES NOT, stated because the manifesto record rests on the distinction: the document's digest is still named in the frozen plan, the plan's hash is in the manifest, and a frozen check asserted that digest against the staged copy with its verdict in the witness — that chain holds. What is ABSENT is the identity-level binding: the chain root does not commit to the document's bytes. Per the never-backfill rule the affected record is not reissued and not recomputed; it says what it said. The null-where-an-error-belongs half is the more general finding: a hash function that answers "nothing" when it means "I could not look" converts a missing input into a recorded fact.

**REG-68 · Anchor-kind vocabulary seam: the policy and the exporter name the same anchor differently (specification underspecified → registered vocabulary). STATUS: OPEN. Closes when: the anchor-kind vocabulary is settled in one place, with the exporter's emitted kinds and a policy's `required_anchors` drawing from the same registered names, and a live record carrying an RFC 3161 token over `root_core` evaluates DEFENSIBLE true under a policy that requires a post-run root anchor.** Surfaced by run 38, where it is the entire reason DEFENSIBLE is false. The policy `gad4-default` requires an anchor of kind `post_run_root_anchor` over `root_core`; the exporter emits the kinds `rfc3161_anchor_note` and `post_run_root_rfc3161_token`. No name matches, the required-anchor predicate finds nothing, and DEFENSIBLE computes false. THE ANCHOR IS NOT MISSING: the RFC 3161 token from freetsa.org (serial `0x07435033`, timestamped Aug 25 2026, 22:55:48 GMT) is present in the envelope, and its message imprint equals `root_core` — `253d9e8c62154f5a3edfd409c1e7480fefd9ca978af86e1efd477c7b3e2fd629` — exactly, which `openssl ts -reply` recomputes from the published bytes without reference to anything this register says. The reference record (run 36, the succession-7 ceremony) fails the identical condition identically, which is what makes this a pre-existing seam between two vocabularies rather than a property of either run. Recorded here rather than resolved by loosening the policy: a policy edited to accept whatever the exporter happened to emit is a policy that cannot fail, and the false is published as plainly as the trues on the record's own page. Category: specification underspecified — two components name the same object differently and neither is wrong on its own terms.

**REG-69 · Waypoint's handoff panel does not surface envelope status (implementation nonconforming, Waypoint). STATUS: OPEN. Closes when: the handoff panel reports whether an export produced an envelope and what that envelope's anchor and evaluation state are, and a check verifies the panel's report against the exported bundle rather than against the run's state.** Observed during run 38. Waypoint supervised the run and presented its handoff panel at completion; the panel reported node and gate state and reported nothing about the GAD envelope — whether one was produced, whether it was anchored, whether it had been evaluated. An operator reading only the panel has no signal separating a run that exported a complete envelope from one that exported nothing, which is REG-66's confusion arriving from the opposite direction. The information exists at that moment; it is simply not surfaced. Two of this ceremony's four defects are therefore the same shape, and the shape is worth naming on its own: the operator learns the record's real status later than the system knew it. Category: implementation nonconforming — a supervision surface that omits the artifact the run exists to produce.

**REG-70 · Policy credential authority and the judgment's evaluator credential do not correspond; R1 through R9 did not gate on it. OPEN QUESTION, NOT A DEFECT. STATUS: OPEN as a question. Closes when: the specification states whether the R-condition predicate set is meant to gate on evaluator credential authority, and either the predicates gate on it or this register records why they do not.** Observed in run 38's signed judgment. The policy `gad4-default` lists `accepted_credential_authorities: ["authority:atlas-north-registrar"]`. The judgment's `evaluator_credential` is `cred:test-fixture:evaluator`, with `evaluator_identity` "gad-evaluate dev evaluator". Those do not correspond, and R1 through R9 all pass regardless. THE QUESTION, stated neutrally because the answer is genuinely not obvious: is the R-condition set meant to gate on credential authority at all, or is `accepted_credential_authorities` consumed only by the DEFENSIBLE computation and its independence rule, leaving CONTRACT_SATISFIED indifferent to who evaluated? Both readings survive the current text, which is what underspecified means. NOT CLAIMED HERE: that the judgment is invalid, that the predicates are wrong, or that run 38's CONTRACT_SATISFIED is unsound. WHAT IS RECORDED, because the published record states it plainly too: this evaluation is NOT independent in the sense the policy defines. The policy evaluates independence over the NAMED PARTIES in the judgment and the record's canonical operator, never over bytes, and a development credential does not satisfy it. Category: specification underspecified.

**REG-71 · Replay layer names and provenance layer names may or may not share a namespace. OPEN QUESTION, NOT A DEFECT. STATUS: OPEN as a question. Closes when: the specification states whether `replay_layers_exercised` and a policy's `accepted_provenance_layers` are drawn from one vocabulary, and the schemas or the predicate registry record the answer.** Observed in run 38 alongside REG-70 and recorded the same way. The policy `gad4-default` lists four `accepted_provenance_layers`: `signed_entries_protected_keys`, `pre_dispatch_commitment`, `external_timestamp`, `independently_replayable`. The judgment's `replay_layers_exercised` holds exactly one entry, `authenticated_engine_observation`, which is not among the four. R1 through R9 all pass. THE QUESTION: are these two lists drawn from one namespace — in which case a judgment exercising a layer the policy does not accept is a condition something ought to evaluate — or are they two distinct vocabularies that happen to share the word "layer", in which case the non-correspondence is not a finding at all and the naming should stop implying that it is? A reader cannot tell from the current text, and neither could the evaluator, which did not gate on it. NOT CLAIMED HERE: that the evaluator failed to enforce something it was required to enforce. If the answer is that the vocabularies are distinct, the closure is a naming change and a note, not a predicate. Category: specification underspecified, with a naming hazard as the secondary half.