Key takeaways
- Keep two linked histories: the definition trail explains how the SOP changed; the run trail explains what happened in one execution.
- Every run must name the exact SOP and workflow version used. A timestamp beside the latest document is not enough.
- Record decisions as before-state, evaluated rule, outcome, actor and evidence reference so another person can replay the reasoning.
- Test the trail by reconstructing one awkward case without asking the original operator what they remember.
Separate how the rule changed from how the work ran
| Trail | Question | Minimum events |
|---|---|---|
| Definition | Why did the approved procedure change? | Proposed, redlined, reviewed, approved, effective, retired |
| Run | What happened to this case under that procedure? | Started, step completed, decision, exception, approval, effect, finished |
Document version history alone cannot prove that a run followed the document. A list of run timestamps cannot prove which rule was in force. The join is explicit: every run-start event names the SOP version and compatible workflow version.
ISO 9001 covers documented information, controlled operation, performance evaluation and improvement. An audit trail supports those activities, but this general event model does not by itself establish conformity with ISO 9001 or any sector-specific rule.
Use one event envelope across both histories
| Field | Purpose | Example |
|---|---|---|
| event_id | Deduplicate and cite the record | evt_0187 |
| occurred_at | Order events using a declared time standard | 2026-07-31T16:04:21Z |
| actor | Name the person, service or policy engine | role:vendor-data-owner |
| action | Use a stable event vocabulary | proposal.rejected |
| subject | Identify the SOP, clause, run or step | run:SC-2048 |
| version | Bind the event to approved instructions | sop:2.4 / workflow:4.1 |
| before_after | Show the state transition or exact proposal | Address diff or status change |
| reason_rule | Record human reason or evaluated rule ID | missing-region |
| evidence_refs | Point to source artifacts without copying secrets | Request and approval record IDs |
| correlation | Join retries, approvals and external effects | SC-2048 |
Reconstruct one awkward run from the record
Run start: request SC-2048 entered under SOP 2.4 and workflow 4.1. The request proposed a supplier-address change; the stored evidence references point to the submitted form and supporting file.
Decision: rule region-required passed, while duplicate check address-used-by-3 created human review. The vendor-data owner rejected the exact proposal because the supporting document named a different legal entity.
Effect: no supplier record changed. The run closed as rejected. The packet contains the proposal hash, source references, decision identity, reason and final-state check. Values and identifiers are illustrative.
A useful audit test gives this packet to a reviewer who did not handle the case. They should be able to state what was proposed, which rule created review, who had authority, why it was rejected and whether an external effect occurred. Any phone call needed to fill a gap identifies a missing event or evidence reference.
Check completeness, integrity and usefulness separately
| Quality | Test | Common false comfort |
|---|---|---|
| Completeness | Can all required states and effects be accounted for? | A high log volume with missing approvals |
| Integrity | Can records be altered, reordered or detached without detection? | Read-only interface backed by editable rows |
| Usefulness | Can an operator retrieve and understand the evidence in time? | Raw technical logs with no business context |
Set access, retention and redaction rules before broad collection. More data can create more exposure without improving replay. Keep secrets and unnecessary personal data out of event payloads; store controlled references instead.
For AI-specific provenance such as model, prompt, retrieved evidence and tool authority, extend this design with the AI agent audit-trail envelope. The SOP trail remains the source for which operating rule was approved.
Limitations and when not to use this
- Audit trails are evidence, not proof that a decision was correct or a procedure was adequate. Review content as well as event presence.
- Retention, electronic signatures, employee monitoring and regulated records may carry jurisdiction- or sector-specific requirements that this guide does not determine.
- Tamper evidence, independent time sources and durable storage require technical controls beyond the event fields shown here.
Sources
- ISO 9001:2015 — Quality management systems — International Organization for Standardization Accessed 31 July 2026
- AI Risk Management Framework Playbook — National Institute of Standards and Technology Accessed 31 July 2026
Set up the change loop
Use the audit record as evidence for owned, reversible procedure updates.
Set up the change loopUli Prantz
Builds and operates all-agents
Uli Prantz builds all-agents, the process-automation platform this site documents. He writes about the operational side of automating recurring business work: where deterministic code beats model judgment, where it does not, and where a human still has to approve.