Ten artefacts that make an AI-agent decision reviewable

Reviewable agent decisions depend on a small chain of artefacts connecting workflow purpose, authority, configuration, evidence, findings, controls and ownership.

Categories: Evaluation & assurance, Governance & privacy Series: Leadership and research

An AI-agent decision becomes reviewable when another qualified person can reconstruct what was proposed, what system was evaluated, what evidence was considered, what uncertainty remained and who accepted the outcome.

That does not require a bureaucratic archive. It requires a small chain of linked artefacts, scaled to consequence. The ten below support release, expansion, procurement and continued-operation decisions without pretending documentation itself is assurance.

Frame the workflow with two artefacts

1. Workflow decision brief. State the decision, intended outcome, users, process boundary, alternatives and consequence of error. Include why an agent is being considered instead of conventional automation or process change. Name the accountable workflow owner.

2. Authority and data-flow map. Show inputs, sensitive data, identities, tools, state changes, external destinations, confirmations, prohibited actions and handoffs. Mark where policy is enforced and how delegated user authority propagates.

Together they prevent a model-centric review. The NIST AI RMF Core links mapped context, roles, measurement and management; these two artefacts establish that context.

Identify the system with two artefacts

3. Configuration manifest. Record model/provider, prompts, tool schemas, retrieval sources, memory policy, orchestration, code and infrastructure versions, runtime settings and evaluation harness. Include dependencies that can change behind stable names.

4. Responsibility and change map. Name who can approve release, modify prompts or tools, change permissions, accept findings, operate monitoring, declare incidents and suspend service. Define which changes trigger reevaluation and which require a new decision.

The NCSC secure AI development guidance spans design, development, deployment, operation and maintenance. These records carry ownership and identification across those transitions.

Do not store secrets in the manifest. Store references to the controlled systems that manage them.

Make evaluation traceable with three artefacts

5. Evaluation plan and case register. Map requirements and risks to routine, boundary, fault and adversarial cases. Record provenance, expected outcome, grader and known coverage gaps.

6. Results and trace index. Preserve aggregated results, repeated-run variability, invalid runs, grader disagreement and stable links to representative traces. Check final state and tool behaviour, not only text output.

7. Findings and disposition log. For each material issue, record the requirement affected, evidence, plausible consequence, reproducibility, owner, treatment and decision effect: block, constrain, monitor, accept or backlog.

The GAO AI Accountability Framework combines governance, data, performance and monitoring. Those dimensions become concrete when cases, results and management dispositions remain linked.

Connect controls to operation with two artefacts

8. Control and recovery evidence pack. Document identity and authorisation enforcement, sandbox or egress boundaries, confirmation, logging, rate/value limits, rollback, kill switch and business restoration. Include test evidence and known gaps, not only control descriptions.

9. Operating evidence plan. Define post-release metrics, thresholds, alerts, review cadence, sampling, incident intake and regression updates. State what signal causes scope restriction, investigation or suspension and who acts.

A compact control table helps:

Control Evidence before release Evidence in operation Owner
Action authorisation Denied/allowed path tests Blocked-call trend and exceptions Identity owner
Recovery Fault and compensation drill Restoration time and unresolved state Operations owner
Evaluation freshness Release-suite result Change and incident-triggered reruns Product owner

The artefact is useful only when evidence can be retrieved during a review or incident.

Close with the decision record

10. Signed decision and obligations. Record the exact configuration and scope approved, decision owner, date, evidence considered, material dissent, accepted residual uncertainty, release conditions, open actions and expiry or review triggers.

Avoid “passed testing.” A useful decision says, for example, that the agent may draft cases for a defined user group while external actions remain disabled, subject to a 30-day evidence review and closure of a named finding.

The IIA AI Auditing Framework distinguishes governance, management and internal-audit roles. The signed record should preserve that distinction: evaluation and assurance inform the owner; they do not silently inherit the business decision.

Use stable identifiers and version control so a decision points to the exact manifest, plan, results, findings and controls considered. Keep raw traces and sensitive data in appropriate systems; the review record can reference them with access controls and sanitised summaries.

Automate generation where reliable—configuration, test runs and release metadata—but retain human judgement where consequence, scope and acceptance are decided. Check links and ownership as part of the release gate.

Reviewability does not guarantee a good decision. It makes a weak decision visible, a sound one explainable and either one revisable when the system or context changes. That is the practical foundation for accountable agent operation.

Scale the package without breaking the chain

Proportionality should reduce depth, not remove the connection between artefacts. A low-consequence internal assistant might use a two-page decision record linking a version manifest, a small evaluation set and standard platform controls. An agent that can alter customer or financial state needs deeper authority mapping, independent challenge, recovery evidence and more frequent operating review.

Use a minimum metadata header across the package: artefact owner, status, system/version, decision reference, last review, next trigger and authoritative location. This avoids public-facing workflow labels while keeping internal records accountable. It also helps automation identify stale evidence without judging whether the evidence remains adequate.

Perform a link test before the gate. Select one acceptance criterion and trace it forward to cases, results, findings, control and final disposition. Then start with one production alert and trace backward to the risk, authority and release condition it monitors. Broken links reveal decorative documentation.

After release, update artefacts through events rather than calendar ritual alone. A model or tool change updates the manifest and triggers scoped evaluation; an incident updates cases, findings and recovery evidence; an expanded user population revisits the workflow and authority map; a control exception appears in the decision obligations and operating plan.

Retire records deliberately. When an agent is decommissioned, preserve the decision history required for audit, incident or contractual needs, revoke identities, stop queued work and document data disposition. Reviewability includes knowing when authority ended.

The ten artefacts are therefore not a one-time pack. They are a living chain around a sequence of decisions. Keeping that chain small, linked and event-driven makes it more likely that leaders and practitioners will use it when the system changes under pressure.

Review the chain from three perspectives

Before approval, ask three people to traverse the package. The workflow owner should be able to connect evidence to business consequence and scope. An engineer or operator should be able to identify the exact configuration, controls and recovery steps. A reviewer outside the delivery team should be able to see assumptions, unresolved findings and the basis for acceptance.

Each perspective catches a different failure. A technically complete record can lack a meaningful decision; a clear executive summary can point to the wrong build; a large evidence archive can omit the one exception that changed scope. Resolve discrepancies in the authoritative artefacts rather than adding explanatory email.

Use access testing too. Confirm that expected reviewers can retrieve linked records and that sensitive traces remain restricted. Record lawful or contractual retention needs with qualified owners instead of keeping everything indefinitely. A link to evidence that has expired, moved or become unreadable is not traceability.

Finally, sample completed decisions during operating reviews. Check whether obligations were met, triggers caused reevaluation and incidents updated cases. The quality measure is not the number of documents produced. It is whether the chain helps the organisation detect changed assumptions and make the next decision with less ambiguity.

Get the agent release checklist

Working through this decision?

Build the evidence chain for one release, expansion or control decision.

A little more clarity

Questions worth asking.

Start with the questions that shape a better decision.

Must these artefacts be ten separate documents?

No. Several may live in one controlled record or system. The important qualities are clear ownership, versioning, linkage and retrievability.

Are all ten required for a low-risk assistant?

The depth should be proportionate to consequence. Lightweight records may be enough, but purpose, ownership, configuration and the basis for release should still be clear.

Do the artefacts prove that an agent is safe?

No. They make evidence, assumptions, controls and residual uncertainty reviewable. They do not eliminate unknown behaviour or replace accountable judgement.