Home › Study guides › CCAO-F › Domain 2 › Lesson 2.4
CCAO-F · Domain 2 · 21% of the exam · Lesson 2.4 · 19 min read
When a human must review
How to match review to the stakes: six risk factors, four levels of review, when facts need extra checking, and why you stay accountable for what you send.
Written against objective 2.4 of the official CCAO-F exam guide (Version 1.0, effective July 2026). An independent resource, not affiliated with Anthropic; the practice questions are written from scratch.
2.4.1 Why five polished drafts need five different reviews
Marta runs people operations at a 200-person software company, and this week five pieces of writing land on her desk. Staff want an FAQ about the new holiday calendar. Engineering needs a job posting for a senior developer. Payday is moving, so everyone needs a summary of the change. An employee's formal grievance about how on-call shifts are shared out needs a reply. And a dismissal that leadership has already decided needs a termination letter. She drafts all five with Claude, handling personal details the way her company's AI policy allows.
By Tuesday afternoon the drafts are done, and none of them looks rough. That is exactly the difficulty. Claude brings the same polish to every draft, so the holiday FAQ and the termination letter look equally finished. What differs is the cost of an error. A wrong date in the FAQ costs a correction. A wrong sentence in the termination letter can misstate why someone lost their job and hand the company a legal dispute.
Unless Marta tells it, Claude does not know who in her company must see which document, and it can never answer for the result; those are human jobs. So the skill in this lesson is triage: deciding, for each output, how much review it needs, from whom, and which of its facts must be confirmed first. The name for this is risk-based review: the checking rises with the cost of being wrong.
One week, five drafts, rising stakes
2.4.2 Scale the review to the stakes
It is tempting to pick one rule for everything: "I read whatever Claude writes", or "legal sees everything". Both fail. The first lets a termination letter out after the same quick read as a holiday FAQ. The second buries the legal team in FAQs until people start working around it, and then nothing gets reviewed. Review time is limited, so it has to go where an error would do the most damage.
Think about how you check the weather. Before a walk to the shop, you glance at the sky. Before a mountain hike, you read the forecast, plan the route and tell someone when you will be back. The sky is the same; what is at stake is not. Review works the same way, and six questions tell you how much is at stake in a draft.
| Factor | The question to ask | Holiday FAQ | Termination letter |
|---|---|---|---|
| IMPACT | What does an error cost, and whom? | A correction email | A person's job; a legal claim |
| AUDIENCE | Who reads or relies on it: colleagues, or customers, the public, a regulator? | Colleagues | One employee, and perhaps later their lawyer |
| REVERSIBILITY | Can it be fixed once it is out? | Edit the page | Cannot be unsent |
| YOUR KNOWLEDGE | Can you confirm every fact yourself? | Yes, from the approved calendar | No; the legal points need a lawyer |
| NOVELTY | Is the case new, unusual or unclear? | Routine | Every dismissal is its own case |
| REGULATION | Does law or a regulator govern it? | No | Employment law |
Memorise the six factors. You do not need a score for each; one high answer is often enough to move a draft up.
For Marta, the holiday FAQ is low on every factor. The job posting is public, and its technical requirements are something only engineering can confirm. The payroll summary touches everyone's money and rests partly on rules she cannot check herself. The grievance reply adds ambiguity: the on-call policy says nothing about how shifts are shared. The termination letter is high on nearly every factor.
2.4.3 Four levels of review
Once you know the stakes, the next question is who reviews the draft. There are four levels, a ladder that runs from a check you do yourself to a formal sign-off.
| Risk | Review level | In Marta's week |
|---|---|---|
| Low: internal, easy to correct, every fact checkable by you | SELF-CHECK: you read it against your own source | Holiday-calendar FAQ |
| Moderate: public or widely read, but correctable | PEER REVIEW: a colleague who knows what you don't | Job posting, read by the engineering hiring manager |
| High: money, rights or law, or facts you cannot check | EXPERT REVIEW: a legal, compliance, HR, finance or clinical specialist | Payroll summary (payroll lead); grievance reply (employment lawyer) |
| Highest: a decision about a person, hard to undo | FORMAL APPROVAL: the accountable owner signs off, after expert review | Termination letter (Head of People, after the employment lawyer) |
Memorise the four levels and their order. The last column only shows them at work in Marta's company; your own organisation decides who reviews what.
Two details make the ladder work. First, the levels stack rather than replace each other: Marta still checks the termination letter against the decision record herself, so the lawyer spends time on the law, not on typos. Second, choose each reviewer to fill the gap in YOUR knowledge, not by seniority. Marta is the HR expert on the job posting, so her reviewer is the hiring manager, the only one who can say whether "eight years of cloud security" is a real requirement. An exercise in Anthropic's AI Fluency course makes the underlying point: your own knowledge of a subject is what lets you judge an answer about it.
Anthropic's Usage Policy follows the same logic. It lists legal, financial and employment decisions among its high-risk use cases. Where Claude is used for advice, recommendations or decisions in those areas that directly affect people, a qualified professional in that field must review the content before it goes out or is finalised. The requirement is written for consumer-facing uses, but Marta's triage rests on the same reasoning.
2.4.4 When the facts need extra verification
Review asks whether a draft is right for its purpose. A narrower question comes first: does it rest on facts that anyone has confirmed? Some statements you can confirm yourself; others rest on a source you cannot vouch for, or on no source at all. How to check a fact is a separate skill; the decision here is spotting WHICH statements need checking, and who can confirm them.
Here is the core of Claude's payroll summary. Read it line by line and ask where each statement came from.
Subject: Payday is moving from November
From November, salaries will be paid on the 25th of each month instead of the last working day.
If the 25th falls on a weekend or public holiday, you will be paid on the working day before.
Expense claims must be submitted by the 18th to be included in that month's pay.
This change does not affect your tax or pension contributions.
No action is needed from you.
Marta gave Claude two things: the payroll provider's official change notice, and a forwarded message in which a finance colleague wrote that the expense cutoff would "probably move to the 18th". The new pay date and the weekend rule match the official notice, so Marta can confirm them herself. The expense cutoff rests on a colleague's guess, a source whose authority is unclear, so the payroll lead must confirm it. The tax, pension and "no action" lines came from neither document. Claude filled a gap with plausible, reassuring sentences, and they read just as confidently as the lines that are true.
Confidence is not evidence. Anthropic's Claude 101 course warns that Claude occasionally produces plausible but incorrect information, especially specific facts, and advises verifying key facts independently for high-stakes work. So the payroll lead confirms the tax, pension and "no action" lines, or they come out.
2.4.5 Who answers for the output, and where questions go
Here is a belief worth dropping early: once Claude has drafted something, or a reviewer has looked at it, the responsibility has moved. It has not. The person who uses or sends an output answers for it. Anthropic's AI Fluency course calls this deployment diligence: taking responsibility for verifying and vouching for the outputs you use or share.
Nobody accepts "the spellchecker missed it" as an excuse for a typo in a contract. Claude is the same kind of help, only far more capable. It is a useful first reader: ask which sentences in the grievance reply a lawyer should look at, and it can point out the ones that sound like promises. But spotting issues is not signing off, and "Claude wrote that part" is no answer Marta can give the employee. A reviewer answers for their advice; Marta still answers for what she sends.
Some questions Marta should not settle alone, however carefully she reads. The on-call policy is silent on how shifts are shared, so how to read it is for the policy's owner to decide; any legal question in the grievance is for the employment lawyer. Neither is for Claude or for Marta's best guess. Technical builds have owners too. If the finance director wants payroll notices generated automatically from the payroll system every month, that is an integration, not drafting, and it belongs to Claude Architects and Developers. Marta's part is to recognise the handover and state the requirement, including where a person must still review.
Where each question goes
2.4.6 Make the review part of the routine
Review rarely fails through a bad decision. It fails by being skipped, usually late on a Friday. Deadlines are when review feels most expensive and mistakes are most likely, so time pressure is never an exemption: a wrong termination letter delivered on time is still wrong.
Two habits keep review from being squeezed out or forgotten. The first is to plan review time into the schedule: if the lawyer needs a day, the letter is drafted two days early. When a reviewer really is unavailable, split the output. Send the low-risk part now, such as a short note confirming the grievance was received and when a reply will follow, and hold the part that needs review.
The second habit is to write the rule where the work happens. A Project keeps instructions and files together for recurring work, and Claude uses a Project's instructions in every chat inside it. Here are the rules Marta adds to her people-operations Project. Look at the second line, which asks for a review level on every draft, and the last, which tells Claude never to imply an approval it cannot give.
You help the people-operations team draft messages for staff, candidates and managers.
Start every draft with one line stating its review level: SELF-CHECK, PEER REVIEW (name who), EXPERT REVIEW (name the function) or FORMAL APPROVAL (name the owner).
Dismissals and changes to one person's contract or pay: FORMAL APPROVAL by the Head of People, after review by the employment lawyer.
Grievances and discipline: EXPERT REVIEW by the employment lawyer.
Pay dates, amounts, tax or pension effects: EXPERT REVIEW by the payroll lead.
Public material such as job postings: PEER REVIEW by the hiring manager.
After each draft, list under "To confirm" every statement not supported by the documents in this Project, and who can confirm it.
Never describe a draft as approved, final or legally checked. Approval is given by a person, outside this chat.
The instructions enforce nothing. Claude can label a draft and list what to confirm; only a person can do the review. What changes is that each draft arrives with its review level attached, so nobody has to remember it. On a Team or Enterprise plan, Marta can also share the Project with colleagues, unless an admin has turned sharing off, so the whole team works under the same rules.
A written rule can be relaxed, but only on evidence. Before the routine monthly payday reminder drops to a self-check, Marta tests the Project on past months, awkward ones such as a holiday payday included, and the payroll lead, who owns the process, agrees.
2.4.7 The exam traps
Most traps below skip or shrink the review; one inflates it until nobody can keep up.
- ✗ Sending a high-stakes draft because it reads well and Claude sounded sure. ✓ Set the review by the stakes. Polish and confidence look the same on every draft, so they tell you nothing about risk.
- ✗ Asking Claude whether its draft is compliant and treating "yes" as sign-off. ✓ Use Claude to spot issues, then route the draft to the qualified person. A draft cannot approve itself.
- ✗ Adding "drafted with AI, please check" and sending it. ✓ Review first. Being open about AI's role is good practice, but the label hands the checking to readers who cannot do it.
- ✗ Skipping review because the deadline is today. ✓ Send a low-risk holding message if you must, and hold the part that needs review. An error sent on time is still an error.
- ✗ Sending everything to legal, or banning Claude from people-related work. ✓ Match the level to the risk. Blanket review builds a queue people learn to bypass; a ban throws away help on the low-risk majority.
- ✗ Believing responsibility moved to Claude or to the reviewer. ✓ Whoever uses the output answers for it. A reviewer answers for their advice, not for your decision to send.
Five things that are not a review
2.4.8 Put it together: triage a week of drafts
You now have the whole method. Six questions set the stakes, four levels name the reviewer, unconfirmed facts go to their owners, and you stay accountable throughout. Writing the rule into the workflow keeps a deadline from erasing it. The exercise lets you watch that rule work, and then watch what happens without it.
The rest of this domain builds on this triage. Adapting outputs for different audiences (2.5) changes tone and length without changing the facts a reviewer approved. Choosing output formats (2.6) includes outputs that carry their sources and status, which makes a reviewer's job easier. In Domain 6, judging which uses are appropriate at all (6.1) explains why Claude can help draft a termination letter but must not make the dismissal decision on its own. Your organisation's AI policy (6.3) may already set some review levels for you.
Key takeaways
- ✓ Review is scaled to risk: impact if wrong, audience, reversibility, whether you can check it yourself, novelty or ambiguity, and regulation.
- ✓ Four levels stack from self-check through peer review and expert review to formal approval by the accountable owner, and each reviewer fills a gap in your knowledge.
- ✓ Additional verification is required when an output rests on facts you cannot confirm or on sources whose authority is unclear.
- ✓ The person who uses the output stays accountable; Claude drafts and spots issues but never approves, and "Claude wrote it" shifts nothing.
- ✓ Policy judgments go to the policy's owner, legal ones to a lawyer, and complex or technical builds to Claude Architects and Developers.
- ✓ Deadlines never waive review; build the requirement into the workflow, for example in Project instructions, so it happens every time.
Check your understanding
4 questions written for this lesson, then one from the CCAO-F question bank on the same topic. Every answer option is explained, including the ones you did not pick. Nothing is stored.
78 CCAO-F questions on Domain 2, free
Every question in the bank is tagged to a domain, so you can drill 78 questions on Output Evaluation and Validation alone, or sit the full 60-question timed simulator.
Open the CCAO-F question bank → Back to Domain 2 →
The question bank is free. It asks for an account only because the quiz engine has to store answers to score them and show which domains are weak. The questions on this page need nothing.