Two things are true of almost every mature engineering organization, and they only look like separate problems.

The first: the written ruleset can grow but it cannot shrink. Adding a rule after an incident is cheap, visible, and looks like accountability. Removing one requires arguing that a bad thing won’t happen, against a downside that would land personally on whoever made the argument. So rules accumulate, and the stories that justified them evaporate as their authors move on.

The second: when a rule gets too expensive, nobody repeals it. They get an exception. That’s the cheaper move — one quiet ask to one person with the authority to say yes, no debate, no record. The rule stays on the books at full strength while the actual behavior routes around it, case by case.

Put them together and you get the thing nobody designed. The written policy is a ratchet that only tightens. The waiver path is the only release valve. And the organization’s actual operating policy isn’t either one — it’s the difference between them. It’s the set of rules that are enforced minus the set of asks that get approved, and that difference exists nowhere in writing. It lives in a handbook that overstates what’s required and in one person’s memory of what they’ve been letting through.

This is why “what’s our policy on X” is such a strangely hard question to answer honestly. The handbook answer is technically correct and practically wrong — it describes what happens to people who don’t know who to ask. The real answer requires knowing both halves: what’s written, and what actually gets waived. Almost nobody has both. New hires get the first half and learn the second half socially, over months, by watching what senior people do. That informal transfer is the actual onboarding, and it’s invisible in every process document you have.

The diff also explains why process reform keeps failing. A team decides the rules are too heavy and launches an effort to simplify. They audit the written ruleset, find the rules that look obsolete, and propose deletions. But the written ruleset was never the binding constraint — the parts that were genuinely too expensive have already been quietly neutralized by waivers, and the parts still hurting are the ones nobody thought to ask about. You end up deleting rules that were already dead and keeping the ones that are actually costing you. The audit examined the wrong artifact.

What makes this tractable isn’t a better policy document. It’s making both halves legible at the same cost. Rules get a one-line provenance note — the incident, the date, the condition that made it necessary — written while the story is still free. Exceptions get a one-line log — who asked, what would have blocked them, why this case was different. Neither is a process; both are a habit that costs about thirty seconds at the moment it’s cheapest.

Do both for a quarter and the diff stops being folklore. You can lay the two lists side by side and read your actual policy off the page. A rule waived eleven times for the same reason isn’t a rule, it’s a tax on people who don’t know the shortcut — fix it or delete it. A rule never waived and never explained is either load-bearing or vestigial, and now you can ask which. A rule whose provenance condition stopped being true two years ago can be removed with an argument instead of a shrug.

The goal isn’t fewer rules. It’s knowing which ones you’re actually running. Right now most organizations can produce a document describing what they wish they did and one person who knows what they really do, and those two facts have never been in the same room.