CCAO-F 5.4 — Keeping configurations current

The maintenance cycle

Triggercalendar date, or something changed
Reviewknowledge, instructions, connectors, access
Updateremove superseded, revise, re-authorise
Testre-run the questions that must stay right
Informtell the users what changed and why

Record the date and the owner; the next review starts from here

The last step is the one people skip. A shared configuration that changes without notice produces a week of people wondering why Claude is behaving differently.

Four things that go out of date, in different ways

It helps to separate them, because each decays for a different reason and each has a different fix.

What	How it goes stale	What maintenance looks like
Knowledge	A document is superseded, but the old one stays in the Project	Remove the old version; date the filename of the new one
Instructions	Rules accumulate, contradict each other, or name things that were renamed	Re-read them end to end; delete more than you add
Connectors and access	Permissions change, people leave, authorisation lapses	Check what is connected, by whom, and whether it is still needed
Memory	Claude carries forward a preference or a fact that is no longer true	View what is stored, edit or delete individual items

Knowledge is the most dangerous of the four, because retrieval has no sense of chronology. If a Project holds both the 2025 and 2026 expenses policies, the question “what is the mileage rate?” is answered from whichever passage matches best — which may well be the older one, if it happens to be more clearly worded. That failure looks exactly like a correct answer. Nothing in the response says “from a superseded document”.

Two Projects, a year on

Unmaintained

Three versions of the same policy, none dated
Instructions naming a product renamed last spring
A connector authorised by someone who has left
Nobody owns it, so nobody reviews it
Answers are fluent and quietly out of date

Maintained

One current version of each document, dated in the filename
Instructions re-read quarterly; contradictions removed
Connector list reviewed; unused connections removed
A named owner and a review date
A short changelog users can read

Neither Project shows an error. The difference only becomes visible when somebody acts on an answer and is wrong.

What triggers a review

Two kinds of trigger, and you need both. The calendar trigger is a standing review — quarterly suits most teams, monthly for anything regulated or commercially sensitive. The event trigger is anything that changes the underlying truth: a policy revision, a price change, a reorganisation, a product rename, a new regulation, a change of plan or of connector permissions, or the arrival of a capability your setup should now use.

There is a third trigger worth naming because it is the most informative: a wrong answer traced back to the configuration. When someone reports that Claude gave an outdated figure, the fix is not a better prompt. It is to find which document, instruction or connector produced it, correct that, and then check what else shares the same fault.

Worked example · The expenses policy that changed in April

Sofia owns a shared Project used by 40 managers to answer expenses questions. In April the company changed its mileage rate and its approval thresholds. She hears in June that a manager approved a claim at the old threshold.

She traces it to the source. The Project holds both the old and new policy documents; the old one was never removed, and its wording on thresholds is clearer, so it kept being retrieved.
She removes rather than adds. The superseded document comes out. The current one is renamed with its effective date so staleness is visible at a glance next time.
She re-reads the instructions end to end. Two of them refer to approval bands that no longer exist. Both are rewritten; one is deleted outright.
She tests with the questions that must stay right — mileage rate, approval threshold, receipt requirements, the two edge cases people always ask about — before telling anyone it is fixed.
She informs the users. A short note: what changed, when it took effect, and that answers given before today may have used the old thresholds. This is the part that turns a fix into a correction.
She adds a dated changelog note to the Project and puts a quarterly review in her calendar with her name against it.

Takeaway: The technical fix took ten minutes. The valuable parts were tracing the wrong answer to a specific document, telling 40 people that earlier answers may have been wrong, and making sure the next policy change has a named person waiting for it.

Maintaining memory

Memory is configuration too, and it is the part users are least likely to think of. When it is on, Claude generates memory from your chats and carries context forward. Each Project has its own separate memory space and its own project summary, so project context stays isolated from your other work. Anthropic documents it as enabled by default on the Free, Pro and Max plans and disabled by default on Team and Enterprise, where an owner must turn it on.

The controls live in Settings and then Memory. You can see what Claude remembers about you under Topics, and edit or delete individual memories — you can also tell Claude directly in a conversation to remember or forget something. Pausing memory keeps what exists but stops new memories being created. Resetting memory permanently deletes all memories, including project memories, and cannot be undone. An incognito chat is not saved to your history, and Claude will not save memories from it. On Team and Enterprise, owners control memory organisation-wide under organisation settings, and memory toggles appear in audit logs.

A quarterly configuration review

Fails: One current version of every documenttwo expenses policies present
Check: Filenames carry the effective datehalf of them do
Fails: Instructions match today’s products, roles and thresholdstwo reference retired approval bands
Check: Connectors still needed, still authorised, owner still hereone authorised by a leaver
Passes: Stored memories are still true
Missing: A named owner and a next review dateno owner recorded
Passes: Users told what changed last timenote posted in April

Twenty minutes, four times a year. Everything failing here was working correctly on the day it was set up.

Informing people is part of the job

The objective puts “inform” first, and that ordering is worth taking seriously. A shared configuration is something colleagues rely on without seeing. If you change the instructions in a shared Project, behaviour changes for everyone in it, with no announcement from the product. People who notice will assume something is broken; people who do not notice will carry on with a mental model that no longer matches reality.

Say what changed and when it takes effect — in one short message, not a document nobody opens.
Say what it means for work already done. If earlier answers may have been wrong, say so plainly; this is the sentence people most need and least like writing.
Say who owns it now, so the next person with a question knows where to go.
Allow for propagation. Organisation instructions can take up to an hour to reach every Claude product, so do not announce a change and invite everyone to test it immediately.
Keep a dated changelog in the Project itself, so the history travels with the configuration rather than living in someone’s inbox.

Worked example · A product rename that touched four places

A software company renames its flagship product. The old name appears in organisation instructions, in three Projects’ instructions and knowledge, in a proposal skill, and in people’s stored memories.

They list the places first, because a rename that is half-done is worse than one not started: answers become inconsistent between colleagues.
Organisation instructions are updated by an owner, within the 3,000-character budget, and everyone is told the change may take up to an hour to appear.
Each Project owner updates their own instructions and knowledge, replacing rather than supplementing the old naming.
The proposal skill is updated and re-tested, since a skill is loaded when Claude judges it relevant and will otherwise keep reproducing the old name in drafts.
Individuals are told how to correct a stored memory — edit that topic in Settings rather than resetting memory wholesale.
One person owns the checklist and confirms each item, rather than assuming four teams all did their part.

Takeaway: Configuration lives in more places than anyone remembers. The habit that makes rollouts survivable is writing down where the standing context lives, at the time you create it, so that a change has a list to work through rather than a search to conduct.

Traps the wrong answers are built from

Tempting but wrong	Do this instead
Fixing an outdated answer with a prompt workaround	Find the document, instruction or connector that produced it and correct the source.
Adding the new version and leaving the old one in place	Remove superseded documents; retrieval cannot tell which version governs.
Changing a shared configuration silently	Tell the users what changed, when it applies, and what it means for earlier work.
Resetting memory to correct one wrong item	Edit or delete that topic in Settings; a reset removes everything, project memories included, irreversibly.
Setting up a Project with no owner and no review date	Name the owner and the review cadence at the time you create it.

You should now be able to

Run a review of knowledge, instructions, connectors and memory on a defined cadence.
Trace an outdated answer to the configuration element that produced it.
Remove superseded material rather than adding to it, and date filenames so staleness is visible.
Use the memory controls proportionately: view, edit, delete a topic, pause, or reset as a last resort.
Inform users of a change, including what it means for work already done.
Assign an owner and a review date to any shared configuration.

Keeping configurations current