Governance and Audit
What an Auditor Should Be Able to See After an Automated Process Runs
An audit record should reconstruct the operation as it happened. A success status and a pile of disconnected logs are not enough.
Governance and AuditPractical guide8 min read
The record should reconstruct one run from cause to outcome
After an automated process runs, an auditor should be able to see what triggered it, which inputs it used, which workflow version executed, which model version contributed where relevant, who approved any consequential step, what action was sent, what response came back and how the run concluded.
The evidence should be connected by a stable execution identity. Without that connection, teams are forced to compare timestamps across application logs, email approvals, pipeline history and spreadsheets. That reconstruction is slow and can still leave ambiguity about whether the records describe the same case.
Good execution evidence is produced as the operation runs. It is not a narrative written later to explain what people remember happening.
Start with the trigger and permitted input
The record should identify the event, schedule, file, webhook, request or database change that started the run. It should also show the actor or system identity responsible and the input values that policy permits to be retained.
Sensitive inputs need deliberate retention and visibility rules. Evidence does not mean exposing every payload to every reviewer. It means retaining enough attributable information, under configured access, to explain the decision path.
If data is transformed before use, the record should distinguish the source from the normalised form. Otherwise a reviewer cannot tell whether a later mismatch arose in the source system, the transformation or the target action.
Pin the workflow, rule and model versions
The current workflow definition may not be the one that ran six months ago. Each execution should identify the published workflow revision and the code or rule logic carried by it. Change history should show who authored and published revisions.
Where an AI model participates, the record should identify the endpoint and model version used to the extent the deployment makes that context available. A prompt and response without model context is difficult to compare after the model changes.
Version evidence does not guarantee a good decision. It establishes which controlled artefacts contributed to that decision so it can be reviewed or reproduced appropriately.
Show the authority, not just the word approved
When approval is present, record the named reviewer, their decision, the time, the relevant reason and the context presented. The workflow should preserve whether the reviewer approved, rejected, corrected, escalated or requested more information.
The action after approval matters too. An approval followed by a failed write is not a completed operation. The evidence chain should connect authority to the exact system action and its response.
If policy allows an action to run automatically, the record should show the policy path that permitted it. Human absence can be a governed decision rather than an unexplained gap.
Capture actions, responses, exceptions and final outcome
For each relevant step, retain the action attempted, target system, result and error path. Retries and partial completion should be visible. A workflow that updated one system but failed at another needs a different operational response from one that never started.
The final state should be explicit: succeeded, rejected, corrected, partially completed, failed or cancelled according to the workflow's vocabulary. Timestamps should make ordering clear without requiring manual correlation.
Nexus execution history connects triggers, versions, node results, approvals and outcomes inside the customer estate. It supports evidence gathering, but the organisation remains responsible for its retention policy, access controls and interpretation against any applicable framework.
Eight questions to ask of any automation record
Use these questions during platform evaluation or control design. They apply whether the process handles finance, infrastructure, security response or AI-assisted decisions.
- 01What initiated this exact run?
- 02Which source inputs and transformations were used?
- 03Which workflow, rule and code versions executed?
- 04Which model and version contributed, if any?
- 05Who approved or corrected the case, and why?
- 06What action was attempted against each target system?
- 07What response, retry or exception followed?
- 08Where is the complete evidence chain retained and who can access it?
Frequently asked questions
Is an execution log the same as an audit trail?
Not necessarily. An operational log may show technical events without connecting trigger, identity, versions, authority and outcome. An audit trail needs enough context to reconstruct the governed operation.
Should every input be retained?
No. Retention and visibility should follow the organisation's policy, especially for sensitive data. The record should retain enough permitted context to explain the run.
Does an evidence record prove compliance?
No. It can support an organisation's evidence requirements. Applicability, control design and compliance judgement remain the organisation's responsibility.
What if a workflow partially completes?
The record should show which steps succeeded, which failed, what retries occurred and which correction or review path followed. Partial completion must be an explicit state.
Related reading
- Governance and auditThe platform execution record, identity and version model.
- Compliance evidenceHow operational records can support evidence requests.
- AI governance in practiceThe additional model and assessment context required for AI workloads.
- ComplianceClear boundaries between evidence support and certification.
Evidence review
Bring one automated process and the evidence request it must answer.
We will map the trigger, versions, authority, actions and outcomes that need to remain connected after each run.