The incident record says “the model failed.”
That sentence is usually where the useful investigation stops. Before the answer reached the user, the request may have passed through prompt assembly, retrieval, routing, fallback logic, tool execution, and approval. Any of those may have been the first wrong step.
I want the review to start with the user’s symptom and end at that first divergence.
{
"model": "model-id",
"route": "reasoning-fallback",
"prompt": "rendered prompt snapshot",
"retrieval": ["doc-184", "doc-219"],
"tools": ["update_ticket_priority"],
"approval": "shown-diff-approved",
"firstMismatch": "stale retrieval result"
}
The rendered prompt matters more than the template. A template can be correct while the assembled prompt contains a stale retrieval block, a changed tool description, or a safety instruction buried below irrelevant context.
Retrieval needs its own evidence: query text, index version, document IDs, timestamps, ranking, and permission filters. A missing source is a different incident from a source that existed but was ranked out of view.
Tool output needs to stay intact too. A tool can return ok and still leave the workflow wrong:
{
"tool": "update_ticket_priority",
"arguments": {
"ticketId": "INC-1842",
"priority": "high"
},
"result": { "status": "ok" },
"verification": "no customer-impact check"
}
The ticket changed. That does not mean the incident is resolved.
Approval belongs in the same record. What did the user see? Was the action presented as a write, delete, publish, or vague continuation? Did the approval cover one action or an entire chain? If the final side effect differs from the approved action, the mismatch is part of the cause.
Replay is the standard I use. The team should be able to rerun the prompt, route, retrieval snapshot, tool schema, and approval state closely enough to test a fix. Perfect reconstruction may be impossible. No reconstruction is an operational failure of its own.
An AI incident review should leave a path from symptom to first wrong step to change made. “Model bad” is not a diagnosis.
Related posts

About Jeremy London
Engineering leader and builder in Denver. I write about AI platforms, agents, security, reliability, homelab infrastructure, and the parts of engineering work that have to survive production.