Four Root-Cause Patterns Behind Underperforming Output

Why naming the cause comes before fixing it

When an output disappoints, two unproductive instincts take over. One is to give up and conclude the tool simply cannot do the task. The other is to thrash, changing random things until something happens to work. The Claude Certified Associate - Foundations (CCAO-F) exam replaces both with a diagnostic habit, and the foundation of that habit is knowing that underperformance is not a single undifferentiated problem. It has four separate root causes, each producing similar-looking bad output but each demanding a different fix.

This is a remember-level knowledge point for a reason: you cannot run a diagnostic sequence, read symptom timing, or match a scenario to a remedy until you can name the four patterns cleanly. Get the taxonomy wrong and every downstream decision inherits the error. So the starting skill is simply this: hold the four causes in mind as distinct categories, and resist collapsing them into one vague sense that the prompt needs work.

Under-specification and context overload

Under-specification is the most common cause and the cheapest to fix. The prompt itself left out something the task needed: the context that frames the request, the constraints that bound it, or the format the answer should take. Claude answered the question it was actually asked, which was not quite the question you meant. The fix is to add what was missing, and because the problem lives entirely in the prompt, it costs almost nothing to correct.

Context overload is a different animal. A long conversation has grown toward the limit of the context window, and to make room, earlier content gets automatically summarised. Detail compresses, and the early instructions that were once crisp lose their force. Nothing about the prompt is wrong; the problem is that the conversation has simply gotten too big. Rewriting the prompt does not help here at all. The fix is to restart, or to carry forward a summary, so the window is focused again.

Wrong feature or model, and stale configuration

The third cause is choosing the wrong feature or model for the task. A calculation asked for in prose, when it should have run through code execution, produces numbers that are subtly off. A task needing deep, careful analysis, handed to a model tier chosen for speed, produces something shallow. The output is not bad because the prompt was unclear; it is bad because the wrong tool was pointed at the job. The fix is the right feature or the right model tier, not more prompting.

The fourth cause is stale configuration. A standing instruction, a knowledge source, or a Skill that used to work has drifted out of date, and it is now quietly degrading output. This is the "it used to work" case: the same setup that produced good results last month no longer does, because something it depends on has changed underneath it. The fix is maintenance of the configuration, not any change to the prompt or the conversation. This is closely related to reading symptom timing, which is how you tell these four apart in practice.

What the CCAO-F exam trips candidates on

The first trap is treating every bad output as the same generic "prompting problem." A scenario will describe a disappointing result, and the tempting answer is always "the prompt needs to be better." But rewriting a prompt does nothing when the real cause is a conversation that has overloaded the window, or a knowledge file that has gone stale. The exam rewards naming the specific pattern, because the fix follows from the name.

The second trap is assuming one fix solves all four cases. Adding detail to a prompt is the right move for under-specification and useless for the other three. Restarting the session fixes overload and is irrelevant to a wrong model tier. The four causes are genuinely separate, with genuinely separate remedies, and the exam tests whether you have internalised that separation rather than defaulting to a single favourite fix.

Common misreadings to avoid

How this shows up on the exam

Domain 7 questions on this knowledge point present a disappointing output and ask you to name the most likely cause, or they list the four patterns and ask which fix matches which cause. The reliable approach is to treat the four as a fixed vocabulary: under-specification, context overload, wrong feature or model, stale configuration, each with its own remedy.

This foundational point unlocks reading symptom timing to identify the cause, which turns the four categories into a fast diagnostic based on when the failure appears, and the cheapest-fix-first diagnostic sequence, which orders the checks so you rule out cheap causes before expensive ones. It also sets up the finer distinction in wrong feature versus wrong model, since those two share a symptom but need different fixes. Learn the four cleanly and everything downstream in this domain gets easier.