Model retirements made AI maintenance visible

Model retirements made AI applications look more like maintained software.

A model name is a runtime version and an API contract, not a permanent setting. It can drift, disappear, change price, become stricter, or stop being right for the task.

Start with inventory:

- surface: support-draft-summarizer
  owner: support-platform
  model: provider/model-name
  purpose: summarize ticket history before human reply
  fallback_model: provider/alternate-model
  eval_suite: evals/support-summary.yml
  last_reviewed: 2026-02-10

The migration question is not only what replaces the old model. It is where the old route lives, who owns it, which behavior matters, and what happens if the replacement regresses on an important slice.

Use ugly representative cases: long and malformed inputs, policy edges, prompt overflow, stale retrieval, and requests where refusal is correct. Shadow runs and canaries help. A tested rollback path helps more.

Prompt coupling needs its own comparison. Test the old prompt with the new model before changing the prompt too. That separates model behavior from instruction changes and context assembly.

A retirement date is a maintenance deadline with a visible clock. Teams handle it well when they know their inventory, have representative evals, and can explain where the fallback lives.