KAIRONULL

AI Incident Evidence Reconstruction: A Practical Guide

KairoNull · Published and reviewed 14 October 2026

When an AI-assisted workflow causes an unexpected outcome, the first useful question is concrete: can the team reconstruct what happened to one decision? A model response alone rarely explains which version of a policy was applied, who approved an exception or whether the resulting action succeeded.

This guide describes a bounded review of one decision. It is an operational method, not a legal opinion, an incident-response service or a guarantee that missing evidence can be recovered.

Start with one decision and one timeline

Select a decision identifier and a defined time window. Record the workflow owner, the action being investigated and the systems involved. Preserve available original records through your approved incident-handling process before creating working copies. Keep personal information and access credentials out of public examples.

The evidence to connect

  1. Request and released response: the relevant input, the response actually released and identifiers linking them. A draft response is not evidence of what reached the user.
  2. System configuration: available model identifier, application version and relevant prompt or configuration version. Note any version you cannot establish.
  3. Policy in force: the policy version applicable at the time and the result of the policy check.
  4. Approval or override: who or what authorised the action, when, and how that authorisation connects to the released response.
  5. Action and outcome: the downstream action, execution result and any retry, reversal or escalation.

Distinguish a missing record from a failed control

If an approval record cannot be located, the supported finding is that approval is not currently provable from the supplied material. That does not establish that approval never occurred. Conversely, a record saying “approved” does not establish that the correct person approved the exact action taken.

Use explicit findings: PROVEN, PARTIALLY PROVABLE, NOT CURRENTLY PROVABLE or UNKNOWN. State the evidence and limits beside each finding. Separate changes to the operating process from changes needed to capture evidence.

A synthetic account-recovery example

Suppose a system recommends recovering an account. The available records show the request, an AI response and a successful reset. The approval event is missing, and the policy record has no version. The outcome may be established while the authorisation path remains unproven. This is an illustrative example, not a customer deployment or a claim about a real incident.

What integrity verification can establish

Hash chains and timestamp evidence can help detect changes to recorded material when the necessary verification material is available. They cannot establish that a source record was truthful, that capture was complete or that the original decision was correct. A coordinated rewrite cannot be ruled out by comparison with a manifest controlled by the same party alone.

Read the verification methodology and inspect the synthetic sample audit report for the distinction between evidence integrity and evidence coverage.

Turn the findings into a bounded next step

The KairoNull AI Evidence Readiness Assessment reviews one to three workflows and attempts to reconstruct one selected historical decision for the engagement. The Evidence Readiness Record identifies supported findings and gaps in the supplied material. Scope and handling arrangements are agreed before records are shared.

Review the assessment scope, or read the account-recovery evidence checklist to prepare an identity workflow.