In Rego, what does `not input.metadata.annotations.exempt` evaluate to if the object has no annotations?

## The rule In Rego, `not E` is satisfied exactly when `E` is undefined or `false`. If `E` is defined and not `false`, the negation is not satisfied and the surrounding body is undefined. That single sentence covers the whole behaviour, and it has one consequence people find surprising: **negation over data that is not there always succeeds**. `not input.metadata.annotations.exempt` passes for an object with no `annotations` map, for an object whose annotations map lacks the key, and for an object where the key is present with the value `false`. Three quite different situations, one indistinguishable result. ## Why this is usually right For the common case — an exemption guard on a deny rule — this is exactly the semantics you want: ``` deny contains msg if { not input.metadata.annotations["policy.example.com/exempt"] ... } ``` An object that never requested an exemption has no such annotation, the negation succeeds, and the rule proceeds to check it. If negation over absent data failed instead, you would have to annotate every object in the estate just to state that it is not exempt. ## Why it bites The interesting property of `not` is that it **reverses the direction in which a mistake fails**. - A mistyped path in a *positive* expression makes the body undefined. The rule stops matching, nothing is denied, and the failure is silent — you find out when someone asks why the gate has never fired. - The same mistyped path inside `not` is *always* satisfied. The guard becomes vacuously true, the rule fires for objects it was meant to skip, and the failure is loud — a wave of denials on workloads that hold a legitimate exemption. Neither is good, but they need different reflexes. The silent one requires you to prove the rule can still deny; the loud one announces itself the moment it ships and mostly costs you trust with the team that got blocked. The second bite is that `not` erases the difference between absent and false. If your policy needs to distinguish "this object explicitly declared itself non-exempt" from "this object says nothing about exemptions" — which matters the moment an exemption carries an expiry, an owner or a ticket reference — negation cannot do it for you. ## Distinguishing absent from false Bind the value and compare it, rather than testing it through a negation: ``` annotations := object.get(input.metadata, "annotations", {}) exempt := object.get(annotations, "policy.example.com/exempt", "absent") ``` Now `exempt == "absent"`, `exempt == "false"` and `exempt == "true"` are three testable states, and the rule can require a real, well-formed exemption value rather than merely the absence of a contradiction. `object.get` returns its default when the key is missing, which is what turns undefined into a value you can reason about. ## Two more properties worth knowing **`not` never binds.** A negated expression containing a variable that is not already bound elsewhere in the body is unsafe, and the compiler rejects the policy — this is a load-time error, not a silent one. Negation tests; it does not produce bindings for later expressions to use. If you want "there is no container that violates X", express it as a negation over a rule or a comprehension that is itself fully defined, so the variable is bound inside that construct rather than under the `not`. **Double negation is not identity.** `not not E` is satisfied when `E` is defined and not false — it collapses the distinction between undefined and false in the opposite direction from what people usually intend, and reading it in a review is much harder than reading a positive test. Prefer binding a value and comparing it. ## What to say in an interview State the rule first — negation succeeds on undefined or false — then show that you know which way it makes mistakes fail, and finish with the practical guidance: use `not` for "this marker is absent", use an explicit bound comparison whenever the difference between absent and false is meaningful to the decision, and never rely on a negation to prove a field was checked.