Why does a Rego policy shaped as a deny set fail open while default allow := false fails closed?

## The asymmetry Both shapes express the same policy. They disagree about the default answer when the policy has nothing to say. **Deny set (the ecosystem default).** `deny` is a partial set of messages. Zero matching evaluations means an empty set. The runner turns an empty set into exit code zero. *Silence is approval.* **Boolean allow.** `allow` is a complete rule. Written on its own it is *undefined* when its body fails; adding `default allow := false` gives it the value `false` in exactly that case. The caller admits the change only on an explicit `true`. *Silence is denial.* ```rego package ci.retention min_days := 90 default allow := false allow if { every job in input.jobs { job.artifacts.retention_days >= min_days } } ``` The consequence shows up not when the policy is right, but when it is *absent*. ## What actually goes wrong in practice The failure mode is almost never "the rule said the wrong thing". It is "the rule was never consulted": - the package was renamed while refactoring the library, so `data.main.deny` no longer exists; - the runner was pointed at one namespace and the rule lives in another, with no `--all-namespaces`; - the policy directory was not mounted or copied into the job at all; - the rule matched a field path the input document no longer uses. With a deny set, every one of those yields zero messages and a green check. The gate has been decorative for three weeks and no signal was ever emitted, because *the absence of a complaint is exactly what success looks like*. With `default allow := false`, the first three still leave the whole document undefined, but the fourth — the body simply failing to hold — produces `false` and blocks immediately. Someone notices within minutes, because a fail-closed policy that stops working is loud: it blocks everything. ## The caveat that separates a good answer from a slogan `default` is a property of a **rule**, not of the query. It supplies a value when the rule's body does not succeed. It cannot supply a value for a rule that is not in the compiled policy at all. If the package path is wrong, `data.ci.retention.allow` is undefined, and undefined is not `false`. So the fail-closed property is really two things: 1. `default allow := false` inside the policy, covering the body failing; and 2. a **consumer** that treats an undefined or missing result as a denial rather than as an approval. A harness that does `if result == false: block` and otherwise proceeds has thrown the property away. It must be `unless result is exactly true: block`. ## Why the ecosystem still defaults to deny sets Given all of that, why is nearly every published policy library written as deny sets? Because the runner looks rules up **by name**. conftest resolves `deny`, `violation` and `warn` (optionally suffixed) inside a namespace and needs no configuration to know what question to ask. A boolean decision has no such convention — you have to write the query and the harness yourself. Deny sets also give you per-violation messages for free, which is most of what a developer needs from the gate, whereas a bare boolean tells them only that something is wrong. That is a real engineering trade, not laziness: cheap contribution and good messages, bought with a failure direction that hides its own absence. ## How you buy the safety back Since you cannot get fail-closed behaviour out of a deny set by writing better Rego, you get it from the harness around it: - keep a deliberately non-compliant fixture — a pipeline file whose log retention is below the floor — and assert in the policy repository's own CI that the gate rejects it. If a rename silences the rule, this test goes red. - pin the package path and the namespace in the gate invocation rather than relying on discovery, so a mismatch is a configuration error rather than a quiet no-op. - have the gate report how many rules it evaluated, and treat *zero* as a failure of the gate rather than a clean bill of health. ## What to say in an interview State the asymmetry in one sentence (empty set reads as approval; `default allow := false` reads as denial), give a concrete cause that triggers it (a renamed package), then add the caveat that `default` covers a failing body and not a policy that never loaded, so fail-closed is shape plus consumer. Finish with the fixture test, because that is what you would actually do on Monday.