How a Rule Resolves

### Rego has two document roots, and only one of them comes from the caller A Rego policy never "receives arguments" the way a function does. It evaluates against a document tree, and that tree has exactly two roots: `input` and `data`. **`input` is the document under evaluation.** The caller supplies it with the query, it exists only for the duration of that one evaluation, and nothing in the policy can write to it. In an infrastructure gate, `input` is typically the thing being judged — the JSON a plan export produced, a manifest, a request payload. Policies read it by path: `input.resource_changes`, `input.resource_changes[0].change.after.machine_type`. **`data` is everything the engine already holds.** Two different kinds of thing live in this single tree, and the query path cannot tell you which is which: - *Base documents* — plain JSON or YAML loaded alongside the policies. A file placing `{"catalog": {"families": ["n2", "c3"]}}` into the tree makes `data.catalog.families` readable by any rule. This is where slow-moving reference facts live: an approved machine-family catalogue, an owner registry, a list of sanctioned regions. - *Virtual documents* — the outputs of rules. A rule named `violations` declared in `package estate` publishes its value at `data.estate.violations`. It is computed on demand, when something asks for that path, not stored. That last point is the one candidates most often miss. Rules do not "return"; they **define documents inside `data`**, addressed by package path plus rule name. This is also why one rule can consume another simply by naming its path — there is no call, just a reference to a document that happens to be computed. ### Reading either root Both roots are read the same way, with dotted or bracketed paths: ```rego package estate approved_family if { family := input.resource_changes[0].change.after.machine_type family in data.catalog.families } ``` `import data.catalog` lets the body write `catalog.families` instead of the full path — pure shorthand, no loading semantics attached. There is no `read()`, `lookup()` or `fetch()`: if the path is present the reference evaluates to its value, and if it is absent the reference is undefined, which makes the expression — and therefore the rule body — produce nothing rather than raise an error. ### The boundary between the two The mechanical split is fixed: | | `input` | `data` | |---|---|---| | Who supplies it | the caller, per query | loaded with the policy, or computed by rules | | Lifetime | one evaluation | until the engine is reloaded | | Writable by a rule | never | yes — every rule defines a document under it | | Typical content in a gate | the artifact being judged | reference facts plus rule output | Two collisions are worth knowing. First, a base document and a rule cannot occupy the same path: if JSON is loaded at `data.catalog.families` *and* a rule named `families` exists in `package catalog`, the engine reports the conflict instead of choosing one. Keep loaded-data paths and rule packages disjoint. Second, `input` is a reserved root — you cannot declare a package or a rule under it, so any fact the policy needs but the caller did not send has to arrive through `data`. ### Why interviewers open here Every later question about rule shapes, query paths and gate wiring assumes this model. A candidate who thinks `data` is "the config file" and `input` is "the request body" is half right and will still be surprised the first time they query `data.estate.violations` and get a computed answer back — because the rule they wrote is, from the caller's point of view, indistinguishable from a JSON file someone loaded.