- In short
- Operating and maintaining a Claude system means sustaining it after launch: monitoring quality, cost, and latency against the original requirements, and managing model version updates, prompt changes, and dependency upgrades. Because behaviour can shift across model releases, maintenance includes revalidating the system rather than assuming it still passes.
Keeping a live Claude system healthy
A Claude system does not stop needing attention the moment it ships. Task statement 2.2 of the Claude Certified Developer - Foundations (CCDV-F) exam covers the two life-cycle phases that follow deployment, operation and maintenance, and this knowledge point is about sustaining a system through both. It builds directly on systems development life cycle phases, where those phases were named; here you learn what actually happens inside them for an AI system. The exam treats this at the understand level, so it wants you to grasp what operation and maintenance involve and why they carry AI-specific risks that a traditional system does not.
The short version is that operation is about watching, and maintenance is about changing, and both are measured against the requirements the system was built to satisfy. Everything below expands those two ideas and the drift risk that makes them non-optional on a Claude project.
- Operation and maintenance
- The post-launch phases of a system's life cycle. Operation monitors quality, cost, and latency against the original requirements while the system runs. Maintenance changes the system over time, through model updates, prompt revisions, and dependency upgrades, and revalidates it because behaviour can shift across model releases.
Operation is monitoring against the original requirements
Operating a Claude system means keeping it under observation while it runs, and the thing you observe it against is the set of requirements it was built to meet. Those requirements came from task statement 2.1, so operation is where the functional requirements and the non-functional targets earn their keep. You monitor three things above all: quality, whether the outputs still meet the behavioural bar the evals encoded; cost, whether per-call and aggregate spend stay under the ceiling; and latency, whether responses still return inside the budget.
The reason all three matter, not just quality, is that a Claude system can regress on any of them independently. Output quality can hold while cost creeps up because prompts grew or traffic shifted. Latency can degrade under load even when answers stay correct. Cost can spike when a change increases token usage. Monitoring against the original requirements is what turns these silent regressions into visible signals, which is the whole point of the operation phase. A system nobody is watching against its targets is a system that can fail its requirements without anyone noticing.
Maintenance is managing change over time
Maintenance is the phase where the system is deliberately changed to keep it healthy, and on a Claude project three kinds of change dominate. Model version updates, when you move to a newer model release. Prompt changes, when you revise the instructions the system runs on. And dependency upgrades, the SDKs, libraries, and services the application relies on. Each of these is a normal, expected part of sustaining an AI system, not an emergency, and each one changes the behaviour of a probabilistic system in ways that need to be checked.
This is where the second exam trap lives: treating maintenance as bug fixing only, ignoring drift and cost regressions. Bug fixing is reactive, waiting for something to break. Maintenance of a Claude system is broader and partly proactive, because the risks are not only outright bugs but gradual drift in quality and quiet regressions in cost. A prompt that grew over several edits can raise token spend without breaking anything. A dependency upgrade can change how requests are formed. Maintenance owns all of it, which is why it is a substantial phase rather than a bug queue. Pinning the model version, covered in model version pinning, is one of the levers that makes these changes deliberate rather than accidental.
Behaviour shifts across releases, so revalidate
The idea that ties operation and maintenance together, and the one the exam most wants you to hold, is that model behaviour can shift across releases. A system that passed its evals on one model version is not guaranteed to pass on a newer one, because the newer model may respond differently to the same prompts. This is not a defect; it is a property of moving between model versions, and it is precisely why maintenance includes revalidation rather than a blind swap.
The first exam trap follows directly: assuming a system that passed launch evals will keep passing after a model update. It will not, automatically. The correct discipline is that any model update is followed by re-running the evals to confirm the system still meets its quality bar, and by checking that cost and latency have not regressed either, before the change reaches production. Revalidation is the safety mechanism that lets you adopt new models without gambling on unseen behaviour changes. Without it, an update that looks like routine housekeeping can silently break the requirements the system was signed off against.
A worked example
Worked example
A Claude system that summarises support conversations has run smoothly for months. A newer model version is announced, and the team wants to adopt it.
The tempting move is to swap the model identifier and ship, on the reasoning that the newer model is more capable, so it can only improve things. That reasoning is the trap. Capability improving in general does not guarantee that this specific system, with its specific prompts and its specific quality bar, behaves the same way on the new version. Behaviour can shift, and a summary style the old model produced reliably might change in tone, length, or grounding on the new one.
The maintenance-phase discipline is different. Before touching production, the team re-runs the evaluation set that gated the original launch against the new model version and compares the results: does quality still clear the bar, has latency moved, has token usage and therefore cost changed. Suppose the new model produces slightly longer summaries; quality holds but cost per call rises above the ceiling. That is a cost regression the operation-phase monitoring would eventually have caught, but revalidation caught it first, before users were affected. The team adjusts the prompt to constrain length, revalidates again, and only then promotes the change.
Notice that none of this was bug fixing. Nothing was broken. It was maintenance in its proper sense, managing a model update with revalidation so a routine upgrade did not quietly breach a requirement.
Common misreadings to avoid
Misconception
A system that passed its launch evals will keep passing after a model version update.
What's actually true
Misconception
Maintaining a Claude system is basically bug fixing when something breaks.
What's actually true
How this is tested on the CCDV-F exam
Scenarios on this knowledge point describe a live Claude system and a change or a symptom, and ask what operating or maintaining it correctly requires. The winning answers monitor quality, cost, and latency against the original requirements, and treat any model or dependency change as something to revalidate rather than assume through. The losing answers swap a model on the strength of it being newer, or frame maintenance as waiting for bugs. Keep both traps in view: launch evals do not stay valid across model versions, and maintenance is broader than bug fixing.
Operation and maintenance describe what sustaining a Claude system takes. The remaining knowledge point in this task statement, integrating Claude into an existing SDLC, turns to how that work slots into an established engineering process.
A live Claude assistant has met its quality, cost, and latency targets for six months. Ops reports outputs are still accurate but the monthly bill has climbed steadily. What best describes the situation and the right response?
People also ask
What does operating a Claude system involve?
Why do Claude systems need revalidation after a model update?
Is maintaining an AI system just bug fixing?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
No videos curated for this concept yet
We are still curating the best official and community videos for this topic.
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.