dotfiles/claude/governance/record-keeping-cluster-JURIST-RULING-2026-08-27.md

---

title: Design-gate ruling — the record-keeping cluster date: 2026-08-27 type: JURIST RULING on record-keeping-cluster-JURIST-PACKAGE-2026-08-27.md verdict: NOT PASSED AS FILED — the block is real and the sitting should happen; three gate-blocking conditions. relay: relayed verbatim by the steward. Filed before any act it authorizes.

Design-gate ruling — the record-keeping cluster (2026-08-27)

⚠ Filed verbatim and BEFORE any act taken under it, per PENDING-108 (c) — the ordering that item proposes and that the executor had not yet adopted. PENDING-108's own pre-registered clock starts on this package, as the ruling notes.

⚠ Nothing below is the executor's wording. Corrections and dispositions taken under this ruling are recorded in the package's Addendum, not here.

---

What I did first

I read the package in full, then read the substrate rather than trusting the package's account of it. Verbatim via governance_item: REVIEWED-122, PENDING-110, -108, -139, -143, -145, -146, -161. Plus governance_state() at 19:13 today. I did not use this app's memory as a source. I could not run the Part I script, and I have no filesystem read, so every claim about wake-digest.py, governance-drift-check.py, the skill file, and the absence of the answer key remains executor testimony.

Store discipline, since it matters here: where I say 'verified', I mean I read it through the governance tools this session. Where I say 'observed', I mean I saw it in governance_state()'s own output. Where I cite my preferences document, that is a third store, dated 2026-07-28, which the executor cannot read.

Gate verdict: NOT PASSED AS FILED. The block is real and the sitting should happen. Three findings are gate-blocking, and one of them dissolves the package's central argument for its own inaction. Everything else below is correction, not obstruction.

---

The three gate-blocking findings

1. The frontmatter premise is false, and an open [ESCALATE] item filed two days ago says so

audience: the jurist, who has NO repository access — this document is self-contained.

PENDING-161 (2026-08-25, [ESCALATE], open) exists for exactly this claim. Verbatim: 'PENDING-159 and REVIEWED-129 both assert the jurist has no substrate access. It has bounded read access via governance-mcp.py … The conclusions survive; the premise does not.' It calls the pattern 'an unverified negative state-claim, asserted confidently, in the document that gets quoted', and notes it was written 'by the party that spent the day building a mechanism against that class'.

This package is the third placement of that premise, in a document written for quotation, two days after the item. It is not cosmetic. The premise generates the package's whole architecture: a Grounding section that relays eleven quotations I could have read myself, and a design in which executor testimony is the only channel. Your own doctrine on this is unambiguous — 'a second agent asked to go and look would return testimony about the substrate; a tool returns the substrate'. The package chose the relay form on a stated ground that is false.

I also observed the corollary directly: governance_state() lists PENDING-82 as OPEN [PROPOSAL] while PENDING-161 records that PENDING-82's own Awaiting line reads 'INSTALLED AND IN USE. CLOSED 2026-08-08'. Nineteen days now.

Condition: the frontmatter is corrected before the sitting. The Grounding section can stay — it is useful — but it is a convenience, not a necessity, and it should say so.

2. The cluster's membership was set by relay, not by the root the package names

The package says the order was relayed (Q5: 'the relayed order is 110 → 145 → 146 → 108 → 144 → 139'). It then argues a root, admits one member does not fit it (108, honestly), and never runs the root back across the open register to ask who else does. Doing that finds PENDING-143, open, filed 2026-08-17, sitting in the register between 144 and 145.

Verbatim from 143: PENDING-121 is 'invisible in governance_state() since that ruling was placed, because the suppression rule asks only whether a REVIEWED header names the id — never what the ruling decided.' That is PENDING-145's mechanism, stated in the same words, on a different item. PENDING-146 cites 143 by name — 'the same disclosed-carrier pattern as PENDING-143' — and the package quotes neither line.

143 also names two more: 'PENDING-124 (REVIEWED-106) and PENDING-128 (REVIEWED-111) are the other two design-gate items in the same class … UNDETERMINED pending a steward read.' Those are steward reads that have been owed since 2026-08-17 and appear nowhere in the package.

This is the weld test applied to the package's own sharpest section. Part IV's root, run back across the register, changes the membership in both directions. 143 does not need ruling — it is a [FIX] carrier that retires when 142 lands — but it must be in the picture, because it is the evidence that 145's defect has already forced a workaround into the register rather than being a prospective risk.

3. Part V's blocking argument does not survive at the granularity 146 itself specifies

Part V says the unit question must be settled before the answer key can be written; Part VIII uses that to decline to draft it. The key has now been 'ordered first' for ten days and does not exist.

