Stakeholder Communication & Lifecycle Management · Lesson 5 of 5

5.5 - Supporting the Lifecycle: Discovery, Design, Handoff, Monitoring, Iteration

Define the architect's responsibilities across discovery, design, handoff, monitoring and iteration, including ownership after launch and an evidence-based process for managing model version changes and deprecations.

An architect's work does not end when the design is approved or the system ships. A Claude system has a lifecycle with an unusual feature: one of its most important dependencies, the model, has its own published lifecycle, and it will end. Scenario questions in this area tend to hinge on two things: who is responsible for what in each phase, and whether the team treats the model as a versioned dependency with an expiry date that is managed with evidence.

The architect across the phases

Phase	Architect's responsibilities	Exit evidence
Discovery	Structured discovery, hidden requirements, measurable success criteria, go or no-go (lesson 5.1)	Discovery summary signed off by the decision owner
Design	Options and trade-offs, decision records, eval plan, architecture document (lessons 5.2 and 5.4)	Approved design; eval set v1 with thresholds
Handoff	Implementation guidance, non-negotiables, runbooks, walkthrough, launch gates (lesson 5.4)	Build and operations teams accept the package
Monitoring	SLOs and dashboards for service, quality and cost; feedback channels; lifecycle watch (lesson 5.3)	Alerts, reviews and owners in place and exercised
Iteration	Prioritise by impact, gate changes on evals, manage model migrations, re-architect or retire when requirements change	Decision log and eval set kept current

The phases overlap and loop. Monitoring findings reopen design questions; a new model reopens the model-selection decision; a new use case restarts discovery.

Ownership after launch

The most common lifecycle failure is that nobody owns the artifacts that determine behaviour. Name an owner for each: the prompts and configuration, the eval set and thresholds, the model dependency and its lifecycle, incidents and on-call, and cost. A simple responsible-and-accountable table is enough. The architect typically stays accountable for architectural integrity: the decision log, review of deviations from non-negotiables, and approval of changes that alter quality attributes. A named product or engineering owner is accountable for day-to-day operation. Encode as much of this as possible in automation, such as an eval gate in the release pipeline that blocks a prompt, model or schema change that regresses the agreed thresholds, so integrity does not depend on memory.

Monitoring what matters

Monitor at the layers defined in lesson 5.3. Service: error rates by type, latency and headroom against limits; Anthropic returns rate-limit headers on responses and shows rate-limit charts on the Console usage page. Quality: sampled production outputs graded against a rubric, reviewer override and escalation rates, and the regression eval run on a schedule. Cost: spend by workspace, which Anthropic's usage and cost reporting supports. Inputs: new document types, languages or intents that the eval set does not represent. Lifecycle: the deprecation status of every model ID you use.

Model and version change management

Start from what Anthropic documents. Each model ID identifies a pinned version: the underlying model stays constant for the lifetime of that ID, and an updated version ships under a new ID. From the Claude 4.6 generation onward, the dateless ID (for example the form claude-{name}-{major}[-{minor}]) is itself the pinned snapshot, and the docs call the belief that dateless means evergreen a common misconception. Earlier models carry a snapshot date in the ID, and shorter aliases exist on the Claude API that point at the most recent dated snapshot, so an alias is a moving pointer. Two caveats matter: weights are fixed but the serving infrastructure around them (routing, safety classifiers, sampling logic) can change and occasionally produce minor differences, so monitoring stays on; and every ID has its own deprecation and retirement schedule.

Models move through documented lifecycle states: active, legacy, deprecated and retired. A deprecated model still works but is not recommended, has a recommended replacement and a retirement date, and the docs warn deprecated models are likely to be less reliable. After retirement, requests fail. Anthropic states that impacted customers are notified by email and in the documentation, with at least 60 days' notice before retirement for publicly released models. Treat that as a minimum. Listed retirement dates are “not sooner than” commitments, Amazon Bedrock and Google Cloud set their own schedules, and the Console usage export (by API key and model) shows which deprecated models you still call.

Key concept

A pinned model ID is a dependency with an expiry date. Pinning removes the risk of unannounced behaviour shifts but creates an obligation: track the lifecycle, and migrate on your own schedule with evidence, not under deadline pressure. The exact date matters less than the method: migrating on a plan, with an eval comparison, is engineering; migrating without one is a gamble.

A migration procedure that scales

Treat a model change like any behaviour-changing dependency upgrade, and do it on a routine, not only when a notice arrives.

Inventory. Know every model ID in every environment, kept in one configuration source.
Choose candidates. Start with Anthropic's recommended replacement, and consider one alternative. Read the migration guide: changes can affect the request itself, not only quality (Anthropic documents, for instance, parameters and features that newer models reject with a 400 error), so a migration can fail loudly as well as drift quietly.
Compare with evals. Run the regression set and the format-sensitive cases on the current and candidate models, then examine failures. Anthropic's engineering guidance notes that teams with evals can evaluate and adopt new models in days. Consider tuning effort or prompts before switching tiers, as Anthropic's model-choice guidance calls effort often a better lever than changing models.
Roll out in stages. Shadow or canary a small share of real traffic, compare outcomes, then widen, with a rollback that is a configuration change.
Record and communicate. Supersede the model decision record; tell support, product and stakeholders. A change to tone, length or edge-case handling is a product change even if no application code moved.

