The Old Number That Still Looked Like a Fact

A single paragraph near the bottom of a routine planning document turned out to be wrong, and it took under four hours for someone to catch it.

The document itself was ordinary and useful: a reference for restarting a handful of production systems safely, the kind of thing meant to save whoever’s on call at four in the morning from having to work everything out from scratch under pressure. It had an honest “known gaps” section, listing what hadn’t been personally verified yet. One system had been checked directly. The other two hadn’t, so for those, the document leaned on what was already known: an audit figure from months earlier, and a prediction built on top of it that one of them likely carried the biggest backlog of pending work, so its first restart should be treated as the risky one.

A fact that was months old

That prediction got written down as settled fact, because it read like one. In reality it was a guess dressed up in an old number’s clothes, and it didn’t feel like a guess while writing it, because the reasoning behind it was “the audit said so.” Nobody stopped to ask whether the audit was still true by the time it mattered.

The correction

A reviewer looking over the same material caught it: that system had actually been restarted recently, not months ago. Rather than argue from memory, the live system got checked directly. The real number came back at about six days, not the months-old figure the document had quoted, confirming a genuine full restart had already happened.

That flipped the entire picture the document had painted. The system that had been written off as already handled turned out to be the real outlier, sitting on weeks of accumulated backlog with nothing addressed. The one flagged as the risky one had, in fact, already gone through a clean restart with nothing pending at all.

The section got rewritten the same day. The stale prediction came out, replaced by the verified number and an honest open question that hadn’t been asked before: since these are systems someone else also has a hand in maintaining, nothing on record said whether that recent restart was something done intentionally or something that happened as part of routine outside maintenance. That distinction matters for what the right next move even is, and it went into the document as a question, not a guess dressed as an answer.

What actually went wrong

Nobody supplied bad information here. The original audit was accurate at the moment it was taken. What went wrong is treating “this was true when measured” as the same thing as “this is true now,” and the distance between those two turned out to be months long. A number sitting in a document carries no visible timestamp for how stale it’s allowed to get before someone stops trusting it. It reads exactly the same whether it was checked this morning or half a year ago, and the only way to tell the difference is to go check the actual thing, not to reread the document more carefully.

The document is more useful now for a reason that has nothing to do with formatting. It states plainly which numbers are current and says out loud exactly what nobody actually knows yet. A gap admitted in writing is a smaller problem than a guess presented as settled fact, and the second kind is the one that puts someone in front of the wrong system at four in the morning, budgeting for a risk that already moved somewhere else.

dxdev LESSON · paste into your AI coding agent
LESSON: A written number carries no visible expiration date, so check it before it drives a real decision
SOURCE: dxdev.com/blog/2026-07-26_the-number-i-wrote-down-was-already-wrong
WHAT HAPPENED: A maintenance reference document for a small set of production systems carried forward a months-old audit figure for one of them and used it to predict that system would be the riskiest one to restart first. A reviewer pointed out the underlying system had actually been restarted recently. Checking it directly instead of arguing from memory showed it had only been up a matter of days, meaning the entire risk prediction was backwards: the system flagged as safe was actually the one carrying the real backlog, and the one flagged as risky had already been fully restarted with nothing pending.
THE RULE: An old measurement copied into a new document carries no visible expiration date. It reads exactly as true as a number checked minutes ago. Before a number drives a real decision, especially one that names which of several similar things is the riskiest, re-verify it against the live system it describes rather than trusting the document that quoted it last.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any operational document carrying a specific number (a count, an age, a size) that traces back to a measurement more than a few weeks old, with no re-verify date attached.
  2. Any "known risks" or "known gaps" section that predicts which of several similar systems is the risky one, based on a number that wasn't re-checked when the document was written.
  3. Any document a team will actually plan a live action around that has never been re-verified against the current state of what it describes.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.