Issue 6: The Vacuous Green: Why Your Checks Pass When They Never Ran
The Vacuous Green
Why your checks pass when they never ran.
The Tape
The surface motion (this week): Eval harnesses. Agent observability. Context engineering. Second-brain retrieval. "We have 100% coverage of our agent."
Everyone is shipping dashboards that go green.
The moving conversation is how much you can measure.
Underneath (the computable part): A check that did not run and a check that ran and found nothing are observationally identical unless you design them apart.
This is the inspection game, formalized by Avenhaus, von Stengel and Zamir in "Inspection Games," Handbook of Game Theory Vol. 3 (eds. Aumann and Hart), North-Holland/Elsevier, 2002. An even earlier ancestor is the RAND game-theory programme of Melvin Dresher, whose Games of Strategy: Theory and Applications (Prentice-Hall, 1961) develops the mixed-strategy equilibria this rests on. Its equilibrium is well-characterised: when non-inspection is cheap and undetectable, the inspected party's best response is to defect exactly where inspection does not reach.
The formal name for the failure is a vacuous truth: the statement for all x in the empty set, P(x) is true for every predicate P, regardless of what P says. An assertion over an empty collection is true by definition. A guard pointed at a directory that does not exist finds no drift. It passes.
Absence of a finding is not a finding of absence. Everyone knows this sentence. Almost nobody encodes it.
The Read
The saturated topic is memory and context engineering. The topic nobody will write about until next quarter is what happens when your verification layer silently stops verifying, which is what happens to every agent stack the moment the eval suite outgrows the person who wrote it.
We get to it first. We also get to it with data nobody else has.
The Studio's Worked Examples
In seven days the studio produced six failures. All one shape. All inside records marked VERIFIED:
1. Silent placeholder render (LP-529/G7): Issue 4 shipped live to paying subscribers with five image placeholders rendered as literal body text. The publisher printed a success message. The success message described an API call, not what a reader saw. The guard existed; it never asked the question. [Ref: projects/bernard-newsletter/regression-guards/g7-publisher-no-artefact-leak.sh]
2. Stale verification bind (LP-530/G8): A verdict: PASS gate bound to SHA 9fec5e04... while the draft had moved to 96b0b45f.... The PASS was true about a file that no longer existed. Nobody noticed until the hash itself was checked, not the memory. [Ref: projects/bernard-newsletter/regression-guards/g8-verification-record-hash-bound.sh]
3. Hard-coded comparison target (LP-530/G9): A parity guard compared the vault against a path hard-coded as $HOME/bernard-vault. The vault actually lives at /mnt/c/Users/.../Documents/bernard-vault/. The guard iterated zero files and printed PASS. Written one line differently, it would have called diff twice and reported the actual divergence. [Ref: projects/bernard-newsletter/regression-guards/g9-publish-path-runtime-vault-parity.sh]
4. Missing script at runtime: newsletter-publish-ready-flip.py existed only in the vault mirror, never at the runtime path where the Wednesday cron would look for it. The Wednesday job died on missing file. Under "silence ships" (RULE 85), a dead cron that prints nothing is not an error; it is an issue that never appears in logs. [Ref: LP-530]
5. Chain with no first event (LP-527): The pipeline's own event watcher asked "did the previous stage fire?" Nobody asked "does next week's issue exist?" An issue six days from publication did not exist. A chain with no first event is indistinguishable from a healthy chain at rest. [Ref: research/learnings/LP-527-absence-assertion-has-no-code-gate.md]
6. Crashed checker, silent PASS (LP-530): A self-healer treated a crashed invariant checker (exit 127, command not found) as "0 late stages, all clear." The checker never ran. The exit code was not examined. [Ref: projects/bernard-newsletter/regression-guards/g22-wednesday-readiness.sh]
The Mechanism
Formalise the distinction between three states that every monitoring system collapses into one display: green.
GREEN-VERIFIED: The assertion executed against a non-empty, concrete referent. The check looked. The check ran. The check held.
GREEN-VACUOUS: The assertion executed against an empty referent or one that does not exist. True by default. Worthless as evidence. An assertion over an empty set is always true, regardless of what it claims.
GREEN-UNRUN: The assertion never executed. The checker crashed, was skipped, or was never wired. The exit code is unknown or discarded.
A check is only evidence if GREEN-VACUOUS and GREEN-UNRUN are mechanically separable from GREEN-VERIFIED. The monitoring regime must report what it looked at, not merely what it found. Because when non-inspection is indistinguishable from clean inspection, the equilibrium is no inspection at all.
This is mutation testing territory. A test suite that survives every mutant is a suite that asserts nothing. A guard that returns green because it looked nowhere is a guard that guards nothing.