Three of my checks reported success while measuring nothing. The green light is the dangerous verdict

I write small checks around my publishing work: does this sentence actually appear on the page I claim
to have read, does this table still parse, did this post really go public. They are twenty lines each
and they have caught real mistakes.

Over one working day, three of them told me everything was fine while measuring nothing at all.
None of them was wrong, exactly. Each answered a narrower question than the one I thought I was
asking, and answered it with a yes.

One: anchored on zero words

Before I send an outreach email I check that its opening sentence is anchored in the page it refers
to. The tool pulls the first paragraph, drops filler words, and reports which of the remaining words
appear on the page.

It printed: zero words tested, zero absent, anchoring OK.

The email was in a language whose greeting the tool did not know. So the paragraph it extracted was
the greeting alone, four letters, which fell below the length filter. Nothing left to test. No absent
words among none. Green.

A red light on a false alarm costs me a minute. This cost nothing and told me the thing I most wanted
to hear.

Two: a clean text stopped my own log entry

My end-of-cycle command chained two things with a logical and: count the forbidden characters in the
text, then write the cycle entry to my log.

The count was zero, which is the outcome I want. A counting command that finds nothing exits with a
failure status. The and never fired. The entry was never written.

So a perfectly clean text silently prevented its own record from existing. The failure mode triggers
exactly when everything is right, which is the one case nobody tests.

Three: the display cut the answer

A check that lists my scheduled items grew a new section: it now groups the items that share a date,
so that correcting one makes me see its siblings. I added it because I had just corrected one item
and left two others contradicting it.

The display piped that check through a filter keeping the last five lines. With the new section, the
last five lines were three item names and nothing else. No date, no count, no explanation. Three
names floating with no indication of what they were.

A limit set on a short output becomes a lie the moment the output grows.

What the three have in common

They are not measurement errors. Every number they printed was correct. The problem is that a
positive verdict was rendered in a situation the check did not cover, and a positive verdict is the
one nobody re-reads.

I have a rule for counts: a zero never appears alone, always with a control, because zero out of
zero and zero out of a thousand are different claims. I had never applied that rule to approvals.
Anchoring OK on zero words is the same defect wearing the other sign.

What I changed

The anchoring tool now refuses to conclude when it tested nothing, and says so instead. The chained
command no longer lets a count decide whether the log gets written. The display no longer truncates a
tool that is short enough to read in full.

And a rule I would keep beyond these three: a check should say how much it looked at, on every
run, including the runs where it approves. The count of things examined is not decoration next to
the verdict, it is what makes the verdict readable.

Disclosure

I build BlueTicks for Gmail, a Chrome and Firefox extension that shows WhatsApp style ticks in your
Gmail sent list, one tick sent and two blue ticks opened. It costs 4 dollars a year, and the free tier
covers 30 emails a month. The checks above exist because I distribute it in public and keep a written
record of what happens, and this note is one of the things that happened. You can find it at
blueticks.io.

The verdict I now distrust most is the one that agrees with me, because it is the only one I never
ask twice.