Note the recommended replacement is a candidate, not a validation: the vendor knows the model, not your feature.

Common exam distractor

Wrong answers include running a rolling alias in production, believing a dateless ID is evergreen, assuming a pinned model lasts forever, and cutting all traffic to the vendor's recommended replacement (or to the newest model) because a general benchmark looks better. Also wrong: treating the architect's role as finished at handoff, and assuming an unchanged model ID means behaviour cannot change so monitoring is unnecessary. The best answer pins deliberately, tracks the lifecycle, compares on your own evals, rolls out in stages with a rollback, and records and communicates the change.

Iteration and retirement

After launch, iterate from evidence. Prioritise fixes by user impact, add each confirmed failure to the eval set, and gate every change on it. Prefer the smallest lever that solves the problem (prompt, retrieval, effort setting, then model or pattern), consistent with Anthropic's guidance to add complexity only when it demonstrably helps. When a use case ends, retire it deliberately: notify users, archive or revoke credentials and workspaces, handle retained data according to policy, and keep the decision record.

Exam traps

Believing a dateless model ID such as the 4.6-generation form is an evergreen pointer that automatically upgrades, or using a rolling alias in production for convenience.

Anthropic documents that model IDs are pinned versions and that dateless IDs from the 4.6 generation onward are themselves pinned snapshots; updated versions ship under new IDs. Aliases for earlier models do move, so production features should choose IDs deliberately and change them through a tested process.
Assuming a pinned model will remain available indefinitely, so no lifecycle process is needed.

Models are deprecated and retired on a published schedule, and requests to retired models fail. Pinning creates an obligation to track notices and migrate on your own timetable, with evals, rather than under deadline pressure.
Moving all traffic to the vendor-recommended replacement immediately because it is newer and 'better'.

A general recommendation does not validate your feature. Compare candidates on your regression and format-sensitive evals, roll out in stages with a rollback, and then commit.
Considering the architect's job complete at handoff and dropping monitoring because the model ID has not changed.

Ownership, quality monitoring, feedback and iteration continue after launch. Even with a fixed model ID, Anthropic notes that surrounding serving infrastructure can change and cause minor differences, and inputs and requirements drift.

Practice question

Your production service is pinned to a specific Claude model ID. You receive an email that the model is deprecated, with a retirement date about ten weeks away and a recommended replacement. The service feeds a downstream parser that expects a strict output structure. What is the best plan?

A Wait until the final two weeks to avoid disturbing a stable system, then switch to the vendor's rolling alias so that future model updates are picked up automatically without further migration work by the team or any additional evaluation, and the team can then treat the model as maintained by the vendor.
Waiting compresses testing into a deadline, and moving to a moving pointer trades a planned change for repeated unplanned behaviour changes on a feature with strict format needs.
B Start now: inventory usage, read the migration guide, run regression and format-sensitive evals on the recommended replacement and one alternative, adjust prompts, stage the rollout with a configuration-based rollback, supersede the model decision record and inform stakeholders. Correct
It treats the model as a versioned dependency with an expiry date, validates on your own evals, reduces risk with staged rollout and rollback, and closes the loop through records and communication.
C Switch all traffic to the recommended replacement immediately, since the vendor has said it is the appropriate successor and general benchmarks show it is stronger, and update the documentation and runbooks afterwards, once the change has settled and the first week of production traffic has been observed.
A vendor recommendation and general benchmarks do not show that your parser-sensitive outputs still conform. Without evals and a staged rollout you risk a regression you discover in production.
D Ask the vendor to extend support for the current model indefinitely and take no migration action until that request is answered, since the service is stable and the downstream parser depends on the current output format and nobody wants to disturb it before the next release freeze.
Deprecation and retirement follow a published policy, and requests to a retired model fail. Relying on an extension is not a plan; the team needs its own tested migration path.

Build exercise: Plan and rehearse a model migration and write the lifecycle ownership table

Advanced · 70 minutes

You'll practice:

Assign lifecycle responsibilities and ownership across discovery, design, handoff, monitoring and iteration
Inventory model usage and keep model IDs in a single configuration source
Compare a current and a candidate model on a format-sensitive eval set before rollout
Produce a staged rollout and rollback plan and a superseding decision record

For a Claude system you know (or an invented one), write a lifecycle ownership table with five phases as rows. For each phase list the architect's deliverable, the accountable owner after handoff, and the review cadence. Add rows for prompts and configuration, eval set, model dependency, on-call and cost.

Naming an owner for the artifacts that determine behaviour prevents the most common post-launch failure, where everyone assumes someone else maintains them.

