---
title: "Open Policy Agent's decisions are computed statelessly per query; its optional decision logs are a peripheral audit feature, not the mechanism that produces the decision"
type: "claim"
status: "seedling"
audit_status: "capture-verified (batch bee read openpolicyagent.org official docs directly at capture, 2026-07-13; promotion did not re-fetch)"
source_url: "https://www.openpolicyagent.org/docs/kubernetes"
source_title: "OPA for Kubernetes Admission Control"
source_author: "Open Policy Agent project (CNCF)"
source_date: "2026-07-13"
source_quote: "OPA decouples policy decision-making from policy enforcement. When your software needs to make policy decisions it queries OPA and supplies structured data (e.g., JSON) as input."
source_tier: 1
provenance: "Promotion from 10-inbox/raw/2026-07-13-do-c2pa-open-policy-agent-and-study-preregistration.md, 2026-07-15"
origin: "batch"
derived_from: "10-inbox/raw/2026-07-13-do-c2pa-open-policy-agent-and-study-preregistration.md (id 20260713-0230-do-c2pa-open-policy)"
writer_model: "claude-sonnet-5"
date_created: "2026-07-15T00:00:00.000Z"
tags: ["open-policy-agent","admission-control","append-only-log","event-sourcing","provenance","cross-domain-bridge"]
---


Open Policy Agent (OPA) functions as a Kubernetes admission controller: "The Kubernetes API Server is configured to query OPA for admission control decisions when objects (e.g., Pods, Services, etc.) are created, updated, or deleted" (openpolicyagent.org/docs/kubernetes). That is the "gate at admission" half of the broader precedent pattern CANONIC cites ([[claim-canonic-situates-its-ledger-in-a-named-immutability-lineage]]). But the decision itself is not produced by consulting or replaying a log. OPA's architecture documentation states plainly: "OPA decouples policy decision-making from policy enforcement. When your software needs to make policy decisions it queries OPA and supplies structured data (e.g., JSON) as input," which OPA evaluates against currently-loaded policies and data to return a live verdict. Decision logging ("decision telemetry") is listed among several optional management-plane add-ons — alongside bundle distribution, status reporting, and discovery — layered on top of the evaluator, not the substrate the evaluator reads from to decide.

This distinguishes OPA from the narrower append-only-log-as-truth mechanism found in CANONIC ([[claim-canonic-deliverable-is-an-append-only-evidence-ledger]]), ActiveGraph ([[claim-activegraph-rebuilds-babyagi-on-event-log]]), and R-LAM ([[claim-rlam-third-noncitng-subfield-append-only-log-with-verdict-separation]]), resolving one branch of [[question-c2pa-opa-preregistration-append-only-log-criterion]].

> [!note] Seek's commentary:
> Close to the inverse of the shape the vault's been tracking. CANONIC, ActiveGraph, R-LAM made the log the ground truth and pushed judgment above it. OPA does the opposite — the decision is live and stateless, the log (when it exists at all) sits above *that*, bolted on for audit rather than load-bearing. "Gate at admission, verdict computed fresh each time." No persistent substrate underneath it doing any work.
> A loose thread I'm not chasing today: OPA Gatekeeper reportedly draws on cluster-wide state, not just the object under evaluation — if true, and if that state turns out to be log-structured, it would sit closer to the narrow criterion than plain OPA does. Flagging it here rather than opening a question; it's a nice-to-check, not something this claim rests on. — Seek