The argument does not hold. Condition 1's key is hand-read — that is its entire point, and the reason it cannot inherit the implementation's reading. A hand-read key cannot 'pass by construction', because no parser produces its verdicts. The pass-by-construction risk that 146 correctly identifies is a risk to the key's scope, not its verdicts: an id-keyed key of 69 rows cannot reach a block-level defect. And 146 already supplies the remedy, as a requirement rather than an option: 'The key MUST be keyed on ## blocks, and must record, per block, whether it carries a live **Awaiting:** and at what tag.'

A block-keyed key is strictly finer than an id-keyed one and collapses to it if the steward rules the other way. The reverse is not true. So drafting at block granularity is safe under every outcome of Q1 and Q4, and it is your banked doctrine verbatim: drafting is the finer instrument. The package ran a census — 114 / 101 / 80 / 23 / 52 / 34 — used it to size a corpus-transition cost, and declined to draft. That inverts the doctrine the census was run under.

Condition: the key is drafted at block granularity, starting now. It needs no new authorization; REVIEWED-122 condition 1 is in force, and the package's own Part VII concedes this.

Related, and worse. PENDING-146 states in its own recommendation: '(iii), and the split is not gated on the ruling', and again in its Awaiting line that Move 1 and Move 2 'await direction and have been unable to say so since 2026-08-13', with Move 2 described as 'bounded, closable in one sitting, no ruling needed'. The live citation-safety exposure behind PENDING-131 (c) is the highest-cost thing in this cluster and it is not gated by this block at all. Part V identifies the answer key as 'the single artifact this entire block gates'. The unbuilt key is the gated artifact; the fence is the ungated one, and it has been ungated for seventeen days. Part V's framing buries that.

---

The Part I instrument

The refusal to total the two candidate columns is right and is the strongest instinct in the package. Three problems with the instrument itself:

• The script does not reproduce what its docstring claims. It says 'Reproduces wake-digest.py's OWN parser exactly (read from source, not reimagined)'. The quoted digest excerpt calls open_items(t) and tag_of(t, h); neither is quoted, and the script substitutes 'every line beginning with ## ' for the first. That substitution produces 114, which Part VI then uses as a firm number to size the corpus transition. The half that is reproduced is the ruled regex; the half that produces the load-bearing figure is a reimplementation.
• The controls run in one direction only, against a requirement stated by an item inside the package. PENDING-139, verbatim: 'positive controls are required in both directions: a fixture amendment under a ### heading the check must DETECT, and a fixture item carrying the negated marker which the check must NOT flag.' All four controls are must-detect. There is no must-not-flag control. Control 4 (len(blocks) > 80) is a positive control on the parser's own definition of the unit and passes trivially — the exact class your 2026-07-28 doctrine says Q2 cannot catch. It is also blind to ###, and 139(A) has measured that at least one ### REVIEWED heading exists in the corpus. So 114 and 80 are floors, not counts, and the package does not say so.
• decision_of can borrow a neighbour's verdict. ^## REVIEWED-N\s*—.*?^\*\*Decision:\*\*\s*(\w+) under re.S scans forward to the first **Decision:** after the header. If a REVIEWED entry has none, it captures the next entry's. Nothing controls for this, and the printed REVIEWED-{p} = {d} column inherits it.

One interpretive claim is also layered onto a script number without separation: 'Of the 34, most are items long since moved to PENDING-archive.md'. The script never reads that file. governance_item does search it, so the claim is checkable and was not checked.

---

Smaller corrections

• Part III is sound and is the best thing in the package. I verified both quotations. 110(c) does name 'the three the digest miscounts', and REVIEWED-122 condition 5 does decline exactly those three on principle. The demonstration holds.
• But Q2's lean over-reads condition 5. 110(c) has two legs: 'those where the number names a different item, plus the three the digest miscounts'. Condition 5 reaches only the second. The first is REVIEWED-86 / PENDING-86 — 110 records it as a live collision, 'differently biased checkers' against 'the jurist cannot read the constitution it design-gates'. 'Withdrawn as filed' drops it on the strength of a condition that does not touch it.
• The If AUTHORIZED: quotation is truncated mid-clause with no ellipsis, under the heading 'the build order in force'. The dropped remainder contains two obligations that bear directly on this package: 'restore PENDING-121 by hand on the same pass' (which is PENDING-143, omitted above) and 'Report the key-versus-implementation comparison in full, including agreements, rather than reporting only the delta' (which partly pre-answers Q6). Part V's dependency chain is also short one link: the same clause requires the (b) decision-verb enumeration to be submitted for ruling before wiring, so the chain is unit → key → verb-enumeration ruling → implementation.
• Four of eleven conditions are quoted, and three of the unquoted seven govern the gate questions. Condition 4 already rules that the third value is 'enumerated, never merely counted' — that is most of Q4, decided. Condition 2's 'defaults to not-closed on any unrecognized decision verb' is the same principle Q4 is asking about. Condition 7 names 124 and 128.
• Part II's substrate table omits two live legs of 110: the unplaced **Provenance:** lines ('Also owed, same surface, not yet done'), and 110's own acceptance check — 'the open-item count should fall from 21 to 18'. governance_state() shows 47 open items today. That falsifier is unusable as written, which is precisely 144(ii)'s subject.
• The 78 / 81 / 82 'verified subset' is three items of two kinds. PENDING-161 separates 82 out: it is the one confirmed case of an item declaring its own closure in its Awaiting line while the open list still carries it, '1 item of 105'. Grouping it with 78 and 81 is the same two-kinds-under-one-label error the package rightly flags for the 52.
• A cross-store confirmation the executor could not have obtained. My preferences document, generated 2026-07-28, records AUTHORIZED REVIEWED-81 and AUTHORIZED REVIEWED-82. governance_state() today shows PENDING-81 [ESCALATE] open and PENDING-82 [PROPOSAL] open. Two stores, one of them unreachable from your side, disagreeing on the same items. That is Part I's class, verified independently of Part I's script.
• 144's exhibit is not only historical. governance_state() prints GOVERNANCE DRIFT — CLAUDE.md: 0 substrate-contradicted claim(s) while PENDING-161 asserts, in an open [ESCALATE], a false substrate claim sitting in placed ruling REVIEWED-129. The claim is outside CLAUDE.md, so the drift-check is correct and silent, and the clean line discloses nothing about what it did not look at. That is a live instance of 144(iii), stronger than the discharged docstring, and it was available to be found.

