A failure register with one bucket cannot produce a root cause. When a model defect, a provider stall, a bad route, and a broken check all land as the same row, none of them can be acted on, and the silent retry that rescues the run deletes the evidence that it ever failed.
Every AI incident review I have sat in, ours and other people's, opens with a version of the same four words: the model was bad. It is offered as a conclusion and usually accepted as one. Then the ticket closes, someone notes that we should try a different model next quarter, and the meeting moves on.
To be fair to the instinct, "the model was bad" is true in roughly the way "the server was slow" is true. It names a symptom, it names the component you control least, and it ends the conversation where the useful work starts. In a regulated shop that is not a root cause, it is a category error that got promoted to a category.
I have argued before that a green agent dashboard tells you the service answered and nothing about whether the answer was right. That post assumed the fix was scoring runs instead of pinging endpoints. Having lived with run-level scoring for a while, I can report that the binary is the next problem. A run that failed and a run that failed for an identified reason are different artifacts, and only the second survives a second-line reviewer.
The agencies just handed the register design back to you
On April 17, 2026 the Federal Reserve, the OCC, and the FDIC issued SR 26-2, Revised Guidance on Model Risk Management (opens in new tab), which in the agencies' own words "supersedes and replaces SR letter 11-7." Anyone who spent a decade mapping controls to SR 11-7 should read the replacement closely, because it says something easy to misread (opens in new tab): "Generative AI and agentic AI models are novel and rapidly evolving. As such, they are not within the scope of this guidance."
Treat that as an exemption at your own risk. The same document continues that "a banking organization's risk management and governance practices should guide the determination of appropriate governance and controls for any tools, processes, or systems not covered in this document." The agencies did not excuse agentic systems from governance. They declined to specify it, which means the design of the record is yours and you will be examined against your own design. If that design is a one-column failure log, it is the standard you volunteered for.
The guidance is also precise about what monitoring is for: "Outcomes analysis compares model outputs to corresponding real-world outcomes to assess model performance relative to model objectives and business use." You cannot compare an output to an outcome when your record of the output is the word "failed." For anything you did not build, it adds that sound practice means monitoring "whether vendor models are accurate, remain fit for purpose, and continue to be reliable," three findings a single bucket collapses into a shrug.
One bucket is the same as no register
Security operations solved this years ago and we forgot to carry the lesson across. No SOC I have run would accept "the network was bad" as a disposition; we classify into misconfiguration, credential compromise, detection gap, false positive, upstream outage. Classification routes a finding to the owner who can fix it, and it is why a trend line means anything later. Here is the taxonomy I would want on an AI failure register, each row carrying a different owner and a different remedy:
- Wrong output. The answer was incorrect, ungrounded, or unsupported by the source it cited. The only row that is genuinely a model verdict.
- Incomplete output. Part of the task was performed and returned as though finished. Different detection, different fix, often the most expensive one.
- Wrong tool or authority. The system reached for a capability it should not have, or used a permitted one against the wrong object.
- No output. Provider error, throughput stall, timeout, rate limit, capacity rejection. A counterparty event, not a capability event.
- Wrong route. The request landed on a different model, endpoint, region, or effort setting than the lane specified.
- Check failed. A control rejected the output and worked as designed. A failure for the run and a success for the control.
- Check was wrong. The control rejected a good output or passed a bad one. A defect in your control environment, not in anyone's model.
- Human judgment. The output was valid and unacceptable anyway. Taste, tone, risk appetite.
Eight rows, and exactly one means what people mean when they say the model was bad. The other seven route to a vendor manager, a platform engineer, a control owner, or a business owner. Collapse them and you get both bad outcomes at once: a model swap that fixes nothing, and a real deficiency buried under infrastructure noise.
A provider stall you filed as a model defect is a credit you forfeited
Attribution is not an accounting nicety, because on the provider row there is money attached. The Amazon Bedrock service level agreement (opens in new tab) pays a service credit of 10 percent of the affected region's charges when monthly uptime falls below 99.9 percent but stays at or above 99.0 percent, 25 percent below 99.0 and at or above 95.0 percent, and 100 percent below 95.0 percent. To collect, the request has to reach AWS by the end of the second billing cycle after the incident, with "the specific dates, times, and Availabilities for each 5-minute interval with less than 100% Availability" plus "request logs that document the errors and corroborate your claimed outage."
Read that as a control requirement, not a billing footnote. A provider event you filed as a model defect is simultaneously a forfeited contractual claim and a corrupted model verdict. You paid twice: once in the credit nobody claimed, once in the quarter your team spent evaluating replacement models for a problem the vendor's capacity planning caused. The evidence also has a shelf life measured in billing cycles, so the classification has to be right at the moment of failure.
I own both security and DevOps at a fintech platform sitting behind more than 1,500 financial institutions, so I hold the availability conversation and the correctness conversation with the same vendors in the same week. They need different evidence. We pin model traffic to endpoints we chose rather than accepting whatever routing maximizes availability, precisely so "the request went somewhere else" and "the answer was wrong" stay separable rows. When a stall and a hallucination look identical in your log, you have neither an enforceable SLA nor a defensible model assessment.
The retry is where your evidence goes to die
Now the harder failure, and the one I find in mature shops rather than sloppy ones. A well-built harness detects a failed check, feeds the failure evidence back to the model, and retries. That is good engineering. It is also, if you log only the final disposition, an evidence-destruction mechanism running in production with your blessing.
A run that succeeded on the first attempt and a run that succeeded on the third are two different control claims. The first says your system produced acceptable work. The second says your system produced unacceptable work, caught it, and recovered, which is a stronger claim about your controls and a considerably weaker one about your model. If you record verdicts instead of attempts, you have deleted the failure from the record and kept only the reassurance.
Control effectiveness testing has always cared about this. When an auditor tests a change control they do not ask whether the deploy eventually succeeded; they ask whether the control operated as designed each time it was invoked. First-attempt pass rate answers that for an AI lane. Eventual pass rate is a reliability figure, useful for capacity planning and close to useless as control evidence. So the register wants one row per attempt, each carrying attempt number, resolved model identifier, provider, endpoint and region, the check and its version, the verdict, and the raw check output, because a verdict without the raw output is an assertion.
A check that has never rejected anything is an untested control
Which raises a question almost nobody asks about their own evaluation layer. Has your check ever failed a known-bad input? Not in principle: in your repository, against a fixture, on a schedule. I have written that a policy expressed as prose is context rather than enforcement, and hard requirements need hard checks. The follow-on question is whether the hard check works, and answering it requires a negative fixture, a deliberately bad artifact the check must reject, run before you trust a single green result. This is the same finding an auditor writes for a detection rule that has not fired in eighteen months. The rule is not proof of coverage, it is an untested control wearing coverage as a costume, and every green result it produced inherits the doubt.
That is why "check was wrong" needs its own row. Without it, a broken grader quietly becomes your acceptance standard and a team burns a quarter tuning prompts to satisfy a control that was measuring the wrong thing all along. I watched a version of this with a schema validator that turned out to be permissive about a nested field. The model was fine. The register said otherwise, because it had one column.
Half of what governed the run is NOT_EXPOSED, and that is a finding
Here is where honesty has to intrude, because a register records only what you can observe, and you cannot observe all of it. You can inventory your own harness: instruction files, skills, tool schemas, permission scopes, retrieval sources, the model you asked for. You cannot inventory the vendor's system prompt or its routing logic.
The best available case is instructive rather than reassuring. Anthropic is unusually transparent and publishes the system prompts for its consumer surfaces (opens in new tab), while stating that "this prompt is periodically updated to improve Claude's responses." One of those published prompts goes further and tells the model that "the visible tool list is partial; many tools ... are deferred and loaded via tool_search." So even where the vendor publishes the text, the instruction layer changes on the vendor's schedule with no change ticket in your system, and the tool surface for a given run is resolved at runtime by a mechanism you did not configure and cannot replay.
The consequence is precise, and it is not a complaint about vendors. A static inventory of what you configured is not evidence of what shaped a particular run. Only a run-level record answers what an examiner asks, which is what governed this decision on this date, and part of that record sits permanently outside your boundary. Even the standard instrumentation concedes the gap: the OpenTelemetry GenAI semantic conventions carry gen_ai.request.model for the model a request is made to and a separate gen_ai.response.model for the model that generated the response, because the authors knew those two values diverge. Most teams populate the first with a family name rather than a resolved identifier and never notice the second exists. Same failure as three tools reporting three token counts: not a data-quality problem, an attestation problem.
So label the gap instead of faking completeness. I use three words for control inputs in run records: VERIFIED when the input is captured in a trace we control, INFERRED when we reconstructed it from surrounding evidence, NOT_EXPOSED when the vendor does not surface it. Marking a row NOT_EXPOSED feels like an admission and functions as the opposite. Examiners have seen plenty of complete-looking artifacts, and a map with its holes drawn beats a map without holes, because the second one is always a lie and everyone in the room knows it.
Then the label has to change a routing decision or it is decoration. Ours is blunt. Any workload whose effective instruction set cannot be reconstructed after the fact does not carry regulated data and does not take an irreversible action. It can draft, summarize, and propose. It cannot move money, change entitlements, or write to a system of record unless a control we own sits between the output and the effect. That is owning the harness and renting the reasoning, one layer down: every load-bearing check runs where we can prove it ran, and its result lands in our register, not the vendor's.
The register is the cheapest thing on this list
None of this needs a platform purchase. It is a schema change, a typed enum, and the discipline of writing one row per attempt instead of one per outcome. The expensive part is cultural: refusing to accept a disposition that names the model when nobody has ruled out the provider, the route, or the grader.
So here is the exercise I would hand any CIO or CISO with agents in production. Pull your last ten AI failures and count how many are typed. If ten out of ten say some version of "the model underperformed," you do not have a model problem yet, you have a classification problem busy manufacturing model problems, and you are one examination away from learning that your own register was the standard you got held to. I would genuinely like to hear how other teams draw the attempt-versus-outcome line in their run records, and whether anyone has found a vendor willing to expose enough trace detail to move a NOT_EXPOSED row into the VERIFIED column.