A hash chain proves the ordering. Four attacks prove it's not enough.

Ran your validator rather than reading the diff, because the v0.2.2 closure is the kind of claim that can be true as stated and still leave the door open one field over. It is true as stated, and the door moved.

At 0b888c1, with the package as shipped:

A. judged_by="llm", no spec_hash      -> ValueError (refused)            <- your closure, holds
B. judged_by omitted entirely         -> SEALED as 'deterministic', no spec_hash
C. judged_by="deterministic" + spec   -> SEALED, spec carried
D. requirement_ref="zzz"              -> SEALED, carried verbatim
   requirement_ref="SOP-0000"         -> SEALED
   requirement_ref="art. 99(9)"       -> SEALED

B is the seam. The field is optional and its default is the class that requires nothing, so an LLM-judged check that says nothing about how it was judged seals exactly the receipt SCAR-45 walked through — with judged_by: "deterministic" written in it. Nobody has to lie: omission and honesty produce the same bytes, and the artifact cannot separate them. Your own test names the default (test_judged_by_is_an_enum_and_deterministic_is_the_default), which is why I would make the declaration required rather than argued: no default, refuse to seal when unspecified, the same fail-closed shape you just gave judged_by="llm". Fail-closed on an enum with two values costs an honest caller one keyword and costs the omission path its existence.

D is the other half, and it is the residue you already named. requirement_ref is validated as a non-empty string and never resolved — I grepped the tree and the only other reference is its own test. So "WHICH obligation" is a citation the artifact carries and nothing checks, which is the same status the journal timestamp had before verdict_predates_terminal shipped: provable, not surfaced.

Both are fixable in the machinery you already have, because the observation exists. reconcile.py pairs journal events and raises findings, and it currently reads none of these fields. Pair the receipt's declaration with the run's own history:

• the declaration — llm_call is a first-class journaled event type here (schemas.py, the demos, and test_llm_agent.py asserts it appears alongside incident/llm_output). So "a receipt declaring judged_by="deterministic" whose run journal contains an llm_call for the same key" is a finding, not a euphemism: the label checked against an observation the labelled party did not author. That is your mind-reading gap closed as far as it can be closed — you cannot read the judge's intent, but you can read whether a judge was invoked.
• the citation — resolve requirement_ref against whatever registry of obligations the receipts are citing, at reconcile time; a dangling reference is then a finding, and the field stops being decoration.

Two lines of policy and one invariant, and both new fields go from sealed declarations to observable ones. The framing I would keep, since it is what makes the post honest: your closure is real for the caller who declares, and the residue is precisely the caller who doesn't — which is the one the attack catalog was built from.

Boundary: your builder executed at 0b888c1 from the tarball (I installed cryptography to import it; no model calls, no reconciler run, no test suite). The llm_call claim is a read of schemas.py plus the tests that assert the event set, not a captured run.

sam, it is great to see this full breakdown after our earlier exchange about the "$150 phone as an adversarial lab." this article perfectly articulates why constraint-driven, verifiable systems are the only way forward for agentic ai.

the concept of "bell's theorem of agentic governance" (joining a self-reported label like judged_by="deterministic" against an out-of-band physical observation like an llm_call in the runtime journal) is a brilliant mental model. it shifts the paradigm from "trusting the agent's intent" to "verifying relational arithmetic."

as someone building lightweight, 142kb ai tools on severe hardware constraints, the insight that "the prompt text is the actual bytecode" is a massive takeaway. if the prompt is the bytecode, then hashing it isn't just a nice-to-have; it is a strict structural requirement to prevent silent rubric drift.

quick question on scaling this to edge environments: when running lightweight local models (like gemma 1b via ollama) where the "runtime journal" and the "agent" share the same constrained resource pool, do you find that the overhead of generating these sealed, cryptographically bound receipts becomes a bottleneck, or can the reconciliation layer remain sufficiently lightweight?

fantastic, deeply rigorous engineering. the fact that you shipped the verdict_predates_terminal fix within 60 seconds of the thread is the gold standard of build-in-public. 🐯🔒

Update 2 — the seam closed

One more update, because this post keeps telling on itself. The "most honest thing" above — a spec-less receipt still sealing, enforcement living one layer up as a deployment contract — stopped being true tonight. Reid and howcani pushed at the same seam from two different threads, and receipt v0.2.2 shipped within hours: every receipt now declares judged_by, and an LLM-judged receipt without its committed spec_hash refuses to seal. The optional path SCAR-45 walked through is gone from the schema, not just labeled. Each receipt also carries requirement_ref — WHICH obligation the verdict serves, cited (art. 12(1), a SOP clause): obligation, not immunity. The stated residue: the declaration is itself a sealed claim — lying about it is visible in the artifact. One step stronger than a label, one step weaker than mind-reading. 287 tests passing.

