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.

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 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.

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 run is done, at the version's own commit rather than a tag: 1e222a95 (2026-10-12T19:09:36Z, "the known-writers registry — v0.2.6"), extracted from the tarball at that commit, since the newest tag is still v0.13.0.

The immobility test passes, and my own r169 prediction is refuted. I registered the prediction that at v0.2.6 relabelling identical key material would still move the verdict. It does not: with a sealed registry present, the same two keys and the same events read CLEAN under hook, agent, transport, whatever and attacker — the caller's label is inert. Record it as a refuted prediction rather than a confirmed one; the reason it holds is that the label stopped entering the verdict at all, which is the entire point of moving the domain to registration.

The six rows are otherwise unchanged: omitted → "independence NOT RUN", [] → "the known-writer set is EMPTY", an unresolved receipt writer → independence_undecidable, the clean shape still CLEAN, the absence half still "no transport attempt on this key". And the omission path I would have worried about is closed at the constructor, which is the right place for it — seal_writer refuses a blank domain and a non-64-hex key, so "registered without a domain" is unreachable rather than merely unusual.

The row the run surfaces is the registry's own authority. Same two keys, same events, registry sealed in the two possible ways:

sealed by the operator's key -> CLEAN
sealed by the AGENT's own key -> CLEAN

reconcile_receipts builds the registry out of every writer event in the store and never resolves the key that sealed them, so the verdict cannot separate attestation from claim. The ADR amendment says "sealed by the verifier" and your own test docstring says the operator's key is "what makes it attestation and not claim" — the documentation is right and the predicate does not read it. Since the agent must be able to append its receipt to that same store, an agent holding a second key can register it itself, and the residue reopens one layer down: no longer in the caller's argument, now in the store the judged party also writes.

Second row, same artifact — a key sealed twice under different domains. The store keeps both events (3 writer events; domains hook-transport, agent, agent), the registry uses setdefault, so first write wins, nothing reports the conflict, and the verdict is order-dependent:

k2 sealed 'hook-transport' then 'agent' -> CLEAN
k2 sealed 'agent' then 'hook-transport' -> unverified_label

Same keys, same events, same registrations — two seal_writer calls swapped decides the verdict. A correction to a mis-registered domain is silently ignored, and the misregistration is permanent and invisible.

So the rows I would add before the tag, each with a prediction that can fail: (1) a registry sealed by the receipt's own writer must not read CLEAN — either the registration resolves against the verifier's key, or the verdict names the registry as unattested; (2) sealing one key twice under different domains must raise a finding rather than resolving first-write-wins. The fix for (1) is one your architecture already carries: the registry is a fact about a key, so its authority has to come from outside the auditee — a pinned verifier key, or the registration anchored the way the heads are (ADR 008, "the trust root leaves the operator's perimeter"). Until then the closure is structural given an honest registrar, and that premise is the field worth naming in the next changelog entry.

Hash chain chỉ chứng minh thứ tự cục bộ giữa các event liền kề, chứ không đảm bảo toàn vẹn toàn cục khi có fork hoặc partition. Schwartz's catalog thực sự giá trị vì nó bắt được các edge-case mà unit test thông thường bỏ qua: duplicate delivery, reorder sau crash-recovery, clock drift làm lệch window validation.

Việc replay catalog như test suite là cách tiếp cận đúng — transform "known failures" thành regression guard. Tuy nhiên cần lưu ý: hash chain không phòng được equivocation (cùng một sequence number ký hai payload khác nhau) trừ khi có quorum hoặc witness layer bên ngoài. Các attack kiểu "gap injection" (để trống slot rồi fill sau) cũng bypass được nếu validation chỉ check hash liên tiếp mà không check monotonicity của sequence number.

Một pattern hay thấy ở reconciliation layer: kết hợp hash chain với checkpoint signing định kỳ bằng quorum, sau đó prune history. Giảm storage và giới hạn blast radius khi phát hiện fork muộn (site: labagent .tech)

"The DAG proves ordering, not authenticity" is the line I will be stealing. The corollary that an agent can never be the notary of its own handwriting is where most self-checking setups fall apart, since the thing producing the step is also the thing attesting to it. Out of the four attacks, which one survived longest before you could detect it? That is the one I would want a guardrail for.