What You Need to Know
A systems life cycle is the sequence of phases a system goes through, from first idea to switch-off. Each of its canonical phases owns a set of activities.
- Planning and requirements
- Design
- Development
- Testing
- Implementation and deployment
- Operations and maintenance
- Retirement
A lighting shop has piloted a Claude assistant that drafts replies to customer questions about bulbs. Staff check every draft in a manual review queue. Now the assistant is moving to production.
The Phases and What They Own
- Designing the regression eval set is testing, even when the shop does it weeks before any deployment. Evals are derived from requirements, not reverse-engineered from incidents. A suite built from incidents pins yesterday's failures instead of the required behaviour.
- The cutover plan that swaps the pilot's manual review queue for the production approval flow is implementation. It happens once.
- The standing cost-per-task dashboard, error triage, prompt fixes and the plan for moving off a deprecated model are operations and maintenance. They recur for the life of the system.
- Switching off the pilot stack and disposing of its logs is retirement. Data disposition is part of that phase. Turning the servers off is not the whole phase.
The usual mistake treats go-live as the finish line, where the project is done. For a Claude application the maintenance load is structural, not residual. A prompt change is a behaviour change, and it can ship in hours. The model underneath also moves on a clock the shop does not control.
Cadence Changes, Concerns Do Not
Agile, iterative and plan-driven frameworks all contain the same concerns: requirements, design, build, test, deploy, operate, retire. They differ in how often the loop turns. Claude applications push cadence to the fast extreme: the shop changes a prompt, runs evals and releases in short loops. Each turn changes behaviour, so the eval suite is the recurring test phase rather than a one-time gate.
The Deprecation Clock
Anthropic's documented model lifecycle runs Active, Legacy, Deprecated, Retired. A deprecated model still works but is no longer recommended. Anthropic gives it a recommended replacement and a retirement date. A retired model fails every request. Publicly released models get at least 60 days' notice before retirement, on the deprecations page and by email. Once a model is deprecated, all usage must be migrated to a suitable replacement before its retirement date.
The shop does not set that date, and after it every draft request to the old model fails. So the shop plans for the migration from day one, as an external event.
- Re-run the eval suite against the replacement, to check it still meets the shop's requirements.
- Roll the replacement out through the normal release process.
- Audit which keys still call the old model, because any key left on it fails at retirement.
These dates bind Anthropic-operated platforms. Amazon Bedrock and Google Cloud set their own retirement schedules. A shop serving its assistant from two surfaces could face two migration deadlines for one model.
Confirming what an identifier currently resolves to is one API call.
import anthropic
client = anthropic.Anthropic()
model = client.models.retrieve("claude-sonnet-5-5")
print(model.id, model.display_name, model.created_at)
# What can this key still reach?
for m in client.models.list(limit=20):
print(m.id)A shop that learns of a retirement from failing requests skipped the maintenance phase.
In the exam
This is the domain's lightest sub-skill and its most mappable. Items do not ask you to recite phases; they hand you an activity and ask which phase governs it. Learn the ownership table and most of the sub-skill follows. If an item asks which framework adds or removes a life cycle concern, the answer is none. Platform matters whenever a stem mentions it.
A prompt fix after go-live is maintenance
Once the system is live, prompt changes ride the operations loop with evals as the gate. The two misplacements keyed most often are filing them under development and writing the eval suite only after production behaviour disappoints.
The deprecations page carries the lifecycle states and dates; the Models API shows what your keys can reach today.
Exam Traps
Placing the cutover plan in operations because it governs how the production service starts operating.
Cutover is the implementation phase and happens once. The standing dashboard is its recurring near-neighbour in operations, and phase-placement items love putting the two side by side.
Assuming deprecation dates are uniform across every platform that serves Claude models.
The documented dates bind Anthropic-operated platforms; Amazon Bedrock and Google Cloud set their own retirement schedules. The same model can retire on different dates on different surfaces, so read the stem for the platform.
Designing the eval suite in response to a production incident and calling that the testing phase.
Evals are designed against requirements in testing and re-run in operations. A suite reverse-engineered from incidents pins yesterday's failures instead of the required behaviour; a stem showing this is showing the anti-pattern.
Practice Scenario
A launderette chain's Claude-based machine-fault report classifier is moving from a six-month pilot to production service. The team lists four activities: (1) a standing dashboard tracking cost per classified report plus a written plan for migrating when the pinned model is eventually deprecated; (2) the regression eval set that will gate every release; (3) the cutover plan replacing the pilot's manual review queue with the production approval flow; (4) decommissioning the pilot stack and disposing of its logs. Which activity belongs to the operations and maintenance phase?
Build Exercise
Write the Maintenance Plan Before Go-Live
What you'll learn
- How to assign real activities to life cycle phases
- How to separate recurring work from one-off work
- How to read the deprecation page as a maintenance input
- How to write a migration runbook before it is urgent
- Take a Claude application at or near production and list every activity in its next six months: eval runs, dashboards, prompt changes, dependency updates, model migrations
Why: The ownership table only sticks when populated with work you actually face.
You should see: A list of eight to fifteen concrete activities.
- Assign each activity a life cycle phase and mark it recurring or one-off, challenging any one-off that would in fact repeat
Why: Phase placement plus the recurring-versus-one-off distinction is exactly the two-axis judgement the items key.
You should see: Every activity carrying a phase and a cadence, with at least two corrections from your first instinct.
- Open the model deprecations page and record the current lifecycle state of your pinned model and its earliest possible retirement date
Why: The deprecation clock is an operations input on a schedule you do not control; reading it now is what makes migration a planned task.
You should see: A state (Active, Legacy, Deprecated or Retired) and a date, or confirmation that no date is set.
- Write the migration runbook now: the replacement candidate, the eval suite to re-run, the rollout mechanism, and the usage audit that confirms no key still calls the old model
Why: A runbook written before the notice arrives turns a 60-day clock into a routine release instead of an incident.
You should see: Four named steps a colleague could execute without you.
- Close by writing the retirement entry: what switching this system off would require, including data disposition
Why: Data disposition is the phase element candidates forget, and writing it once fixes that permanently.
You should see: A short paragraph covering the stack, the logs, and any stored member or customer data.
Sources
- Model deprecations — Claude Docs, the Active/Legacy/Deprecated/Retired lifecycle and the 60-day notice commitment
- Models overview — Claude Docs, current model identifiers and what each resolves to
- Claude Certified Developer Foundations Exam Guide — Domain 2, Systems Life Cycle — Anthropic