Audit Evidence
When you need to explain a run afterwards — to an auditor, a customer, or yourself in three months — these are the things worth keeping, and the things to leave out.
Keep the instance ID, the definition name and version, how each step ended, and the event types in order.
The version matters more than people expect. Without it you cannot tell which code produced the run, and the whole record loses its meaning.
A projection explains the current view. The event stream is the record. Keep the stream.
For anything involving who acted, record: the provider ID, the account category, the principal reference, the source key and its version, and the resulting receipt.
Redact subject values you don’t need. If the question is “did the right kind of person approve this”, you rarely need the name to answer it, and a redacted record is one you can share.
Gate G9 — required implementation. Receipts are part of the authorization work that isn’t finished. Only record one when that is actually available. Until then, events and projections are your audit trail — and they’re enough for everything in the tutorial.
For a call to another system, or a source refresh, keep the stable event ID, the acknowledgement, and whether the call turned out to be a duplicate.
A request leaving your process is not success. The other side’s answer is. This is the single most common mistake in an evidence bundle.
The Day 1 state, Events, and audit checkpoint and the workshop route table show how to package this without copying sensitive data along with it.