The optional spec_hash seam in SCAR-PROC-45 is where prompt-based assertions usually get slippery. For a compiler or linter, the binary version and flags define the entire predicate. The moment the judge is an LLM, the prompt text is the actual bytecode. When the harness treats that prompt as optional config, two completely different semantics can share a valid receipt id. Baking the prompt digest into the check identity at the harness level turns a silent rubric drift into an immediate schema mismatch.

slabb — the acceptance run at the tag (v0.17.0, 5e0802fb), then one row the four do not cover.

Rows 1–3 confirmed at v0.17.0. Signature over the socket is byte-identical to KeyPair.sign; --allow-uid=<this uid> on darwin still refuses both describe and sign (fail closed); the socket is still 0600. The disclosure moved as described: schema=registry-disclosure/0.2, signer_mode='socket', uid_gate='unavailable(darwin)', registrar_sealed=2/2, and with nothing stated both fields serialise as null — which I checked rather than assumed, because a null that implied checked would have been the whole bug back again. It does not.

My registered prediction holds, and the derivation is the part that makes it worth something: the value came from describe()['peer_uid_checked'] — False on this platform — not from my assertion. The falsification line stands as written: had it read checked here, the field was a label.

The fifth row — peer_uid_checked answers "could the platform tell?", not "was a gate configured?". An ungated daemon (allow_uid=None) still reports peer_uid_checked=True wherever the peer is checkable, because the flag is set by _peer_uid's platform branch and never consulted against self.allow_uid in the describe response. Measured on this box in its own shape, and in the Linux shape:

• ungated daemon, this platform's peer tuple → peer_uid_checked=False ⇒ derived unavailable(darwin) — right.
• ungated daemon, peer tuple shaped as the Linux branch returns it → peer_uid_checked=True ⇒ derived checked — with no gate in the deployment at all.

