The Core Failure Taxonomy for Production Claude Systems

You cannot fix a failure you have not classified

When a production Claude system misbehaves, the instinct is to reach for a fix, usually "improve the prompt." The CCAR-P exam treats that instinct as the mistake. Production issues come in distinct classes, each caused by a different thing and each demanding a different remedy, so the fix that resolves one class does nothing for another. This remember-level knowledge point establishes the taxonomy and the discipline that goes with it: classify the failure first, because the classification determines the fix.

Four distinct classes

The taxonomy names four failure classes. Prompt failure happens when the instruction was ambiguous or underspecified and the model filled the gap in a way you did not intend; the root cause is in the prompt. Hallucination happens when the model produces confident, fluent content that is not grounded in the input or a reliable source; the root cause is missing grounding, not wording. Model mismatch happens when the chosen model tier is wrong for the task's complexity, or a model was swapped without re-evaluation; the root cause is the model selection. Orchestrator-workers failure happens in multi-agent systems when something breaks across the boundary between the orchestrator and its subagents; the root cause lives in the coordination, not any single call.

The reason to memorize these as separate classes is that their fixes are as distinct as their causes, clarify the prompt, add grounding, re-select the model behind an eval, or repair the orchestration boundary, and those are explored in the knowledge points that follow.

Classification is the first step, not the last

Because the fixes diverge, classifying the failure correctly is a prerequisite, not something you do after trying a fix. If you skip classification and apply a generic remedy, you will fix only the cases that happened to belong to the class your remedy targets and leave every other class untouched, while believing you have addressed the problem. The order is fixed: observe the failure, classify it into one of the four classes, then apply the matching fix. Reversing the order, fix first, understand later, is how teams burn cycles making a hallucination worse by rewording the prompt.

Why the failure is usually silent

There is a reason this discipline is harder for LLM systems than for traditional software. A conventional system tends to fail loudly, an exception, a crash, a stack trace, so failures announce themselves and monitoring can catch them automatically. An LLM system rarely crashes. It produces a response that is confident, fluent, and subtly wrong, and nothing in the logs flags it as an error because, mechanically, nothing errored. The harder-to-catch failure mode is exactly this quiet wrongness, which means failures have to be actively surfaced, through evaluation, monitoring, and human judgment, and then classified, rather than waiting for an exception that will never come.

What the exam trips candidates on

The first trap is applying a single generic fix, such as "improve the prompt," to every production issue regardless of which class it is. A scenario will describe a team that reflexively rewords the prompt for a problem that is actually a hallucination or a model mismatch; the credited reading insists on classifying the failure first and applying the class-appropriate fix.

The second trap is assuming a system with no crashes or exceptions in its logs has no failures. A scenario will present clean error logs as evidence of health; the correct answer points out that the dangerous LLM failure is a silently wrong response that never throws an exception, so clean logs are not clean output, and failures must be surfaced actively.

Common misreadings to avoid

How this shows up on the exam

Domain 4 questions on this knowledge point present a vague production symptom, wrong answers, poor quality, and either a reflexive prompt fix or clean logs offered as reassurance. The reliable move is to insist that failures be classified into the four classes before any fix, and to treat a subtly wrong, non-crashing response as the default LLM failure mode.

This taxonomy is the entry point for the diagnosis task statement. It splits into prompt failure vs hallucination and fixing model mismatch for the single-call classes, and into orchestrator-workers failure attribution for the multi-agent class, with change attribution handling why a metric moved. Surfacing silent failures depends on logging the four categories a production system must capture.