Two things happen to code that runs constantly, and neither of them is anybody’s job. The first is that it gets examined — it turns up in profiles, its logs get read during unrelated investigations, its behavior ends up in someone’s head where it can be recalled under pressure. The second is that it gets repaired — every execution is an assertion against the current environment, so when a hostname stops resolving or a permission tightens, the disagreement surfaces immediately as an incident that someone fixes. Attention and repair, both delivered continuously, both free, both invisible on any plan.

Put them together and the shared cause becomes obvious: it isn’t correctness that maintains hot code, and it isn’t care. It’s frequency. Execution is the mechanism. Everything that keeps the common path healthy is downstream of the fact that it keeps running, and none of it transfers to code that doesn’t. That’s the whole thing — the under-examination and the decay aren’t two problems, they’re one property observed from two sides.

The consequence is a category error worth correcting. We treat readiness as a stock: something a system accumulates by having the right code, the right runbooks, the right redundancy in place, drawn down when needed. But if execution is what confers readiness, readiness is a flow — a property of a relationship that has to be continuously re-established, not a substance that sits in the repository between uses. A backup you have never restored is not a backup. It’s a belief about a file, and the belief is aging.

This reframes what preparation should look like. A great deal of reliability work is stock-shaped: writing the failover, documenting the procedure, adding the redundant replica, reviewing the incident plan. All of it is necessary and none of it is sufficient, because it produces artifacts rather than contact. The flow-shaped version costs more and looks less impressive: restore the backup on a schedule from the real artifact, cut over to the replica during a normal deploy, let the page actually page someone at three in the afternoon and see who answers. What that buys isn’t confidence in a document. It’s the same free attention and free repair that the common path has been getting all along, purchased deliberately for the parts of the system that don’t earn it naturally.

Which gives you one question that cuts through most reliability discussions, and it isn’t whether something is correct or well-designed or covered by tests. It’s when did this last actually run, end to end, against the real world? If the answer is a date, the confidence should decay from that date. If the answer is “at authorship” or “in staging, against a mock,” then what you have is a hypothesis with good formatting. And if the answer is that nobody knows, that’s the answer — you’ve found the part of the system whose readiness is a matter of faith.

There’s no version of this where you get to stop. Readiness can’t be banked, because the world it’s readiness for keeps moving, and the only thing that ever checks is running. The systems that hold up aren’t the ones that prepared hardest at some point in the past; they’re the ones that kept touching reality on purpose, in the places where reality had stopped touching back.