Observed outcome verification

Observed-outcome verification compares the intended authorized effect with an independently observed state or authoritative downstream record.

01 / The operating case

What changes in a real workflow?

An agent receives HTTP 200 from a firewall API, but the rule has not propagated to the actual enforcement devices.

Trace the authority boundary
  1. 01Authority origin
  2. 02Task and grant
  3. 03Current decision
  4. 04Observed outcome

02 / Decision contract

What the executor must check

Correlate request and execution receipt with a later state query, define acceptable delay and mark unknown outcomes rather than reporting success.

InputPrincipal · task · action · target
DecisionGrant ancestry · policy · current state
ResultEnforce · record · verify outcome

Architecture review / negative test

Make the boundary testable.

Choose an authoritative observation source separate from the request response. A firewall control may require querying applied rules on devices; a payment requires a ledger or transaction reference. Define eventual-consistency windows and what operators see before confirmation. An observation is scoped to what the source can actually prove.

03 / Failure and evidence

What goes wrong, and what can be proven?

Failure mode

A successful transport response is treated as completed protection, hiding partial application or rollback.

Evidence to retain

Retain observed state, observation time, source and discrepancy status alongside the original decision.

04 / Canonical scope

Why this reference stands alone

Execution receipts describe what the executor attempted; this page owns the verification of what actually changed.

Architecture field test

Observation is a separate measurement

What changed after execution?

Decision path for this question
  1. 01Record intended target and state
  2. 02Capture executor reference
  3. 03Read authoritative state
  4. 04Classify match, partial or unknown

Work the boundary

An account-disable API replies accepted. A later authoritative directory read still shows the account active. The evidence record must say accepted but not confirmed, then alert or retry according to the operation contract.

Decision contract and failure case
Required factsPre-state, target ID, requested effect, provider reference, observation source and time, propagation window.
Allow only whenThe observed state matches the intended effect within the defined window and source of truth.
Deny whenA tool response is treated as proof when the target system still shows old state.

Break the assumption

Read from a lagging replica and then from the authoritative system. Test a partial effect where one of several regions changed. Preserve source and timestamp so a later reader can judge confidence.

Design tradeoff

Independent observation costs time and may require different credentials. For irreversible actions, that cost can be lower than the risk of declaring an unseen effect complete.

For observation is a separate measurement, consult NIST NCCoE agent identity and authorization concept. This worked decision and negative test are ProofGrid analysis.

Continue with Execution receipts.

Primary references

Read the underlying material

Architecture discussion

Choose one consequential action and make its boundary explicit.

Request a Conversation