Red gets attention. It's loud, it blocks the merge, somebody looks at it. Green gets a glance and a merge.
In one working session on 2026-08-26 I went looking for false greens in my own project and found six. Three of them were the checker itself, quietly returning zero and calling that a pass. I'm writing them down because the shapes repeat, and because none of them look like bugs while you're reading the code.
Shape one: the checker that found nothing because it looked in the wrong place
A scanner split records on a delimiter it had assumed rather than measured. The real records used a different one. So the scan produced one enormous record, matched nothing inside it, and reported zero findings. Zero findings prints exactly like a clean repository.
That's the first shape, and the tell is that the result was zero rather than small. A detector that returns a handful of hits is doing something. A detector that returns exactly zero on a large input is either right or asleep, and you can't tell which from the output alone.
Shape two: vacuous equality
A comparison asserted that two files were byte-identical. They were, in the sense that both of them did not exist. The read returned empty on both sides, empty equalled empty, the assertion passed, and the check had never touched the artifacts it was named after.
Any comparison that can succeed on absent inputs will eventually succeed on absent inputs. The cheap fix is an existence assertion before the equality one, which is embarrassingly obvious in retrospect and was not there.
Shape three: the pattern that couldn't reach the thing it was matching
A regular expression looked for a field in a JSON payload. The payload escaped the field's path. The pattern never fired, not because the field was absent, but because the shape it was written against wasn't the shape on the wire. Same output as shape one: zero, therefore clean, therefore green.
Shape four: the threshold that was never the answer
Separately, on 2026-08-29, an audit probe was misclassifying. I tightened it and it misreported 18 of 65 items. Loosening it made it under-report instead. There was no setting that got both sides right, which is usually a sign that the problem isn't the setting.
It wasn't. The probe had two outcomes where the situation had three. Things that failed, things that passed, and things that couldn't be examined at all had to land in one of two buckets, and "couldn't examine" got folded into "failed". That's a measurement failure being reported as a property of the thing measured, and the tool doing it was the audit tooling for a project whose entire first principle is that unevaluable is not the same as denied. I broke my own rule inside the instrument built to enforce it.
Shape five: a valid signature over an empty claim
This one is my favourite, in the way a hangover is memorable. A receipt verified. Signature good, structure good, verdict recorded. Its read set was empty.
The read set is the field that says which state the change was derived from, so an empty one means the record is intact and says nothing about attribution. Cryptographic validity was never the claim I needed. It was the claim I checked, because it's the one that has a function call attached to it.
Shape six: silence that reads like good news
Continuous integration on this project has run zero jobs on any push since 2026-08-15T17:25:29Z. That's thirteen days and 2,245 commits with no machine signal at all, and the cause was billing, not code. The runs that show as failed report two to five seconds of "duration", which is the scheduler refusing the job before it was ever assigned. There's no log for any of them because none of them ran.
The dashboard was not lying, exactly. It just had no vocabulary for "this never started", so it drew the same shape it draws for "this ran and failed". Meanwhile the absence of new failures felt, day to day, like an absence of new problems.
What I actually changed
Four things, and only the first two are interesting.
Every gate now ships with a negative control: an input that must make it go red, run alongside the input that makes it go green. If the red case doesn't go red, the green case means nothing. This costs about ten lines per gate and it caught two of the six above on the day I added it.
Detectors that can return zero now run a second, deliberately redundant pattern over the same input, written against a different assumption about the format. Agreement between two wrong assumptions is unlikely enough to be informative. Disagreement is the alert.
The other two: gate silence is now itself an alert rather than an absence, and the audit vocabulary got a third value so "couldn't examine" stops being spelled "failed".
The question worth asking about your own suite
Can it pass with zero assertions executed?
For a lot of test setups the honest answer is yes, and nothing in the output distinguishes that run from a real one. If you want to check, delete the body of the thing under test and run the suite. If it stays green, the suite was measuring its own existence.
I do this on a project that's about exactly this problem, which is either ironic or the reason I keep finding them. Code is at github.com/TraceFold/tracefold, Rust, Apache-2.0, and the limits page is longer than the feature list on purpose.
Not released. Correction 2026-09-01: the v0.1.0-alpha tag picked up a single Linux x86_64 tarball on 2026-08-31, built outside CI. Still nothing on crates.io, so "not released as a package" stays true; the bare two words above no longer are.
