Model lifecycle: active, deprecated, retired

The lifecycle states

The catalogue records every model with one of four lifecycle states, drawn from the provider's own published documentation:

active — the model is generally available and the provider has not announced deprecation.
preview — the model is publicly available but the provider explicitly labels it as preview, beta, or pre-release. Terms may change without notice.
deprecated — the provider has announced that the model will be retired. Typically a retirement date is published.
retired — the provider no longer serves this model. Retired models stay in the catalogue for historical reference but should not be integrated.

Each state is a verified field with a citation pointing at the provider's documentation. When a state is unknown, the field renders the canonical unverified-data label rather than an assumption.

Why lifecycle matters before integration

Model lifecycle is one of the few fields that has a hard deadline attached. Integrating a deprecated snapshot weeks before its retirement date locks the team into a migration the moment the new system ships. Integrating a preview model means accepting that the API surface, pricing, and capability envelope can change. Integrating an active model with no announced successor is the lowest-friction path, but does not guarantee that state will hold.

What to verify on every lifecycle field

The current lifecycle state — active, preview, deprecated, retired.
The retirement date if any — deprecated models usually have one; retired models have one in the past.
Whether the provider has announced a successor snapshot you should target instead.
The retrieval date on the lifecycle citation — providers update lifecycle pages without notice.
Whether your integration timeline fits comfortably before the retirement date, including the time needed to migrate after rollout.

Verified examples from the catalogue

The table below shows the lifecycle field for a slice of the catalogue. The point is not to recommend an active model — it is to show how the field renders and how deprecation appears.

Verified examples · Lifecycle status

Verified lifecycle states. Note that the catalogue keeps deprecated and retired models for historical reference — they are not removed when a successor ships.

Model	Provider	Lifecycle status	Source state
Claude Opus 4	Anthropic	deprecated (retires 2026-06-15)	verified · citation on record
Claude Opus 4.7	Anthropic	active	verified · citation on record
Claude Sonnet 4.6	Anthropic	active	verified · citation on record
Gemini 2.5 Pro	Google	active	verified · citation on record
DeepSeek V4 Pro	DeepSeek	active	verified · citation on record
Mistral Large 3	Mistral	active	verified · citation on record

Inspection only. The catalogue does not rank these models on the field above.

Retirement and migration references

When the provider publishes a deprecation notice with a retirement date, the lifecycle field carries that date. Migration references — the provider's recommended successor — are surfaced through the model's record when the catalogue has retrieved them from a primary source. The catalogue does not assert a migration path on its own.

Common mistakes

Treating a preview model as a stable foundation.
Preview models can have their API, pricing, or behaviour change without a migration window. Plan for that or pick an active model.
Integrating a deprecated snapshot without checking the retirement date.
Deprecation announcements typically run months ahead, but not always long enough to absorb integration + migration time.
Assuming a retired model has a 1:1 successor.
Providers often replace snapshots with a new generation that has different context, output, and pricing semantics. Treat migration as a fresh selection workflow.
Skipping lifecycle on hosted models.
Hosting platforms inherit the creator's lifecycle. A model deprecated by its creator stops being safe to host even if the platform still serves it.

Apply this workflow

Practise this lesson

These exercises route the lesson concept through the verified-data product surfaces. Each one ends with a concrete artifact you can share.

Data gaps to watch

Some providers publish lifecycle on a separate page from their main model docs, and some publish only when a model nears retirement. When the lifecycle field is unverified for a model you care about, open the model record and check whether the provider has a separate lifecycle / deprecation page worth requesting via the reverification queue.

/coverage — per-provider verified-field counts including lifecycle.
/use-cases/governance-review — the use case that explicitly weights lifecycle state.
/docs/model-page-schema — the data-model definition for the lifecycle field.

Sources and freshness

Lifecycle states carry their own citations and retrieval dates. The reverification queue prioritises lifecycle fields when they are near or past published retirement dates.

Teaching example

Illustrative — not a recommendation.

Situation: A team is preparing a Q3 launch that depends on a model snapshot. The catalogue lists the snapshot's lifecycle as 'deprecated' with a retirement date in early Q4.

Decision to make: Is there enough runway to ship on this snapshot, or should the team migrate before launch?

Verified fields that matter:

Lifecycle status (verified field)
Retirement date if any
Migration target named by the provider (if published)
Source citation + retrievedAt

What to inspect next:

Weak vs better approach

Weak approach

Treat lifecycle as a footnote, not a gate.
Integrate the deprecated snapshot 'just for now'.
Skip checking for a published migration target.
Discover the retirement date during incident response.

Better approach

Confirm lifecycle is verified active before integrating.
If deprecated, record the retirement date in the brief and design a migration window.
Check whether the provider published a successor snapshot.
Subscribe the source to /reverification so changes surface early.

Why better: Lifecycle is the field most likely to bite during launch week. Treating it as a gate puts the migration plan in the design doc instead of in the incident postmortem.

Example artifact

Illustrative example — not a recommendation. Substitute your own values when you run the workflow.

Lifecycle review note

## Lifecycle review (illustrative)
Candidate: <slug>
Lifecycle status: <active / preview / deprecated / retired>
Retirement date: <date or n/a>
Source URL: <provider docs>
RetrievedAt: <date>

Provider-named successor: <slug or 'not stated'>
Integration timeline buffer: <days/weeks until retirement>
Action: <proceed / migrate-first / re-scope>

Substitute your real values when you walk the workflow. The catalogue never generates this artifact for you.

Concept → workflow bridge

Step 1
Learn the concept →
Read lifecycle as an integration gate, not a footnote.
Step 2
Apply in /select →
Filter the catalogue to active-only candidates first.
Step 3
Verify in /coverage →
Audit the provider's recent deprecation history.
Step 4
Test in /lab →
Schedule a regression suite to catch silent snapshot rotations.

Review before moving on

Lifecycle for the integration target is verified active OR I have a documented migration plan.
Any retirement date is recorded in the brief.
I checked whether the provider named a successor snapshot.
The source citation has a retrievedAt date.
The relevant source is on /reverification cadence appropriate to the launch timeline.

Caution: No persistence — the checklist resets on every visit. Capture progress in your own notes.

What this lesson does not teach

Telling you when a provider will deprecate a model — that is the provider's announcement to make.
Asserting a migration path from one snapshot to the next — providers publish their own migration notes.
Recommending which active model to migrate to — that depends on your workload.