In OPA, what does a single decision log entry record about a policy decision?

## What the decision log plugin is A running OPA answers queries: something hands it an `input` document, OPA evaluates a policy path against it, and OPA returns a result. Nothing about that exchange is durable — the caller sees the answer and moves on. The **decision log plugin** is the part of OPA that turns each of those exchanges into a record and ships it somewhere. It is configured in OPA's configuration file under a `decision_logs` section, and it is off unless you configure it. It is worth being precise about scope: this is OPA's *decision* log, not its diagnostic log. The diagnostic log is OPA telling you about itself — bundle downloads, plugin state, errors. The decision log is OPA telling you what it decided, one entry per evaluation. ## The shape of an entry Each event is a JSON object. The fields you will be asked about: - **`decision_id`** — an identifier unique to this one evaluation. It is what lets a caller that received an answer and an operator reading the log stream agree they are talking about the same decision. - **`path`** — the policy path that was queried, for example `kubernetes/admission/deny`. This is the *query*, not the rule that fired. - **`input`** — the input document verbatim, as OPA received it. This is the field that makes decision logs a data-handling problem as well as an observability feature: whatever the caller sent, the log now contains. - **`result`** — what OPA returned. For a policy whose entry point yields a set of violation messages, that is the set; for a boolean rule, the boolean. - **`bundles`** — the bundles OPA had loaded, each with its **revision**. This pins the answer to a specific version of the policy. - **`timestamp`** — when the decision was made. - **`labels`** — the OPA instance's identity, including its id and version, plus any labels the operator set in configuration. This is how you tell which of forty OPA sidecars produced an entry. - **`metrics`** — timing information, present when metrics are enabled. - **`erased`** — present when a mask policy removed fields, listing the paths it removed. The revision field deserves a second look, because it is the one juniors skip. Policy changes over time. Two entries with the same `path` and an identical `input` can legitimately carry different results if a bundle was activated between them. Without the revision, the log tells you the engine changed its mind and gives you no way to say why. With it, you can go to the exact policy version that produced each answer. ## Every decision, not just the interesting ones A common wrong assumption is that the decision log is a denial log. It is not. OPA emits an entry for evaluations that allow as readily as for ones that deny — the plugin does not know or care which outcome your policy considers bad. That is what makes decision logs useful for questions like "is this rule ever actually hitting anything?", and it is also why the volume can be surprising: a busy admission or authorization path produces one entry per request. ## The two sinks **Console.** Setting `console: true` makes OPA write each event as JSON on its own log output. In a container this is the cheapest possible integration — whatever already collects stdout and stderr collects your decisions too. It is also the sink with the fewest guarantees of its own: there is no batching, no retry, and delivery is entirely the surrounding log pipeline's problem. **HTTP service.** Pointing `decision_logs.service` at a service defined in OPA's `services` block makes the plugin buffer events in memory, batch them, compress them, and POST them to that service. It backs off and retries on failure. This is the production shape, and it introduces the property that matters most for anyone treating the log as a record: the buffer is *in memory and bounded*. Events sit there between the decision and the upload. Both can be enabled at once — a common setup during a rollout, where console output is what an engineer greps locally and the service sink is what feeds the central pipeline. ## What an entry does not tell you It records the question and the answer. It does not record the reasoning: which rule body was satisfied, which expression was undefined, which of five violation conditions matched. If you need that, the decision log is the pointer — the `decision_id`, the `input`, the bundle revision — not the explanation.