One rule accounts for most of your break-glass overrides this quarter - what do you conclude?

## Why override rate is the most informative number a gate produces A gate emits denials and passes. Neither tells you whether the gate is right - a denial only says the rule matched. An override says something much stronger: a human with authority looked at a specific denial and decided the rule was wrong about this change, or at least less important than shipping. That is a judgement, recorded, at scale. Treated as a stream of defect reports against your policy set, it is the closest thing a policy programme has to user feedback. ## Get the denominator right The usual mistake is overrides per deploy, which mixes every rule together and hides the interesting rule inside a large, healthy total. The number that means something is **overrides as a share of that rule's denials**. A rule that denied twice this quarter and was overridden once is a curiosity. A rule that denied four hundred times and was overridden two hundred is not a control; it is a speed bump with a recording device attached. Segment before you interpret: - **One rule, many teams.** The rule is the problem. Independent teams with different workloads reaching the same conclusion is about as clean a signal as this domain offers. - **Many rules, one team.** Look at that team's workload before you look at their discipline. They may own the one service that legitimately talks to the outside world - or they may be routing around everything, which is a different conversation with a different owner. - **One rule, one team, repeatedly.** Usually a single unmodelled legitimate case. Often the cheapest thing in the whole list to fix. ## The three explanations, and how to tell them apart **The rule is too broad.** It was written to catch a risk and it also catches a common legitimate shape, because the distinction was hard to express when it was authored. You can identify this by reading the stated reasons: they will all describe the same legitimate case in slightly different words. **The rule is asked a question it cannot answer where it sits.** The information that separates good from bad is not present at the point of evaluation - whether an external destination is a sanctioned vendor may be known to the service owner and to nobody at the gate. Rules like this cannot be tightened into correctness; they must move, acquire the missing input, or stop blocking. **The organisation has already decided to accept the behaviour.** Every override is granted, quickly, by people who agree it is fine. The rule expresses an intention nobody currently holds. That is a real finding, and the honest response is to change the rule to say what the organisation actually wants rather than leaving a control that is contradicted every week. ## The cost of leaving it alone A blocking rule that is usually overridden does three kinds of damage. It trains everyone that a denial is an administrative step rather than information, which bleeds into how they read every other rule. It consumes the break-glass path's alarm value - if the pull happens constantly, nobody looks at any individual pull, including the one that mattered. And it is very hard to describe as an enforced control to anyone who asks how it works, because the honest description is "it blocks, and then we let it through". ## The organisational layer, which is the actual principal question "Fix the rule" is easy to say and usually costs somebody who is not in the room. Narrowing an egress rule so that legitimate destinations pass generally means somebody must maintain the list of legitimate destinations, review additions, and answer questions about it - continuing work, on a team that did not plan for it. If that owner is not named and funded, the decision quietly becomes "keep overriding", which is the status quo with extra meetings. So the call has three parts, and a lead owns all of them: what the rule should become, who carries the ongoing cost of it being narrower, and what the interim position is while that work is done. An explicit interim - the rule is advisory for this class of change until the destination list has an owner - is far better than an implicit one where the rule blocks and everyone knows the override is automatic. The first is a decision; the second is a decision that nobody has to admit to making. ## The reverse signal A rule with no denials and no overrides is not evidence of health. It may be perfectly targeted, or it may not be matching anything at all - a selector that never applies, a surface that stopped being produced, a check that silently stopped running. Silence needs the same interrogation as noise: confirm the rule still fires and still denies a case you construct on purpose, before you count it as a working control. ## What to bring to the review Rate per rule with its denominator, the segmentation, the stated reasons in the overriders' own words, the trend after any change you made, and the list of overrides whose follow-ups were never closed. Bring the numbers rather than the anecdote - the anecdote is always about the one dramatic night, and the decision should be about the two hundred ordinary ones.