Yes, and the programs that refuse to are the ones that fail.
If there is no sanctioned way to say “this rule does not fit here,” teams do not comply — they route around you. They stop running the linter, they add a blanket ignore at the top of the file, or they quietly stop sending their specs through the pipeline at all. You do not get compliance by removing the exit; you get invisibility, which is worse than a documented exception because now you cannot even count it.
What separates a healthy exception from a hole is three properties.
Sanctioned. Somebody with the authority to say yes said yes, on the record. An inline ignore comment that any developer can add unilaterally is not an exception, it is an opt-out. The request and the approval should both be artifacts you can find later.
Owned. An exception has a name attached — a person or a team who holds it and who gets asked about it. Unowned exceptions accumulate until nobody can tell you why any of them exist, and at that point the ruleset is decorative.
Expiring. This is the one people skip and it is the one that matters most. Every exception carries a date. When it lapses it comes back for renewal, and renewal is a real conversation rather than a rubber stamp. Without an expiry you have not granted an exception, you have silently amended the rule for that team forever — and you will not find out until someone audits the ruleset and discovers half the estate is exempt.
The useful reframe is that a pile of exceptions is data, not failure. If forty teams have all filed an exception against the same rule, the rule is wrong, or it is right but unachievable given how those teams actually work. Either way the exceptions told you something the compliance percentage never would. Treat the exception register as feedback on the ruleset, review it on a cadence, and let it drive which rules you fix, relax, or retire.
