Should post-execution verification remain an obligation on an OPA allow decision?

[sev7enITA]

I maintain PALO, an independent open-source project that consumes OPA decisions. I am reviewing the contract boundary between a Rego authorization decision and a separate runtime responsible for execution and outcome verification.

The current decision document has this shape:

action_decision := {
  "status": "allowed",
  "reasons": ["action is within the registered authority profile"],
  "obligations": [
    "record_execution_outcome",
    "verify_declared_effects",
  ],
} if {
  input.within_authority
  input.approval_valid
}

An allowed result authorizes an execution attempt. A separate runtime records the outcome and verifies the declared effects against authoritative post-state. It does not treat allowed as evidence that the intended effect occurred.

Question

Which contract would be clearer for downstream OPA consumers?

1. Keep record_execution_outcome and verify_declared_effects as obligations attached to the authorization decision.
2. Keep the authorization entrypoint limited to authorization and expose post-execution evidence requirements through a separate document or entrypoint.

The intended properties are:

• keep allowed distinct from verified;
• prevent authorization from being interpreted as proof of execution;
• preserve replayable decision logs;
• avoid coupling the authorization decision to executor-specific evidence formats;
• retain an explicit link between the authorized action and its required checks.

Is there an established OPA/Rego pattern for this separation?

If a separate document is preferable, should it be returned as a sibling decision document in the same evaluation, or exposed through a distinct entrypoint?

Reproduction and source

• Minimal Rego Playground reproduction- Version-pinned policy
• Version-pinned tests
• Policy-as-code documentation

The repository tests currently pass locally: 13/13.

.tools/opa/opa check examples/policy-as-code
.tools/opa/opa test examples/policy-as-code -v

Scope clarification: OPA is used only as the policy decision component. A separate developer-preview runtime handles approval binding, execution, receipt creation and post-state verification. This is an independent integration, not an OPA-maintained or endorsed component.