Model Lifecycle: Version, Monitor, Migrate

Outcome. You can create a version record, canary plan, rollback rule, and migration checklist for a hosted or self-hosted model.

Hosted providers release snapshots, moving aliases, previews, stable versions, deprecations, and retirements. A moving alias may change behavior without changing your code. A pinned snapshot improves repeatability but eventually may require migration. Downloadable weights do not share the same provider-retirement path, yet runtimes, hardware, security fixes, and dependencies still evolve.

Treat model, prompt, retrieval index, tool schema, safety policy, and grader as versioned components. Before a change, run offline evals; then canary a small share of traffic, compare quality and severe failures, watch latency/cost, and retain a tested rollback. Log enough metadata to reproduce which stack produced an output.

Migration is not only API compatibility. New models can interpret instructions differently, expose different controls, call tools differently, change tokenization or cost, and shift refusal behavior. Maintain a calendar of vendor notices and an owner for each production dependency.

Mental model. The model is a versioned dependency with behavioral contracts, not a timeless intelligence endpoint.

Evidence trail — reviewed 23 July 2026. OpenAI explicitly recommends pinned versions and evals because behavior can change: https://platform.openai.com/docs/api-reference/backward-compatibility. Check live deprecation pages for OpenAI, Anthropic, and Google; dates do not belong in durable lesson prose.