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 owns 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 rests 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. Walk 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 leave no trace in the prose.

Traceability: ask Claude to indicate where in the attached material each claim came from, then spot-check the claims that carry weight. An output that cannot be traced gets no benefit of the doubt.

On the exam: the guide's own Domain 2 sample turns on verifying a cited subsection against the official text; trusting Claude's expressed confidence and rewording for polish are the named wrong answers. Self-confirmation is never a check.

Each failure type has a recognisable shape and its own correct response; crossing the wires is the distractor pattern.

• Specificity is not evidence. An invented figure arrives exactly as precise and confident as a real one. Risk is highest where grounding is thinnest: 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 and unstated assumptions, and apply the read-aloud test: would the framing survive being 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 and how each conclusion was reached, then spot-check what carries weight.
4. Triangulate the load-bearing figure: when one number drives the decision, confirm it in two independent places.

• 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 decorate.
• Self-check has a real but limited place: a cheap first pass that catches arithmetic slips and internal contradictions. It is not independent validation; self-reported confidence is not a reliable accuracy signal.
• Proportionality cuts both ways. Skimping on the consequential claim fails; so does uniform maximal verification, which spends limited time on prose nothing depends on. Depth of checking follows what rides on the claim.

The triggers. Escalate to qualified human review when the output carries any of: an external audience; legal, financial or contractual consequence; decisions about people; safety or health implications; irreversibility once sent. Any one trigger is enough. 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 buries reviewers and erodes 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 leads belongs to you. Two legitimate remedies for a draft that misses: 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 load and ordering (urgent item first) while the substance survives: findings, recommendations, costs. Both failure directions are tested: sending reader-hostile output because it is accurate, and simplifying the substance away. 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 defaults to the prettiest prose, and style is the one contest fluent output always wins. Fluency is never a criterion.
• Generator, not judge: Claude produces the variants and articulates the differences; the human applies the criteria and picks. Asking Claude which version is better outsources 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 it must travel. Inline content can be turned into an artifact with one message; the choice stays in your hands.
• On the exam: the keyed question is always the container the reader receives. Options about Projects, Research mode or model choice are Domain 3 bait inside a format stem. Format-by-habit options (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?"