You renamed a policy rule's id last sprint and nothing failed - what silently broke?

## Why a rename is quiet A rule id is a key, and every consumer of it does a lookup. The property that makes a rename dangerous is that **all of those lookups fail open or fail invisibly**. A waiver register does not validate that its keys correspond to live rules. A suppression in someone's manifest is just text until a rule with that id is evaluated against that file. A control map is a document. A dashboard query returns an empty series, which renders as a flat line at zero. Nothing in that list is wired to raise. So work through the consumers explicitly. **Waivers.** An exemption keyed on the old id no longer matches anything the rule emits, so it exempts nothing. Two things follow. First, the register now overstates: rows sit there looking active, and a reviewer counting live exceptions counts fictions. Second, whatever those waivers were covering is now evaluated with no exemption. Whether anyone notices depends entirely on enforcement mode - see below. **Suppressions in consumer repositories.** These live outside the rule library, in dozens of repositories you do not own, and they are the hardest to inventory. After the rename they are dead text that nobody will delete, and they will confuse the next engineer who reads them into believing a check is suppressed when it is not. **Control maps.** A row saying "this written control is enforced by rule X" now names an id that appears in no report. The check may well still be running under its new name, but the evidence trail from control to running check is severed, and it is severed in a document that is only read when someone comes asking for evidence - typically months later. **Trend data and alerting.** The old id's series goes to zero and the new id's series starts at zero on the rename date. Read casually, the first looks like a guardrail that stopped firing because teams fixed things, and the second looks like a brand-new problem. Any alert with a threshold on the old id silently stops firing. ## Loud or silent depends on the enforcement mode This is the part that separates a senior answer. If the rule blocks, a dead waiver produces a failed build within a day, someone investigates, and you find out - painfully but quickly, and usually with the affected team convinced the rule is broken. If the rule is in a warn or record-only mode, the dead waiver produces nothing at all: no failure, no ticket, no signal. The rename then sits undetected until an audit or an incident asks the question that the control map can no longer answer. **The safest-feeling rules are the ones where a rename does the most undetected damage.** ## The compounding failure: reuse Everything above describes references that stop matching. The worse variant is a reference that starts matching **something else**, which happens when the old id is later minted for a new rule. Now the stale waivers do not exempt nothing; they exempt the new rule, for repositories nobody assessed against it, with a justification written about different logic. This is why retirement must be permanent and recorded rather than a deletion. ## How to rename safely - or not at all The first answer is: do not. Titles, descriptions and remediation links exist to be improved; the id does not need to be pretty. Reserve renames for cases where the id is actively wrong - it names a check the rule no longer performs. When a rename is genuinely required, treat it as a breaking change to a published interface: 1. **Add, do not replace.** Emit the new id while continuing to emit or resolve the old one for a deprecation window, so both keys match during the migration. 2. **Inventory the consumers.** The waiver register, suppressions across consumer repositories, the control map, dashboards, alerts, ticket templates and any downstream report that groups by rule. Searching only the rule repository is the classic miss - most references live in other people's repositories. 3. **Migrate each consumer** and confirm the new key matches, rather than assuming it does. 4. **Retire the old id permanently**, keeping it resolvable as deprecated so a future rule cannot inherit its references. 5. **Announce the window** to the teams whose exemptions and suppressions you are about to invalidate, because they are the ones who will be blocked if step 3 misses one. ## Making the next rename cheaper The library's own CI can hold the line: fail the build when an id present in the last release disappears without a deprecation marker, and fail it when a waiver or control-map row references an id no rule emits. That second check converts the entire silent class of failures into a red build in the repository that owns the rules, which is the only place anyone is watching.