Originally published on hexisteme notes.
I write these essays with a lot of delegation.
I draft a brief describing what happened and what the essay should argue, hand it to a writer instance, and then hand the draft to an independent reviewer instance whose only job is to compare the draft against the source material I pointed it at.
That pipeline has worked well enough, often enough, that I mostly stopped worrying about it.
Then I wrote a brief with four confident factual claims in it, and all four turned out to be wrong — and the reviewer caught exactly two.
The essay in question was about a scheduled background job that silently failed while its own status output kept reporting green (a different story, told elsewhere — I won't retell it here).
What matters for this piece isn't the job or the bug.
It's the four sentences I put in the brief describing how bad the failure had been, and what happened when I went back and actually measured them.
Four claims, one brief, one blind spot Here's what I told the writer, and what the primary data said once I checked it properly.
What the brief said What the measurement actually showed Did the reviewer catch it?
It died every night The complete log file contained exactly one failure line, at one timestamp — one scheduling attempt, zero successes No The stale fallback data was weeks old The database row in question was timestamped the previous afternoon No One real run took a counter from 1 to 3 Two separate runs did that — a manual reproduction, then a direct invocation through the real launchd job (a manual kickstart, not a wait for the scheduled slot) Yes A unit test for the failing function passes No test file anywhere in the test directory even references that function Yes The writer copied all four claims faithfully into the draft.
That's the writer doing its job correctly — a writer's task is to turn a brief into prose, not to audit the brief.
The reviewer's job was different: compare the draft against the source document I'd pointed it at, and flag anything the draft says that the source doesn't support.
It reported four blockers.
Two of them were the claims in the table above marked "yes" — the ones where the source document actually described events differently than the brief claimed.
The other two blockers were things the reviewer found on its own, unrelated to my brief: a missing field in a code snippet, and a count of failing tests that was off by two.
All four of those catches were correct, and I fixed all four.
But notice what's missing.
The reviewer's four blockers and the brief's four wrong claims overlap in exactly two places.
The two claims about frequency and age — "every night," "weeks old" — sailed through untouched.
Not because the reviewer was careless.
Because the source document the reviewer was checking against never said how many times the job had failed, or how old that database row was.
It was silent on both counts.
And a draft that repeats a claim the source is silent about does not contradict the source.
It matches it — vacuously, but it matches.
Why a compare-to-source reviewer can't catch this A review built as "does the draft say anything the source doesn't support" is a refutation engine.
It's very good at catching claims the source actively disputes — dates that don't line up, a sequence of events told out of order, a fact the source states differently.
It has no leverage at all over claims the source simply never addresses, because there's nothing there to disagree with.
Silence isn't evidence against a claim; it's the absence of evidence either way.
A reviewer running a pure compare-to-source check treats absence of contradiction as a pass, which is the same thing as treating silence as agreement.
The part that makes this worth writing about is where the wrong claims came from.
Not the writer, who copied faithfully.
Not the reviewer, who compared faithfully.
Both of them received the same four claims from the same single document — the brief — and