Home › Study guides › CCAO-F › Domain 5 › Lesson 5.4
CCAO-F · Domain 5 · 12% of the exam · Lesson 5.4 · 19 min read
Keeping instructions and knowledge current
Why a Claude Project drifts out of date, and how to replace superseded files, stage future ones, retest after each change and tell the people who use it.
Written against objective 5.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.
5.4.1 Why the old tagline keeps coming back
It is late September at Wrenfold, a maker of cleaning sprays, hand soap and laundry pods. In June the brand changed: a new logo and a new tagline, "Care in every corner", replacing "Clean made simple". Aisha, the brand manager, looks after the Brand Voice Project, a shared Claude workspace where fourteen marketers draft product copy, social posts and retailer emails. This week a retailer points out that a promotional email signed off with the old tagline.
Aisha pulls up a month of drafts. About a third still end with "Clean made simple", and two describe the logo as "the green leaf", which was retired with the rebrand. That is puzzling, because someone uploaded the new brand book in June. And in July, Marco, who runs social media, told Claude the new tagline in a chat and got perfect posts back that afternoon.
Claude isn't malfunctioning. Every new chat in a Project starts from what the Project holds: its instructions and its knowledge files. When Aisha opens them, the 2024 brand book is still there beside the new one. The instructions, written two years ago, still say "Sign off every social post with Clean made simple", with three later patches tacked on underneath. Marco's correction lived in Marco's chat and went nowhere else. The Project was set up well once, and nobody has looked after it since.
Looking after it is the subject of this lesson. A configuration is everything that shapes Claude's answers before anyone types: a Project's instructions and knowledge, and around them memory, personal instructions and connected tools. Keeping one current takes an owner, updates that replace rather than pile up, a retest after every change, and a word to the people who use it.
5.4.2 Where old guidance hides
When a Project that used to work starts going wrong, where do you look? A configuration decays without anyone touching it, because the world it describes keeps moving: policies change, documents are replaced, campaigns end. Old guidance tends to hide in four places.
Four places old guidance hides
Knowledge files are superseded but not removed: a new brand book arrives, and unless someone takes the old one out, both stay. Instructions collect patches, such as "UPDATE: new logo from June" appended below a line that still says the opposite. Memory, where it is switched on, saves context from a person's chats as topics, so an old preference can outlive the rule it came from. Personal instructions, which apply to all of one person's chats, go stale the same way.
Connectors outlive their purpose too. Once a service such as a shared drive is connected, Claude can bring it into a conversation on its own when it fits the request. A drive connected for last year's campaign can still put last year's files in front of Claude.
Two symptoms tell decay apart from a one-off bad answer. Answers use retired material, such as an old tagline, product name, price or rule. And the same wrong pattern shows up in many chats, for many people. One odd answer may come from one weak request. The old tagline in a third of a month's drafts comes from something those chats share, and that is the configuration.
5.4.3 Fix it where it lives
Here is the question that catches people out. Marco told Claude the new tagline, so why didn't it stick? Because a Project does not learn from its chats. The Help Center is plain about it: context is not shared across chats within a Project unless the information is added to the Project's knowledge.
Think of a restaurant that changes its soup of the day. Telling one waiter fixes what that waiter says tonight, but every other table still gets the printed menu with yesterday's soup. In a Project, the instructions and knowledge are the printed menu and each chat is one table.
Memory adds a wrinkle. If memory is on for Marco's account, Claude may save the new tagline, and his own next chats may get it right. That hides the problem from the one person who thinks he fixed it. But memory is no place for a team's rules: it belongs to one person, and Marco's sits beside a brand book that still says the opposite.
A chat correction versus a Project update
Told Claude in a chat
Updated the Project
So Aisha changes what every chat starts from: she rewrites the sign-off line in the instructions and replaces the brand book in the knowledge. No one has to remember to remind Claude.
5.4.4 Replace, label, stage and log
When a document changes, the tempting move is to add: upload the new brand book and keep the old one "for reference". Nothing is lost, so it feels safe, but it is one of the quickest ways to break a Project. Claude now has two documents that each claim to be the brand book and nothing to say which is in force. It may follow either, or blend them into the new logo with the old tagline.
A proper update rests on four habits.
- REPLACE. Remove the superseded file when you add the current one. First confirm with the document's owner that the new version is the approved one, because newer does not mean in force.
- LABEL. Name each file with its version, status and effective date, such as "Brand Book v3, approved, effective 1 June 2026". Anthropic's Claude 101 course notes that Claude uses file names to find the right information.
- STAGE. Keep material that is approved but not yet in force outside the live Project. Wrenfold's new packaging guidelines apply from January, so Aisha holds them in a staging folder and swaps them in on the date. If people needed answers about both periods before then, she would add the file labelled with its date, plus an instruction saying which version applies when.
- LOG. Change an instruction by rewriting the line itself, not by appending an "UPDATE" underneath, and record what changed, why and who changed it.
| The change | The tempting move | The proper move |
|---|---|---|
| A document is replaced | Upload the new one beside the old | Remove the old, add the new with a clear label |
| A rule in the instructions changes | Append "UPDATE:" at the bottom | Rewrite the rule itself and log why |
| New material is approved for a later date | Add it now so the Project is ready | Stage it until it takes effect |
| An old file is needed for the record | Keep it in the knowledge just in case | Archive it outside the Project |
If you remember one row, make it the first: two versions of one document are a conflict, not a backup. The other rows follow from the same rule: the live Project holds only what is approved and in force today.
Keep the change log beside the Project, not in its knowledge, where Claude would read the retired tagline as guidance. Look at the reason on each line: a year from now, it tells the next owner whether a rule can safely go.
Brand Voice Project: change log (kept outside the Project)
24 Sep 2026, Aisha. Knowledge: removed Brand Book v2 (2024); added Brand Book v3, approved, effective 1 June 2026. Reason: retired tagline still appearing in drafts.
24 Sep 2026, Aisha. Instructions: sign-off line rewritten to the new tagline; three "UPDATE" lines removed. Reason: they repeated or contradicted the main rules.
24 Sep 2026, Aisha. Staged, not live: Packaging Guidelines 2027, approved, effective 1 January 2027. Swap in on that date and rerun the test set.
24 Sep 2026, Aisha. Test set rerun after all changes: 6 of 6 pass. Team told by email.
5.4.5 An owner, a schedule and a test set
How did the Brand Voice Project drift for three months? All fourteen marketers could edit it, and none of them was responsible for it. Upkeep became everyone's job, and so no one's.
Three things fix that. A named owner, here Aisha with a deputy, keeps edit access, and everyone else gets view access, which still lets them chat in the Project. A review schedule, say once a quarter, means someone reads the instructions top to bottom and checks that each file is still current. Claude 101 advises the same periodic review, because outdated documents lead to outdated responses. And change triggers mean review now, not at the next date: a policy change, a product launch, a rebrand, or repeated feedback about the same error.
The last piece is a regression check: a fixed set of test requests you rerun after every change, each with a note of what a good answer looks like. A regression is something that worked before and has stopped working. The check covers both halves of a change: whether the update fixed what it should, and whether it broke anything else. Because the set never changes, any difference in the answers comes from your update. In Aisha's set, look at the pass lines, and at request 6, which checks something the update should not touch.
Brand Voice test set (rerun in a new chat after every change)
1. Write a two-line social caption for the lavender floor cleaner, with our sign-off. Pass: ends with "Care in every corner".
2. What is our tagline, and since when? Pass: the new tagline, from June 2026, citing Brand Book v3.
3. Describe our logo for a printer's brief. Pass: the new wordmark, no mention of the green leaf.
4. Draft a short retailer email about the new refill pouches. Pass: approved claims only, new sign-off.
5. Can we still use "Clean made simple" anywhere? Pass: says it is retired.
6. Write a product description for the citrus hand soap. Pass: the usual voice rules, exactly as before the update.
The upkeep cycle
5.4.6 Tell people, then tidy up
The files are right and the tests pass, but the update isn't finished. Marco still types the tagline at the top of his chats. Tell the people who use the Project what changed, what to stop doing and where to report a problem. In Aisha's note, look at the "Work in progress" line: it covers drafts written before the update, which no change to the Project can reach.
Subject: Brand Voice Project updated, and the new brand book is now the only one
What changed: the Project now holds Brand Book v3 (approved, effective 1 June) and nothing older. The old sign-off and the green-leaf logo are gone from the instructions.
Work in progress: drafts written before today may still use "Clean made simple" or describe the leaf logo. Check them before they go out, and start a new chat for new work.
Your memory: if you use Claude's memory, open your memory settings and correct or delete anything about the old tagline or logo.
Coming next: the 2027 packaging guidelines go live on 1 January. I will swap them in, retest and write again.
Problems: if a draft uses retired material, send me the request and the draft.
Then tidy the three things that sit around the Project.
- Memory. Memory is personal: not even an organisation Owner can view or edit someone else's, so each user checks their own. The memory settings list everything Claude remembers as topics you can edit or delete, and you can also tell Claude in a chat what to change or forget.
- Connectors. Each person reviews the services connected to their account, disconnects those they no longer need, as the Help Center advises, and reconnects any whose sign-in has stopped working.
- Old Projects. Wrenfold's "Spring Launch 2025" Project still holds retired claims and the old logo. Retire Projects nobody needs, so no one drafts from them by mistake.
5.4.7 The exam traps
Every trap in this objective either fixes the problem in the wrong place or adds where it should replace.
- ✗ Correcting the old tagline in a chat and treating it as fixed. ✓ Update the instruction or file where it lives. A chat correction changes one conversation; every new chat starts from the Project.
- ✗ Asking everyone to remind Claude of the change in each request. ✓ Fix it once in the configuration. A reminder works only while every person remembers, every time.
- ✗ Uploading the new version beside the old one "for reference". ✓ Remove the superseded file and add the approved current one, labelled with version, status and date. Two versions leave Claude to choose, or to blend.
- ✗ Adding approved future material to the live Project early. ✓ Stage it until its effective date. If people need both periods answered, label both and add an instruction saying which applies when.
- ✗ Appending "UPDATE:" lines to the bottom of the instructions. ✓ Rewrite the rule in place and log what changed and why, so contradictions don't pile up.
- ✗ Making a change and assuming it worked. ✓ Rerun the same test set in a new chat, then tell users what changed.
5.4.8 Put it together: run a clean update
You now have the whole upkeep routine. Find where old guidance hides, fix it where it lives, replace rather than add, retest and tell people. The quickest way to believe it is to break a small Project on purpose and watch what happens.
Keeping a Project current leads straight into troubleshooting. When outputs go wrong and you are not yet sure why, diagnosing poor outputs (7.1) gives you a method for finding where a problem enters. Adjusting your approach from feedback (7.2) shows how to turn repeated feedback, one of the triggers here, into a tested change.
Key takeaways
- ✓ Configurations decay on their own: files are superseded, instructions collect patches, memory keeps old preferences and connectors outlive their use.
- ✓ A correction made in one chat changes only that chat; fix outdated guidance where it lives, in the Project's instructions or knowledge.
- ✓ Replace superseded files instead of adding the new one beside them, and label each file with version, status and effective date.
- ✓ Keep approved but not-yet-effective material out of the live Project until its date, and log every instruction change with its reason.
- ✓ Give each Project a named owner, a review schedule and clear change triggers, and rerun a fixed test set after every change.
- ✓ Tell users what changed and what to stop doing, then tidy memory, unused connectors and retired Projects.
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.
42 CCAO-F questions on Domain 5, free
Every question in the bank is tagged to a domain, so you can drill 42 questions on Configuration and Knowledge Management alone, or sit the full 60-question timed simulator.
Open the CCAO-F question bank → Back to Domain 5 →
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.