Principle Exception Register

An organisation's principle reads: every service must survive the failure of any single dependency. It has been in the handbook for three years. Nobody can say how many services comply, and the architecture group's honest answer to a new team asking whether it applies to them is "ask us". In practice there are 14 live exemptions, granted in conversations, recorded nowhere.

A principle with no record of its exceptions has no feedback loop, so it cannot be revised, and it cannot be enforced either: the first team told no will point at the ones who were told yes, and nobody will be able to show whether those were different.

Why it matters

A principle is a bet that a class of decision has a right answer often enough that it is cheaper to decide once. The exceptions are the data on whether the bet is still good. Three exemptions in three years means the principle is holding. Fourteen in a year, roughly 1 in 3 of the services built that year, means it is either wrong, scoped too broadly, or impossible to comply with, and in all three cases the principle is now a tax on honesty: the teams that ask get delayed and the teams that do not ask ship.

The register also converts a political argument into an evidential one. "This principle is unrealistic" and "this principle is essential" are both unfalsifiable. A list of 14 exemptions, 11 of which were granted for the same reason, is an argument that ends.

And it removes the silent violation, which is the real risk. A principle with no published exception route is not complied with; it is worked around, which removes the only signal that it needs changing.

Implementation patterns

• Four fields, no more: which principle, which system, why the exception was needed, and when it expires — 90 or 180 days is a usual window. Expiry is the load-bearing field — an exception without one is a quiet amendment to the principle.
• Name who may grant one, in the principle itself. If nobody is named, exceptions are granted by whoever is asked, inconsistently.
• Review the register, not the principles, on a cadence. Quarterly, read the exceptions and ask one question per cluster: is this principle wrong, is it scoped wrongly, or is compliance genuinely too expensive? Each diagnosis has a different fix.
• Cluster before judging. Eleven exemptions for internal tools means the principle should exclude internal tools, not that it should be weakened for everyone.
• Keep it where the principles are, in version control, so the history shows when the exception pattern changed.
• Expire loudly. An exception reaching its date should produce a notification to the owning team and the architecture group, not silently lapse into permanence.

Industry example

The pattern is standard practice in regulated environments, which is where it is best documented: a control framework that does not record waivers cannot be audited, so financial and healthcare organisations have maintained risk-acceptance registers with named approvers and expiry dates for decades, and external auditors read the register before they read the policy.

Engineering organisations arrive at the same artefact later and for the same reason. Published accounts of technology-radar practice, a format in public circulation since 2010, make the point in a different vocabulary: a radar that only records what is adopted and what is held, with no record of who was allowed to deviate and why, is read as advice rather than as a decision, and advice does not change what gets built.

Failure scenarios

• Exceptions without expiry, so the register grows and never shrinks, and the principle's real scope is unknowable.
• A register nobody reads. The artefact exists, the quarterly review never happens, and it becomes a filing cabinet.
• Granting becomes the architecture group's main activity, which is the signal that the principle is wrong and is being enforced anyway.
• Unrecorded refusals. Only the yeses are logged, so the register makes compliance look worse than it is and nobody can see the cases where the principle did its job.
• Weaponisation. The register is used to compare teams rather than to revise principles, and teams stop asking.

Trade-offs

Recording exceptions costs a small, recurring amount of administration, and it makes non-compliance visible — which is uncomfortable for the people who own the principle and for the teams in the list. That visibility is the whole point, and it is why the practice is resisted.

The second cost is honest: a register makes the exception route official, and an official route gets used more than an unofficial one. Expect more recorded exceptions and fewer silent ones, which looks like a regression on a dashboard and is an improvement in reality.

When not to use it

Do not build a register for a principle that is already enforced by a machine. If the rule is a build check or an admission policy, the exception mechanism is the override list in that tool and the register is a second, divergent copy. One source only.

Also skip it where there are fewer than about 5 principles and 3 teams: the exceptions are known to everyone in the room, and a register adds process to a conversation that is working. Introduce it when the first team asks "does this apply to us?" and nobody can answer from memory.

Interview question

Q: You inherit an architecture handbook with 12 principles. Within a month you have been asked for 5 exceptions, 4 of them for internal tools. What do you do, and what do you do differently from what the handbook's authors would have?

What a strong answer covers: granting with recorded reasons and expiry dates rather than refusing or deciding ad hoc · clustering the four internal-tool requests and treating the cluster as evidence that the principle is scoped wrongly, then narrowing its scope explicitly rather than weakening it · distinguishing the three diagnoses — wrong principle, wrong scope, compliance too expensive — because each has a different fix · publishing who may grant exceptions, so the answer stops depending on who is asked · and the measurement: exception rate per principle per quarter, with a rising rate read as a defect in the principle rather than in the teams.

Quick check

Quiz: What does a principle with no exception route actually get? — Silent workarounds, which remove the only signal that the principle needs revising, and an enforcement story that collapses the first time two teams compare answers.

Flashcard: Which field makes an exception register useful rather than decorative, and why? — The expiry date. Without it an exception is a quiet permanent amendment to the principle, the register only grows, and the principle's real scope becomes unknowable.