TL;DR: A production model passes through data, training or adaptation, evaluation, safety review, a registry, staged release, serving, monitoring, updates and retirement. At each stage a platform PM owns a decision: purpose and data, quality bar, release evidence, latency and cost targets, monitoring triggers, and retirement timing. The stage teams most often neglect is the loop from monitoring back to data, which is what keeps models from decaying unnoticed.
Why a lifecycle view
Teams tend to treat a model as a project that ends at launch. In production it is a living asset: data changes, users find new failure modes, better base models appear, costs shift, and eventually the model must be retired without breaking the products and customers that depend on it. A lifecycle view makes each of those moments a planned decision.
The stages
| Stage | What happens | PM owns | Main risk |
|---|---|---|---|
| Data | Sourcing, cleaning, labelling, rights and consent checks | Use cases and acceptable data | Rights violations, bias, poor labels |
| Train or adapt | Pre-training, fine-tuning, distillation, or prompt and retrieval configuration | Build versus adapt versus buy | Expensive work that does not beat a baseline |
| Evaluate | Golden sets, benchmarks, segment analysis, cost and latency | Quality bar per failure mode, set before results | Averages hiding segment regressions |
| Safety review | Red-teaming, dangerous-capability and misuse evaluations | Evidence required to release | Shipping capabilities with unmitigated risk |
| Register | Versioned record: owner, data lineage, evaluations, approvals | What must exist before production | Unknown models in production |
| Staged release | Shadow, canary, ramp with rollback | Pace and rollback criteria | Regressions reaching all users |
| Serve | Infrastructure, batching, quantization, autoscaling | Latency and cost targets, capacity | Cost overruns, slow responses |
| Monitor | Quality, drift, latency, cost, abuse | Signals that trigger investigation or rollback | Silent degradation |
| Update | Retraining, new versions, behaviour fixes | Cadence and communication | Surprising behaviour changes |
| Retire | Deprecation and migration | Timeline, replacement, support | Breaking customers' integrations |
The feedback loop
The arrow from monitoring back to data is what separates healthy model operations from decaying ones. Production failures become evaluation cases; corrected outputs become training or tuning data; drift in inputs triggers re-evaluation. Without the loop, the evaluation set measures last year's traffic and the model slowly falls behind users.
For API and platform products
When customers build on a model, every stage has external consequences. A release changes behaviour for thousands of integrations; a retirement forces customers to migrate. That makes versioning, documentation, advance notice, migration tooling and stable behaviour within a version part of the lifecycle, not add-ons. See launching a model and model migration.
Governance across the lifecycle
- A registry is the only route to production, so every serving model has an owner and an evaluation record.
- Risk tiers decide how much evaluation and safety evidence each stage requires.
- Changes to prompts, retrieval configurations and model versions go through the same release gates as code.
- Retirement policies are published so customers can plan.
Common failures
- No owner after launch, so monitoring signals go unread.
- Evaluation sets frozen at launch.
- Old versions running indefinitely because nobody planned retirement.
- Data rights checked once at the start and never again as data sources change.
In the interview
Lifecycle questions test whether a candidate sees beyond launch. Strong answers name the stages in order with a PM decision and risk at each, emphasise the monitoring-to-data loop, and, for platform roles, connect releases and retirements to customer impact. Saying "the lifecycle does not end at launch; retirement is a product decision" lands well.
Next: launching a model · regression gates