01 / The operating case
What changes in a real workflow?
A payment API returns a timeout after accepting a transfer. The agent cannot infer that the transfer failed and safely repeat it.
- 01Authority origin
- 02Task and grant
- 03Current decision
- 04Observed outcome
02 / Decision contract
What the executor must check
Bind decision ID and idempotency key to the executor’s request; record status and downstream reference even when the outcome is unknown.
Architecture review / negative test
Make the boundary testable.
Define a receipt from the component that actually submits the effect, not from the model that proposed it. Include a decision reference, canonical request hash, idempotency key, executor identity, timestamp and downstream transaction reference. Distinguish accepted, rejected and unknown outcomes; a timeout is not evidence of failure.
03 / Failure and evidence
What goes wrong, and what can be proven?
A decision ALLOW is logged as if payment occurred; retries then create a second transfer.
Pair receipt with subsequent reconciliation of the bank record before classifying the observed outcome.
04 / Canonical scope
Why this reference stands alone
Observed-outcome verification owns the reconciliation step; this page defines the executor’s evidence contract.
Technical deep dive
A receipt must originate where the effect is attempted.
A model-generated message saying “done” is not execution evidence. The component that submits the protected operation should record the decision reference, canonical request digest, idempotency key, executor identity, time, provider response and transaction reference. Keep an unknown state when the response is lost. Pair that record with a later independent observation when the external system exposes one; neither receipt should overwrite the historical ALLOW or DENY decision.
Decision: ALLOW / policy P-17 / request hash H Execution: submitted / executor E-4 / key K Provider response: timeout → UNKNOWN Observation: payment ledger entry T-91 → COMMITTED Reconciliation links K, H and T-91
Run the negative test
Drop the provider response after the payment commits. A sound receipt cannot report failure merely because the caller timed out. Reconcile provider state before retrying with key K, and reject any retry whose canonical request hash differs from H.
Continue to Decision receipts for the adjacent boundary.
Architecture field test
Three evidence states, not one success flag
Did the protected system actually execute?
- 01Authorization decision
- 02Executor attempt and response
- 03Independent state observation
- 04Reconcile unknown outcomes
Work the boundary
A firewall API accepts a rule update and returns a request ID. Edge propagation fails. The decision was ALLOW and the API attempt was accepted, but the observed edge rule remains unchanged. An audit should keep all three facts.
| Required facts | Decision ID and request digest, idempotency key, downstream request ID, response or timeout, observed resource version. |
|---|---|
| Allow only when | A receipt states COMMITTED only when the executor has authoritative commit evidence. |
| Deny when | A 200 from an intermediate tool or a timeout is recorded as a completed real-world effect. |
Break the assumption
Drop the provider response after the commit. Retry with the same idempotency key and reconcile the provider reference before another mutation. Never infer DENY or success from a network timeout alone.
Design tradeoff
Outcome verification may lag the action. A truthful UNKNOWN state is more useful than a false success claim; time-bound reconciliation and escalation make it operational.
For three evidence states, not one success flag, consult NIST NCCoE agent identity and authorization concept. This worked decision and negative test are ProofGrid analysis.
Continue with Observed outcome verification.
Primary references