UNOFFICIAL/EXPERIMENTAL. This page belongs to the AICR catalog overview. Every other AICR page describes something the catalog proved. This one describes what the catalog turns down, which is the half of a governance claim that usually goes unrecorded.
npm run aicr-refusal-corpus:verifyA refusal is evidence, and it was being thrown away
When one of those lanes goes red in practice, the refusal appears as a failure, gets fixed, and disappears. The one artifact that would tell an auditor the guard works is the one nobody keeps.
The refusal corpus keeps it. It is a set of changes a contributor could plausibly propose, each declared with the verdict the lanes must return. Every candidate is applied to a throwaway worktree of the commit under test and run through the shipped commands, unmodified. The receipt records that commit, because a run describes the tree it ran against. The verdicts are published at data/aicr-refusal-corpus/summary.md and recorded in the receipt.
Two candidates have to be accepted
A set of lanes that refused every change would produce the same seven refusals as a set that refused the right ones. The corpus therefore carries an unchanged tree and an edit to prose outside every retained scope, and the evaluator refuses a corpus in which nothing is expected to pass.
That is the whole reason to write the accepted cases down. They are what separates a guard from a wall.
The interesting result is which lane stayed quiet
Every candidate runs through all six lanes rather than only the one that owns it, so the record shows the shape of the coverage rather than a single verdict. Retained-byte parity guards the widest surface and catches five of the seven refused candidates on its own. The two it misses are the ones that matter most.
A contributor who retains an upstream document carrying a literal NGC key, and records its checksum correctly, has done nothing a checksum can detect. The retention is internally consistent. Only the credential rule stands between that and a key in a public repository, and the corpus is where that rule is shown working rather than asserted.
The same holds for the two files the upstream signature is bound to. Editing one leaves every digest index intact, because those files are not part of any entry's rendered surface. The binding check is the only thing that notices.
Regenerating does not launder an edit
One candidate exists because it is the obvious next move when a lane goes red. A contributor edits a retained Application, sees the digest index refuse it, and runs the generator to bring the index back in line.
The generator refuses the same drift the verifier refuses. Retention checksums record what upstream published, so they are not a derived artifact that a regeneration may overwrite. Recording that as a candidate makes it a property the catalog keeps rather than a detail of how the generator happens to be written today.
What this proves and what it does not
It proves the shipped commands refuse these shapes today, and that they accept changes outside the surfaces they claim to guard. It does not prove the corpus is complete. A shape nobody thought to propose is not covered, and the honest reading of a green run is that the listed rules hold rather than that the entries are unbreakable.
Every rule the corpus declares has a candidate behind it, and the loader refuses a corpus where a rule has none, so the coverage table cannot quietly go empty as rules are added.
Everything runs offline against committed configuration bytes. No cluster, no organization, and no network takes part, no GPU workload is claimed anywhere in this corpus, and no credential named in it is real.