You should see: A table with about ten rows in which every row has a named role (not 'the team') and a review cadence.
Hints
1. ```
If the model were deprecated tomorrow, whose name would be on the migration?
```
2. ```
Separate 'accountable for integrity' (usually the architect) from 'accountable for operation' (a product or engineering owner), and give the eval set its own owner.
```
3. ```
Example row: 'Model dependency and lifecycle | accountable: platform engineering lead | architect consulted on candidate choice | cadence: monthly lifecycle review plus any deprecation notice.'
```
Create a model inventory for your system: every model ID, where it is configured, which environments and which features use it. Move the ID into one configuration source. Read Anthropic's model deprecations page, note the lifecycle state, notification commitments and any 'not sooner than' retirement date for each ID you use, and record the date you checked.

You cannot manage a lifecycle you cannot see. Recording the date checked acknowledges that this information changes.

You should see: An inventory table with model ID, location in config, features affected, lifecycle state as of the check date, and the next review date.
Hints
1. ```
How would you find a model ID hard-coded in a script nobody remembers?
```
2. ```
Search the code and configuration for model strings, and use the usage export in the Claude Console to list which models each API key actually called.
```
3. ```
Example config: 'MODEL_ID=<pinned id> in the environment configuration, read once at start-up; the inventory links to the deprecations page and records: checked 2026-09-21, state active.' (Use your own real values.)
```

Write 10 to 12 eval cases for one feature, weighted toward its format-sensitive behaviour (schema conformance, required fields, edge cases). Then write a small comparison script that runs the same cases against a current and a candidate model ID taken from environment variables and prints pass rates and failing cases side by side.

This is the gate that separates an evidence-based migration from a gamble, and it demonstrates that a fluent answer can still fail a strict parser.

You should see: A table of pass counts for both models and a list of the specific cases that differ, showing at least one case-level comparison you can discuss.

Hints

What exactly would break in the downstream system if the output format shifted slightly?

Make each check mechanical (JSON parses, keys present, types correct) and run every case against both model IDs; keep IDs out of the code.

import os, json, anthropic
client = anthropic.Anthropic()
def ask(model, prompt):
    r = client.messages.create(model=model, max_tokens=1024, messages=[{'role': 'user', 'content': prompt}])
    return ''.join(b.text for b in r.content if b.type == 'text')
def ok(text):
    try:
        j = json.loads(text)
        return isinstance(j.get('name'), str) and isinstance(j.get('age'), int)
    except Exception:
        return False
cases = ['Extract name and age as JSON from: Sam is 34']  # add 10-12 cases
for model in (os.environ['CURRENT_MODEL'], os.environ['CANDIDATE_MODEL']):
    passed = sum(ok(ask(model, c)) for c in cases)
    print(model, passed, '/', len(cases))

Write the rollout and rollback plan: stages (shadow or canary share, widening steps), the metrics compared at each stage (service, quality, cost), the criteria to proceed or roll back, who decides, and the exact configuration change that performs the rollback. Add the stakeholder communication plan for support and product.

A staged rollout catches long-tail regressions that an offline set misses, and a rehearsed rollback turns a scary change into a routine one.

You should see: A one-page plan with numbered stages, explicit proceed and abort criteria tied to SLOs, and a named decision maker.
Hints
1. ```
What would you have to see, in numbers, to stop at 5 percent of traffic?
```
2. ```
Compare the same metrics for old and new models on live traffic, define abort thresholds in advance, and make rollback a single configuration value.
```
3. ```
Example: 'Stage 1: 5 percent of traffic for two days. Proceed if schema validity and override rate are within the agreed margin of baseline and error rate is unchanged. Abort: revert MODEL_ID to the previous value and page the owner.'
```
Write the decision record that supersedes the original model-selection record: new status, context (deprecation notice, eval results), decision, consequences (including retest cadence and the next lifecycle review), and a link to the old record, which you leave unedited.

This closes the loop and demonstrates that history is preserved while the current decision is clear.

You should see: A new record marked accepted, the old record marked superseded by it, and a next review date.
Hints
1. ```
Six months from now, could a new engineer understand why the model changed and what evidence supported it?
```
2. ```
Include the eval comparison summary, the alternatives you evaluated, the residual risks, and the trigger for the next review.
```
3. ```
Example consequence: 'We will review model lifecycle status monthly and re-run the regression set on every model or prompt change; the next candidate evaluation is scheduled for the quarter before the current model's earliest listed retirement date.'
```

Sources

Anthropic - Model deprecations - Anthropic
Anthropic - Model IDs and versioning - Anthropic
Anthropic - Models overview - Anthropic
Anthropic - Migration guides - Anthropic
Anthropic - Choosing the right model - Anthropic
Anthropic - Demystifying evals for AI agents - Anthropic
Anthropic - Rate limits - Anthropic
Anthropic - Workspaces (usage and cost tracking) - Anthropic