What You Need to Know
A configuration is the setup of a Project: its custom instructions and its knowledge base. Claude applies the instructions to every chat within the Project. Anything uploaded to the knowledge base is also used across every chat within the Project. Keeping a configuration right has three duties: inform, maintain and update. The work is noticing on a schedule, curating rather than accumulating, and remembering the people the configuration serves.
A pet shop set up a Project well last year to answer customer questions. Its knowledge base holds the price list and the returns policy. Nobody has touched it since.
Three Ways a Good Setup Decays
Knowledge goes stale. An uploaded file is a snapshot, and nothing announces that its source was superseded. Outputs go on quoting the old policy, price or procedure with complete confidence. At the pet shop, last year's price list still answers price questions.
Instructions go out of date. They apply to every chat, whether or not the world they describe still exists. When the audience or the format changes, the rules go on enforcing the old world.
Scope creeps. A Project that works attracts neighbouring work. Each addition dilutes instructions written for the original job, until they fit none of it.
All three look fine from inside the Project, so maintenance has to be scheduled. A trigger to wait for never fires.
Remove, Do Not Accumulate
When a document is superseded, remove the old version. Do not add the new one alongside it. Completeness is an archive's virtue. A working Project needs exactly one answer to which version is current. A knowledge base holding both gives Claude no way to know. The pet shop uploads the new price list and deletes the old one.
Two middle options fail: a note file explaining which version governs, or an instruction telling Claude to prefer the newer document. Both patch around a problem the knowledge base should simply not have.
After swapping a document, also read the instructions for rules written against the old wording. A standing rule quoting the old notice period outlives the file it came from. At the pet shop, that might be last year's returns window.
Informing Is a Human Step
When colleagues share a Project, an unannounced change produces outputs they cannot explain and stop trusting. The person who made the change is rarely in the room when that happens.
The documentation gives one notification fact: members receive an email notification when a project is first shared with them. No notification of any kind is documented for later edits to knowledge or instructions. So telling collaborators what changed and when is a human step, always.
The date matters as much as the change, because it lets work in flight be placed. A reply drafted last week can be recognised as pre-revision instead of argued about. The pet shop's manager tells staff which file changed and on what day. Where a plan supports shared editing, several people may hold edit permission on the same Project. That raises the stakes of saying what changed.
The Maintenance Habit
The habit that works has three parts.
First, a named owner. "Someone should keep this current" means nobody does. A drifted Project usually turns out to have no owner. The pet shop names its manager.
Second, a review point tied to a real recurring event: the quarterly figures, the policy refresh, the start of the season. A diary note attached to something that already happens fires. A general intention does not. The pet shop reviews its Project whenever a new price list arrives.
Third, removal treated as an active step of the review. Additions happen naturally all year. Deletions happen only when someone asks which items are superseded and which have never been used.
In the exam
The guide names the three duties. Every exam version of this objective is the same Project: set up well once, and drifted since. Update matters least, because updating is easy once you have noticed. Inform is named explicitly, and almost everyone skips it.
Two boundaries apply. A stem that opens with a bad output and asks what went wrong belongs to Domain 7. A perfectly maintained Project still produces first drafts whose facts get verified under Domain 2.
The additive trap
The distractor that keeps both versions feels thorough and careful. That is why it is wrong: it applies the archive instinct to a working tool. The keyed answer removes the superseded version, sweeps the instructions, and tells the people who use the Project.
A Note on Sources
No Anthropic article covers editing a saved configuration or telling collaborators it changed. This lesson rests on the exam guide's objective wording, ordinary professional practice and the one documented sharing notification.
Exam Traps
Uploading the revised document while keeping the superseded version, sometimes with a note saying which is current
Nothing tells Claude which version governs, so outputs can cite either. A working Project needs one current version and the old one removed; completeness belongs in the archive, not the knowledge base.
Adding an instruction telling Claude to prefer the newer document
This patches the instructions to route around a knowledge base that should simply be curated. The superseded document has no business staying in a working Project, and the patch itself becomes one more stale rule to maintain.
Assuming the system will tell colleagues the configuration changed
The only documented notification is the email when a project is first shared. No notification of any kind is documented for later edits to knowledge or instructions, so informing collaborators is always a human action in the keyed answer.
Practice Scenario
A bird observatory trust runs a Project that the bookings secretary and two other committee members use for overnight-stay booking correspondence. The booking terms were revised in March. Letters have started quoting the old cancellation notice period, and the secretary finds both versions of the terms in the project knowledge. The trust intends to keep the Project as its booking workspace. What should she do?
Build Exercise
The Three-Pass Audit
What you'll learn
- How to audit instructions for aspirations, dead rules and orphaned wording
- How to separate current, superseded and never-used knowledge
- How to name an owner and tie the next review to a real event
- How to write the one-sentence change note collaborators need
- Open a Project you already use, or the one built in the earlier exercises of this domain, and commit to auditing it in three passes
Why: Drift is invisible from inside day-to-day use; only a deliberate audit surfaces it.
You should see: The instructions and the knowledge list open side by side.
- Pass one, every line of the custom instructions: is it a behaviour a colleague could follow, an aspiration, or a rule written for a situation that has passed? Rewrite or delete accordingly
Why: Instructions decay by outliving the world they describe, and the audit is where orphaned rules finally get caught.
You should see: A shorter instruction set where every line is checkable and currently true.
- Pass two, every item in the knowledge base: current, superseded, or never actually used? Remove the superseded items rather than adding notes beside them, and remove anything that has never been needed
Why: Removal is the step that never happens naturally, and superseded material is how confident wrong answers get made.
You should see: A culled knowledge list holding exactly one version of everything, with upload dates noted.
- Pass three, the parts nobody owns: write down who owns this Project, what real recurring event triggers its next review, and one sentence you would send to everyone else who uses it describing what you just changed and when
Why: A named owner and a real trigger are what make the next audit happen, and the change note is the inform half done properly.
You should see: An owner, a dated trigger, and a one-sentence change note ready to send.
- If you could not name an owner in pass three, treat that as the finding: agree with the other users who owns it before closing the audit
Why: A Project that drifted usually turns out to have had no owner; fixing that outlasts every individual fix from passes one and two.
You should see: A named person attached to the Project, even if it is you.
Sources
- Manage project visibility and sharing — Anthropic
- How can I create and manage projects? — Anthropic
- Claude Certified Associate – Foundations Exam Guide — Anthropic. No Anthropic article covers editing a saved configuration, removing knowledge files or telling collaborators about changes. This lesson draws on the exam guide's objective and standard practice; the sharing article documents the one notification.