AnthropicClaude Certified Architect – Professional2026-106.5 Support lifecycle phases (discovery, design, handoff, monitoring, iteration)
Coordinate changes across the whole release
Completed by the knowledge check
Learning objective
Manage change — model upgrades, prompt revisions, index and tool changes — with regression evaluation, staged rollout, and rollback.
Core idea
As the service architect, you govern the combination of components that produces a business outcome. A prompt revision, index rebuild, or tool deployment can alter that outcome even when the model stays unchanged. Treat each as a release candidate with an inventory of affected components and an owner authorized to accept the change.
See 4.3.4 for evaluation thresholds and staged-release mechanics. This lesson adds lifecycle coordination: which owners must participate, how linked changes remain compatible, and how a provider retirement deadline constrains the recovery plan. NIST AI RMF MANAGE 4.1 places change management within post-deployment operations, while MANAGE 3.2 calls for monitoring pretrained models as part of system maintenance.
How it works
Inventory what the candidate actually changes
Use 6.4.1’s release inventory to identify what is deployed. Before implementation begins, attach a change record that adds the business reason, affected consumers, accepting owners, rollout dependencies, and recovery target. These organizational artifacts connect the deployed combination to the decision authorizing its change.
Distinguish the four change classes:
| Change | Owning role and review question | Recovery dependency |
|---|---|---|
| Model upgrade | Model owner: does the replacement meet this service’s quality, cost, and latency criteria? | An available, validated model path and compatible application configuration |
| Prompt revision | Prompt owner: which instruction or example changes behavior, and who approves its business meaning? | Prior prompt together with the configuration and tools it expects |
| Index change | Retrieval owner: which source snapshot, ranking, or access behavior changes? | Compatible index snapshot or rebuilt baseline, including access rules |
| Tool change | Integration owner: do arguments, returned data, authorization, or business effects change? | Compatible tool implementation and a plan for effects already performed |
Avoid hiding several changes behind “model migration.” A model and prompt may need to move together, but that does not make a simultaneous index and tool redesign necessary. Isolate independent changes so a failed comparison has a useful interpretation. When components must change together, record why and evaluate the combination that production will use.
Assign regression decisions to the affected owners
Use a common evaluation baseline and the maintained coverage from 4.2.4. The release record points to the exact candidate, cases, grading rules, and results. Include the specific incident or requirement that motivated the change and the existing behaviors it must preserve. A content correction can fix one answer while damaging access separation or a different product’s policy answers.
Require approval from the owners of changed obligations, rather than asking the architect to sign every release. The quality owner accepts the measured task results, the content owner accepts changed meaning, the integration owner accepts tool compatibility, and the service owner accepts operational exposure. A security-relevant access change invokes the corresponding risk owner even if the aggregate score improves.
NIST MANAGE 4.2 calls for measurable improvement activities integrated into updates with stakeholder engagement. Implement that as an acceptance decision tied to the original reason for change. Passing a general suite does not establish that the promised business improvement occurred, and a business improvement does not waive a failed safety requirement.
Coordinate staged exposure and recovery
Google’s SRE Workbook defines a canary as a partial, time-limited deployment evaluated to decide whether rollout should proceed. Its prerequisites include deploying to a subset, evaluating that subset, and integrating the evaluation into release decisions. Use those prerequisites to test whether your change is operationally releasable, then apply the staged procedure from 4.3.4.
For a linked index and tool change, confirm that both can be selected consistently for the candidate population. Otherwise, a nominal canary can receive a candidate prompt with a baseline tool or an unintended index revision. The release record identifies the deployed combination observed in production, not merely the build label a team intended to send.
Use 4.3.4 for validated-bundle rollback and in-flight work, and 6.4.4 for the runbook covering effects rollback cannot repair.
Coordinate the component teams around those procedures. Before exposure, each team confirms when its candidate revision becomes available, how long the baseline remains available, and who can authorize switching between them. The rollout owner resolves conflicting windows before scheduling the trial. An index owner’s plan to remove the baseline on Friday cannot support a tool team’s recovery commitment through Monday. Record a shared recovery window or change the release sequence.
Give the service owner one decision package covering all participating teams. Separate component approvals cannot authorize expansion if the combined recovery arrangement remains unresolved. At each stage, that owner confirms that the agreed dependencies and support commitments still hold; a component team changing its maintenance window reopens the coordination decision.
Expansion cannot be authorized while the combined recovery arrangement remains unresolved, and a component team changing its maintenance window reopens the coordination decision.
Treat model retirement as a scheduled dependency change
See 2.1.4 for model lifecycle states, notice periods, platform-specific retirement schedules, and the availability constraint on rollback. Here the model owner turns the applicable deadline into a coordinated delivery plan: identify the last safe migration date, reserve time for a failed candidate, and separate deadline-driven work from unrelated index or tool redesign. The sponsor funds the required migration capacity rather than allowing elective changes to consume the recovery window.
For Console usage, open Claude Console Usage, select Export, and inspect the CSV broken down by API key and model. That documented audit supports caller discovery; see 2.1.4 for its place in lifecycle monitoring. Because the breakdown identifies keys and models, it distinguishes callers only as finely as the organization assigns keys. As an inventory design, use a dedicated key per caller or job when separate migration closure is required, or reconcile shared-key traffic with application records. Keep partner-platform caller inventories separate from this Console export.
Assign the model owner responsibility for closing the combined inventory, including scheduled jobs and test environments. Each caller owner confirms its migration result, relevant evaluation, and operating path after the deadline. An unclaimed caller is an unresolved migration obligation, not evidence that the main application team has finished the service migration.
Schedule the handover to a non-AI fallback before the baseline can no longer return. The operations owner accepts its capacity and support arrangements; the product owner accepts its reduced functionality. If candidate evaluation fails near the deadline, the service owner can then choose that prepared path rather than approve an unvalidated replacement. Record the decision date and who informs affected consumers.
Key distinctions and trade-offs
Change size differs from blast radius. A one-line policy instruction can affect every response. A large internal refactor can leave externally evaluated behavior unchanged. Review exposure and affected obligations rather than counting lines.
Rollback availability differs from rollback correctness. A prior deployment can be selectable yet incompatible with the tool or index that remains live. The release record needs a tested combination and an outcome check.
Provider deadline differs from internal acceptance. Retirement creates urgency but does not establish replacement fitness. Start early enough to retain alternatives and fund a bounded fallback if migration results remain unacceptable.
Architecture / decision scenario
A financial-services research assistant must migrate before its deployed model’s published retirement date in six weeks. The integration team also proposes a tool-schema revision and a replacement retrieval index. The tempting plan is to ship all changes together after a single aggregate evaluation.
The service owner instead separates the independent index redesign from the deadline-driven model migration. The model owner prepares a candidate with the necessary prompt revisions and compares it against the baseline. Quality passes the agreed 97% threshold, but the integration owner finds that the candidate expects a tool field absent from production. Exposure waits until that compatibility defect is fixed and evaluated.
The approved candidate reaches 5% of analysts for a defined observation period before expansion. Operations can restore the compatible baseline before retirement; it also rehearses a human-research fallback that remains available afterward. The tool owner records any completed writes for reconciliation. The model owner then verifies the remaining caller inventory, including scheduled research jobs, before declaring migration complete.
Common exam traps
- Exempting prompt edits and index rebuilds from release management.
- Bundling independent changes so a regression has no clear owner.
- Accepting separate component approvals without a shared recovery window.
- Closing migration after the main application moves while scheduled callers remain unclaimed.
- Letting an elective index redesign consume the deadline-driven migration window.
What to remember
Manage the deployed combination and its owners. Every behavior-changing component enters regression evaluation and controlled release, with a compatible recovery target. Model retirement adds a deadline and an availability constraint; it does not remove acceptance requirements.
Knowledge check
A legal-research assistant must leave its current model before the model’s published retirement date in eight weeks. The candidate model passes evaluation only together with a revised system prompt. The search team also wants to ship a redesigned retrieval index, which the migration does not need. How should the releases be organized?
A linked index and tool change for an insurance-quoting assistant has approvals from its quality, integration and retrieval owners. The baseline tool requires the baseline index. The index team plans to delete that index on Friday; the tool team’s rollback commitment runs through Monday. The canary is scheduled for Thursday. What should the service owner do?
A model’s retirement date is a month away. The main application has migrated and passed evaluation. The Claude Console Usage export still shows traffic on the retiring model from one API key that three scheduled reporting jobs and a test environment share. What should the model owner do next to identify the remaining callers for migration closure?
Ten days before a model’s retirement date, the replacement candidate for a loan-servicing assistant fails a blocking evaluation. Operations has accepted the capacity of a prepared manual-processing fallback, and the product owner has accepted its reduced functionality. What should the service owner choose?