A monitoring runbook's own numbers were stale prose, not live truth

None of these mismatches were dangerous on their own. A runbook saying seven dashboards when there are fifteen costs nobody anything directly; it is simply a sentence written when the count was seven, which nobody had reason to revisit as integrations were added one at a time. The design document describing a dead-man’s-switch response time as about ten minutes was similarly innocent. Ten minutes was the target, and the measured value of just over thirteen lived in a different document written by a different pass.

The pattern is what makes it worth recording. Every number in operational documentation is one of two kinds. Some describe a fixed design decision, and those stay true until the decision changes. The rest describe the current state of a living system, and those have a shelf life, which is invisible to the reader unless the number carries a date. A reader has no way to tell from the page whether seven dashboards is this morning’s count or last spring’s.

Two practices came out of the audit. Every operational number now carries the date it was measured, so the reader can decide for themselves whether to trust it. And where a count can be recomputed, the runbook prefers a command the reader can run over a figure someone typed once, because a command cannot go stale.

The transferable form is simple enough to adopt today. Treat any undated operational number in your own documentation as a claim rather than a fact, and prefer numbers a reader can recompute over numbers someone remembered.