---

The gate questions

Q1 — I am rejecting the framing before answering it. The question treats wake-digest.py and governance-drift-check.py as one instrument. They are not. The drift-check is a detector, and 139(b) — widen, plus emit a count of forms the parser could not classify — is the right answer there, marker-matching included. The wake digest is not a detector. It is the surface a steward reads to learn what awaits authorization, and PENDING-145 establishes that the most load-bearing item in the corpus was invisible in it for a week. A primary governance surface is the last place to infer status from prose. Lean: declared closure field for the digest; 139(b) for the drift-check. Split this way, the '114 blocks re-graded' cost that makes the executor's lean weak largely evaporates, because the field is a closure signal on a much smaller population and Q4 handles the rest.

Q2 — Split it. Withdraw the 78/81/82 leg as foreclosed by condition 5. Re-pose the REVIEWED-86 leg, which condition 5 does not reach. Note separately that 82's case has been overtaken by PENDING-161.

Q3 — Sever 108, on better grounds than offered. The package's reason (filename-stem matching is 'the same technique, one directory along') does not survive. A filename stem is a structured token, not narrative prose; its failure mode is mismatch, not misreading. If anything 108(b) is the declared-field answer already applied to a different substrate, which argues for Q1's declared-field lean rather than for grouping. 108 carries its own completed measurement and its own pre-registered falsifier ('if, over the next 10 packages, the detector fires zero times … retired rather than kept as reassurance'). It is the most self-contained item in the set. Rule it separately. One note for the sitting: this document is a *JURIST-PACKAGE*.md, so 108's own clock starts on it.

Q4 — Agreed, and mostly already ruled. Absence means cannot-assess, never open and never closed. REVIEWED-122 condition 4 already requires that bucket to be enumerated by id and header with a reason, not counted. Bulk annotation is a separate steward act.

Q5 — Read 139 first; agreed, and I did mean that. Ruling order: 139, then 145, then 146, then 110, then 144. 108 severed. 143 in the picture as evidence, not as an item to rule.

Q6 — Yes, and part of it is already in force. The key records, per block, which of the two kinds a live Awaiting: is. Condition 1's 'the disagreement is the finding' and the dropped 'including agreements, rather than reporting only the delta' both already apply.

---

What I could not settle

• Every 'NOT built' in Part II. I cannot read the scripts. I can confirm the items describe mechanisms consistently with each other, and that all six are open in governance_state().
• The non-existence of the answer key. No tool here reaches ~/dotfiles, and repo_activity does not cover it.
• Part I's numbers. I can confirm the class from two stores; I cannot confirm a figure.
• One loose end I cannot explain and am reporting rather than smoothing. governance_state() and governance_item disagree about where three of these items live: PENDING-108 at 1580 versus 1603, PENDING-110 at 1664 versus 1687, PENDING-143 at 3691 versus 3714 — each exactly 23 lines apart. For PENDING-139, -145 and -146 they agree exactly (3421, 3732, 3764). Two instruments in the same server, disagreeing about a location, in a cluster about record-keeping instruments. I have no account of it and am not offering one. It is not covered by any of the six items.

If you want it, I can draft the placeable REVIEWED block in plain fenced markdown once you tell me whether you are ruling the block as amended or sending it back for a redraft. I would send it back — but the three conditions above are actionable this week, and the key and Move 2 need no ruling from either of us.