What this domain tests
10% of the exam — the lightest domain, and the most formulaic. Roughly six of sixty items. Nearly every question has the same shape: a realistic symptom (bad output, degraded workflow, frustrated user), four responses, and exactly one that addresses the actual mechanism rather than repeating, escalating, or giving up.
The blueprint lists three task objectives:
| # | Objective | What it looks like on the exam |
|---|---|---|
| 7.1 | Identify, diagnose, and resolve issues with underperforming prompts or poor outputs | Symptom → cause → fix scenarios: pick the response that targets the true cause |
| 7.2 | Adjust approach based on feedback and results | Iteration discipline: what to change, how to phrase feedback, when to reset |
| 7.3 | Optimize workflows for efficiency and effectiveness | Spot the highest-leverage improvement to a working-but-wasteful process |
First-hand reports describe the Foundations Associate exam as judgment-heavy rather than memorization-heavy — less "recall the parameter" and more "which response shows sound thinking." That makes this domain cheap points: learn the failure table, internalize the diagnostic order, and the correct option usually identifies itself because the three distractors follow predictable broken patterns (blame the model, repeat louder, or over-escalate).
Theory outline
7.1a The diagnostic method: inputs before engine
The core skill the exam probes is a debugging order. When output disappoints, a prepared candidate checks the things the user controls, in sequence:
- The prompt — is the task specified? Audience, format, length, context, definition of done?
- The provided context — did Claude actually receive the data it needs (file uploaded, source pasted, structure explained)? Is the conversation so long that early material is crowded out?
- The configuration — right Project? Instructions present? Same style settings as the teammate who gets better results?
- The model choice — is a fast-tier model being asked to do deep multi-document reasoning, or the most capable model being wasted on reformatting?
Only after those four does "the model can't do this task" become a live hypothesis. Wrong answers in this domain almost always skip the sequence: they blame the engine ("the tool is broken, abandon it"), apply superstition ("upload the file again", "ask it to try harder"), or jump to heavyweight escalation ("switch platforms", "buy a bigger plan") when the fix was one sentence of added context.
7.1b The master failure table
This is the densest exam-scoring asset in the domain. For each symptom: the mechanism, then the fix that targets it.
| Symptom | Actual cause | Fix |
|---|---|---|
| Output is generic, "could apply to any company" | Underspecified prompt — no context, audience, or definition of done | Add the missing specification: who it's for, what situation, what format, what good looks like |
| Output correct but wrong shape/format every time | Format described but never demonstrated | Include a gold-standard example (few-shot); examples lock structure better than descriptions |
| Long chat "forgets" details established early | Context crowding — the conversation outgrew what can be attended to | Start a fresh chat seeded with a distilled summary; move standing context into a Project |
| Confident, specific, wrong claims (statistics, citations, quotes) | Hallucination — fluent generation is not verification | Ground the task in provided sources, ask Claude to cite from them, permit "I don't know"; verify externally before use |
| Wrong answers about recent events or current prices | Stale training knowledge — the model's knowledge has a cutoff | Use web search / research mode, or paste the current documents into the conversation |
| Misreads an uploaded spreadsheet's columns | Ambiguous structure in the file | Explain the schema in the prompt (what each column means) or fix headers in the file itself |
| Ignores instructions when a long document is pasted in the same message | Instructions and content bleed together | Separate them with clear delimiters or headings; put instructions before (or clearly apart from) the pasted material |
| Legitimate request refused | Ambiguity pattern-matches to a misuse pattern | Rephrase with explicit legitimate context — who you are, the purpose, the intended use. Never split the request into fragments to slip past checks; that is itself misuse behavior |
| Response stops mid-generation | Output length limit reached | Ask Claude to continue from where it stopped; for recurring long outputs, request labeled parts from the start |
| Same task, different quality per teammate | Different inputs — prompts, model choice, or missing Project instructions/knowledge | Diff the prompts and configuration before concluding anything about the model |
| Reliable prompt drifts after a model update | Model behavior evolves across versions | Re-run your known-good examples, adjust where behavior shifted, date-stamp the change |
| Output gets worse across many correction rounds | Accumulated contradictory steering still sits in context | Consolidate what you learned into one clean prompt; restart in a fresh chat |
Two rows deserve emphasis because candidates confuse them:
- Hallucination vs staleness. A fabricated citation is a hallucination (the model generated a plausible-looking artifact); a wrong "current" CEO is staleness (the model reports a world that has since changed). The fixes differ: hallucination → grounding in provided sources plus verification; staleness → fresher information via search or upload. An exam option offering the staleness fix for a hallucination symptom (or vice versa) is a distractor.
- Refusal handling. The only acceptable fix is adding legitimate context. Any option involving evasion — rewording to disguise intent, fragmenting the request, "trying a different account" — is wrong on governance grounds, not just effectiveness grounds.
7.2 Adjusting approach: iteration discipline
Objective 7.2 tests whether you iterate like an editor or flail like a slot-machine player. The tested principles:
Feedback must be directional and specific. "Make it better" gives the model nothing to optimize; it will change arbitrary things. Strong feedback names what to keep, what to change, and in which direction: "Keep the structure; cut the second section to three bullets; make the tone less formal." The exam contrasts vague exhortation ("try harder", "be more accurate") with actionable direction — pick actionable, every time.
Feedback must carry ground truth when correctness is the issue. Telling Claude "that number is wrong" without providing the right number (or the source it should come from) just triggers another guess — the model apologizes and produces a different wrong value. If the model never had the data, no amount of scolding creates it. The fix is supplying the source material, not iterating on disapproval.
Change one variable at a time. If you simultaneously rewrite the prompt, switch models, and add three documents, you learn nothing from the improvement (or the regression). Deliberate iteration isolates the change so results are attributable.
Know when to continue vs when to reset. Iterating within a chat works because context carries your corrections forward. But every correction persists — after many rounds of partially contradictory steering, the model is optimizing for the argument history instead of the task. The reset move: write one clean prompt that consolidates everything you learned, and start a fresh conversation.
The escalation ladder. When rephrasing doesn't fix it: restructure the prompt (delimiters, example, decomposition) → fresh chat with distilled context → add the right feature (Project for standing context, web search for currency, an artifact for iterative documents) → reconsider model tier → conclude the task needs a human or a different tool. Exam distractors jump rungs — straight from "first attempt disappointing" to "abandon the platform."
7.3 Optimizing workflows for efficiency and effectiveness
Where 7.1 fixes broken output, 7.3 improves working but wasteful processes. The recurring levers:
| Waste pattern | Optimization |
|---|---|
| Re-pasting the same background/instructions into every chat | Move standing context into a Project's instructions and knowledge files — set once, apply always |
| Re-correcting the same format or tone every run | Encode the requirement once: an instruction plus a gold-standard example in the template or Project |
| One mega-prompt doing five jobs inconsistently | Decompose into chained steps with a quick human check between stages, so errors don't propagate silently |
| Premium model used for routine, high-volume, low-reasoning tasks | Right-size: faster/cheaper tier for volume work, most capable tier for genuinely hard reasoning |
| Whole team reinvents prompts individually | Standardize on the best performer's prompt + configuration as a shared template, then improve it centrally |
| No way to tell if "improvements" actually improve | Keep a small set of known-good input→output examples; re-run them after any prompt, workflow, or model change |
Two judgment points the exam pairs with optimization:
- Efficiency never deletes accountability. The tempting "optimization" of removing human review from a consequential workflow ("it hasn't caught an error in two months") is the classic trap — review exists for the tail risk, and its cost is the insurance premium. Correct answers keep review proportionate to stakes: spot-checks and checklists for low-stakes volume, full review for anything external, financial, legal, or about people.
- Optimization is maintenance, not setup. Models update, knowledge files age, teams drift. Resilient teams treat their prompt library like code: versioned, owned, regression-tested against known-good examples, with changes dated. "Set it up once and trust it forever" is always a wrong option.
Worked problems
Problem 1 — the vague-output diagnosis
A marketing associate asks Claude: "Write a product announcement for our new feature." The draft is fluent but generic — it could describe any product from any company. The associate concludes Claude "isn't good at marketing." What is the BEST next step?
- A. Switch to the most capable model tier and resubmit the same prompt
- B. Resubmit the prompt three times and pick the best of the drafts
- C. Rewrite the prompt with the missing specification: the product's actual details, target audience, channel, tone, and length
- D. Ask Claude to "be more specific and less generic"
Approach: Run the diagnostic order. The symptom is generic output; step one is the prompt — and this prompt contains no product facts, no audience, no format. Claude cannot know unstated business context, so it filled the gaps with plausible boilerplate. The cause is underspecification, so the fix is specification.
Why the others fail: A changes the engine when the input was empty — a bigger model can't know facts it was never given. B is the slot-machine move: three samples of an underspecified prompt are three flavors of generic. D asks for specificity without supplying anything to be specific about; the model will fabricate details instead, which is worse.
Answer: C
Problem 2 — instructions swallowed by the paste
A paralegal's prompt template pastes a 30-page contract and, at the very end, three instructions about what to extract. Claude summarizes the contract but skips two of the three instructions. Colleagues report the same template works "sometimes." What change MOST directly fixes the reliability problem?
- A. Add "IMPORTANT: follow all instructions" in capital letters at the end
- B. Clearly separate instructions from the pasted contract with headings or delimiters, and state the instructions apart from the document text
- C. Split the contract into six chats of five pages each
- D. Report the behavior as a product bug
Approach: The symptom is instructions intermittently ignored when mixed with long pasted content. Mechanism: instruction text and document text bleed together when nothing marks the boundary. The structural fix is separation — delimit the document, keep the instructions clearly distinct so they read as instructions rather than as more contract text.
Why the others fail: A adds emphasis without adding structure; the boundary problem remains. C fragments the document, destroying cross-page context the extraction may need, and doesn't address why instructions were missed. D skips the entire diagnostic sequence — the input structure hasn't been ruled out, and it is in fact the cause.
Answer: B
Problem 3 — the stale answer
An analyst asks Claude (no files attached, no search) for a competitor's current subscription pricing. Claude answers confidently, but the numbers are last year's. What is the BEST resolution?
- A. Tell Claude "that's outdated, give me the current prices" and trust the revision
- B. Conclude Claude is unreliable for competitive work and stop using it
- C. Use web search / research mode, or paste the competitor's current pricing page, and have Claude work from that
- D. Ask the same question in five separate chats and keep the majority answer
Approach: Classify the failure: confident-but-outdated on a fast-moving fact is staleness — training knowledge has a cutoff. The fix must inject current information into the conversation: search the live web or provide the current source directly. Once grounded, Claude's synthesis is useful again.
Why the others fail: A demands currency without providing access to it — the model can only re-guess from the same stale knowledge, possibly fabricating "updated" numbers. B abandons a fixable workflow over a understood, solvable limitation. D takes a majority vote among equally stale answers; consensus among outdated sources is still outdated.
Answer: C
Problem 4 — optimizing a working weekly report
An ops manager's weekly Claude workflow works but takes 45 minutes: ~15 minutes re-pasting background documents and standing instructions, ~10 minutes fixing the same formatting deviations, ~20 minutes on genuine review of the content. Which optimization is highest-leverage?
- A. Remove the 20-minute content review since the drafts have been accurate lately
- B. Set up a Project holding the standing documents and instructions, and add a gold-standard example of the desired format
- C. Upgrade every step to the most capable model tier
- D. Ask Claude at the start of each chat to "remember last week's setup"
Approach: Itemize the waste: 15 minutes of repeated setup + 10 minutes of repeated format correction are pure recurring overhead — exactly what Projects (standing context, set once) and few-shot examples (lock format) eliminate. That recovers ~25 minutes weekly while leaving the 20 minutes of genuine review intact, which is the part that should stay human.
Why the others fail: A optimizes away the accountability layer — the review is insurance against the costly tail, not waste. C spends more on capability when the waste is setup and formatting, neither of which a bigger model fixes. D relies on chat-to-chat memory of a prior conversation's setup rather than a durable configuration; standing context belongs in a Project, not in a hopeful request.
Answer: B
Exam traps
- Blaming the engine first. Any option that concludes "the model is broken / abandon the tool" while prompt, context, and configuration remain unchecked is wrong. Inputs before engine, always.
- Repetition-as-fix. "Try again", "ask it to try harder", "upload the file once more", "add IMPORTANT in caps" — emphasis and repetition never fix a structural cause. Look for the option that changes what the model receives.
- Confusing hallucination with staleness. Fabricated specifics need grounding and verification; outdated facts need fresher sources (search or upload). Matching the wrong fix to the symptom is a designed distractor.
- Correcting without ground truth. "Tell it it's wrong until it's right" fails when the model never had the data. The fix supplies the source, not more disapproval.
- Evasion dressed as troubleshooting. For false refusals, only added legitimate context is acceptable. Fragmenting requests or disguising intent is a governance violation and always a wrong answer.
- Over-escalation. Jumping from "first draft disappointing" to "switch platforms / buy the top plan / rebuild the workflow" skips the ladder. The cheapest sufficient fix wins.
- Deleting human review as "optimization." Streamlined ≠ unreviewed. Consequential outputs keep proportionate human checks; "it hasn't failed lately" is the setup for the trap, not a justification.
- One-time setup thinking. Options implying prompts and workflows never need re-testing after model updates ignore that behavior evolves. The professional answer re-runs known-good examples and date-stamps adjustments.