Any set of infrastructure guardrails eventually meets a change that legitimately has to break one of the rules. How would you design the exemption path so that exceptions remain possible without the guardrail degrading into a formality?

## Why the exemption path is a design problem, not an afterthought Every guardrail encodes a generalisation, and every generalisation has exceptions it cannot express. The bucket that really is a public website. The legacy database that genuinely cannot be encrypted before next year's migration. The instance size that is over the cap for one afternoon of a data migration. There are only three possible designs, and two of them are bad. If there is **no exemption path**, engineers find one anyway — a change applied outside the pipeline, a rule quietly deleted, a resource moved out of code entirely. If the path is **informal** — a message to the platform team, a temporarily disabled check — you have exceptions with no record, no expiry and no owner, which is the worst of both worlds because you now believe you have a control. The third design is to treat the exemption as a real, structured object. ## The five properties **Declared.** The exemption lives in version control, next to the thing it exempts, and arrives through the same review as any other change. This single choice does most of the work: an exemption in a diff is seen by a reviewer, has an author, and has a history. **Narrowly scoped.** It names one rule and one resource. The antipattern is the blanket skip — a directive that suppresses *all* rules for a file or a directory, usually added to unblock one thing and then inherited by everything added to that file for the next three years. The scope of an exemption should be as close as possible to the scope of the actual exception. **Time-bounded.** Every exemption carries an expiry, after which the rule fires again. This inverts the default: instead of exceptions accumulating silently forever, they come back for a decision. If an exception is genuinely permanent, that is a signal the rule needs a condition it currently lacks — write it into the rule rather than pretending it is temporary. **Attributed and independently approved.** Requester, reason, approver, ticket. The approver must not be the requester; self-approval is the mechanism by which a control becomes decorative. The reason should be readable by someone who was not in the conversation, because in a year that is the only audience. **Visible in aggregate.** A register of open exemptions — how many, on which rules, how old, who owns them — is the actual health metric of the programme. Nobody's dashboard of blocked changes tells you as much as the age distribution of active exceptions. ## Exemptions are feedback about the rules This is the part that distinguishes a lead's answer. If one rule accumulates forty exemptions, the correct interpretation is not that forty teams are careless. It is one of: - **The rule is too broad.** It fails a case it should not; add the missing condition. - **The rule is at the wrong scope.** It should be strict in production and advisory elsewhere. - **The rule encodes a standard the organisation has not actually agreed to.** That is a conversation to have openly, not to lose slowly through exceptions. So the exemption register should be reviewed on a cycle, and rules with high exemption rates should be revised or retired. A guardrail estate that only ever grows is one nobody is maintaining. ## The friction tradeoff The design tension is real and cannot be optimised away. Make exemptions too easy and the exemption becomes the default path — the fastest way past a failing check, taken without thought. Make them too hard, especially in an incident, and people leave the governed path entirely, which costs you the visibility you were trying to buy. Two things resolve it in practice: a **fast path with a strong record** — an urgent exemption can be granted in minutes but is automatically short-lived and reviewed afterwards — and different friction for different rules, so the small hard-mandatory core has no exemption path at all while everything else does. ## Distinguish exemption from accepted risk A useful separation at scale: an *exemption* is an engineering statement that this rule does not apply here. An *accepted risk* is a business statement that a known exposure will be carried, owned by someone with the authority to carry it. Conflating them lets engineering-level approvals silently accept risks nobody senior ever saw. Route the second kind to the risk owner, keep it in the risk register, and let the exemption reference it. ## Signals your exemption design is failing - Blanket skips outnumber targeted ones. - The median age of an open exemption exceeds its original expiry. - Exemptions approved by their own requester. - No one can produce the list on demand. - Rules are being deleted rather than exempted, because deleting is easier.