Quick Reference: Domain 2 — Output Evaluation and Validation

The stance: treat every Claude output as a strong first draft from a brilliant colleague who can be confidently wrong. The Help Center warns that Claude can produce incorrect or misleading responses and should not be relied on as a singular source of truth. Fluency and confidence are properties of the writing, not evidence about the facts. And the professional who sends the work is responsible for it.

Two review questions, always in this order:

• Accuracy: are the specifics right? Numbers, names, dates, titles, quoted figures, references to documents or rules. Order the checking by consequence: the figure a decision depends on, the name at the top of the letter, the date of the deadline get checked first.
• Completeness: is anything missing? Checked against the source material itself, never against memory of it. Review each part of the source's own structure (its section list, its full set of funds or line items) and confirm each element is represented or knowingly excluded. Omissions are not visible in the prose.

Traceability: ask Claude to indicate where in the attached material each claim came from, then spot-check the important claims. An output that cannot be traced is not assumed to be correct.

On the exam: the guide's own Domain 2 sample depends on verifying a cited subsection against the official text. Trusting Claude's expressed confidence and rewording for polish are the named wrong answers. Asking Claude whether it is sure confirms nothing.

Each failure type has a recognisable shape and its own correct response; giving one type the response of another is the common wrong option.

• Specificity is not evidence. An invented figure arrives exactly as precise and confident as a real one. Risk is highest where Claude has the least grounding: private internal systems Claude was never given material about, events after its training data, precise figures not in the source.
• Capability hallucination: Claude may claim to have sent an email, saved a file or supplied a working link when it has no access to any of those tools. A completion claim is a claim to check, not a delivery confirmation.
• Bias spotting: read across descriptions rather than sentence by sentence, watch for coded language (words that suggest a group without naming it) and unstated assumptions, and apply the read-aloud test: would the framing still be acceptable if read aloud to the group it describes?

Ordered from cheapest to heaviest:

1. Check against the source you gave Claude: the attachment is already in the conversation and settles most questions in minutes.
2. Verify external claims against independent, authoritative, primary sources: the official publication, the regulator's text, the funder's published criteria, your organisation's records.
3. Make the output traceable: ask Claude to show where each claim came from, then check the important claims at those places yourself.
4. Confirm the deciding figure in two places: when one number from a source drives the decision, confirm it in two independent places. For a figure Claude calculated, check its inputs and redo the calculation.

• Independence is the test. A second AI summary, a forum post or Claude's own earlier output is circular verification: the check inherits the errors of the thing being checked. Web search is a legitimate way to reach an authoritative source, but the source does the validating, never the search. Citations exist to be checked, not to make the output look better.
• What a self-check can and cannot do: a self-check is a direct request, a re-run of the same request, or a follow-up that asks Claude to verify its statements. It can find an arithmetic slip, a contradiction or a figure that differs between runs. Use what it finds as a list to check against the source. It cannot confirm a fact or approve an output for sending, because no new information enters the check.
• Calculated figures: a total, percentage or average that Claude worked out is in no source, so it is a separate claim. Check the numbers it came from against the source, then do the calculation again yourself.
• Proportionality applies in both directions. Too little checking on the consequential claim fails; so does verifying everything to the maximum, which spends limited time on prose nothing depends on. Depth of checking follows what depends on the claim.

The triggers. One trigger is enough. An output with any one of these needs review by a person qualified in its subject:

• an external audience for claims in the organisation's name: adverts, public posts, press, letters to many customers, funders (an error reaches many readers at once)
• legal, financial or contractual consequence
• decisions about people, including references
• safety or health implications
• irreversibility once sent

A routine reply to one customer, with facts you can check, does not have the external-audience trigger. How confident the output sounds and how well it reads are never on the list.

• Qualified, not senior. The Usage Policy requires a qualified person for advice or decisions in its High-risk Areas: someone with the training or experience to evaluate the output in that field. Apply the same competence test everywhere: contract language to legal competence, tax figures to the accountant, clinical claims to the clinician. A senior manager's skim-read of a lease clause is comfort, not review.
• Under-escalation: "only internal" is not a waiver when the output feeds an external or consequential decision; the destination decides more than the drafting location.
• Over-escalation is a tested wrong answer too. Routing every routine draft through committees or professionals gives reviewers too much work and weakens the channel high-stakes outputs need. Untriggered outputs get your own careful two-pass review, which is a real review, not a waiver.

Boundary notes: when the reason to stop is the data itself (personal, regulated, against AI policy), that is Domain 6. Handing a task to a Claude Developer or Architect because it needs automation is the programme's technical escalation, not this objective's.

You are the editor. Claude drafts and rewrites on request; the final verdict on what stays, what goes and what comes first belongs to you. Two legitimate remedies for a draft that does not work: edit it yourself, or direct a revision that names what must change.

• Right for its reader: a technically correct output can still be wrong for its audience: jargon for lay readers, dense analysis for a time-poor executive. Adaptation changes vocabulary, sentence complexity and ordering (urgent item first) while the substance stays: findings, recommendations, costs. Both failure directions are tested: sending output that is hard for the reader because it is accurate, and simplifying until the substance is lost. After adapting, check the new version against the original for anything lost or softened.
• Criteria before reading: when comparing versions, fix the criteria first (nothing factual lost, right register for the named reader, urgent items first), then read against the list. Comparison without criteria chooses the prettiest prose by default, and style is the only comparison that fluent output always wins. Fluency is never a criterion.
• Claude generates, you judge: Claude produces the variants and articulates the differences; the human applies the criteria and picks. Asking Claude which version is better passes to Claude the exact judgement this objective certifies.

Boundary with 1.3: sharper feedback to improve the next draft is prompt iteration; assessing and finishing the output already in front of you is this objective.

Curation: a long, productive conversation is not a deliverable. Start from the deliverable (who reads it, what they do with it, will it be reused), extract exactly what that reader needs, and shape it into its container. Forwarding the whole conversation delegates the curation to a reader who will not do it.

• The artifact's life: substantial, standalone content in a dedicated window; changed by asking Claude or by editing directly, branched by editing an earlier message, and shareable as a link when other people need it. Inline content can be turned into an artifact with one message; the choice remains yours.
• On the exam: the question being tested is always the container the reader receives. Options about Projects, Research mode or model choice belong to Domain 3 and are wrong options in a format question. Options that use one format for everything (everything a table, everything an artifact) sound systematic and are wrong; the answer to "which format?" is always "what does the reader do with this?"