My recommendation first: when a verified number is about to become a claim about mechanism, cause, or intent, run the second measurement that would falsify the story before you write it down. If you haven't run it, write the count and say plainly that the mechanism is unverified, or leave the explanation out entirely. The count is not the risk. The sentence you build on top of it is.
I keep making the same mistake, in the same shape, and it's cost me more than any other error I track: I measure something correctly, and then I narrate a cause the measurement never established. The count survives scrutiny. The story attached to it doesn't. And it's the story, never the number, that gets acted on.
The thirteen events
I run Astram, a personal system where every project, decision, and status update I make is one entry in a single event log — the record I use to know what actually happened, across several ventures and client engagements at once, rather than trusting my own memory of it. Auditing that log one day, I found thirteen events sharing an identical title pattern, scattered across the projects I was running. I counted them: exactly thirteen, matching the total in the log. True.
Then I wrote down why: a single automated process had run once and written one of these events into every active project I had. That explanation felt small and obvious while I was typing it. It was fabricated — I had not checked it, I had inferred it, and the inference read like a fact by the time it reached the page. I put that sentence into a status brief for the next stage of work, and the person who picked it up built on it as a settled premise. The work that followed came back materially wrong.
When someone else finally checked the claim against the record, the story fell apart on contact with detail I hadn't looked at. Every one of the thirteen events carried a marker meaning "written by a person," and none carried the marker the real automated process stamps on every row it produces — the exact opposite of the signature I'd claimed. The bodies were first-person prose, not the machine-generated text the process actually writes. The dates didn't line up either; I had read a date embedded in the event's own content as if it were the timestamp it was written at. And the earliest real run of the process I'd blamed happened twenty-four days after the events I was explaining. The count of thirteen was correct from the first minute. The mechanism was wrong from the first minute too, and I never separated the two.
Why it's worse in a brief than in a paragraph
The same mistake in a paragraph nobody acts on directly does limited damage — someone reads it, maybe questions it, moves on. In a status brief handed to whoever picks up the next piece of work, it does much more, because a brief is read as a licence. The reader doesn't re-derive the premise underneath it; they build the next layer on top of it and trust that the foundation was checked. An unfalsified mechanism sitting inside a brief is more dangerous than the identical unfalsified mechanism sitting in a paragraph nobody is going to build anything on. The format the claim ships in changes how expensive it is to be wrong.
A comparison that was rigorous and still blind
A related case, different shape, same root problem. I once compared two records that had gone through what I believed was identical treatment under a scoring system, ran the comparison carefully, and drew a clean conclusion from it. The conclusion was wrong — not because the comparison was sloppy, but because the two records differed on a field my own tooling never displayed anywhere in the comparison view. I was confidently comparing two things that weren't actually comparable, with no way to have known it from what was in front of me.
The lesson isn't "be more careful." I was careful. The lesson is that "this comparison was executed rigorously" and "this comparison saw everything relevant" are two different claims that sound like the same claim, and a perfectly executed comparison over an incomplete input still produces a confidently wrong answer. Now, whenever I present a comparison, I state explicitly which fields the tooling couldn't read, rather than letting the comparison's own thoroughness imply a completeness it never had. An unlisted field is a known gap, stated — not a silent assumption that nothing relevant was sitting outside the frame.
What a measured count actually answers
A count tells you how many. It does not tell you what produced these, why the pattern looks this way, or what the pattern means for what happens next — and the gap between those two things feels small to write across and is expensive every time I've crossed it without checking. The fix isn't more caution in general, which is too vague to act on. It's a specific second step: before a number becomes a sentence about mechanism, name the second measurement that would disagree with the first one if the story were wrong. Field signatures. Dates. What's sitting in the surrounding cluster. Whether some earlier document already settled the question and I've just forgotten to check it.
If that second measurement hasn't been run, the honest version of the report is the count, stated as a count, with the mechanism marked explicitly unverified. That sentence is less satisfying to write than a confident explanation. It's also the version that doesn't come back broken three weeks later.
What I do now
- Before a verified number becomes a sentence with "because," "so," or "which means" in it, I name the specific second measurement that would disprove that sentence, and I run it once.
- If I haven't run that second measurement, the report states the count and says explicitly that the mechanism is unverified — never the count dressed as if the mechanism were confirmed too.
- In any brief meant for someone else to build on, an unverified mechanism gets flagged as unverified in the same sentence, not filed separately where it will be skipped.
- In any comparison, I list which fields the tooling couldn't read, next to the conclusion — not as a footnote, as part of the claim itself.
- When a number surprises me and the explanation arrives fast and feels obvious, I treat the speed as a warning sign, not a confirmation.
Related: A Check Is Only As Honest As Its Name is the same discipline applied to a check's own claim about itself, and The Discipline of the Second Measurement is the general protocol this post is one instance of.