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

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.