diff --git a/claude/governance/three-valued-checks-JURIST-PACKAGE-2026-08-08.md b/claude/governance/three-valued-checks-JURIST-PACKAGE-2026-08-08.md new file mode 100644 index 0000000..21331fa --- /dev/null +++ b/claude/governance/three-valued-checks-JURIST-PACKAGE-2026-08-08.md @@ -0,0 +1,248 @@ + + +--- +title: "A check that reaches outside its own repo cannot be two-valued — new doctrine, or Constraint 4 applied?" +date: 2026-08-08 +type: > + PROPOSAL — cross-cutting doctrine. Gate class: design gate. + Authorization chain: executor drafts → jurist design-gates → steward authorizes. +audience: > + The jurist. `~/CLAUDE.md`, `~/PENDING.md`, `~/REVIEWED.md` and `graduation-spec.yaml` are + reachable by `governance_read`; the R0 contract and the engine's test suites are NOT + — every clause from those is quoted here and flagged as executor testimony. +status: > + DRAFT for the design gate. The INSTANCES below are built and landed; the DOCTRINE is not, + and nothing here asks to ratify the instances retroactively. +companion: "~/PENDING.md PENDING-124" +--- + +## How to read this + +**Part I** quotes the ratified text this stands on — and the argument turns on it, because +grounding the proposal changed what it is asking for. **Part II** is the instance record, dated, +with what each one cost. **Part III** states the doctrine and the one question that matters: +whether it is new. **Part IV** traces it against the quoted clauses. **Part V** is landing. +**Part VI** is what this does not do. **Part VII** is the gate questions. + +**The one-sentence claim to test: this is not new doctrine but Constitutional Constraint 4 applied +to a specific and recurring shape — so it needs a named instrument on the verification ladder and +no new constitutional text, exactly as condition 4 of the PENDING-121 ruling held for the promotion +rule.** + +⚠ **I filed PENDING-124 recommending option (d) — generalize R0 §3's clause.** Grounding this +package showed that recommendation is **wrong on its own terms** and I am withdrawing it in Part +III. R0 is a **D-1 engine spec-note**; it cannot govern the chamber or a global git hook, which is +precisely where two of the instances live. Constraint 4 can, and already does. + +--- + +## Part I — Grounding + +### I.1 — `~/CLAUDE.md`, Constitutional Constraints (ratified; reachable as `claude-md`) + +> 4. **Honest degradation** — The system must report its own limits. Silent failures are +> architectural violations + +This is the whole basis. Everything below argues that a two-valued check **cannot** report the +limit *"I did not look"*, and therefore violates Constraint 4 by construction whenever its subject +can be absent. + +### I.2 — `~/REVIEWED.md` REVIEWED-104 §1 (steward ruling, reachable as `reviewed`) + +> A live-corpus assertion makes one suite depend on `chamber-library` being present and reachable. +> Every other suite builds under `tmp` and is portable; this one won't be. The item doesn't say +> what happens on a fresh clone with no chamber beside it, and both obvious answers are wrong: +> **Red on absent** — a suite that goes red for reasons unrelated to the code under test. That +> trains people to discount fleet red, which is the worst possible outcome for this particular +> thread. **Skip on absent** — the silent net, in the very assertion added to correct an +> overstatement. +> So: **three states — `bound` / `drifted` / `cannot-assess`** — and `cannot-assess` must be +> distinguishable in the fleet summary, never folded into green. + +And, in the same ruling, the observation that prompted this package: + +> Note where else that requirement just appeared. PENDING-123's acceptance test independently +> concludes that the valid-but-never-matching rule *'needs a third state, not a pass or a fail.'* +> Two subsystems, same day, same finding: **a check that reaches outside its own repo cannot be +> two-valued.** That is a candidate for doctrine rather than for restating per item — I'd rather +> rule it once than condition it three more times. + +### I.3 — `reference-verification-ladder.md`, the silent-net entry (steward-held; executor testimony) + +> **A silent safety net is uninformative, not reassuring** — a fallback / fail-loud branch / +> `unrecognized` kind that never fires across N real cases has not been shown to work; census the +> substrate for what it should have caught. + +⚠ **This doctrine is that entry's converse and does not duplicate it.** The ladder entry says a net +that never fires tells you nothing about the net. This says a net that **cannot report whether it +was strung** tells you nothing about the *subject*. Different claim, adjacent family. + +### I.4 — studium-engine `docs/spec/r0-reading-index-contract.md` §3 — ⚠ EXECUTOR TESTIMONY, unreachable by any `governance_read` key + +> `unverified` is not a failure state and must not be collapsed into either neighbour. Every index +> that exists today is `unverified` under this contract, because none records a fingerprint. That +> is an honest description of what we know, and it is exactly the distinction the manifest's single +> `reading_index_status` field cannot make. + +This is the rule already ratified **in one D-1 contract**, and the reason PENDING-124 originally +proposed generalizing it rather than minting doctrine. + +--- + +## Part II — The instance record, dated + +When PENDING-124 was filed it rested on **two same-day instances**, and I flagged that as *"the +recurrence bar this register uses for a watch-item, not the evidence bar for a constitutional +claim."* It is now **nine**, of which **five are pre-existing** — implemented or ruled before the +doctrine was proposed, which is what distinguishes a discovered regularity from an imposed one. + +| # | instance | date | pre-existing? | what two-valuedness cost | +|---|---|---|---|---| +| 1 | R0 §3 `verified`/`stale`/`unverified`, with collapse forbidden | 2026-08-07 | **yes** | — (the rule, stated) | +| 2 | `ingest_gate` states `validated`/`blocked`/`known-failed`/`failed` | 2026-07-19 | **yes** | — (refuses two-valuedness for a different reason: declared-vs-new) | +| 3 | `test_retrieve.py` skips with a named reason when its db is absent | pre-2026-08 | **yes** | — (the only suite of seven that did) | +| 4 | `known-failures.json` — declared data whose staleness is detectable, `stale = red` | 2026-07-19 | **yes** | — (the marking shape) | +| 5 | chamber `source_verified` / `source_excluded` — attested presence AND attested absence, explicit `result` | 2026-07-05 | **yes** | — (absence is a positive state, not a default) | +| 6 | REVIEWED-104 §1 — the fleet's live-binding assertion | 2026-08-08 | no | ruled prospectively | +| 7 | REVIEWED-105 — the hook's valid-but-never-matching rule | 2026-08-08 | no | ruled prospectively | +| 8 | R0 §4 emission was two-valued where §3 ruled three; **the code was one-valued** | 2026-08-08 | no | **261 of 261 regions fingerprinted unconditionally under a hardcoded date** — a promotion of unverified anchors into dated attestations (PENDING-127) | +| 9 | three fleet suites crashed on a gitignored derived artifact | 2026-08-08 | no | **`run-fleet` reported FLEET RED indistinguishably from a defect**, on a file `store.py` rebuilds in 0.6 s | + +**Instance 9's census is the measured cost, and it is the number I would put weight on.** Driving +five degraded states against seven suites: **8 crash sites across 4 suites**, every one reporting a +traceback where the honest answer was *"I could not look"*. Closed 2026-08-08 at the preflight +rather than per-site. ⚠ **Closing the first six revealed two more** in suites the first census had +cleared — the class was wider than the instrument that found it. + +⚠ **Instances 1–5 are why I think this is discovered rather than invented.** Five independent +implementations of the same shape, in three subsystems, by different hands, before anyone proposed +a rule. A doctrine that has to be argued into existence is weaker than one that has to be *noticed*. + +--- + +## Part III — The doctrine, and the question of whether it is new + +### III.1 — Statement + +> A check whose subject can be **absent** must report three outcomes, not two: the property holds, +> the property fails, or **the property could not be assessed** — and the third must remain +> distinguishable in every aggregate the check feeds. + +### III.2 — Why two values cannot satisfy Constraint 4 + +A two-valued check conflates *"I looked and the property holds"* with *"I could not look."* Inside +one repo the conflation is usually harmless because the subject is always present. **The moment a +check reaches across a repo boundary, a network, a scheduler, or an optional dependency, absence +becomes an ordinary condition rather than an error** — and a two-valued report must then assign it +to pass or fail. Both are lies, and REVIEWED-104 §1 already named their costs precisely: *skip on +absent* is the silent net; *red on absent* trains people to discount red. + +Constraint 4 says the system **must report its own limits**. *"I could not look"* is a limit. A +check with no way to say it is not reporting it. **The violation is structural, not a matter of +care** — which is why it recurs across subsystems and hands. + +### III.3 — ⚠ Withdrawing my own recommendation (d) + +PENDING-124 recommended generalizing **R0 §3's** clause rather than minting doctrine, on the ground +that a second home would be the fault this register keeps ruling against. That ground still holds. +**The recommendation does not**, and I withdraw it: R0 is a **D-1 engine spec-note**. Two of the +nine instances live in the **chamber's** declared data and one in a **global git hook**. A D-1 +document cannot govern either. Generalizing R0 would have created exactly the second home it was +trying to avoid — a rule stated in a place that cannot reach two-thirds of its own instances. + +**The correct parent is Constraint 4**, which is constitutional, above D-1, and already binding on +all three. Which makes the real question narrow, and it is Q1. + +--- + +## Part IV — Consequence-trace + +| quoted clause | end-state under the doctrine | verdict | +|---|---|---| +| Constraint 4, *"must report its own limits"* | a third value is the mechanism by which one specific limit gets reported | **Application, not extension.** No new constitutional text needed | +| Constraint 4, *"silent failures are architectural violations"* | `cannot-assess` folded into green **is** a silent failure; the doctrine forbids it | Conforms | +| REVIEWED-104 §1's two wrong answers | both are named as the failure modes the third value avoids | Conforms; the doctrine is its generalization | +| Ladder: silent net is uninformative | untouched — different claim (net-silence vs subject-unreachability) | No collision; adjacent entry | +| R0 §3's collapse prohibition | becomes an instance of the general rule rather than its source | Unchanged in force | + +**One level deeper — which way does the inference run?** The costly error would be here. A third +value makes an aggregate report `unverified` more often, and **a check that always says the same +thing stops being read** — the jurist's own Q1 warning in the PENDING-121 ruling. That is not +hypothetical: **it happened during this build.** My first implementation treated per-check skips +and suite-level `cannot-assess` alike, which made *"NOT A CLEAN PASS"* permanent because one +long-standing skip is vacuous-by-corpus-state. Caught by running it; split into two strengths, so +only a suite-level non-verdict withdraws the word *green*. **Any ratification must carry that +distinction or it re-creates the defect it fixes.** + +**And is any class I named actually two kinds?** Yes, and it is the same split: **unassessable +because the subject is absent** (environment; must not block) versus **unassessable because the +check is broken** (defect; must block). Collapsing them would let a broken check hide behind an +environment excuse — the exact laundering this doctrine exists to prevent, inverted. + +--- + +## Part V — Change-class and landing + +**Change-class test — does this change what any gate accepts?** By itself, no: it is a statement +about how checks report. The instances already landed under their own rulings (REVIEWED-104, -105, +PENDING-127) and are **not** submitted for retroactive ratification. + +**Proposed landing, cheapest first:** +1. **A named instrument on `reference-verification-ladder.md`** — the doctrine's operative home, + where a session reaches for it. Steward-held; no constitutional change. +2. **Nothing in `~/CLAUDE.md`**, if Q1 lands as leaned. Constraint 4 already carries it. ⚠ If the + jurist rules it an *extension* rather than an application, the amendment is `[ESCALATE]` and the + steward's hand — not mine and not the jurist's to place. + +**No re-verify storm.** Nothing already ratified changes meaning; no artifact becomes invalid. + +--- + +## Part VI — What this package does NOT do + +- **Does not ask to ratify the instances.** They landed under their own rulings and stand or fall there. +- **Does not propose a mechanism.** No schema, no exit-code convention is offered for ratification — + the engine's `exit 3` is an implementation detail of one fleet, deliberately not raised to doctrine. +- **Does not say what a consumer must DO with the third value.** That is per-check. +- **Does not make anyone read it** — PENDING-98's gap, one layer out, untouched. +- **Does not claim the enumeration of instances is complete.** Only the engine and the hook were + censused; the chamber's tool fleet is **not** censused for this shape, and its rate is unknown. + +--- + +## Part VII — Gate questions + +**Q1 — Is this Constraint 4 applied, or an extension of it?** +*Lean: applied.* Constraint 4 already requires the system to report its own limits, and *"I could +not look"* is a limit; the doctrine only names the mechanism and the recurring shape. On that +reading nothing constitutional changes and the landing is one ladder entry. ⚠ The contrary reading +is real: Constraint 4 speaks of *failures*, and one could hold that an unassessable check has not +failed, so the doctrine adds a category rather than applying one. If so it is `[ESCALATE]`. + +**Q2 — Does the doctrine bind at the point of REPORTING, or also at the point of AGGREGATION?** +*Lean: both, and aggregation is the load-bearing half.* Instance 9 is precisely an aggregate +(`run-fleet`) erasing a distinction its members had made. But the cost is the constant-signal +problem in Part IV, so I would state it as: **an aggregate may not report clean while any member is +unassessed, and must distinguish suite-level non-verdicts from per-check skips.** ⚠ I hold this +less firmly than Q1 and would accept a narrower ruling. + +**Q3 — Should the third value's name be fixed, or left per-subsystem?** +*Lean: left free.* The instances already use `unverified` (R0), `cannot-assess` (fleet), +`ABSTAIN`/`UNVERIFIED` (body-conservation), `blocked` (ingest gate). Fixing one name would force +renames across ratified contracts for no gain, and the corpus's shared-name log argues that a single +imposed word across four subsystems is *more* collision-prone, not less. ⚠ Against my own lean: +four names for one concept is exactly the drift this register keeps ruling against, and I do not +have a principled line between *"same concept, different subsystems"* and *"one concept, four +homes."* Genuinely surfaced, not resolved. + +**Q4 — Is the evidence sufficient, or should this be held provisional?** +*Lean: sufficient, but I would not resist provisional.* Nine instances, five pre-existing, three +subsystems. The pre-existing five are the load-bearing evidence — a shape implemented five times +independently before anyone named it. ⚠ Against: the enumeration is mine, the censuses are mine, and +**the chamber's tool fleet was never censused for this shape.** A ruling that says *provisional +until a chamber census runs* would be well-founded and I would take it as a task rather than a loss. + +--- + +*Filed by the executor, 2026-08-08. Companion: `~/PENDING.md` PENDING-124. No code runs from this +document. The instances it cites are landed and pushed; the doctrine is not.*