The life cycle, as a loop
- Planrequirements and success criteria
- Buildprompts, tools, integration, config
- Verifyevaluate against the criteria
- Operaterelease, monitor, support
- Evolve or retirechange, migrate, decommission
every change re-enters at plan · nothing ships straight from build to operate
The phases, and what each one owes the next
Whatever framework your organisation uses — a staged waterfall, an iterative sprint cadence, or continuous delivery — the same responsibilities have to land somewhere. Planning produces requirements and the measurable success criteria that task statement 2.1 covers. Build produces the application, its prompts, its tool definitions and its configuration. Verification compares the built thing against the criteria rather than against somebody's impression of it. Operation runs it, watches it and supports the people using it. Evolution changes it, and eventually retires it.
What each phase owes the next is an artefact, and that is what exam scenarios usually probe. Planning owes verification a target that can fail. Build owes operations a configuration that is written down rather than typed by hand. Operations owes evolution evidence: what actually happened, how often, at what cost. A team that cannot say what “good” looked like last month has no basis for deciding whether this month's model upgrade helped.
| Phase | Typical activity on a Claude system | The artefact it hands on |
|---|---|---|
| Plan | Turn a business outcome into measurable criteria | Success criteria with units and a sample |
| Build | Prompts, schemas, tools, settings, pinned model ID | A repository that fully describes the system |
| Verify | Run the evaluation set; review code and outputs | A pass/fail record against the criteria |
| Operate | Monitor errors, latency, spend; support users | Traces, usage data and incident history |
| Evolve | Migrate models, revise prompts, widen scope | A change record and a fresh evaluation |
| Retire | Decommission, export data, revoke keys | A decommissioning record |
Operating a system whose dependency has its own calendar
This is the part generic life-cycle training does not prepare you for. Anthropic publishes a lifecycle for every model with four states: active, fully supported; legacy, still working but no longer receiving updates; deprecated, given a retirement date and a recommended replacement; and retired, at which point requests to that model fail. For publicly released models, Anthropic commits to notifying customers with active deployments at least 60 days before retirement, by email and on the deprecations page.
The practical consequences are maintenance tasks, and they are the kind of thing a question can be built from. Audit which model IDs your organisation is actually calling — the Console's usage data will tell you, and it is often not what the team believes. Test against the recommended replacement well before the date. Migrate rather than waiting, because the day after retirement is not a good day to discover a behaviour change.
A model's service life
from fully supported down to unavailable
- Activesupported and recommended
- Legacyworks, no longer updated
- Deprecatedretirement date and replacement named
- Retiredrequests to it fail
Change that arrives without a release of yours
Two more external clocks are worth knowing. The first is the API version itself: requests carry an anthropic-version header, and within a version Anthropic preserves existing input and output parameters. Additive changes are explicitly allowed without a version bump — new optional inputs, new values in enum-like outputs such as additional stop_reason values or new streaming event types. That is a maintenance instruction disguised as a policy: parse defensively, ignore fields you do not recognise, and never write a switch that crashes on an unfamiliar value.
The second is the platform around the model. Model identifiers from the 4.6 generation onward are dateless and each one is a fixed snapshot whose weights are not updated; new versions ship as new identifiers. The serving infrastructure around them — routing, safety classifiers, sampling — can still evolve, so small behavioural differences are possible even on a pinned identifier. That is precisely why verification is a repeatable artefact rather than a one-off.
Two kinds of change
Change you schedule
- A prompt or schema revision you ship
- A new tool added to the application
- An infrastructure or dependency upgrade
- You choose the date and the rollback
Change that arrives
- A model moves to deprecated with a retirement date
- A newer model makes your current one worth re-testing
- Additive API fields and new enum values appear
- Your input mix shifts as users find new uses
Wiring the life cycle into the tools the team already uses
Life-cycle management becomes real when it lives in the pipeline rather than in a document. Claude Code's GitHub Action runs inside a repository's workflows and can be pointed at a pull request: the review workflow installs a review plugin and posts findings as inline comments on the pull request rather than burying them in a run log. Teams cap what each run may do with arguments such as a turn limit and an allowed-tool list, and store credentials as repository or organisation secrets rather than in the workflow file.
None of that replaces human review, and the exam does not reward pretending otherwise. It supports the verification phase: an extra reviewer that never gets bored, on every pull request, with the project's standards written down where both people and tools can read them.
Traps the wrong answers are built from
| Tempting but wrong | Do this instead |
|---|---|
| Treating go-live as the end of the project | Plan operations and evolution as explicit phases with owners and artefacts. |
| Waiting for the retirement date before testing the replacement | Start the comparison when the deprecation notice arrives; at least 60 days' notice is only useful if you use it. |
| Writing code that fails on an unfamiliar enum value | Parse defensively — additive values and new event types can appear without an API version bump. |
| Keeping prompts and configuration outside version control | Put them in the repository so a change gets review, history and an evaluation run. |
| Judging a new model by trying a few prompts by hand | Re-run the same evaluation set and compare against the recorded baseline. |
You should now be able to
- Name the life-cycle phases and the artefact each one hands to the next.
- Describe Anthropic's model lifecycle states and the minimum retirement notice period.
- Plan a migration off a deprecated model using usage data and an existing evaluation set.
- Explain which API changes can appear without a version bump, and how to code for them.
- Place verification activity inside a pull-request pipeline rather than after release.