What you’ll be able to do
- Check an output against both the source material and the original request
- Find the details most likely to be wrong and verify those first
- Match how hard you check to what the output will be used for
What you need to know
Accuracy and completeness are two different checks
An output can fail in two separate ways. It can be inaccurate: it says something that isn't true or doesn't match the source. Or it can be incomplete: everything it says is true, but it skipped part of what you asked for. A meeting summary that correctly lists five decisions but leaves out the sixth, the one about the budget freeze, is accurate and still unfit to send.
The habit that catches both is to hold two things next to the output: the source (the uploaded file, the meeting notes, the data) and the request (what you actually asked for). Read the output against the source for accuracy, then read it against the request for completeness.
Fluency is not a signal
Claude writes clearly and confidently whether or not a given detail is right. Good structure, a professional tone, and confident wording tell you the output is readable, not that it is correct. The same goes for asking Claude "are you sure?" or "is this accurate?" A yes from the model is not evidence. A model's view of its own confidence does not reliably track whether a detail is right. Evidence comes from comparing the output with something outside it: the source document, the system of record, or a person who knows.
Know where errors hide
You rarely have time to check every sentence with equal care, so check the riskiest parts first. Errors tend to cluster in specific, concrete details:
- Numbers and calculations: totals, percentages, dates, deadlines, prices pulled from a spreadsheet or report.
- Names and attributions: who said or owns what, which vendor offered which term, job titles.
- Quotes and citations: a quoted sentence, a section or clause number, a source title.
- Commitments: anything that promises something to a customer, employee, or partner.
- Things the source didn't say: a reasonable-sounding detail filled in to make the summary feel finished.
Even when you've uploaded the file yourself, a summary can still misread a table, merge two items, or drop a caveat. Having the source in the conversation makes errors less likely. It does not rule them out.
A practical completeness check
Before reading the output closely, turn your request into a short checklist. If you asked for "a comparison of the three vendors on price, support hours, and contract length, plus a recommendation," that's four items times three vendors, plus one recommendation. Then tick them off. Anything missing gets a follow-up prompt that names it exactly ("You didn't cover Vendor C's contract length. Add it from the uploaded proposal."). Don't just regenerate and hope.
You can also ask Claude to help with the check in a way that produces evidence: "For each figure in the summary, quote the sentence in the uploaded report it came from." Then you look at the quotes yourself. That is very different from asking Claude to grade its own work. It gives you something you can verify.
Proportionate review
How hard you check depends on what happens next. A brainstorm list of webinar titles needs a quick read for relevance. A figure going into a board update, a policy answer going to employees, or a number someone will make a decision on needs to be checked against the source, every time. When you can't confirm a detail, flag it clearly instead of passing it on as settled. Ask: who will rely on this, and what goes wrong if one detail is off? The more people affected and the harder the mistake is to undo, the more checking it needs. Lesson 2.3 covers when that means bringing in a human reviewer.
Key concept
Check an output against the source for accuracy and against your request for completeness, and verify the specific details first. A confident, well-written answer is not proof of either.
Exam questions usually offer a "looks good, send it" option, a "ask Claude if it's sure" option, and an option that checks the output against an authoritative source or the original requirements. The last one is almost always the right answer.
Practice scenario
Work it through, then open this
Two checks apply. For completeness: the request had three parts, and all three appear, but check whether termination covers both parties’ rights, and whether any notice periods tied to renewal were left out. For accuracy: the renewal date is exactly the kind of specific, load-bearing detail that has to be confirmed in the contract itself. Leadership may plan around it, and if it’s wrong a renewal could be missed. The manager should find the renewal clause in the original document, confirm the date and any notice requirement, and ask Claude to quote the clauses behind each key term so they can be checked quickly. The polish of the summary changes nothing here.
Hands-on exercise — Audit a summary against its source
Beginner · 15 min
What you’ll learn
- Turning a request into a completeness checklist
- Getting Claude to show where each claim came from
- Spotting the details most likely to be wrong
-
Upload a document you know well (a policy, a report, a long email thread) and ask Claude for a summary that covers three specific things you name.
- Why: Using a source you know means you can tell when the summary is wrong.
- You should see: A clean summary that looks complete at first glance.
-
Write your three requested items as a checklist and tick each one off against the summary. Then ask Claude: “For each number, date, and name in your summary, quote the sentence from the document it came from.”
- Why: This tests completeness first, then gives you evidence you can check for accuracy.
- You should see: Quotes you can match to the document, and possibly a detail with no clear source behind it.
-
Open the original document and check two of the quoted sentences and any detail Claude couldn’t source.
- Why: The model’s quotes are a lead to follow, not the final word. You confirm them yourself.
- You should see: Most details confirmed, and a clear sense of which kinds of details need a closer look next time.
Exam traps
Treating polished writing as evidence of accuracy
Claude writes fluently whether a detail is right or wrong. Tone and structure tell you nothing about correctness.
Checking only what the output says, not what it left out
Completeness is a separate check. Compare the output against every part of the original request.
Asking Claude whether its own answer is correct and accepting the yes
A model’s statement of confidence is not evidence. Verify against the source or the system of record.
Spot-checking the easy parts and skipping the numbers
Errors cluster in figures, dates, names, quotes, and commitments. Check those first.
Assuming a summary of an uploaded file can’t contain errors
Having the source available helps, but Claude can still misread tables, merge items, or drop caveats.
Giving every output the same level of review regardless of use
Match the effort to the stakes. A brainstorm needs a skim. A figure in a board paper needs to be checked against the source.
Sources
- Claude Help Center
- Claude Docs
- Anthropic, Claude Certified Associate – Foundations Exam Guide v1.0 (July 2026)