5.3 Maintaining and Updating Configurations Over Time

Everything built in the first two lessons of this domain — a well-configured Project, curated knowledge, a sharp system-level instruction — has an expiration date if nobody tends to it. Business context and source material change: policies get revised, processes get updated, documents get superseded. Because a Project's instructions and knowledge persist by design, that same persistence becomes a liability the moment the underlying reality moves and the configuration doesn't move with it.

This reframes configuration work: it isn't a task you complete once at setup and check off. It's an ongoing responsibility with three concrete parts. Refresh knowledge sources when documents change, removing superseded versions so Claude doesn't cite stale facts. Update instructions when the process, tone, or rules change. Review periodically whether the Project still reflects how the team actually works, rather than waiting for something to visibly break.

• 1.Refresh knowledge sources when documents change; remove superseded versions.
• 2.Update instructions when the process, tone, or rules change.
• 3.Review periodically that the Project still reflects how the team actually works.

Stale configuration is dangerous precisely because Claude behaves correctly with respect to what it was given. It faithfully follows outdated instructions or cites an old policy document, producing output that looks confident and well-grounded while being wrong. There's no error message, no crash, no obvious signal — the failure is silent unless a person notices that the output no longer matches current reality. Compare that to a system that visibly breaks when something changes: at least that failure announces itself. Stale configuration doesn't.

This is why keeping knowledge and instructions current deserves to be understood as an accuracy control, on the same footing as other verification practices from Domain 2, rather than as mere tidiness. A Project that's never revisited will drift out of sync with the business it's meant to support, even though nothing about the Project's original setup ever "broke" in any technical sense.

When a policy document in a Project is replaced by a new version, the correct action is to update or remove the old source so Claude grounds answers in the current policy — not to keep both versions in place "for completeness." That impulse to keep the old version feels safe, as if more information is always better, but it directly recreates the curation problem from Lesson 5.1: two documents with equal apparent authority, one of them wrong, and no signal to Claude about which one currently applies.

The same logic applies to a Project's instructions. If the team's process, tone requirements, or rules change, the instruction has to change with them — promptly, not eventually. An instruction written for last quarter's refund policy that nobody updated is functionally the same failure as an outdated document: Claude will follow it exactly, which is precisely the problem.

Periodic review is what catches the drift that individual updates miss — nobody remembers to update an instruction the moment a process changes, so a standing habit of checking whether the Project still reflects how the team actually works is the safety net underneath the other two maintenance practices. This closes the loop on the whole domain: Lesson 5.1 built the Project and curated its knowledge, Lesson 5.2 wrote instructions that actually constrain behavior, and this lesson makes sure both of those stay true as time passes and the business keeps moving.

Put together, the exam trap running through Task Statement 5.4 is really one trap wearing two outfits: assuming a one-time setup stays correct indefinitely, and leaving outdated documents in place instead of replacing them. Both traps share the same root cause — treating configuration as a project you finish, instead of a standing responsibility you keep.

• •Leaving outdated documents in a Project so Claude grounds answers in superseded material — replace or remove, never "keep both."
• •Assuming a one-time setup stays correct indefinitely as the underlying process evolves — review periodically instead.
• •Treating stale configuration as a minor inconvenience rather than an accuracy failure — it's silent, confident, and wrong.