The exception that made sense once and confuses everyone now

Every business has at least one of these: a customer who's had non-standard terms for years, a product priced oddly against its category, a supplier who skips a step everyone else has to follow. Ask why, and the answer is a shrug. It's just how it's always been.

The uncomfortable part isn't that the exception exists. It's that nobody can currently tell the difference between an exception that's still earning its place and one that's just inertia wearing the costume of a decision.

Exceptions start out completely reasonable

Almost nothing is granted arbitrarily. The customer got extended terms because they were a founding client who took a risk on the business early. The product is priced oddly because it was positioned against a competitor that no longer exists. The supplier skips a step because they proved reliable enough, over years, that the step stopped being necessary.

Every one of these was a defensible judgement call at the time it was made. The problem isn't the decision. It's that the decision doesn't decay gracefully — it just sits there, unchanged, long after the circumstances that justified it have moved on.

Why the reasoning disappears faster than the exception does

The exception is encoded in the system — a term, a price, a flag. It persists automatically, forever, with zero maintenance. The reasoning behind it lives in someone's memory, which does require maintenance, and gets none. The person who approved it moves to a new role. A colleague who remembers the story leaves the company. Within a few years, the exception is exactly as active as the day it was created, and the explanation is completely gone.

This produces a strange asymmetry: the least-examined parts of a business are often its oldest exceptions, precisely because they've been running fine for so long that nobody has had a reason to look.

Why "it's always been this way" is a warning sign, not an answer

That phrase means one of two very different things, and there's no way to tell which from the phrase alone. Either the original reasoning is sound and simply hasn't been restated recently, or the original reasoning expired years ago and the exception has been running on pure momentum ever since. Both produce the identical phrase from the same person's mouth, and only one of them is actually fine.

That ambiguity is the real cost. It's not that old exceptions are necessarily wrong — many of them are still exactly right. It's that nobody can currently tell which ones are which, and that uncertainty is itself a risk, whether or not any individual exception turns out to be a problem.

Making exceptions self-explaining

Attach an expiry or review date to every exception granted, not because it should necessarily end, but because a scheduled check forces someone to re-confirm the reasoning still holds, rather than letting it run indefinitely on autopilot.

Record the reasoning at the moment the exception is granted, in plain language, attached to the exception itself — see configuration without a reason attached. "Founding client, took an early risk on us" is a complete, durable answer. A shrug three years later is not.

Periodically list every active exception and ask, out loud, whether each one still earns its place. This doesn't need to be frequent — annually is often enough — but it needs to actually happen, because nothing about the system will prompt it on its own.

What to do this week

List the exceptions currently running in your business that nobody has questioned in over a year. For each one, ask whoever's closest to it: do you know why this exists? If the answer comes easily, you're fine. If it doesn't, you've just found the ones worth reviewing before the reasoning disappears entirely.

Common questions

Why do old exceptions become hard to explain over time?

Because the exception itself persists automatically in the system with no maintenance required, while the reasoning behind it lives only in someone's memory, which erodes as people change roles or leave the company. The exception and its explanation age at completely different rates.

Is an unexplained exception necessarily wrong?

No. Many long-standing exceptions are still entirely justified — the problem is that nobody can currently tell which ones are and which aren't, and that uncertainty is itself a risk worth addressing regardless of any individual exception's merits.

How often should exceptions be reviewed?

Annually is usually sufficient for most businesses — frequent enough to catch reasoning that's genuinely gone stale, infrequent enough not to become its own burden. The key is that it happens on a schedule, since nothing about an exception prompts its own review automatically.

What's the simplest way to make an exception self-explaining?

Record the reasoning in plain language at the moment the exception is granted, attached to the exception itself rather than in a separate document. A short, specific note made at the time is far more durable than relying on someone's memory years later.

Related: configuration without a reason attached · what a system of record cannot do · transactions are not decisions