A smoke alarm with a flat battery does not go quiet. It chirps. That chirp is the single best design decision in the device, because a silent dead alarm is indistinguishable from a working one on a day with no fire. Most software checks are silent dead alarms. They report success because nothing stopped them, and "nothing stopped me" is not the same as "I checked".
We have been bitten by this enough times in one summer to call it a position rather than a bug.
Three ways a check lies
The first is a check that stops running and still returns a failure code. Our security self-test has a long list of assertions before it reaches the part that actually probes the review lanes. One of those early assertions went stale after an unrelated rename. It aborted the whole suite, with its own loud "do not ship" banner. Everyone read the banner as a legitimate failure and moved on. For eight days, the lane probes underneath it never ran. It had happened once before, in July, for weeks. Same mechanism, different assertion.
The second is a flag that does nothing. One review lane was supposed to run with its tools switched off. The switch was set. The names in the switch did not match the tool names the program used, so the empty list matched nothing and the lane ran with every tool live. The test that should have caught this passed, because the model politely declined the bait. Model virtue is not a security control. The flag looked configured. That is the dangerous kind of wrong.
The third is a tool that reports done having done nothing. A database migration on one of our live systems exited clean. It had read a stale copy of the migration files left over from a previous run, found nothing new, and applied nothing. The exit code was zero. The schema was unchanged. The person watching the exit code had every reason to believe it was live.
A green result from a check that never ran is worse than no check at all, because it removes the reason to look.
The rule we hold now
Judge by effect, never by report. A scheduler that returns silently is not proven until a job it should have run leaves a mark. A lockdown is not proven until a probe that should trip does trip. A migration is not proven until the schema says the new version. And every absence-test needs a positive control: something that must fail, so that a run where nothing fails is inconclusive rather than clean.
We apply the same standard to our agents. An agent's own account of its work is a claim. The marker it was told to leave, the file it was told to write, the row it was told to change: those are evidence. When a worker's session died mid-task in August, we did not read its last message. We read the disk.
Why this is a position, not a tip
Because the instinct runs the other way. A green tick feels like a gift, and checking it feels like distrust. But a check exists to remove a reason to look, and a check that can pass without looking removes that reason fraudulently. We would rather have fewer checks that fail loudly when they cannot run than many that smile through a blackout.
We stay until it works. "Works" means the effect is there, not that the report said so.
For the technical reader
The self-test fix was structural: convert the pre-canary asserts from abort-on-fail to accumulate-and-continue, so a stale assert degrades one check instead of blindfolding every probe below it. The lockdown fix added a positive control that must trip, with the run reporting inconclusive on exit if it does not. The migration fix is a mandatory clean of the staging directory before copy, and verification against the migrations table rather than the tool's exit code. The absence-probe rule came from a scheduler that returned silent zero under one shell and had never been proven to run. In each case the artefact we now trust is one a lying process cannot produce.