What You Need to Know
The objective names five lifecycle phases (discovery, design, handoff, monitoring, iteration). This lesson splits build and validate out between design and handoff, giving six. Each phase produces outputs the next phase can check, such as a baseline: the measurement later changes are compared with. A phase gate holds the next phase until those outputs exist. The architect's job does not end at deployment.
Take a camera shop adding an assistant that answers customers' lens and repair questions.
Phases Are Gated by Outputs, Not Dates
A date cannot show that a phase produced what the next one needs. Design that starts on an unmeasured problem produces an architecture nobody can validate. Build that starts without an evaluation plan produces a system whose quality is a matter of opinion. Each phase owes 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 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 an incident loop that works.
- Iterate: evidence-gated changes that re-enter design rather than bypass it.
A project can be delivered exactly on schedule and still be impossible to declare finished, because nothing was produced that could settle the question. If the camera shop never measures today's wrong lens 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 well enough to localise a failure.
- Roll a change back.
- Know who to reach when none of that is enough.
A team missing any of them will operate the system and refuse to change it, since it cannot measure or undo a change. That looks like stability and is paralysis. Before the camera shop's staff take over, the architect has them run the evaluation suite and read a failed trace.
Iteration Is Evidence-Gated
Iteration means a change licensed by evidence and validated against a baseline. A plausible failure: a team answers complaints with prompt edits, ships them with no regression suite, and calls it continuous improvement. Each edit fixes the reported case and silently moves an unreported one. With no baseline, nobody can tell. At the camera shop, fixing one wrong lens-mount answer may break others nobody rechecked.
The Events That Are Certain to Arrive
Some events are certain. A design that omits them meets them as emergencies. Model deprecation is the best documented. Anthropic classifies model versions as active, legacy, deprecated and retired. Requests to a retired model fail outright. Deprecated versions are flagged as likely to be less reliable than active ones. Customers with active deployments are notified ahead of a retirement, with 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, as a checklist item in its own right on every migration path. A version change moves 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 the system serves. Planning for them belongs in design, where it is cheap. For the camera shop, a new supplier catalogue is one such event.
Quiet Is Not Evidence
A system with no complaints, a baseline nobody has re-run and a moved corpus is unevidenced, not healthy. Complaints are the most lagging and most expensive signal available. Waiting for them is the evasion posture wearing patience.
Going Backwards Is Professional
Phases are not a ratchet. 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. Saying so early is the entire point of having phases, and far cheaper than building on a known falsehood. If the camera shop's logs show mostly repair 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 can honestly begin. It examines outputs that license the next step, not phase names. Deprecation, the best-documented event, is the most examinable. The prompt-edit failure above is a planted distractor. A stem offering stability as the reason to skip re-validation is the trap. When evidence contradicts discovery, the distractors are carrying on because the plan says so, or reframing it as a scope item for later. Enablement work (tooling, environments, workflows) belongs to Domain 7. This objective is deciding what must be true before ownership transfers, and verifying it did.
Exam Traps
Treating launch as the finish line, with monitoring, ownership and the incident loop unassigned
The operating phases produce the only evidence that a system still meets the criteria it was signed off against. Without them it is unevidenced from the day it goes live.
Handing a model deprecation to the commercial or vendor-relationship owner
Obstruction 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 against last week's complaints and calling it iteration
Each edit fixes the reported case and moves an unreported one. With no regression suite and no baseline, nobody can tell which happened, and the system rots one improvement at a time.
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 buys a delivery date and loses 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, and the model version the baseline was measured on has entered its deprecation window. 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 make ownership real
- 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 owes, then mark which of those outputs actually exist today
Why: Phases are gated by what they produce, and the gap between the plan and the artefacts is where unvalidatable work begins.
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 — 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 paralysis 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 meet as an emergency with a retirement date attached.
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 licenses 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 costs a weekend 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 it fires
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