Most AI product roadmaps are organised around capabilities: add retrieval, improve answer quality, connect another tool, support another channel, reduce latency. Those are legitimate investments, but they assume the main question is what the system should do next. In production, the more important question is often how the system can fail and what capability is required to contain that failure.
A failure taxonomy should therefore come before the feature backlog. It gives product, engineering, risk, operations and domain teams a common language for classifying breakdowns and deciding which ones deserve roadmap priority.
The problem with a generic “model error” category
When an AI workflow produces a bad outcome, teams often label it hallucination, prompt failure or low confidence. That diagnosis is too broad to guide product decisions. The model may have interpreted the request correctly but used stale evidence. It may have recommended a valid action that policy did not permit for this customer. The tool call may have succeeded technically while the downstream business state remained incomplete.
Treating all of these as model-quality problems leads to more prompt tuning and evaluation while the operating weakness remains.
A six-part failure taxonomy
Interpretation failure occurs when the system resolves the wrong intent, subject, identity or requested outcome. The product response may involve confirmation UX, structured intake or identity checks rather than a different model.
Evidence failure occurs when the system retrieves incomplete, stale, conflicting or out-of-scope information. The response may require source ownership, freshness rules, versioning and retrieval constraints.
Policy failure occurs when the system applies the wrong rule, misses an exception or acts where decision rights are unclear. The response is usually policy-as-code, domain ownership and deterministic validation.
Execution failure occurs when a tool action is rejected, duplicated, partially completed or timed out after acceptance. The response requires idempotency, transaction state and compensating action.
Confirmation failure occurs when the system mistakes a technical response for a verified business outcome. The response is to define success in the system of record and wait for durable confirmation.
Recovery failure occurs when the workflow detects a problem but cannot return to a known state or hand the case to a human with sufficient context. The response is a recovery contract, escalation service and operator evidence package.
Prioritise by consequence, not frequency alone
Once failures are classified, product teams can score each class using frequency, impact, detectability and containment cost. A rare failure that creates an irreversible financial or safety outcome may deserve priority over a frequent but harmless wording defect. A highly detectable problem with a reliable fallback may be acceptable at launch; an invisible partial execution may not be.
This makes roadmap trade-offs more defensible. “Improve groundedness” becomes targeted investments tied to evidence failures. “Add human in the loop” becomes a design for specific policy or recovery failures, with clear entry criteria and context requirements. “Increase autonomy” becomes conditional on the classes the system can detect and contain.
Connect the taxonomy to release gates
The taxonomy should shape test design. Each high-impact failure class needs at least one realistic scenario that forces the workflow through the relevant state. Tests should verify not only the final message but also identity, policy version, tool requests, approval history, downstream confirmation and recovery state.
It should also shape observability. Instead of a dashboard limited to latency, token use and answer scores, teams can track failure-class rates, time to verified outcome, manual correction, repeated exceptions and customer promise breaches.
Turn the taxonomy into portfolio governance
The same taxonomy can be used across multiple AI products. Portfolio leaders can compare where risk is accumulating and avoid funding the same control repeatedly in separate teams. If several products experience evidence failures, the enterprise may need a shared knowledge-freshness service rather than five retrieval projects. If execution and confirmation failures dominate, investment belongs in the tool and workflow layer before another model upgrade.
This comparison also improves sequencing. A team may want to launch a new autonomous action, but the portfolio view may show that the required recovery service, identity propagation or policy evaluator does not yet exist. Building that shared capability can enable several product roadmaps while reducing duplicated controls.
The taxonomy should remain small enough to use. Teams can add domain-specific subtypes, but the top-level categories should be stable so incidents, evaluations and investments can be compared over time. A classification that operators cannot apply consistently will create reporting theatre rather than learning.
The goal is not another governance document. It is a practical operating model. Each failure category should have an owner, a detection signal, an acceptable threshold and a roadmap response.
Features still matter. But in enterprise AI, the ability to add a capability is not the same as the ability to operate it. A failure taxonomy makes that difference visible and helps teams invest in the less glamorous capabilities—confirmation, containment, recovery and ownership—that determine whether AI can be trusted in production.
