An AI failure needs a name before it needs a dashboard

“Bad output” told us almost nothing

An AI workflow can return a syntactically valid answer and still fail. The retrieval may be wrong, a tool may return stale data, the model may ignore evidence, an agent may loop, or the final response may violate a business rule.

If every one of those becomes “bad output,” how can a team know what to fix?

A valid response can still be a system failure

Traditional exceptions tell us where software stopped. AI evaluation must also tell us how a system remained operational while becoming incorrect.

I use a layered fault model:

input -> retrieval -> reasoning -> tool use -> output -> policy
          wrong       weak         failed      malformed  violated

The layer is only the first coordinate. A useful record also needs severity, reproducibility, affected capability, likely owner, and evidence from the trace.

The vocabulary came before the dashboard

The taxonomy becomes a contract shared by evaluators, traces, dashboards, and regression tests. A retrieval failure should not be mixed with a hallucination. A tool execution timeout should not be scored as reasoning quality. A schema violation should be visible even when the semantic answer looks correct.

Automated metrics can contribute evidence without becoming the entire verdict. Retrieval metrics, groundedness checks, structured-output validation, trace rules, and model-based graders each cover a different failure surface. The framework combines them into a normalized result that can be compared across runs.

Once categories are stable, regression detection becomes meaningful. Instead of asking whether one global score fell, the system can say that a prompt revision improved answer relevance but increased unsupported claims in a specific workflow.

I started with metrics too early

The temptation was to begin with metrics because tools make metrics easy to generate. But a metric without a failure model creates impressive graphs and weak decisions.

It was also tempting to make the taxonomy extremely detailed immediately. That produces categories nobody can apply consistently. The better approach is a small stable hierarchy with an escape hatch for “unknown,” followed by refinement from observed failures.

What remains true after the implementation

Observability begins with vocabulary. The dashboard is downstream of the language used to describe failure.

A good taxonomy is not merely reporting infrastructure. It shapes ownership, testing, debugging, prioritization, and eventually the architecture itself. If the system cannot state how it failed, it is not yet ready to learn from failure.