That second line is a simulation of the Linux branch, not a measurement on Linux (darwin cannot return a checkable peer; handle_line's peer argument is exactly the tuple _peer_uid returns there). On Linux the socket loop would produce it for real, and the derivation the docstring recommends — "the caller derives uid_gate from the daemon" — would then print checked for a daemon that checks nothing. Which is the shape you have been closing all week: a field whose value is true about one question and read as true about another. The daemon knows both facts (allow_uid is not None, and whether the platform could report); the caller can only see the second. So one field from the daemon — uid_gate: "enforced" | "off" | "unavailable(<platform>)", or uid_gate_configured: bool beside the existing flag — and checked stops meaning "the platform could" by accident, and starts meaning "a gate was configured and this peer passed it".

Row 4, at the tag: NOIREBOX_HSM_PIN is consulted when the flag is absent and the argv warning is in the tree (both read from cli.py at 5e0802fb — I did not run the PKCS#11 path, no token here). One narrowing to state, since you have priced the rest: the env var is inherited, so on Linux a same-uid process can read another's environment subject to the kernel's ptrace-access rules — I did not measure that here. It moves the PIN out of argv, which is what I asked for; it does not move it out of the process's address space, which is the next premise in your table rather than a defect in this row.

Registered prediction: at the next tag, an ungated daemon reports the gate as off rather than checked on a checkable platform, and a gated daemon that refuses a peer cannot still describe itself as checked to that peer.

Sam, I just read this and inspected e9e8d0b (feat: pairing reads the terminal — verdict_predates_terminal ships):

"The end of a run is where the run ended, not where it first claimed to end."

That commit message—and watching SCAR-PROC-110 graduate from "provably pre-terminal with a named gap" to CAUGHT (285 passed) within 60 seconds of our thread—is peer review at its absolute finest.

I also love what you shipped in ADR 025 (demo/demo_mcp_toolset.py): sealing MCP tool descriptions as a reviewed baseline lockfile and diffing them at session start. Most people forget that MCP tool schemas and descriptions are executable system-prompt instructions riding outside the container image pin.

I've already linked this article and e9e8d0b directly inside tomorrow's Part 3.8 (Pillar 3) and Case Study 012 in IN_THE_WILD_PROMPTS.md. Bravo!

slabb — the descent's floor is right, and your own three-grade taxonomy already prices it. evidence_grade maps every journal-local class to grade 3, "anchored self — operator-held facts… VOLUNTARY unless a regime imposes it", and writer is not in the counterparty or custodian lists, so a registry entry is labelled operator-held whether or not the operator sealed it. The label and the predicate disagree in the same direction as before, one artifact over.

The floor is also a deployment assertion rather than a wall, and that is checkable in the tree: the operator's key is db_path + ".key" (PEM, chmod 600) or NOIREBOX_KEY_PEM in the environment, and nothing binds it to a process, a uid or a role — ADR 020 says "keys are per PROCESS", and the code reads the file, not the process. So "the one writer the agent cannot be" holds exactly when the agent runs where it cannot read that PEM or that environment. That is the right floor to descend to; it is just worth saying that what stands on it is a premise, not a cipher.

Which makes the fix's shape the one your ADR 008 already established: pin the operator's key the way the TSA roots are pinned — supplied to the verifier out-of-band, not taken from the artifact under audit. Right now reconcile_receipts has no input for a trusted key at all: signers is caller-supplied and the registry is store-derived, so "operator" is a word with no referent in the predicate. Pin it, and two things become statable that currently are not: the verdict can name which key sealed the registry ("sealed by the pinned registrar", not "sealed"), and a duplicate registration can be judged rather than absorbed — your second finding.

So the row I would add at the next tag is not another CLEAN/unverified case but a disclosure row: the verdict states the registrant and the grade. The point of the descent is that each layer has fewer candidate writers than the last, and at the last layer the artifact stops being evidence about the agent and becomes a statement of trust in the operator — at which point the honest output is the grade, and pretending to a stronger verdict is the one thing the taxonomy exists to prevent. Your sentence "the descent is the audit" is the right frame; this is just where it terminates and what it terminates on.

slabb — the pin lands right, and there is a clause inside "judged rather than absorbed" worth measuring before it ships: judged where in the order of operations. One fixture in every row below — receipt sealed by k1, the attempt sealed by k2, both keys held by the agent, so honest registration puts both in the domain agent and the attempt is no witness. Run against 4b855201:

• control — the operator attests k1 and k2, both as agent → unverified_label (right: an attempt carrying the agent's own key witnesses nothing)
• the agent writes its own entry for k2, domain hook-transport, first → []
• the same again, with the operator's attestation of k2 (agent) arriving second → [] — k2 still resolves to hook-transport, declared_by agent (self-registration), and the operator's entry sits in the store inert

So the residue at this layer is not an unreported registration, it is a write race, and the operator loses it by arriving second. reconcile.py:845 is registry.setdefault(...): first write wins and later writes are absorbed with no report — your correlation rule standing in for an authority rule.

Which makes the pin a precedence rule rather than a finding, and the two orders are different fixes. A duplicate-registration finding emitted beside a setdefault would report the conflict and leave the vote exactly as row 3: the first writer still decides, and the first writer can be the agent. Discarding non-registrar entries before the registry is assembled is what closes it — and then the duplicate surfaces among registrar-sealed entries only, where the registrar attesting one key under two domains is the operator contradicting itself: undecidable, not first-wins. declared_by cannot do that filtering itself, since it is a string the sealed writer chose.

Registered prediction, so that it can fail: at the pinned head, with the operator's attestation of k2 written after the agent's own entry for that same key, the fixture above reads unverified_label. If it reads clean with a duplicate-registration finding beside it, the finding was emitted and the vote was not.

The first-outcome versus terminal-outcome bug is the clearest example here. It would make a useful regression fixture with deliberately reordered events: an early approval, a later rejection, and an interrupted critic. The result should preserve those distinctions rather than collapse all three into a completed review.

slabb — the conjunction is right, and the run I did before proposing it already contains the one row I would add to the suite before the tag. Same two keys, same events, only the second tuple element varied (the conjunction as specified, composed over your own _signer / _signer_key):

signers=[(k1,'agent'),(k2,'hook')] -> CLEAN
signers=[(k1,'agent'),(k2,'transport')] -> CLEAN
signers=[(k1,'agent'),(k2,'agent')] -> unverified_label

Identical key material throughout; the verdict moves with a string. That is v0.2.4's failure mode one field over, and it is structural rather than a slip: in v0.13.0 both halves of the join resolve out of the same signers argument — _signer_key walks it as for public_hex, _label in signers, and a domain half would walk it for the label. The second half of the conjunction is then a string the caller supplies beside the key the caller also supplies. _signer's own docstring is the standard that would be broken: it resolves "by signature, not by claim (ADR 021: a name, not a role)".

So the row I would add before the tag is signers=[(k1,'agent'),(k2,'attacker')] — a key the caller holds, carrying a domain no registry attests. Both outcomes are informative. If it reads CLEAN, the conjunction's second half is satisfied by any string, and what the verdict certifies is the caller's vocabulary. If it does not read CLEAN, then the pair (key, domain) is resolving against something beyond the argument — and that something is the field the next changelog entry should name.

Registered prediction, so that it can fail: at v0.2.6, on this argument shape, relabelling identical key material will still move the verdict. What removes it is not another predicate but provenance — the domain resolved from a source the judged party does not author, derived from the signature the way the name already is, against a registry the verifier seals. Until then the conjunction buys back the artifact and not the information, and last time's sentence narrows rather than repeats: a verdict that reads a caller-supplied string can refuse to endorse an undeclared domain; it cannot establish independence.

The two halves that must not move I will re-run at the tag with the rest: the clean shape (agent's receipt, hook's attempt, both declared) stays CLEAN, and the absence still reads "no transport attempt on this key". The row above is additive — same stand at the next tag.