What You Need to Know
A systems life cycle is the sequence of phases in the life of a system, from the first idea to switch-off. Each of its standard phases has its own set of activities.
- Planning and requirements
- Design
- Development
- Testing
- Implementation and deployment
- Operations and maintenance
- Retirement
This lesson uses one made-up example throughout: a payments company. Its engineering team has piloted a Claude assistant that drafts replies to merchants' questions about failed payments. Support staff check every draft in a manual review queue. Now the assistant is moving to production.
The Phases and What They Own
- An eval is a test that checks the assistant's output against a requirement. The regression eval set is the group of evals that every release must pass. Designing it is testing, even when the company does it weeks before any deployment. Evals come from requirements. A suite built only from incidents checks for past failures instead of the required behaviour. After launch, Anthropic's guidance is to write an eval for each production incident and keep it in the suite as a regression test. That work belongs to operations. It adds cases to the suite that the testing phase built.
- The cutover is the switch from the pilot arrangement to the production one. The cutover plan that replaces the pilot's manual review queue with the production approval flow is implementation. The cutover happens once.
- The ongoing cost-per-task dashboard, error triage, prompt fixes and the plan to migrate from a deprecated model are operations and maintenance. These activities recur for the life of the system.
- Switching off the pilot stack (the servers and software that ran the pilot) and disposing of its logs is retirement. Disposing of the data is part of that phase. Switching off the servers is not the whole phase.
The usual mistake treats go-live as the point where the project is done. For a Claude application, the maintenance load comes from how the system works. It is not work that remains from development. A prompt change is a behaviour change, and the company can release it in hours. The underlying model also changes on a schedule that the company 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 they repeat the cycle. Claude applications repeat it at the fastest rate: the team changes a prompt, runs evals and releases in short cycles. Each cycle changes behaviour, so the eval suite is the recurring test phase, not a one-time check.
The Deprecation Clock
Anthropic's documented model lifecycle has these states, in order: Active, Legacy, Deprecated, Retired. A deprecated model still works, but Anthropic no longer recommends it. Anthropic gives it a recommended replacement and a retirement date. A retired model fails every request. Anthropic gives at least 60 days' notice before it retires a publicly released model, 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 company does not set the retirement date. After that date, every draft request to the old model fails. So the company plans for the migration from the first day, as an external event.
- Re-run the eval suite against the replacement, to check it still meets the company's requirements.
- Deploy the replacement through the normal release process.
- Audit which API keys still call the old model, because any key that remains on it fails at retirement.
These dates apply to Anthropic-operated platforms. Amazon Bedrock and Claude Models on Google Cloud (Google managed) set their own retirement schedules. A company that serves its assistant from two platforms could have two migration deadlines for one model.
One API call confirms what an identifier currently resolves to.
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 team that learns of a retirement from failing requests skipped the maintenance phase.
In the exam
This is the lightest sub-skill in the domain, and the easiest to map. Questions do not ask you to recite phases. They give you an activity and ask which phase governs it. If you learn which activity belongs to which phase, you know most of the sub-skill. If a question asks which framework adds or removes a life cycle concern, the answer is none. Platform matters whenever a question mentions it.
A prompt fix after go-live is maintenance
Once the system is live, prompt changes are part of the operations cycle, and evals decide whether each change can be released. The exam most often tests two wrong placements: filing prompt changes under development, and writing the eval suite only after production behaviour disappoints.
The deprecations page lists 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 swaps the pilot arrangement for the production flow once, so it is implementation. Operations includes the activities that recur, such as the standing cost dashboard.
Assuming deprecation dates are uniform across every platform that serves Claude models
The documented dates apply to Anthropic-operated platforms. Amazon Bedrock and Google Cloud (Google managed) set their own retirement schedules, so one model can carry two migration deadlines. Check which platform the scenario names.
Designing the eval suite in response to a production incident and calling that the testing phase
Evals are derived from requirements in testing, then re-run in operations. A suite built only from incidents checks for past failures instead of the required behaviour. Design it against requirements before deployment, then add an eval for each incident.
Practice Scenario
A payroll software company's Claude-based classifier for customer error reports 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 (the exact model version named in its requests) is eventually deprecated; (2) the regression eval set that every release must pass; (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 (a written list of the steps for the migration) 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: You remember which activity belongs to which phase only when you sort work you actually face into phases.
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 pair of decisions that the exam questions test.
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 notice period 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, which is how the stored data is disposed of
Why: Data disposition is the part of this phase that 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
- AI-native SDLC playbook: Continuous evals in CI — Claude Academy, an eval for each production incident, kept in the suite as a regression test
- Claude Certified Developer Foundations Exam Guide — Domain 2, Systems Life Cycle — Anthropic