AnthropicClaude Certified Architect – Professional2026-106.5 Support lifecycle phases (discovery, design, handoff, monitoring, iteration)
Define phase exits and production readiness
Completed by the knowledge check
Learning objective
Define phase entry and exit criteria and plan the move from proof of concept to production: hardening, security review, and scaling.
Core idea
As the architect, you decide what a successful experiment authorizes next. A proof of concept can establish that Claude performs a bounded task without establishing that the organization can operate that task safely at production volume. Make the distinction explicit in a phase decision record: the scope entering the phase, the questions it must answer, its exit criteria, and the people authorized to accept the result.
See 6.3.3 for the pilot’s value decision under NIST AI RMF MANAGE 1.1. This lesson adds the chain of phase exits and production-readiness acceptance: what each receiving owner needs before taking responsibility for the next phase. The five lifecycle phases organize your work; the criteria are your organization’s design, rather than an Anthropic deployment workflow.
How it works
Connect one phase’s exit to the next phase’s entry
Start with the operating constraints and problem statement from 6.1.3 and 6.1.4. Record an intended population, permitted actions, business baseline, and acceptance owners. NIST MAP 1.1 grounds the record in intended use and deployment context; MAP 1.5 adds documented risk tolerance. A criterion without a population is easy to pass on convenient examples and impossible to defend for a broader launch.
Use the following phase record as an architectural template:
| Phase | Entry criteria | Exit criteria and accepting role |
|---|---|---|
| Discovery | Sponsor and workflow owners available; business problem identified | Bounded scope, baseline, data owners, acceptance measures, and operating team identified; sponsor accepts |
| Design | Agreed problem and feasible access to representative data | Selected architecture passes task evaluation; hardening and security findings have dispositions; operations accepts the proposed service model |
| Handoff | Candidate deployment and operational package ready for rehearsal | Receiving team demonstrates support and recovery; named service owner accepts responsibility |
| Monitoring | Approved production scope, functioning signals, and staffed response | At each review interval, product and risk owners decide to continue, remediate, restrict, or stop |
| Iteration | Owned issue with expected outcome and affected components identified | Evaluated change accepted for controlled release, rejected, or returned to discovery |
Monitoring does not finish permanently. Its exit is a recurring decision that authorizes another operating interval or another course of action. NIST GOVERN 1.5 calls for planned monitoring and periodic review with defined responsibilities and review frequency. Put the interval in the record rather than waiting for a complaint to reopen it.
Separate feasibility from production hardening
Anthropic’s success-criteria guidance calls for specific, measurable, achievable, relevant criteria. Translate a prototype’s favorable answers into separate tests of useful task completion, operating cost, response time, and harmful failure. See 4.1.1–4.1.4 for measurement design. A passing mean cannot waive a critical security finding or a failed recovery rehearsal.
Create a production-readiness record with three independently accepted parts. Hardening demonstrates that dependency failures, incomplete results, and unavailable human support lead to an approved fallback rather than unbounded work. Security review takes the attack paths identified in 5.2.3 as input and checks them against the intended production data flows and permitted tool effects. Scaling demonstrates behavior under the intended traffic and request mix, including the support load created by unsuccessful tasks. NIST MANAGE 1.3 supports documented treatments; MANAGE 1.4 requires residual risks to remain visible.
Use 5.2.5 for finding disposition and residual-risk acceptance. Production entry adds a verification step: the accepting owner checks that each treatment was re-tested against the production data path, access configuration, and permitted effects, rather than relying on the prototype review. Record which deployment and scope the result covers. If acceptance applies only to a read-only pilot, a tool that writes business records reopens the decision.
Carry that dependency into the phase record. A design exit can authorize implementation while leaving production security verification outstanding; handoff cannot silently inherit that outstanding condition as accepted. The receiving operations owner needs the completed verification or the risk owner’s explicit disposition before accepting production responsibility. When an upstream assumption changes, reopen the affected acceptance and its dependent phase exits, rather than declaring the whole project either permanently approved or entirely back at discovery.
A design exit can authorize implementation, while accepting production responsibility waits for the completed verification or the risk owner’s explicit disposition.
Prove capacity on the path you deploy
On the Claude API, Messages API capacity has three dimensions: requests per minute (RPM), input tokens per minute (ITPM), and output tokens per minute (OTPM). Record measured demand against those three dimensions for the expected model class. A request count alone misses the effect of longer documents or longer answers. Anthropic also documents acceleration limits: a sharp usage increase can cause HTTP 429 responses, so the scaling plan includes a gradual traffic ramp.
A configured limit is a maximum, not guaranteed capacity. Organization-wide limits still apply even when separate workspace limits sum to more. A successful load test therefore records competing organizational traffic and the limits in force. Do not treat a quiet weekend test as proof of Monday capacity when other workloads share the organization.
The readiness record should distinguish an ordinary rate-limit response with retry-after from a spend-cap outage. On the Messages API, an enforced monthly tier cap returns error.details.error_code: "enforced_spend_limit_reached", without retry-after; repeated retries do not restore access. The detailed response policy belongs to operations, but production entry requires that the receiving team can identify the condition and invoke the agreed fallback.
Key distinctions and trade-offs
A phase decision differs from a release decision. A phase decision authorizes a broader responsibility or scope; a release decision accepts a particular evaluated change. Releasing a successful pilot build does not authorize expansion to every user.
Hardening differs from security acceptance. Recovery from a dependency outage does not establish that retrieved content cannot cause an unauthorized action. Keep the findings and accepting roles distinct, even when one review meeting considers both.
A phase exit differs from production-readiness acceptance. A design can be complete enough to implement while production hardening remains unverified. Record the responsibility being transferred and the conditions still open; a completed design milestone does not discharge the operations owner’s readiness decision.
Architecture / decision scenario
A retailer’s returns assistant succeeds on 96% of 500 agreed pilot cases. The sponsor wants to expand from 40 agents to 800 before a seasonal sale. Production entry requires at least 95% accepted answers, p95 completion under eight seconds, a staffed fallback, and accepted security findings. These are example business thresholds.
The load rehearsal passes quality but reaches eleven seconds at the expected peak; an unresolved finding also allows access to another region’s return records. The tempting proposal is to launch broadly because the quality score passed and ask for more API capacity afterward.
The architect rejects that inference. The platform owner records RPM, ITPM, and OTPM demand and shared organization limits, then plans a gradual ramp. The security owner requires the access defect fixed and retested. The design phase can close with an implementation plan for the identified defects, but production entry remains unaccepted. Operations requires the fallback rehearsal, the security owner’s production-path retest, and the platform owner’s peak-load result before taking responsibility for 800 agents. The sponsor funds that hardening work and changes the launch date. The phase record preserves the accepted design decisions while keeping the dependent production transition open.
Common exam traps
- Treating prototype accuracy as proof of security, recovery, and scale.
- Using a calendar milestone as the phase exit criterion.
- Calling API limits guaranteed throughput.
- Letting the architect accept every business and security risk alone.
- Marking monitoring complete after dashboards appear.
What to remember
Define who authorizes each transition and what that decision covers. Carry explicit criteria from discovery into production readiness, keep hardening, security, and capacity acceptance distinct, and reopen the decision when scope changes. A failed criterion calls for remediation, a smaller scope, or an explicit risk decision.
Knowledge check
An insurer’s claims-intake assistant passes its quality threshold on 600 agreed pilot cases. Production entry also requires p95 latency under six seconds, a rehearsed staffed fallback, and accepted security findings. The load rehearsal reaches nine seconds at expected peak, and an open security finding lets adjusters read claims from another business unit. The design reviewers accept the architecture as feasible with a plan to remediate these defects; production verification is still outstanding. The architect is not the security risk owner. What should the phase record show?
A contract-review service on the direct Claude API is load-tested over a quiet weekend. Its dedicated workspace has rate limits configured, and the organization’s workspace limits add up to more than the organization’s own limit. The service goes live on a Monday, when the other workloads are busy. Which evidence supports the capacity claim in the readiness record?
During a readiness rehearsal on the direct Claude API, Messages API calls start returning HTTP 429. The error body carries error.details.error_code: "enforced_spend_limit_reached", and the response has no retry-after header. The organization has configured no spend limits of its own. What should the receiving team’s runbook tell the responder to do?
retry-after , and every retry fails until access resumes. Raising a workspace limit does not address the tier cap, and per-minute rate limits are not what was exhausted. Readiness requires that the team recognizes the condition and moves to the fallback.A procurement assistant’s security review was accepted for a read-only pilot that searches supplier contracts, and its hardening, capacity and design exits were accepted for that scope. The product owner now wants to add a tool that creates purchase orders in the ERP system. What should happen to the phase record?