TLDR
Deployment isn't the finish line - an architect owns a continuous loop of discovery, design, handoff, monitoring, and iteration, because model behavior and usage patterns keep drifting after launch. Anthropic doesn't publish this exact 5-phase list under one name; it publishes several overlapping lifecycle loops across its own guidance (e.g. Planning → Prompting → Deployment → Evaluation → Optimization, feeding back into Planning). Anthropic: Planning to production The exam's phase wording synthesizes that shared continuous-loop shape rather than quoting one canonical source.
What it is
An AI solution's lifecycle doesn't end at deployment the way traditional SDLC often treats "done." Because model behavior, usage patterns, and the underlying model version can all drift after launch, an architect owns a continuous loop of discovery, design, handoff, monitoring, and iteration, rather than a linear waterfall that stops at go-live.
Anthropic does not publish this exact five-phase list, under this exact name, in a single canonical document. It publishes several overlapping lifecycle frameworks across its own guidance, each emphasizing different stages of the same underlying shape: a five-stage loop (Planning → Prompting → Deployment → Evaluation → Optimization, looping back to Planning) in "Planning to production," and a four-stage loop (Develop AI strategy → Create business value → Build for production → Deploy, then "iterate, improve & expand" back to Stage 1) in "Building trusted AI in the enterprise." The exam's discovery/design/handoff/monitoring/iteration wording is a synthesis of this shared, real, if plural, continuous-loop shape - treat the specific five-phase labels as exam framing grounded in genuine Anthropic guidance, not a single direct quote.
How it works
Anthropic frames adoption itself as iterative, not a one-shot deployment. "Successful implementation of AI is iterative. Enterprises that are leading the way in AI transformation start small, evaluate thoroughly, and scale gradually before achieving their best results." This is the philosophy underlying every lifecycle phase below, not just the early ones.
"Planning to production" names its own five-stage loop explicitly as a cycle, not a line. Planning → Prompting → Deployment → Evaluation → Optimization, with Optimization's results feeding back into Planning. Mapped to the exam's phases: Planning ≈ discovery + design; Prompting ≈ design continuing into build; Deployment ≈ handoff; Evaluation ≈ monitoring; Optimization ≈ iteration. The loop-back arrow in Anthropic's own diagram IS the concrete version of "this is continuous, not linear."
Anthropic's own Deploy-stage guidance names the exact mistakes to avoid at the monitoring/iteration boundary. "Building trusted AI in the enterprise" lists explicit Don'ts for the Deploy stage: don't replace the previous system right away, don't treat your offline evaluations as static, and don't make a rollout decision based on a single evaluation test. This is the sourced, concrete version of "monitoring and iteration are load-bearing lifecycle phases, not optional post-launch cleanup."
AWS's cross-vendor GLOE framework maps cleanly onto the exam's phases, since lifecycle discipline for LLM systems isn't Anthropic-specific. The Generative AI Lifecycle Operational Excellence framework names three stages: Development (PoC and experimentation - discovery/design), Preproduction (validation and staging with beta users, plus setting up tracing/logging - handoff prep), and Production (deployment and continuous operations - monitoring/iteration), with Production feeding learnings back into Development.
Once live, the operational layer that keeps the loop closed has a name: LLMOps. Anthropic's own guidance lists five best practices for the Deploy stage: robust monitoring and observability, systematic prompt management, security and compliance by design, scalable infrastructure and cost management, and continuous quality assurance (regular output testing, hallucination monitoring, end-user feedback loops). A model-version upgrade is treated as a change needing re-validation against the eval suite, never a free improvement.

Where you'll see it
Fraud-triage assistant, pitch to steady state
Discovery scopes the pilot and success bar with the risk team; design picks a workflow pattern with a human-approval gate; handoff delivers the eval suite and runbooks to the ops team; monitoring tracks live accuracy against the eval bar plus infrastructure uptime; and a new Claude model version triggers a re-validation pass against the eval suite before adoption, not automatic upgrade.
AWS GLOE mapping in a mixed-vendor org
A platform team uses Development/Preproduction/Production as its internal stage-gate language while an architect maps it back to discovery/design/handoff/monitoring/iteration for stakeholder-facing lifecycle reporting.
Side-by-side
| Exam phase (CCARP-D6-O5) | "Planning to production" loop | "Building trusted AI" stages | AWS GLOE stage |
|---|---|---|---|
| Discovery | Planning | Develop AI strategy | Development (PoC & experimentation) |
| Design | Planning → Prompting | Develop AI strategy → Create business value | Development (PoC & experimentation) |
| Handoff | Deployment | Build for production → Deploy | Preproduction (validation & staging) |
| Monitoring | Evaluation | Deploy (LLMOps: monitoring + continuous QA) | Production (continuous operations) |
| Iteration | Optimization → back to Planning | "Iterate, improve & expand" → back to Stage 1 | Production feeds back into Development |
Question patterns

A team considers their AI solution "done" once it passes UAT and goes live, matching their usual SDLC checklist. What is the architect-level correction?
"the SDLC 'done at UAT' mindset transfers directly to AI systems" - that is the exact trap this objective tests against.An engineer claims Anthropic publishes one official, single-named five-phase lifecycle ("discovery, design, handoff, monitoring, iteration") verbatim in its docs. Is this accurate?
"this exact five-phase list is Anthropic's single official framework" - overclaiming a specific named source that doesn't exist verbatim.A new Claude model version releases. A team upgrades immediately in production because "newer is always better," without re-running their evaluation suite. What does Anthropic's own Deploy-stage guidance say?
"a newer model version doesn't need re-validation since it's strictly an upgrade" - that is exactly the "Don't" Anthropic's own Deploy-stage guidance calls out.Using the AWS GLOE framework as a cross-vendor reference, which stage covers "validating the application with internal or beta users and setting up tracing/logging before go-live"?
"Development, since that's where the beta build originates" - Development is the PoC/experimentation stage; validating with beta users and establishing tracing before go-live is specifically Preproduction's job.A team runs a robust "continuous quality assurance" practice (regular output testing, hallucination monitoring, end-user feedback loops) but has no systematic prompt version control. Per Anthropic's own named LLMOps best practices, what gap remains?
"continuous quality assurance alone covers prompt version control" - Anthropic's guidance names these as five distinct, mutually supporting practices, not one practice subsuming the rest.Frequently asked
Does Anthropic have one official name for this five-phase lifecycle?
Does a model-version upgrade count as "iteration" automatically?
Work this with your AI
Work this concept hands-on with Claude Code, Codex, or claude.ai. Copy a prompt, paste it into your assistant, and practise in tandem. Each one keeps you active (explain it back, get drilled, or build) rather than just reading.
- Drill it like the exam (scenario MCQs)Practice in the exam's scenario-MCQ format with trap awareness.
- Explain it back (Feynman)Build durable, transferable understanding of a concept you can half-state.
- Test me, adapting the difficultyActive recall practice on a concept you think you know.
- Check my prerequisites firstBefore studying a concept that keeps not sticking.
- Find the high-leverage 20%When a domain feels too big and you are short on time.
