Generate execution receipts

The executor should attest what request it accepted and what response or uncertainty it observed.

01 / The operating case

What changes in a real workflow?

A bank times out during a payment release after the policy engine allowed it.

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

Bind decision ID and canonical request digest to idempotency key, downstream request ID, attempt time and explicit success, failure or unknown status.

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

03 / Failure and evidence

What goes wrong, and what can be proven?

Failure mode

An ALLOW is logged as a completed transfer, leading to an unsafe retry.

Evidence to retain

Keep downstream reference and later reconciliation separate from the permission receipt.

04 / Canonical scope

Why this reference stands alone

Decision receipts explain authorization; this guide captures the attempted effect.

Illustrative implementation artifact

Executor receipt states

{decisionId, requestDigest, idempotencyKey,
 downstreamRequestId, attemptedAt,
 status: COMMITTED | REJECTED | UNKNOWN,
 downstreamReference}

Primary references

Read the underlying material

Architecture discussion

Choose one consequential action and make its boundary explicit.

Request a Conversation