- In short
- Description is the discipline of telling the model precisely what you want. Applied to prompt design, a well-described prompt states its scope (what is in and out of bounds), its format (the exact output contract), and its constraints (rules that must never be violated), rather than leaving them for the model to infer. Underspecification is any requirement the output must meet that the prompt does not actually state; where the prompt is silent, the model fills the gap with its own assumption, and that assumption can vary across calls.
Description is a competency, not a nicety
Description is one of the four AI Fluency competencies: the discipline of telling the model precisely what you want. The Claude Certified Architect - Professional (CCAR-P) exam takes that general idea and applies it to prompt design at the understand level. The claim is specific: a well-described prompt names three things explicitly, the scope of the task, the format of the output, and the constraints that bound it, rather than leaving any of them for the model to infer. This is what separates a prompt that works in a demo from one that holds in production.
The reason description matters so much for a reused prompt is that anything you do not state, the model will supply on its own, and it will not supply the same thing every time. Precision in the prompt is how you remove that variance before it happens.
- Description in prompt design
- Applying the Description competency to a prompt by explicitly stating its scope (what is in and out of bounds), its format (the exact output contract), and its constraints (the rules that must never be violated). Where a requirement is left unstated, the prompt is underspecified, and the model fills the gap with its own assumption, which can differ from one call to the next.
Scope, format, constraints
A well-described prompt names three things. Scope is what is in and out of bounds: the boundaries of the task, including what the model should not attempt. Format is the exact output contract: the shape, fields, or structure the response must take. Constraints are the rules that must never be violated: the hard requirements the output has to respect on every call. These map directly onto the parts of a well-structured system prompt covered in system prompt structural components; Description is the competency you apply to write each of them precisely rather than vaguely.
The test for whether you have described the task well is not whether the prompt reads fluently. It is whether, for every requirement the output must meet, the prompt actually states it. A prompt can be well-written English and still be silent on a requirement that turns out to matter.
Underspecification: the gap the model fills
Underspecification is the central failure this competency guards against. It is any requirement the output must meet that the prompt does not actually state. The requirement is real, it exists in the designer's intent or in the surrounding context, but the prompt does not name it. And where the prompt is silent, the model fills the gap with its own assumption. The problem is not just that the assumption might be wrong; it is that the assumption can vary across calls. The same underspecified prompt can produce one interpretation today and a different one tomorrow, because nothing in the prompt pins the requirement down.
This is why underspecification is the enemy of a reused asset. A reused prompt needs to behave consistently across thousands of requests, and every silent gap is a place where consistency breaks. Diagnosing those gaps in an existing prompt is its own skill, developed in diagnosing underspecification gaps.
What the exam trips candidates on
The two traps both mistake something for specification that is not. The first is assuming a requirement is covered because it was implied by context rather than explicitly stated. A scenario will lean on context to argue a requirement is "obviously" handled; the credited reading notes that implication is not specification and the model may not share the inference. The second is confusing a prompt that "reads well" with a prompt that fully specifies scope, format, and constraints. A scenario will offer a fluent, professional-sounding prompt as evidence it is complete; the credited reading checks each requirement against what the prompt actually states.
Worked example
A team's summarisation prompt reads: 'You are an expert analyst. Write a clear, professional summary of the report for our executives.' It reads well, but the summaries come back at wildly different lengths, sometimes with recommendations and sometimes without, and occasionally including confidential figures. How should the architect apply the Description competency here?
The prompt is fluent and professional, which is exactly the trap: reading well is not the same as being well-described. Applying Description means checking each requirement the output must meet against what the prompt states, and here several requirements are only implied.
Length is unstated, so the model assumes one, differently each time, producing the varying lengths. Whether to include recommendations is unstated, so the model sometimes infers yes and sometimes no. The constraint against including confidential figures is not stated at all; it lives in the team's intent but never in the prompt, so the model has no reason to withhold them. Every one of these is an underspecification gap: a real requirement the prompt is silent on, filled by a model assumption that varies across calls.
The fix is to make each implicit requirement explicit. State the scope, an executive summary of the report's findings, excluding raw confidential figures. State the format, for example a fixed length and whether a recommendations section is required. State the constraint, never include the confidential figures named in the source. None of this makes the prompt read better in a literary sense; it makes it specify what the fluent version only hoped for, and the inconsistent output resolves because the model no longer has gaps to fill.
Common misreadings to avoid
Misconception
A requirement is covered as long as it is obvious from the surrounding context.
What's actually true
Misconception
A fluent, professional-sounding prompt is a well-described one.
What's actually true
How this shows up on the exam
Understand-level questions present a prompt and ask what makes it well or poorly described, or ask you to distinguish a fluent prompt from a fully specified one. The reliable answer checks whether scope, format, and constraints are explicitly stated and treats any unstated requirement as an underspecification gap the model will fill inconsistently.
This knowledge point applies the structure from system prompt structural components with the precision the Description competency demands, and it sets up diagnosing underspecification gaps, where you read an existing prompt for what it fails to say. Where a described constraint is high-stakes, structural enforcement of guardrails hardens it beyond a stated rule.
A summarisation prompt reads fluently but its outputs vary in length, sometimes include recommendations and sometimes not, and occasionally leak confidential figures. Applying the Description competency, what is the correct fix?
People also ask
What does it mean to describe a task well in a prompt?
What is underspecification in a prompt?
Why does the model fill silent gaps differently each time?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
No videos curated for this concept yet
We are still curating the best official and community videos for this topic.
Official prep for this domain
Anthropic's own free prep module for this part of the syllabus, on the official prep course. Free with an Anthropic Academy sign-in.
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.