Home › Study guides › CCAO-F › Domain 2 › Lesson 2.5
CCAO-F · Domain 2 · 21% of the exam · Lesson 2.5 · 21 min read
Adapting outputs for your audience without changing the facts
How to adapt one approved source for executives, teams and customers, keep its facts intact, catch distortions, refine with precise edits and compare drafts.
Written against objective 2.5 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.5.1 Why a simpler version can end up saying something untrue
You're the product manager at a company that makes appointment-scheduling software for clinics. Version 4.2 ships on 14 October, and its headline feature is calendar sync: bookings made in your app now appear in a clinic's own calendar, and changes flow both ways. The release notes are written, checked by engineering and signed off by the head of support. Now three groups need to hear about it. The support team needs a full changelog, the detailed list of what changed and how. The executive team wants three lines, and customers need an announcement they can read between patients.
You paste the approved notes into Claude and ask for all three. The support and executive versions look fine. The customer version is warm and easy to read, and its second sentence says the new sync "works with every calendar". The release notes say it supports two named calendar services at launch, and that recurring appointments created before the update sync only after someone re-saves them. A clinic on a third service would switch the feature on and wait for bookings that never arrive.
This is not a malfunction. You asked for something simpler, and simplifying means leaving detail out. The first details to go are often the qualifiers: small words such as "only", "at launch" or "after you re-save" that limit a claim. Claude only knows what is in front of it, and nothing in your request said that the qualifiers mattered most.
This lesson is about the work between Claude's draft and the reader: adapting a draft for a particular audience, refining it with precise edits, and comparing versions against what the reader needs. All three share one rule, and the customer draft broke it.
One approved source, three versions
2.5.2 Same facts, three readers
Start every adaptation with one question: what does THIS reader need to do with it? A version that answers the wrong question fails even when every fact in it is right. Executives ask whether anything needs their decision or their worry. The working team asks what changes in their job on Monday. Customers ask what it means for them and whether they have to act.
| Audience | What they need first, and how it's told | In the 4.2 release |
|---|---|---|
| Executives | The bottom line, then any risk or decision. Short, in business terms, with the detail available on request. | Calendar sync ships 14 October for two calendar services; one known limitation, with a workaround; no decision needed. |
| Working team | Details and actions. Complete, in the terms they use every day, with steps and edge cases. | Setup steps, the re-save workaround for older recurring appointments, and what to tell a clinic that uses a third service. |
| Customers | What it means for them and what to do. Plain language, no internal jargon, one clear action. | Your bookings can now appear in your own calendar; your clinic admin switches it on; open and save older recurring appointments once. |
Memorise the middle column, then look down the right-hand one. The same two services, the same date and the same limitation appear in every row, told at three depths: a few words for executives, a paragraph for support, one instruction for customers. Depth changes from reader to reader; the facts do not.
So say in your request who each version is for and how they will read it. Anthropic's prompting advice counts the audience and the goal as context worth stating, and the more specific the description, the better Claude can aim: "clinic managers reading in the app between appointments" beats "a customer version".
2.5.3 What may change and what must stay fixed
It's tempting to treat adaptation as a style job, where anything goes as long as the result reads well. Resist that. Some parts of an output are presentation, yours to change for each reader. Others are substance, and they belong to the approved source.
The free list is long: tone, length, reading level, terminology, structure and emphasis. The locked list is short and non-negotiable. It holds verified facts (numbers, dates, names), conditions (the qualifiers that limit a claim), limitations and known issues, and approval status: approved, planned or merely under review. Where the source is uncertain, the uncertainty is locked too, so "may" must not become "will".
Think of a good conference interpreter. They change every word the speaker says, often the order of the sentences too, yet the audience hears exactly what the speaker meant. An interpreter who drops the speaker's caveats to make the speech flow has stopped interpreting and started changing someone else's position. Your adapted versions work the same way: completely rephrased, never re-decided.
What adaptation may change, and what it may not
Free to adapt
Locked
The practical move is to put both lists into your request. Look at the last three instructions in this brief: one grants freedom, one names exactly what is locked, and one keeps every claim inside the notes, with a marker for anything missing.
Using only the approved release notes below, write three versions of the 4.2 announcement.
1. Support team: a full changelog with the setup steps, the known limitation and its workaround, in the terms our support staff use.
2. Executive team: three lines. What ships and when, then any risk, then whether a decision is needed.
3. Customers (clinic managers and front-desk staff, reading in the app between appointments): under 120 words, plain language, no internal terms, and the one thing they need to do.
You may change tone, length, wording, order and emphasis for each reader.
Keep these exactly as the notes state them in every version: the two supported calendar services, the 14 October date, that sync stays off until a clinic admin switches it on, that recurring appointments created before 4.2 sync only after they are re-saved, and that a third service is under evaluation with no date.
Take every claim from the notes, with no benefits, figures or promises of your own. If a reader would expect a detail the notes do not give, write [ASK PRODUCT] instead.
Approved release notes:
(the approved 4.2 release notes, pasted in full)
A locked list makes drift less likely. It does not make checking optional.
2.5.4 How simplifying distorts, and how to catch it
Here is the pattern that catches careful people: a version that is clearer, friendlier and shorter than the source, and slightly untrue. Distortion rarely looks like an error. It looks like good writing, because the qualifiers that make a claim accurate are the same words that make it harder to read. Take them out and the sentence gets better while the claim gets worse.
Put the first customer draft beside the approved notes and the four common shapes of distortion all show up.
| The customer draft says | The release notes say | What went wrong |
|---|---|---|
| "Works with every calendar" | Two-way sync with two named calendar services at launch | A condition became an absolute |
| Nothing about older recurring appointments | Recurring appointments created before 4.2 sync only after they are re-saved | A limitation disappeared |
| "Saves your front desk hours every week" | No time saving is stated anywhere | An unsupported benefit appeared |
| "More calendars coming soon" | A third service is under evaluation, with no date | A status or certainty moved up |
Memorise those four shapes. The fourth covers uncertainty too: "may reduce" becoming "reduces" is the same upgrade.
The catch is a comparison, not a reread. Reading the customer version on its own tells you whether it reads well; only reading it beside the source tells you whether it's true. Go claim by claim, finding the source sentence behind each statement. Then check the other way, that every item on your locked list made it across. You're looking for three things: changed, missing and added.
Claude can speed this up. Ask it for a table of every claim in the customer version beside the exact supporting sentence from the release notes, with "not found" where there is none. Anthropic's guidance on reducing hallucinations recommends this kind of quote check. Asking "is this accurate?" gets you a yes, and a yes is confidence, not evidence. The table gives you something to check, but it is still Claude's reading, so find each quote in the notes yourself. If you can't tell whether a softer wording still means the same thing, the owner of the source decides.
2.5.5 Edit by hand, instruct an edit, or regenerate
Once you know exactly what is wrong, how do you fix it? The tempting answer is the weakest: "make it more accurate". A vague request gives Claude nothing to aim at, so it may rewrite the whole piece, including lines you had already checked. Anthropic's Claude 101 course makes the point with length: "make it shorter" is fine, but "cut the first two paragraphs and make the conclusion more action-oriented" is better.
A precise edit instruction names the place, the change and what to leave alone. Here is the fix for the customer draft. Look at the first line and the last one: together they fence the edit in.
Change only the sentences named below and leave everything else in the customer announcement word for word.
Replace "works with every calendar" with the two supported calendar services, named exactly as in the release notes.
Add one sentence: recurring appointments created before 14 October start syncing once someone at the clinic opens and saves them.
Delete "saves your front desk hours every week". The release notes state no time saving.
Delete "more calendars coming soon". A third service is only under evaluation and has no date.
Keep it under 120 words and in the same friendly tone.
Not every fix needs Claude, and not every fix needs a whole new draft. Regenerating means asking Claude to write the piece again from a revised request, rather than patching the old draft. It earns its place when the problem is the shape of the piece rather than a few lines in it. Suppose the executive update had come back as a feature tour with the limitation in its last line. A fresh draft from a sharper request ("line one, what ships; line two, the one risk; line three, no decision needed") beats shuffling sentences by hand.
| The change you need | Best move | Why |
|---|---|---|
| A word, a date or one sentence you can correct from the source | Edit by hand | Quicker than explaining it, and nothing else moves |
| Your own phrasing, greeting or sign-off | Edit by hand | Your voice is easier to write than to describe |
| Several fixes across the draft, such as the four in the customer announcement, or a tone that is too salesy throughout | A precise edit instruction | Claude makes them consistently, and your fence protects the rest |
| The wrong structure, order or angle for this reader | Regenerate from a revised request | Line edits keep the old skeleton |
Remember one rule: the size of the problem decides the size of the fix. Whatever comes back from Claude is new text, so it goes back through the comparison with the source.
2.5.6 Compare versions against criteria, then make it yours
When you're unsure which approach will land with a reader, don't argue with a single draft. Ask for two or three variants that take different approaches. For the customer announcement, that might be one that leads with what the clinic gains, one that leads with the action clinics need to take, and one written as three short questions and answers.
The natural next move is to pick the one that sounds best. But "sounds best" measures fluency, and a distorted draft has plenty of it. Judge the variants the way a teacher marks exams: against a mark scheme written before reading any answers, not by which essay was most enjoyable. For the customer announcement, the scheme might be:
- TRUE TO SOURCE. Every claim matches a sentence in the release notes, and the locked list is complete.
- QUICK TO READ. A clinic manager can tell in ten seconds whether the sync works with their calendar.
- ONE CLEAR ACTION. The re-save step for older recurring appointments is impossible to miss.
- PLAIN. No release codes or internal terms, and under 120 words.
Score each variant against the list, which tests truth and fit for the reader separately; Anthropic's AI Fluency course likewise names accuracy and appropriateness among the qualities to judge in any output. Often the best result merges the opening of one with the action line of another, and the merged version gets the source check like any draft. Comparing has a bonus, too: if two variants disagree about a fact, at least one has drifted, and Anthropic's hallucination guidance treats inconsistencies between outputs as a warning sign.
The last pass is yours. Read the chosen version as the audience will, where they will see it. Then put it into your own voice, because readers who know your updates notice one that doesn't sound like you. The AI Fluency course names the principle behind this step: you take responsibility for verifying and vouching for the outputs you use or share. The announcement goes out under your company's name and yours, not Claude's.
From variants to a version you can sign
2.5.7 The exam traps
Every trap here either trusts a draft for the wrong reason (it reads well, Claude said so, it felt right) or fixes it in the wrong way.
- ✗ Sending the adapted version because it is clear, friendly and well written. ✓ Compare it with the approved source first. Distortion looks like good writing.
- ✗ Dropping a condition or limitation because "this audience doesn't need the detail". ✓ Keep it, in plain words. A shorter version is fine; a less true one is not.
- ✗ Asking Claude to confirm that the version matches, or to "make it more accurate". ✓ Compare claim by claim, name the exact sentence that changed, and give a precise edit instruction.
- ✗ Patching a badly structured draft line by line, or regenerating everything for a one-word fix. ✓ Edit by hand for small, local changes; regenerate for structural ones, and recheck whatever comes back.
- ✗ Picking the variant that sounds best. ✓ Write the audience's criteria first and score every variant against them.
- ✗ Sending every audience the full technical version "so nothing gets lost". ✓ Adapt depth and language to each reader. Identical facts protect accuracy; identical jargon does not.
Four tempting responses, one right one
2.5.8 Put it together: adapt one source for three readers
You now have the whole routine. Decide what each reader needs first, and name what may change and what is locked. Compare every version with the source, fix the exact distortion at the right size, choose between variants by written criteria, and make the last pass yourself. The exercise below shows the routine working, then failing when one ingredient is missing.
The next objective in this domain, organising information and choosing the output format (2.6), decides where each version should live: inline in the chat, in an artifact you keep editing, or as structured data. In Domain 4, communicating Claude's value and limitations to stakeholders (4.5) is this same skill, aimed at readers who need the limits as clearly as the benefits. And if you adapt release notes for the same three audiences every month, the audience descriptions and the rule that facts, conditions and status stay locked belong in Project instructions, which Domain 5 covers.
Key takeaways
- ✓ Every audience reads with its own question: executives want the bottom line, the working team wants details and actions, and customers want to know what it means for them.
- ✓ Adapt tone, length, reading level, terminology, structure and emphasis; never facts, conditions, limitations, approval status or stated uncertainty.
- ✓ Simplifying tends to drop the qualifiers that make a claim true, so a clearer version can be a less accurate one.
- ✓ Compare each adapted version with the approved source claim by claim, and name the exact change before you fix it.
- ✓ Refine with instructions that name the place, the change and what stays; edit small things by hand and regenerate when the structure is wrong.
- ✓ Choose between variants against criteria written for that audience in advance, not by which one sounds best.
- ✓ You make the last pass and own the result: your voice, the reader's view and your name on it.
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.