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 in the Project and uses the knowledge as context in those chats. Lesson 5.1 explains how, including the search mode for a large Project. Keeping a configuration right has three duties: inform, maintain and update. The work has three parts: check on a schedule, remove old items rather than keep adding new ones, and remember the people that the configuration serves.
This lesson uses one made-up example throughout: an accounting firm that configured a Project well last year to answer client questions. Its knowledge base holds the price list and the payment terms. Nobody has changed the Project since.
Three Ways a Good Setup Decays
Knowledge becomes out of date. An uploaded file is a copy from one moment, and nothing tells you that its source was superseded, which means replaced by a newer version. Outputs continue to quote the old policy, price or procedure with complete confidence. At the accounting firm, last year's price list still answers price questions.
Instructions become out of date. They apply to every chat, whether or not the situation they describe still exists. When the audience or the format changes, the rules continue to enforce the old situation.
The scope grows. When a Project works, people start to use it for related work. With each new task, the instructions written for the original job fit the work less well, until they fit none of the work.
All three problems are invisible while you use the Project, so you have to schedule maintenance. If you wait for a sign that maintenance is needed, that sign never comes.
Remove, Do Not Accumulate
When a document is superseded, remove the old version. Do not add the new one alongside it. Completeness is a good quality in an archive. A working Project needs exactly one answer to which version is current. If a knowledge base holds both versions, Claude has no way to know which version is current. The accounting firm uploads the new price list and deletes the old one.
Two compromise options fail: a note file explaining which version governs, or an instruction telling Claude to prefer the newer document. Both options compensate for a problem that the knowledge base should simply not have.
After you replace a document, also read the instructions for rules written for the old wording. A standing rule that quotes the old notice period stays after its source file is gone. At the accounting firm, that rule might quote last year's payment period.
Informing Is a Human Step
When colleagues share a Project, an unannounced change produces outputs that they cannot explain. They stop trusting those outputs. The person who made the change is rarely present when this happens.
The documentation gives one notification fact: members receive an email notification when a project is first shared with them. The documentation describes no notification of any kind for later edits to knowledge or instructions. So telling collaborators what changed and when is always a human step.
The date matters as much as the change, because it lets people tell whether work in progress was done before or after the change. People can recognise a reply drafted last week as pre-revision, instead of arguing about it. The firm's office manager tells staff which file changed and on what day.
When you share a Project, you give each member one of two permission levels. The person who created the Project controls everything. A member with Can view can see the instructions and the knowledge and chat in the Project, but cannot change them. A member with Can edit can change the instructions and the knowledge and manage member settings. On Enterprise plans, that member can also add project tags, which are labels with a name and a value. Project tags are in beta. Give Can edit to the person who maintains the setup, and Can view to colleagues who only use it. At the accounting firm, the office manager holds Can edit and the accountants hold Can view. When several people hold Can edit, it is even more important to say 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 Project that has slowly gone out of date usually has no owner. The accounting firm names its office manager as owner.
Second, a review point tied to a real recurring event: the quarterly figures, the policy refresh, the start of the season. A calendar reminder attached to something that already happens makes the review happen. A general intention does not. The accounting firm reviews its Project whenever a new price list arrives.
Third, treat removal 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 question on this objective describes the same situation: a Project that was configured well once and has gone out of date since. Update is the least difficult duty, because updating is easy once you have noticed the problem. The guide names Inform explicitly, and almost everyone skips it.
Two boundaries apply. A question 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 wrong option that keeps both versions feels thorough and careful. This feeling is why the option is wrong: it treats a working tool as if it were an archive. The right answer removes the superseded version, checks the instructions, and tells the people who use the Project.
A Note on Sources
Anthropic's Claude 101 course advises reviewing and updating a Project's knowledge regularly, because outdated documents can give outdated answers. No Anthropic article covers telling collaborators that a configuration changed. That part of this lesson is based 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 compensate for a knowledge base that should simply be curated. The superseded document should not stay 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. None is documented for later edits to knowledge or instructions, so tell colleagues yourself.
Practice Scenario
A hotel chain runs a Project that the reservations manager and two other team members use for group booking correspondence. The booking terms were revised in March. Letters have started quoting the old cancellation notice period, and the manager finds both versions of the terms in the project knowledge. The hotel chain 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, rules that no longer apply and wording left from replaced documents
- 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 go out of date when the situation they describe has changed, and the audit is where rules that no longer match anything are finally found.
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 reduced 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 removing knowledge files or telling collaborators about changes. The Claude 101 course advises keeping a Project's knowledge current. This lesson draws on the exam guide's objective and standard practice; the sharing article documents the one notification.
- Introduction to projects — Anthropic Academy