Somewhere in every long-lived engineering organization there is a rule that no current employee can explain. Deploys are frozen on Thursdays. Changes to one particular directory need a second approver from a team that no longer owns it. A migration checklist has a step that copies a file to a path nothing reads. Ask why and you get the same answer in three different phrasings: that’s just how we do it, someone got burned once, I inherited it. The rule is enforced with complete consistency and defended with nothing at all.

It didn’t start that way. Every one of those rules was, at the moment it was written, the compressed conclusion of something specific and expensive — an outage, a data loss, a customer call that went badly. The person who wrote it had the whole story in their head, and the rule was a pointer to it. What got written down was the conclusion, because the conclusion is the part that’s actionable and the story is the part that seems like context. Then the person who held the story changed teams, and the pointer was left addressing memory that had been freed.

What’s left behind is a rule that has become impossible to evaluate, and impossible in a specific and asymmetric way. Its cost is perfectly visible: every engineer who hits it pays in friction, every week, and can tell you exactly what it cost them this time. Its benefit is a category of incident that hasn’t happened, experienced by nobody, measured by no one, and indistinguishable from an incident that was never going to happen anyway. So the argument against the rule is always concrete and the argument for it is always a shrug, and the only thing keeping it alive is that nobody wants to be the person who removed it the month before the thing it prevented comes back.

That asymmetry does something predictable to the shape of the ruleset over time: it can grow but it cannot shrink. Adding a rule after an incident is cheap, obvious, and looks like accountability — it’s the thing you can put in the postmortem’s action items and close. Removing one requires a claim about a counterfactual, made by someone with no story to back it, against a downside that would land on them personally. So the rules accumulate the way sediment does, each layer laid down by a real event, none of them ever removed, and a decade in you have a process that is a complete and accurate record of everything that ever went wrong and a very poor description of what anyone should actually do today.

The cheap intervention is not to be braver about deleting rules. It’s to write the story next to the rule when you write the rule, when the story is still free. One sentence naming the incident, the date, and the condition that made it possible — “added after the March incident, because the old deploy tool didn’t verify schema version” — turns an unremovable rule into a testable one. Anyone can now check whether the deploy tool still fails to verify schema version, and if it doesn’t, the rule has a defensible end. Without that sentence, the same check requires an archaeology project that nobody will ever be assigned.

The test for whether a rule is still a rule or has become a ritual is simple, and worth running out loud in a room: can anyone here tell the story? Not justify the rule in the abstract — plenty of rules can be justified in the abstract after the fact, which is exactly the problem — but say what happened that caused someone to write it down. If nobody can, you haven’t necessarily found a rule to delete. You’ve found one you’re following on faith, and you should at least know which of your rules those are.