dotfiles/claude/governance/three-valued-checks-JURIST-PACKAGE-2026-08-08.md

---

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 (steward ruling, reachable as reviewed)

⚠ REPLACED 2026-08-08 at the design gate. What stood here was a NORMALIZED RECONSTRUCTION of this ruling, not its placed text, and my own quote-verification pass counted it among the verified. Differences the jurist enumerated and I confirmed against the record: will not be → won't be; does not say → doesn't say; wrong. → wrong:; CONDITION: → So:; the Notes paragraph and §1 spliced into one block though the record keeps them separate — and the closing sentence dropped. Below is the placed text, ~/REVIEWED.md L1246–1250:

Notes: 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 will not be. The item does not say what happens on a fresh clone with no chamber beside it, and both obvious answers are wrong. Red on absent is a suite going red for reasons unrelated to the code under test, which trains people to discount fleet red — the worst possible outcome for this particular thread. Skip on absent is the silent net, in the very assertion added to correct an overstatement.

1. CONDITION: three states — bound / drifted / cannot-assess — and cannot-assess must be distinguishable in the fleet summary, never folded into green. A green fleet that includes an unassessed binding case is the same overstatement one layer along.

The dropped sentence is the one that answers Q2, and it was in the record all along. See Part VII.

⚠ BOTH citation errors in this package have ONE cause, and the script cannot diagnose it: I quoted the ADVISORY message and attributed it to the PLACED record. They are different documents — placement can add, cut, or re-word — so quoting the advisory systematically loses whatever the act of placing contributed. Here it lost precisely the sentence that would have closed a gate question without asking. Recorded as the generalizable finding, not as two separate slips.

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.

⚠ CORRECTED AT THE GATE — the five are NOT one shape, and my "five … same shape" was wrong. Tested against this table's own rows: two are the doctrine's shape (1 R0's three states; 3 test_retrieve's named skip — a check reporting it could not assess). Three belong to an adjacent principle: 2's own row says it refuses two-valuedness "for a different reason: declared-vs-new", and a declared failure is assessed, not unassessable; 4 is a marking shape, detectable staleness of declared data; 5 is attested absence of a finding, not of an assessment.

So: two pre-existing instances of the shape, three of the adjacent principle, one found at the gate itself (§2 of the ruling — this package's own verifier reporting verified on a reconstruction; the only instance in the set independent of the advisory that proposed the doctrine).

⚠ And the adjacent principle is already ratified, which relocates the proposal rather than weakening it: ~/REVIEWED.md REVIEWED-47, 2026-07-05 — the exclusion path, "attested absence lives in its own honest top-level key source_excluded", with the sectionless: precedent that a bare flag is not a safeguard and an attributed attestation is. I searched for a parent among R0 (D-1, correctly withdrawn) and Constraint 4, and missed the ratified sibling closest to it in content.

---

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.

The third outcome is itself two kinds, and they must not be merged: unassessable because the subject is absent — an environment condition, which must not block — and unassessable because the check is broken — a defect, which must. Merging them lets a broken check hide behind an environment excuse.

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.

---

Quote-verification record

Every blockquote in this document was mechanically checked against ~/CLAUDE.md, ~/REVIEWED.md, ~/PENDING.md, the verification ladder and the R0 contract, on 2026-08-08. Six passages; four verified verbatim; two residuals, both intended:

• the advisory passage in I.2 — correctly not in any governed record, and labelled as advisory after the pass caught me citing it as ruled text;
• the doctrine statement in III.1 — my own proposed normative text, in blockquote formatting because it is a proposal, not because it is a quotation.

⚠ The instrument cannot tell a quotation from proposed text in quote formatting. It reported "2 unverified" and a reader who stopped there would have found a defect that is not one. Stated so that the number is not mistaken for a verdict.

⚠ R0 §3 verified against ~/PENDING.md first (where I had quoted it) and separately confirmed present in the R0 contract itself. The contract remains unreachable by any governance_read key, so for the jurist it is still testimony — the verification is mine, not theirs.

---

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.