Configuration Maintenance as an Accuracy Control

Configuration Is Not "Set and Forget"

Business context and source material change: policies get revised, processes get updated, documents get superseded. Because a Project's instructions and knowledge persist, they need active upkeep to stay correct:

• Refresh knowledge sources when documents change; remove superseded versions so Claude doesn't cite stale facts
• Update instructions when the process, tone, or rules change
• Review periodically that the Project still reflects how the team actually works

Why Staleness Is a Quiet Failure Mode

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; the failure is silent unless someone notices the output no longer matches current reality.

Keeping knowledge and instructions current is therefore itself an accuracy control, on the same footing as other verification practices: a Project that is never revisited will drift out of sync with the business it's meant to support, even though nothing about the Project's setup "broke."

Common exam traps

• Leaving outdated documents in a Project so Claude grounds answers in superseded material -- the correct action when a document is replaced is to update/remove the old source, not to keep both "for completeness."
• Assuming a one-time setup stays correct indefinitely. A Project configured well on day one can still become wrong over time if the underlying process evolves and the configuration doesn't.