On this page
TLDR
Accuracy and completeness are two independent checks, not one: an output can be fully correct on every claim it includes and still fail by silently dropping items, or it can cover everything asked and still get a fact wrong. Fluent, confident, well-formatted text is not evidence of either, look for explicit grounding instead.
What you are deciding
Evaluating output means asking two separate questions: is what it says correct, and did it cover what was asked. Check the output against the source and against the request before you accept it.
Is each claim in this output supported by the source, and is every requested item present?
What it is
Evaluating a Claude output means checking, before you act on it, whether the response is factually correct and whether it fully answers what was actually asked, not just whether it reads fluently. For a business user working in Claude.ai or Claude Projects, this is a review step done every time output feeds a decision, not a one-off audit reserved for high-stakes work. Anthropic frames this as a core habit for anyone deploying Claude in production workflows: start small, evaluate thoroughly, and scale gradually, rather than trusting first-pass output at scale.
The two checks are independent, which is the part this objective actually tests. Accuracy asks whether each individual claim in the output is factually correct. Completeness asks whether the output covers everything the request or source material contains. A response can pass one axis and fail the other in either direction, so checking only one is not a substitute for checking both.
How each certification frames it
CCA-A: How CCA-A tests accuracy and completeness
CCAOF-D2-O1Evaluate Claude-generated outputs for accuracy and completeness
Output Evaluation and Validation opens with evaluating Claude-generated outputs for accuracy and completeness (PDF page 4, Domain 2). The domain is the heaviest on the CCA-A blueprint, so this is a high-yield skill.
Items usually show a request, a source and a polished output. The right answer names the specific mismatch, whether a wrong fact or a missing requirement, and not a general impression.
How it works
Hallucination is an expected failure mode, not a rare bug. Even advanced models "can sometimes generate text that is factually incorrect or inconsistent with the given context." Evaluating for accuracy means checking for this by default on any output feeding a decision, not treating a fluent response as innocent until proven otherwise.
Look for grounding, not confidence. Anthropic's documented hallucination-reduction techniques include allowing Claude to express uncertainty instead of forcing a confident answer, grounding responses in direct quotes from source documents, and asking Claude to cite or verify its own claims against the material it was given. A reviewer can apply the mirror-image check: ask "what source is this claim grounded in?" and treat unsourced, over-confident claims as higher risk, regardless of how polished the language is.
Completeness is a separate count, not a byproduct of accuracy. Checking completeness means comparing what the source or the request contains against what the output actually includes, item by item, not just spot-checking the items that made it in. A summary can be accurate on every line it includes and still silently drop a third of what was asked for.
Stakes should set the depth of review, at two different levels. At the workflow level, Anthropic's enterprise guidance stresses evaluating output against real business outcomes, correct customer responses, accurate content, before scaling a workflow, and recommends staged deployment: start small, evaluate thoroughly, and scale gradually, rather than trusting a single successful run as proof a workflow is production-ready. At the level of a single output, the same stakes-scaling logic applies to how much of it you check: a low-stakes, informal summary can reasonably be spot-checked on a sample of claims, but a high-stakes output, a contract, a compliance filing, a figure that drives a financial or legal decision, needs every claim verified against the source, not a sample, because the cost of one missed error is disproportionate to the cost of checking it.
Worked example: a status report checked against its source and checklist
Authored teaching example, not a bank question.
Claude drafted a weekly project status report from a meeting transcript. The request asked for four things: progress, risks, decisions needed and next week's plan.
| Requested item | In the report? | Supported by the source? |
|---|---|---|
| Progress | Yes | Yes |
| Risks | Yes | Yes |
| Decisions needed | No, omitted | Not applicable |
| Next week's plan | Yes | One claim overstated: 'approved' vs 'will review' |
The report goes out only after both checks pass. Afterwards you can show the checklist and the source lines behind each claim.
How this decision goes wrong
Polished wording masking omissions
Looks right: The report is fluent and well organized, so it is complete.
Why it fails: Fluency says nothing about coverage. A missing section is invisible if you read for quality instead of against the request.
Instead: Build the checklist from the request first and tick items off the output.
Checking facts without checking the request
Looks right: Every statement was verified, so the report is good.
Why it fails: A fully accurate report can still miss a requested part or answer a different question.
Instead: Run both checks every time: claims against the source, and items against the request.
Where you'll see it
Vendor contract review
Because the summary will set the actual payment schedule, every milestone date and amount is verified against the source PDF, not a sample, for accuracy; the milestone count is separately checked against the contract for completeness.
Scaling a customer-response workflow
Evaluates early Claude-drafted responses against real business outcomes and starts small before scaling to full customer traffic, rather than trusting one strong test run.
Side-by-side
| Check | What it asks | How to verify it | Failure that slips through the OTHER check |
|---|---|---|---|
| Accuracy | Is each individual claim in the output factually correct? | Scale the depth to the stakes: sample-check claims for low-stakes, informal output; verify every claim against the source for high-stakes output (contracts, compliance, financial figures) | A summary can be 100% complete, every milestone listed, yet still get one date or amount wrong |
| Completeness | Does the output cover everything the request or source contains? | Count items in the source versus items in the output (e.g. all N milestones present) | A summary can be accurate on every included item, yet silently drop 3 of 12 milestones |
The exam trap
The trap is treating "confident, well-formatted, and fluent" as proof of "accurate and complete." These are independent axes: an output can be completely wrong for the same reason it's completely fluent, and an output can be flawlessly accurate on the parts it includes while silently omitting the rest. The correct instinct is to look for explicit grounding, quotes or citations, and treat unhedged, uncited claims as unverified regardless of tone. A second trap is applying one fixed validation depth, like a quick 2-3-item spot-check, to every output regardless of stakes: a low-stakes draft can be sampled, but a high-stakes output (a contract, a compliance document, a number that drives a real decision) needs every claim verified, not a sample.
Question patterns
CCA-A practice questions
6 approved CCA-A questions for this topic. Tap an answer to check it, then read the rationale for every option.
After three rounds of prompt iteration, a report's structure and tone are now correct, but a specific numeric figure keeps coming out wrong no matter how the prompt is reworded. What does this most likely suggest?
Frequently asked
Showing 5 of 5 questions
Sources and next steps
- Claude Certified Associate - Foundations Exam Guide v1.0 (July 2026), PDF page 4, section: Domain 2: Output Evaluation and Validation, detailed objectives. Checked 2026-10-16.
- Create strong empirical evaluations (Claude API docs), section: Building evals and test cases: success criteria; eval design principles. Checked 2026-10-16.
CCA-A exam guide: Domain 2, Output Evaluation and Validation