A Rego complete rule ran green for months and now errors on one plan. Why?

### A complete rule may produce one value — across every binding, not just every body The failure looks like a mystery because the policy did not change and the engine did not change. What changed is the *input*: for the first time, two resources matched the same rule. Consider a rule written to explain a machine-family violation: ```rego package estate reason := msg if { some rc in input.resource_changes not rc.change.after.machine_type in data.catalog.families msg := sprintf("%v uses an unapproved machine type", [rc.address]) } ``` `reason` is a **complete rule**: its head assigns one value to `data.estate.reason`. The body, however, iterates. `some rc in input.resource_changes` binds `rc` to each element in turn, so the body is evaluated once per resource, and every evaluation that succeeds produces a value for the head. With one offending resource that is one value and everything works. With two offending resources the body succeeds twice with two different strings, and the engine cannot pick one: it raises an evaluation conflict — a complete rule must not produce multiple outputs. The whole query fails; the gate does not return "deny", it returns an error. Two details make this sharper: - Multiple successes with the **same** value are fine. The constraint is one *value*, not one success. That is why a rule like `deny := true if { ... }` never trips over this, and why the bug hides in rules whose value is derived from the matched item — a message, an address, a severity. - The same trap exists in **partial object** form. Keying by something that is not unique per match — `reason[rc.change.after.machine_type] := msg` when two resources share a type — reproduces the conflict one level down. ### Why the tests were green Because the fixtures had at most one violating resource. A conflict of this kind is invisible to any test whose input cannot produce two distinct bindings. The regression test to add is not "assert the message" but a fixture with **two** offending resources — and, for the object form, two offenders that collide on the chosen key. ### `default` does not fix it The most common wrong answer in the room. `default reason := "ok"` supplies a value when the rule is **undefined** — when no body succeeded. This rule is the opposite failure: it is *over*-defined. `default` is never consulted, and it is not permitted on a partial rule at all, so it cannot be smuggled in that way either. ### The fixes, in order of preference 1. **Change the shape to match the cardinality.** If the rule is inherently per-resource, it should not have been a complete rule. Write it as a partial set of messages (`reason contains msg if { ... }`) or, better for a gate that must attribute failures, a partial object keyed by the resource address, which is unique within a plan: `reason[rc.address] := msg if { ... }`. The caller now receives every failure in one query instead of an error. 2. **Aggregate deliberately.** If the caller genuinely needs one value, compute it from the set: `summary := sprintf("%d resources violate the catalogue", [count(reason)])`. The complete rule then depends on the partial one and can only ever produce a single value. 3. **Narrow the body so it can match once.** Legitimate only when uniqueness is guaranteed by the data — a lookup by primary key, for instance. It is fragile as a *fix* for this bug, because the guarantee usually lives in someone's head rather than in the input. ### What an interviewer is really testing Whether you understand that a rule's head is a cardinality declaration, and that iteration inside the body multiplies results regardless of what the head promised. A candidate who reaches straight for `default`, or who says the engine "returns the first match", has the mental model of a function rather than of a document — and that model will keep producing this bug.