Free lesson · Claude Certified Architect - Foundations (CCA-F)
Clarity, Specificity, and the Cost of Ambiguity
Where Domain 4 Fits
Domain 4 is 20 percent of the exam, and it covers how you write what you send to the model - prompts, structure, and the mechanisms that make output reliable.
That sounds like a soft topic next to permissions and architecture. It is not, because the exam approaches it the same way it approaches everything else: as design decisions with trade-offs, not as tips.
This first topic is about the most common source of unreliable output, and it is almost never the model.
The Model Fills Gaps Silently
A person given an unclear instruction asks what you meant. A model does not. It picks an interpretation and proceeds, and the result looks exactly as confident as a result from a clear instruction.
That difference is the whole reason clarity matters here more than in ordinary writing.
graph TD
A["An ambiguous instruction"] --> B["A person asks<br/>what you meant"]
A --> C["A model picks an<br/>interpretation"]
C --> D["Proceeds without<br/>mentioning it"]
D --> E["Output looks as confident<br/>as any other output"]
This diagram contrasts how people and models handle an ambiguous instruction. A person asks what you meant. A model picks an interpretation and proceeds without mentioning it, so the output looks exactly as confident as output from a clear instruction.
From Module 02, this is the ambiguity problem in its original form. There it was about task specifications for agents. Here it is about every prompt you write.
Important: Ambiguity does not produce an error. It produces a plausible answer to a question you did not quite ask. That is why unclear prompts are hard to diagnose - nothing looks broken, and the output is wrong in a way that only becomes visible when somebody checks it against what was actually wanted.
Vague Verbs Are the Main Culprit
The single most reliable source of inconsistent output is a verb with no defined finish.
| Vague | Specific |
|---|---|
| Analyse this data | List the three largest month-over-month changes with their percentages |
| Improve this text | Rewrite this at a reading age of twelve, keeping it under 200 words |
| Review this code | Identify any function that calls an external service without error handling |
| Summarise this | Produce five bullet points covering the decisions made and who owns each |
| Check this document | Confirm every figure in the summary matches the table it came from |
The left column describes an intention. The right column describes a deliverable.
Notice what changes between them. Every entry on the right could be checked by somebody else - you could tell whether it had been done properly. That is the same done-test from Module 02, applied to prompts.
Tip: Read your instruction and ask whether two competent people could disagree about whether it was completed correctly. If they could, the model will also disagree with you sometimes, and you will not know which times.
Say What You Want, Not What You Do Not
Negative instructions are weaker than positive ones, and it is worth understanding why rather than treating it as a rule.
"Do not be verbose" describes a large space of things to avoid and gives no target. "Keep it under 150 words" describes exactly one thing to hit.
| Negative | Positive |
|---|---|
| Do not use jargon | Use language a new team member would understand |
| Do not be too long | Three paragraphs maximum |
| Do not make things up | If a value is not in the source, write "not stated" |
| Do not include preamble | Start with the first finding |
The right column also has a property the left column lacks: you can tell whether it was followed. "Not too long" is a judgment. "Three paragraphs" is a fact.
That said, negative instructions are not useless. They are valuable specifically for the failure you have seen, when you already know what goes wrong.
Tip: Write positively by default and add a negative only after you have watched something go wrong. Speculative negatives - a list of things it might do that you would not like - cost tokens on every request and usually prevent nothing, because the model was not going to do them anyway.
Ambiguity Has Several Sources
Vague verbs are the obvious one. Four others are worth recognising.
Undefined scope. "Summarise the report" - all of it, or the findings? At what length?
Undefined audience. "Explain this" - to whom? An explanation for a specialist and one for a newcomer are different documents.
Undefined format. Prose, bullets, a table, JSON? If you do not say, you get whatever seems reasonable, and it varies.
Undefined handling of the unknown. What should happen when the information is not there? Without an answer, you invite the fabrication problem from Module 00.
graph TD
A["Sources of ambiguity"] --> B["Vague verb<br/>No defined finish"]
A --> C["Undefined scope<br/>How much?"]
A --> D["Undefined audience<br/>For whom?"]
A --> E["Undefined format<br/>What shape?"]
A --> F["Undefined unknowns<br/>What if it is missing?"]
This diagram shows five sources of ambiguity in a prompt. A vague verb with no defined finish. Undefined scope, leaving how much unclear. Undefined audience, leaving for whom unclear. Undefined format, leaving the shape unclear. And undefined handling of unknowns, leaving unclear what should happen when information is missing.
That last one is the most consequential and the least often addressed. It is worth its own habit.
Important: State what should happen when the information is not available. "If the date is not in the document, write 'not stated' rather than inferring one" costs a sentence and closes the most damaging gap in the whole list. Without it, the model has to decide, and a plausible guess is the natural thing to produce.
Specificity Is Not Length
A common misreading. Being specific means being precise, not writing more.
Weak, long: "I'd like you to take a careful look at this document and give
me your thoughts on what the main points are, keeping in mind that this is
for a business audience who may not have a lot of technical background, so
try to keep things accessible while still being thorough and complete."
Strong, short: "Summarise this in five bullets for a non-technical business
audience. Under 150 words total."
The second is a third of the length and considerably more precise. Every requirement in the first is present in the second, and none of the hedging survives.
Tip: Once a prompt is written, try cutting a third of it without removing any requirement. The words that go are usually softeners and repetition, and the prompt gets more precise as it gets shorter. This runs against the instinct that more explanation helps.
A Worked Improvement
Example: Starting point:
Look at these support tickets and tell me what the common issues are.Every category of ambiguity is present. What counts as common? How many should it list? What is a "tell me" - prose, a list? What if a ticket is unclear?
First pass - fix the verb and the scope:
Group these support tickets by root cause. List the five most frequent causes with the number of tickets in each.Better. There is now a done test.
Second pass - add format and the unknown case:
Group these support tickets by root cause. Return the five most frequent causes as a table with three columns: cause, ticket count, and one example ticket ID. Order by count, highest first. If a ticket's root cause cannot be determined from its text, count it under "unclear" rather than assigning a best guess.That last sentence is the one that matters most. Without it, ambiguous tickets get sorted into whichever category seems closest, and the counts look precise while being partly invented.
The finished version is longer than the first, and the length is doing work. Compare that to the hedging example above, where length was doing nothing.
Interactive animation: The finished prompt annotated - a verb with a finish, an exact format, and the unclear bucket against invented counts.
Where Ambiguity Costs the Most
Not all ambiguity is equally expensive, and knowing where to spend effort matters.
| Situation | Cost of ambiguity |
|---|---|
| One-off exploratory question | Low - you see the answer and can ask again |
| A prompt run once by one person | Low |
| A prompt in a product, run thousands of times | High - variance affects everyone |
| A prompt feeding an automated decision | Highest - nobody reads the output |
| A prompt in an agent loop | High - errors compound through turns |
The bottom three are where precision pays. An exploratory prompt can be vague because you are in the loop; a production prompt cannot, because nobody is.
Important: Effort on clarity should scale with how many times a prompt runs and how little supervision it gets. A prompt you will run once and read carefully does not need the treatment. A prompt embedded in a system does, because you are not there when it produces something odd.
The Test Before You Ship
Algorithm: Checking a prompt for ambiguity
- Underline every verb. Could two people disagree about whether it was done?
- Is the scope stated - how much, of what?
- Is the audience stated, where it would change the answer?
- Is the output format stated?
- Is it clear what to do when information is missing?
- Are the negatives things you have actually seen go wrong, or speculation?
- Can you cut a third without losing a requirement?
Step 5 is the one that prevents the most damage. Step 7 usually improves the prompt more than any addition would.
Warning: Do not test a prompt only on the case you had in mind when writing it. Ambiguity shows up on the awkward inputs - the document missing a section, the ticket with no clear cause, the record with a null where you expected a value. Those are the cases where the model has to decide, and where an unclear prompt produces something confident and wrong.
In Short
A model given an ambiguous instruction does not ask what you meant. It picks an interpretation and proceeds, producing output that looks exactly as confident as output from a clear instruction.
Vague verbs are the main culprit, and the fix is a verb with a done test - something a second person could check. Beyond that, ambiguity comes from undefined scope, audience, format, and handling of missing information, and the last is the most damaging because it invites fabrication.
Prefer positive instructions to negative ones, and add negatives only for failures you have actually seen. Specificity is precision rather than length; most prompts get better when a third of them is cut.
Spend the effort where the prompt runs often and nobody is watching, because that is where ambiguity turns into consistent, invisible error.
Interview: Scenario questions here describe inconsistent or unexpected output and ask what to change. The answer is usually a specific missing element - the format, the scope, or what to do when data is absent - rather than a general instruction to be clearer. Options proposing a more capable model are distractors when the prompt never stated what was wanted.
Exercise: Starter. Rewrite these with a done test: "analyse the results", "improve this email", "check the numbers". Then say which category of ambiguity most often causes fabrication.
Intermediate. Take a prompt you use regularly and run the seven-step check on it. Pay attention to step 5 - most prompts do not say what to do when information is missing.
Advanced. Take a production prompt and test it on three awkward inputs: one missing a section, one with contradictory information, and one that is nearly empty. The behaviour on those three is what your prompt actually specifies, as opposed to what you intended.
Quiz: Quick check: A data extraction prompt says "extract the invoice date". When an invoice has no date, the output contains a plausible date that does not appear in the document. What is the fix?
A) Use a more capable model that will not invent dates B) State explicitly what to do when the date is absent - for example, return "not stated" rather than inferring one C) Add "do not make anything up" to the prompt D) Validate the extracted date against the document afterwards
Answer: B - the prompt asked for a date and did not say what to do when there is none, so the model had to produce something. Naming the alternative gives it an honest option. Option C is a speculative negative that leaves the same gap, and D catches the problem after it has been created.