Governed Exception

Standards exist to limit variety, because variety makes an estate expensive to operate. But every standard will eventually meet a workload its author did not foresee — specialised hardware, an unusual protocol, a regulatory requirement, a genuine performance constraint.

Without an exception path, that workload is either forced onto an unsuitable standard, producing something that works badly and expensively, or it leaves the governed estate entirely. The second is far worse: a shadow environment has none of the controls the standard existed to provide.

The governed exception is always better than the ungoverned workaround.

What makes an exception governed

• A named owner, accountable for the exception and for eventually removing it.
• A defined scope — this workload, this environment, this interface — not a general carve-out.
• An expiry that triggers review, not automatic revocation. Without an expiry, the exception becomes the architecture.
• The intent still met by another mechanism. A workload may use different compute and must still meet enterprise identity, common observability, network policy, cost attribution and patch management. The standard exists to protect properties; a different mechanism meeting them has not violated the intent.
• A record, so a pattern of exceptions in the same area is visible.

The pattern the exceptions reveal

A recurring exception is a signal that the standard is wrong, not that teams are non-compliant. If specialised compute becomes a recurring need, the answer is a second sanctioned pattern with its own paved road — not an indefinite series of exceptions.

Two supported patterns are far cheaper than one standard and twenty exceptions, because each exception carries its own review, its own operational unfamiliarity and its own risk.

Industry example

Enterprise technology standards written for commodity compute meet this immediately when a workload requires specialised hardware, a specific interconnect and a different operational model. The standard as written cannot accommodate it, and the workload is genuinely legitimate.

The organisations that handle this well have already written their standards as properties rather than mechanisms — provisioned through the platform, observable through common telemetry, patched on this cadence — so the specialised workload can meet the intent by a different route. The ones that have not face a binary choice between a bad technical outcome and an ungoverned one.

The same dynamic appears with security controls that cannot be delivered before a committed launch, where a compensating control accepted explicitly, with a stated residual risk and a dated commitment to the full control, is far better than shipping with nothing while everyone looks away.

Failure scenarios

• No expiry, so the temporary becomes permanent and nobody notices.
• Accepted by the wrong person — the engineer under deadline pressure rather than someone with authority to accept the risk.
• A general carve-out rather than a scoped one, which quietly exempts a whole team or product.
• Exceptions granted faster than the standard evolves, so the standard describes a minority of the estate.
• An exception process slower than the workaround, which guarantees the workaround.

Trade-offs

Every exception adds variety, and variety is the cost the standard existed to avoid. A liberal exception policy erodes the standard; a restrictive one drives work outside the estate.

The workable balance is to make the exception path fast, visible and expiring — fast so it is used rather than avoided, visible so patterns are detectable, and expiring so the estate does not silently accumulate permanent variety.

Interview question

"A team needs to run a workload your standards do not support, and they have a deadline. Walk me through what you grant, what you require in return, and what you would change if three more teams asked for the same thing next quarter."