Design audit events for autonomous actions

An audit record should connect authority origin to decision, attempt and observed outcome without logging secrets.

01 / The operating case

What changes in a real workflow?

An investigator must reconstruct a payment that timed out and may have been retried.

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

Use stable correlation IDs across task, grant, approval, decision, executor request, idempotency key and settlement observation; encode unknown states explicitly.

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

Disconnected logs show an ALLOW but cannot establish whether one or two transfers occurred.

Evidence to retain

Retain integrity-protected timestamps, producer identity and minimal non-secret arguments.

04 / Canonical scope

Why this reference stands alone

Decision receipts and execution receipts own individual events; this page owns their shared event taxonomy.

Illustrative implementation artifact

Event linkage

taskId -> grantId -> approvalId -> decisionId
       -> executorRequestId -> observationId
shared fields: correlationId, producer, timestamp, version
UNKNOWN is a first-class effect state

Primary references

Read the underlying material

Architecture discussion

Choose one consequential action and make its boundary explicit.

Request a Conversation