Your Rego deny rule skips its message for waived repositories — what does that silence cost you?

## The shape in question The rule enforces a floor on how long build logs and job artifacts are retained. Someone asks for an exception, so a guard goes into the body: ``` deny contains msg if { some job_name, job in input.jobs job.artifacts.retention_days < min_days not data.waivers[input.repo] msg := sprintf(...) } ``` It works. The waived repository ships. And the gate's output for that repository is now byte-identical to the output for a repository that is fully compliant: no messages, exit zero, green check. ## What you gave up **1. Exceptions become uncountable from the outside.** The set of live waivers now exists only in the waiver data, never in the gate's results. Nobody reading a month of pipeline runs can tell how many builds shipped under an exception. The question "how many teams are currently excepted from the retention floor?" can no longer be answered by looking at what the control produced — only by reading the input the control consumed. **2. Excepted and never-evaluated collapse into one output.** A deny set already conflates "compliant" with "nothing matched". Adding a suppression branch adds a third state to the same empty result. When someone later asks why a repository never failed the retention gate, the honest answer is that you cannot tell from the results whether it was compliant, waived, or whether the rule silently stopped matching after a schema change. **3. The gate's output stops being evidence.** A control's own output is the cheapest artefact you have showing that it ran and what it decided. Suppression turns the exception into a non-event, so the record of it lives elsewhere or nowhere. ## What to do instead **Relabel rather than suppress.** Keep one rule that fires on the underlying condition, and let the waiver decide *which name it lands under* rather than whether it exists: - unwaived and non-compliant, the message goes into `deny` and the build fails; - waived and non-compliant, the message goes into `warn`, naming the repository and stating that a waiver is being applied. Both appear in the report. Because the runner reads `warn` messages as warnings rather than failures, the waived team still ships, and the exception is now visible in every run instead of invisible in all of them. The cost is a second rule body — usually a shared helper called from both — which is a fair price for the distinction. **Or change shape.** If a downstream system needs the outcome machine-readable rather than printed, the deny set is the wrong container. A complete rule producing a decision object — the outcome, the reasons, and a flag saying an exception was applied — carries all three states explicitly, at the cost of writing the query and the harness yourself instead of relying on name lookup. ## The one thing the guard gets right `not data.waivers[input.repo]` behaves correctly when the waiver document is missing entirely. In Rego, `not expr` is true when `expr` is false *or undefined*. If `data.waivers` was never loaded, the inner reference is undefined, the negation is true, and the deny fires. A broken waiver-data path therefore over-blocks rather than under-blocks — the safe direction, and worth saying out loud, because the instinctive worry is the opposite. Writing the guard the other way round is where it goes wrong. A positive condition over the same missing document — asserting that the repository is *not equal* to something under `data.waivers` — leaves the whole body undefined when the document is absent, and an undefined body contributes nothing to the set. Same intent, opposite failure direction. ## What an interviewer is listening for Not "suppression is bad". They want you to notice that the output of a waived run is indistinguishable from a clean run, to say which questions that makes unanswerable later, and to propose the relabel — keep the message, change its severity name — rather than reaching for a new subsystem. Naming the `not`-over-undefined behaviour, in the correct direction, is what separates someone who has written these rules from someone who has read about them.