What You Need to Know
The objective names five lifecycle phases (discovery, design, handoff, monitoring, iteration). This lesson adds build and validate as a separate phase between design and handoff. That gives six phases. Each phase produces outputs that the next phase can check, such as a baseline. A baseline is the measurement that later changes are compared with. A phase gate stops the next phase until those outputs exist. The architect's job does not end at deployment.
This lesson uses one made-up example throughout: an energy supplier adding an assistant that answers customers' questions about bills and price plans.
Phases Are Gated by Outputs, Not Dates
A date cannot show that a phase produced what the next phase needs. Design that starts on an unmeasured problem produces an architecture that nobody can validate. Build that starts without an evaluation plan produces a system whose quality is a matter of opinion. Each phase is responsible for these outputs.
- Discovery: the problem with its measured baseline, agreed measurable success criteria, the data and compliance assessment, and the named accountable owner.
- Design: the architecture and its decision records, the evaluation plan, the oversight and control design, and the service-level envelope, which is the range of service levels that the engineering can support.
- Build and validate: the system plus its measured performance against the agreed criteria. A demonstration is not a measurement.
- Handoff: transferred ownership, which is more than transferred code.
- Operate and monitor: the trend against the criteria, and a working process for handling incidents.
- Iterate: changes that require evidence, and that re-enter design rather than bypass it.
A project can be delivered exactly on schedule and still be impossible to declare finished. The reason is that nothing was produced that could show whether the project was finished. If the energy supplier never measures today's wrong billing answers, the assistant can launch on time and nobody can say whether it helped.
Ownership Transfer Is Capability Transfer
Handover is not a document delivery. Ownership has transferred only when the receiving team can do four things.
- Run the evaluations and get a comparable answer.
- Read a trace, the recorded steps of one request, well enough to localise a failure.
- Undo a change.
- Know who to contact when none of that is enough.
A team that lacks any of these abilities will operate the system and refuse to change it. The reason is that the team cannot measure or undo a change. That behaviour looks like stability, but it is an inability to change the system. Before the energy supplier's support engineers take ownership, the architect has them run the evaluation suite and read a failed trace.
Iteration Is Evidence-Gated
Iteration means a change that evidence justifies and that is validated against a baseline. Here is a plausible failure. A team answers complaints with prompt edits. The team ships the edits with no regression suite and calls this continuous improvement. Each edit fixes the reported case and silently changes an unreported case. With no baseline, nobody can tell. At the energy supplier, a fix to one wrong price-plan answer may break other answers that nobody rechecked.
The Events That Are Certain to Arrive
Some events are certain. When a design omits these events, they become emergencies. Model deprecation is the best-documented event. Anthropic classifies model versions as active, legacy, deprecated and retired. Requests to a retired model fail outright. Anthropic flags deprecated versions as likely to be less reliable than active versions. Anthropic notifies customers with active deployments ahead of a retirement. There is a documented minimum notice period.
When notice arrives, take three steps.
- Test against the replacement well before the retirement date.
- Audit usage by API key and model to find where the old version is still called.
- Re-benchmark cost and latency on your own workloads. Make this a separate checklist item on every migration path. A version change affects more than behaviour.
A deprecation is a scheduled re-validation, not an incident. The same applies to corpus migrations, connector and dependency changes, regulatory change, and redesign of the business process that the system serves. A corpus is the set of documents that the system answers from. A connector is the link between the system and an outside data source. Plan for these events in design, where planning is cheap. For the energy supplier, a new set of price plans is one such event.
A Lack of Complaints Is Not Evidence
A system with no complaints, a baseline that nobody has re-run and a changed corpus is not proven healthy. Complaints are the most delayed and most expensive signal available. Waiting for complaints looks like patience, but it avoids the work of checking.
Going Backwards Is Professional
Phases are not one-way: a project can go backwards. When production evidence contradicts a discovery assumption, return to discovery, re-establish the assumption, and re-enter design. The users may not be who discovery described. The consequence of error may be worse than stated. The corpus may not hold what the criteria assumed. To say so early is the entire purpose of having phases. It is also far cheaper than building on something that you know is false. If the energy supplier's logs show mostly business customers, discovery described the wrong users.
In the exam
The exam tests which activity belongs to which phase, and what a phase must produce before the next phase can honestly begin. It examines outputs that permit the next step, not phase names. Deprecation, the best-documented event, is the most examinable. The prompt-edit failure above appears in questions as a tempting wrong answer. When a question offers stability as the reason to skip re-validation, that is the trap. When evidence contradicts discovery, the wrong options are to continue because the plan says so, or to reframe the contradiction as a scope item for later. Enablement work (tooling, environments, workflows) belongs to Domain 7. This objective is about deciding what must be true before ownership transfers, and verifying that it did.
Exam Traps
Reading a quiet, complaint-free system as healthy and waiting for drift to be reported
Complaints are the most lagging and most expensive signal available. A system with a changed corpus and a baseline nobody has re-run is not proven healthy. Re-run the baseline after a corpus or model change.
Handing a model deprecation to the commercial or vendor-relationship owner
A refusal of the work, presented as delegation. The retirement date and the replacement are commercial facts, but re-validating the system against its baseline on the new version is an architectural obligation that cannot be passed on.
Shipping prompt edits in response to last week's complaints and calling it iteration
Each edit fixes the reported case and silently changes an unreported one. With no baseline, nobody can tell. Run each edit against a regression suite and compare with the baseline before shipping.
Continuing to build against a discovery assumption that production evidence has already contradicted
Treating the phase order as one-way. Returning to discovery is the cheap move and the professional one; carrying on because the plan says so meets the delivery date but does not achieve the outcome.
Practice Scenario
A distributor's pricing-support assistant has run quietly for five months and the platform team operates it. The sponsor now asks for it to be extended to a second product line. Nobody has re-run the evaluation baseline since handover. The reference corpus has been refreshed twice. The model version the baseline was measured on is now deprecated, so a retirement date is coming. What should the architect do?
Build Exercise
Write the Lifecycle Plan for One System
What you'll learn
- How to name the phase a system is genuinely in, by its outputs rather than its plan
- How to test a handover against the four capabilities that show ownership has transferred
- How to plan for the lifecycle events that are certain to arrive
- How to write a re-validation procedure for a model version change
- How to recognise the production signal that sends work back to discovery
- For a system you know, write each phase and the outputs it must produce, then mark which of those outputs actually exist today
Why: Phases are gated by what they produce, and work that cannot be validated begins where planned artefacts are missing.
You should see: A phase-by-phase list with each output marked present, partial or missing.
- Test the handover as four capability questions — can the owning team evaluate, diagnose, roll back, and reach the people who know the system — and answer each honestly for the team that holds it now
Why: A team missing any of the four will run the system and refuse to change it, and that inability to change the system is easy to mistake for stability.
You should see: Four answers with evidence, not four assumptions.
- List the foreseeable lifecycle events — model deprecation, corpus migration, connector or dependency change, regulatory change, business-process redesign — with the trigger, the notice you would get, and the re-validation each forces
Why: Each of these is certain, and each is far cheaper to plan for in design than to handle as an emergency once a retirement date is set.
You should see: A table of events, each with a trigger, a notice period and a re-validation scope.
- Write the re-validation procedure for a model version change: what is re-run, against which baseline, what result permits the migration, and what you would re-baseline afterwards
Why: A deprecation handled as a scheduled re-validation is planned work; handled as an incident it needs weekend work and a rollback.
You should see: A procedure with a pass condition somebody else could apply without you.
- Name one production signal that would send this work back to discovery rather than forward to design, and write the sentence you would say to the sponsor when the signal appears
Why: Moving backwards early is professional and cheap; carrying on against a falsified assumption is neither.
You should see: One named signal with a threshold, and one sentence you would be willing to say out loud.
Sources
- Model deprecations — Anthropic
- Migration guide — Anthropic
- Define success criteria and build evaluations — Anthropic
- Claude Certified Architect Professional Exam Guide (v1.0) — Domain 6 — Anthropic