After a consequential AI-assisted decision, “the model did it” is not an explanation. An authorised reviewer needs to reconstruct what the system knew, what it was allowed to do, what happened, who intervened and which version was operating.
An AI system is meaningfully auditable when that reconstruction can be made from retained evidence without relying on memory. This is an architecture test, not a claim of regulatory compliance or certification.
Logs are necessary but not sufficient
A technical log may show that an endpoint returned 200. It may not show which business record changed, which policy applied, whether an approval was valid or what a person saw when intervening. Conversely, a decision memo may name an outcome but omit the model, prompt, tool version or source state.
NIST AI RMF and its Playbook emphasise accountability, documentation, human oversight and lifecycle risk management. W3C PROV provides concepts for entities, activities, agents and provenance relationships. ISO/IEC 42001 describes a management-system approach for AI policies and processes. The evidence model below combines those concerns into a netlinkE reconstruction framework; it is not a substitute for a jurisdiction-specific audit requirement.
The accountability evidence model
| Evidence object | Reconstruction question | Minimum useful record |
|---|---|---|
| Decision context | What business event and consequence were in scope? | Case ID, purpose, affected process and timestamp |
| Source and provenance | What information was used and where did it come from? | Source IDs, retrieval/version time, permitted-use status |
| Authority | What was the system and each person allowed to do? | Role, permission, threshold and policy version |
| Action | What did the system propose or execute? | Tool, parameters, output and resulting state change |
| Approval | Who accepted which action based on what evidence? | Reviewer identity, displayed evidence, decision and time |
| Exception | What departed from the normal path? | Detection, classification, impact and route taken |
| Intervention | What did a person change, stop or override? | Actor, reason, before/after state |
| Version state | Which model, prompt, workflow and rule set ran? | Deployable version identifiers and configuration reference |
| Recovery | How was harm contained or state reconciled? | Stop, rollback or compensation record and outcome |
| Measurement | What outcome and guardrail changed? | Baseline, observed result and review decision |
Design around one reconstruction identifier
Assign a durable case or decision identifier before work crosses systems. Carry it through retrieval, model invocation, tool calls, approval, business-record updates and incident handling. Without it, evidence becomes a collection of timestamps that investigators must correlate probabilistically.
Do not put every sensitive input into one giant log. Store references and integrity information where appropriate, apply access controls and retention rules, and preserve enough context for an authorised review. Auditability must coexist with data minimisation and confidentiality.
Preserve the authority that existed at the time
Current permissions do not prove historical authority. Record the relevant role, policy and configuration version at the event. If approval was required, retain who approved, what they were shown and which action they accepted. A generic “human reviewed” flag is weak evidence.
For automated action, capture the precise tool operation and its business effect. Separate a proposed action from an executed one. Record partial failures and external side effects even when the agent reports failure.
Make exceptions first-class evidence
Normal-path logs rarely reveal whether the system is governable under stress. Record missing sources, conflicting instructions, approval timeouts, failed writes, repeated tool calls and human overrides. Each exception should lead to a known state: contained, awaiting review, compensated or unresolved.
Test reconstruction during exercises. Give an independent reviewer a case identifier and ask them to explain the event using retained evidence. Measure missing links, time to reconstruct and whether recovery can be verified.
The accountability review
Before increasing scope, answer four questions:
- Can we reconstruct representative and failed cases end to end?
- Can we distinguish source, recommendation, approval and action?
- Can we identify the exact authority and version in force?
- Can we show containment, rollback or compensation where needed?
If not, the system may still produce useful outputs, but it is not yet meaningfully accountable under this model.
Sources and scope
NIST, W3C and ISO materials are external governance and provenance references. The ten-object accountability evidence model and reconstruction review are original netlinkE analysis. This article makes no certification, regulatory-compliance or legal-advice claim.
