Our checker did not catch the wrong number. It enforced it.
One number described your product. It appeared in five places with five different values. The tool built to prevent exactly this had spent months making it worse.
Five values for one fact
The number was how many tools our server offers. A simple, countable fact. It is generated from the code itself, so there is no room for opinion.
The generated truth said 122. Thirteen public pages said 126. The launch texts for Hacker News said 89. The marketing emails said 116. An internal strategy document said 140.
Every one of those was written by someone careful, at a moment when it was correct.
The part that should worry you
We had a checker for this. Its job is to reject any number in our copy that is not backed by a claims file.
The claims file itself said 126. So the checker did not merely miss the error. It flagged correct pages as unbacked and pushed people to change 122 into 126.
A checker with a wrong reference is worse than no checker. It carries authority, it is applied consistently, and it moves the whole codebase toward the mistake.
The root cause was small. A claim quoted a generated file and froze its value at the moment it was written. The generator moved on. The claim did not.
The rule that prevents it
Never store a value that something else derives. Store the reference to the deriver.
In practice: a claims file may say this number comes from that generated file. It must not say the number is 126. The moment it repeats the value, you have two sources and no way to tell which is older.
The test is easy. For every constant in your configuration and documentation, ask whether anything else computes the same thing. If yes, delete one of them. Not synchronise, delete.
The second copy nobody sees
There was a second finding underneath, and it is the more common one.
Two tools checked the same rule. One read its patterns from a shared configuration. The other had a copy of that list written by hand in its own source.
The shared configuration had six patterns. The hand-written copy had four. The two missing ones were exactly the patterns that would have caught our number.
So one tool reported the problem, and the tool running beside it reported all clear. Same question, two answers, and the friendlier answer is the one people quote.
Where to look in your own repository
Search for any number that also exists in a generated file, a database, or an API response. Every hit is a candidate.
Then look for lists of rules that appear twice: one in configuration, one in code. Linter patterns, allowed values, ignore lists. Compare the lengths. If they differ, you have already found it.
Finally check whether any tool can rewrite content to match a stored value. Those are the dangerous ones, because they do not just fail to catch the drift. They spread it.
What it cost
Twenty-three wrong statements across thirteen public pages, plus the marketing emails, which are the copy that actually reaches people.
The fix was 35 lines and touched only digits. No sentence was rewritten.
The expensive part was not the wrong number. It was the months in which a tool with authority quietly argued for it.
cachly is a persistent AI Brain for developers — memory shared across Claude Code, Cursor, GitHub Copilot & Windsurf simultaneously. Auto-detects every editor. Bootstraps from your git history. 122 MCP tools. Free tier, EU servers, no credit card.
Your AI is forgetting everything right now.
Every session starts blank. Every bug re-discovered. Every deploy procedure re-explained. cachly fixes that in 30 seconds — your AI remembers every lesson, every fix, every teammate's hard-won knowledge. Forever.