Keeping instructions and sources up to date

The support team at a subscription company drafts replies with a shared Project. The instructions say customers can request a refund within 30 days. Two weeks ago the company cut the window to 14 days and updated the website. Nobody touched the Project. Since then, each of the eight agents has been fixing the refund sentence by hand in almost every draft, and some customers have already been promised a refund they are not entitled to.

A Project does not find out on its own that the policy changed. Someone has to tell it, in the right place.

Fix it once, at the source

If the old rule is in the configuration, fixing it in each chat or each draft treats the symptom. Claude does not “learn” from the corrections agents make by hand in their drafts; the next chat reads the same old instruction again.

The rule:

1. Find where the old data lives: the project instructions, one or more knowledge files, or both.
2. Fix it there, once, in every place where it is repeated.
3. Remove the previous version. If two policies with similar names are loaded, Claude may answer with either one.

The goal is for the Project to be the team’s single source of truth: one current version of each document, and no outdated source waiting for someone to retrieve it.

What does not fix the problem

What is proposed	Why it is not enough
“If documents conflict, prefer the newest one”	Claude cannot always tell which is newer, and the old version is still loaded
Renaming the old file OLD_DO_NOT_USE	It is still in the knowledge and can be retrieved anyway
Opening a new chat for each reply	A new chat in the same Project reads the same configuration
Reminding the team to check the sentence before sending	It depends on nobody forgetting; the error is still in the source
Building a new Project from scratch	It works today, but next year the same thing happens if nobody is in charge

Making sure it does not happen again

Sources go out of date on their own; nobody cleans them up unless it is somebody’s job. That is why every Project needs:

• A project owner: the person who updates instructions and knowledge. In shared projects on Team and Enterprise, only members with edit permission (can edit) can change instructions and knowledge; members with can view chat but do not edit. That permission is best held by a few named people.
• A clear trigger: every time a policy, price or procedure changes, the owner updates the Project. It helps if the department that changes the policy lets them know.
• A periodic review, for example quarterly: go through the file list, remove duplicates and old versions, reread the instructions.
• A test after every change: a few fixed questions whose correct answer is known (“how many days are there to request a refund?”) to confirm the Project answers with the new data.

The typical traps

• Letting every agent keep fixing things by hand “until Claude learns.”
• Uploading the new policy without removing the old one.
• Solving the conflict with an instruction instead of cleaning up the sources.
• Fixing the one case without deciding who takes care of it next time.
• Giving the whole team edit permission “so anyone can fix it.”

On the exam

If the scenario says a policy changed and the Project still has the old data, the first action is to fix the configuration (instructions and any files that repeat the data). If two versions are loaded, the answer removes the old one; if it also asks how to prevent a repeat, it adds an owner who reviews the sources whenever a policy changes. Rule out the patches: “prefer the newest” instructions, renames, new chats and reminders to the team.