Photo by Jonathan Phillips on Unsplash

Somewhere in every mature platform there exists an object no one will delete.

It could be a table, a view, a scheduled job, or a permission granted to a group that no longer matches any team on the org chart. It is probably not documented, and it is not standard. Several things depend on it, though no one is certain which things, and the last person who could have explained it has moved on. It survives because removing it requires knowing why it exists, and that knowledge left the building some time ago.

The object itself is rarely the problem. Whatever it is, it was almost certainly created for a good reason, by a competent person, under a real constraint, and it probably worked. It probably still does. The problem is not the thing itself, but the asymmetry between the two conversations attached to it.

The first conversation, the one that created it, took about eleven minutes. Someone described a problem. Someone proposed an exception to handle it. The tradeoff was obvious to everyone in the room, the deviation was clearly the right call, and the meeting moved on to the next item.

The second conversation, the one that tries to remove it, takes six weeks. It requires archaeology, dependency tracing, three people guessing at the original intent, and eventually a decision made under uncertainty by someone who was not present for the original eleven minutes and cannot recover them.

The cost nobody priced into the exception lives in the second conversation. Almost none of it was visible during the first.

Exceptions Are Not Failures

It is worth establishing the unfashionable premise before the argument, because most writing on this subject treats any deviation as a discipline problem.

A system with no exceptions is not a well-governed system. It is either a young one, a small one, or a dishonest one. Standards are written against the cases their authors could anticipate, and production environments supply cases no one ever expected. A source system that cannot be queried the approved way, or a one-off analysis that matters enormously for six weeks and not at all afterward; even a dataset that is genuinely useful for one project and equally not reusable for anything else.

The exception mechanism is how a standard survives contact with reality. Without it, a standard has only two available outcomes: it blocks work that needs to happen, or it gets ignored and stops being a standard at all. Organizations that pride themselves on having no exceptions usually have a great many, held informally, by people who have learned not to make them too visible.

So the objective is not fewer exceptions. Mature systems permit them. The objective is that the system remembers making them.

The Loan Nobody Books

An exception is a loan. It buys progress now and pays for it later, on terms that were never negotiated.

The metaphor is close enough to be useful and wrong in exactly the way that matters. A loan has a principal, a rate, a schedule, and – critically – a line on the balance sheet. Someone can look it up, it appears in planning, and it has a maturity date that arrives whether or not anyone is paying attention.

An exception, on the other hand, has all of the economics and none of the instrumentation. The borrowing is real, but the liability is never entered anywhere, which means it does not appear in any forecast, does not surface in any review, and becomes visible only when something else fails and the resulting investigation trips over it.

The debt has four components, and three of them are well behaved.

There is immediate complexity: the extra branch, the special-cased path, the structure that now has two shapes instead of one.

Then, there is future explanation: every subsequent maintainer, auditor, or new hire who encounters the deviation and must be told why it is there, multiplied by the number of times that conversation recurs.

And, finally, there is maintenance: the deviation must be carried through every migration, every upgrade, every schema change. Forever.

And it has a remarkable tendency to become the thing that eventually breaks.

The first three are costs attributable to the existing exception; precedent, however, changes the probability/cost structure of future exceptions.

Precedent Is a Rate, Not a Sum

The most expensive part of an exception is not the exception itself, but what the exception does to the cost of the next decision.

Before the first deviation, refusing the second one is a straightforward conversation about the standard. After it, however, the conversation changes shape. The request is no longer may we deviate but why is our case different from that one, and that is a much harder question to answer well, particularly when the honest answer is usually that the cases are more alike than not.

The precedent has supplied the argument, and the person defending the standard now has to litigate a comparison rather than state a rule.

The effect compounds. Two precedents are not twice as persuasive as one; they begin to look like a pattern, and a pattern eventually looks like the actual standard. At some threshold the exception becomes easier to justify than the rule, and the rule quietly inverts without anyone deciding it formally.

Which means precedent does not belong in the sum with the other three. The first three terms describe what this deviation costs. Precedent describes what this deviation does to the price of every deviation after it. It is a rate applied to a future count, not a figure added to a present total.

Treat this as a shape, more than a metric. It should not be turned into a score – the number would be gameable within a quarter and would effectively end up as a measure of documentation diligence rather than architectural drift.

The point of naming the term is to change what gets discussed in the eleven-minute conversation, not to produce a dashboard.

The Same Fact, Opposite Signs

There is a version of this argument that ends here, with precedent as pure corrosion and a recommendation to hold the line. That version, however, is wrong, and the reason behind that judgement may be the most useful thing in the article.

An exception that recurs is evidence. If the same deviation is requested five times by five teams for five unrelated reasons, the standard is no longer entitled to go unquestioned. The standard was written against an expected case, but when five real cases do not fit it, the correct response can very well be to change the standard rather than to keep granting relief from it.

So recurrence carries opposite signs depending on one variable. An unrecorded exception that recurs is drift: nobody can see the pattern, each grant is evaluated in isolation, and the fifth is approved on the strength of the first four without anyone noticing them accumulate. A recorded exception that recurs is evidence: the pattern is legible, and it should trigger a review of the standard itself.

Both outcomes rely on the same behavior, at the same frequency. The difference between invisible erosion and usable evidence begins with whether anyone wrote it down.

The Booking Entry

If an exception is a loan that never gets booked, the remedy is the booking entry.

A deliberate exception should record five things: who owns it, why it exists, what its scope is, what condition ends it, and which principle it set aside.

The first three are conventional and usually the easiest to get, but the latter two are where the value is.

The condition, not the date. An expiration date is renewed reflexively. It arrives, the owner is busy, nothing has visibly broken, and the review becomes a rubber stamp, often several times, until the date itself is treated as ceremonial. A condition behaves differently because it is falsifiable: this exception ends when the source system exposes a supported API, when the second consumer appears, or when volume exceeds the threshold that made the shortcut safe.

A condition can be checked in ten seconds by someone who was not there in the first meeting. A date only tells you that time passed.

The principle that yielded. This is the field almost nobody records, and it is the one that pays.

Every exception is granted at the expense of something. Least privilege yields to supportability. Separation of environments yields to delivery speed. Consistency yields to a deadline. The rationale usually captures what was gained; it almost never names what was given up. In this case, what was given up is precisely the thing a future reviewer needs, because it tells them what to check when deciding whether the trade still holds.

Five fields. None of them takes longer to write than the original eleven-minute conversation took to have.

What the Log Becomes

The fifth field is worth dwelling on, because an exception log that captures it stops being a maintenance artifact and becomes something an organization rarely has.

Every architecture publishes principles, but almost none publish their order or priority. Security, reliability, cost, maintainability, performance, separation of concerns – each is separately defensible, each is written down, and nowhere is it stated which one loses when two of them want opposite things. This is not always carelessness; writing security yields to supportability under conditions X and Y is a public commitment about what comes second, and that sentence is difficult to put in a governing document even at organizations where it is the plain operating reality.

So the order stays unwritten. It still exists – decisions keep getting made, and they are almost never random – but it lives in the judgment of whoever is in the room, and identical situations six months apart resolve opposite ways depending on who attended the discussion.

An exception log with the fifth field records that order incrementally, one decision at a time, in the only place where writing it down is politically uncontroversial. Nobody objects to documenting a deviation, just as no one has to ratify a ranking, defend it in the abstract, or commit to it in advance. The order simply accumulates as a record of what actually happened, and after a year it can be read.

At which point two diagnostics become available at no additional cost. A principle that never appears in the yielded column has either never been tested or has stopped being a principle and become a constraint. A principle that appears in every exception entry is no longer a principle at all. At best, it is decoration, and continuing to publish it costs credibility without buying governance.

The Cheap Case

Most doctrine, where it exists, already contains a version of this mechanism. It is usually applied to the wrong thing.

It is common to find, somewhere in a standards document, one section that does the whole job properly: it states the default, names the condition under which the default may be abandoned, lists what must remain true if it is, requires the deviation to be recorded as a decision, and specifies that if the deviation becomes the norm, the standard itself must be revised. That is precedent with its invalidating condition attached, and it is exactly right.

It is also, almost invariably, applied to something inexpensive. Folder organization. Naming. A layout convention. The section that governs where files live gets a full lifecycle, while the section that governs how much privilege to grant for operational support gets a default pattern and no review condition at all.

This is neither hypocrisy nor hard to explain. The discipline is easiest to apply where the stakes are low enough that nobody argues. Which is why it survives there, and why it goes missing precisely where it would be worth the most.

The useful observation for anyone auditing their own standards is that the pattern is probably already in the document. It does not need to be invented, defended, or introduced. It only needs to be aimed at something expensive.

The Test

There is a single question that separates a governed deviation from an ungoverned one, and it can be asked in a meeting without preparation.

Can you name the owner, the reason, the scope, the ending condition, and the principle being set aside?

If all five have answers, the exception is a loan with terms. It can be tracked, reviewed, retired, or promoted into the standard when the evidence says the standard was wrong. Even in this form, it is still a liability, but it is a booked one.

If they do not, the deviation is not an exception. It is an unrecorded change to the architecture, made by whoever happened to be in the room, and it will be discovered years later by someone who cannot remove it because they cannot reconstruct why it is there.

That is the whole distinction: Good systems permit exceptions. Mature systems remember that they made them.