Model Lifecycle

It describes ongoing responsibility for a system, not merely the completion of a training run. Each stage needs evidence that can be traced to a particular version.

Key takeaways

• Assign ownership across the complete lifecycle.
• Version the full system configuration.
• Plan monitoring, rollback, and retirement.

Start with a purpose, responsible owner, and decision about whether a model is needed at all. Define the operating conditions and what would make the project unsuitable. This prevents a technically interesting experiment from becoming a service without a clear use case. Version the data, preprocessing, model, prompts, and evaluation materials. These components interact: changing a feature calculation or retrieval index can alter behavior without changing the model weights. A release record should identify the complete configuration. Deploy gradually where practical, compare with the previous version, and retain a rollback route. Test startup, cancellation, timeouts, dependency failure, and compatibility with existing clients. Operational readiness includes the surrounding service and the people responding to incidents. After deployment, monitor both system health and task outcomes. Define who reviews alerts, when retraining or replacement is justified, and how old versions are retired. Deleting a model file does not automatically remove retained input data, cached outputs, or a dependent service. Track those assets explicitly.

1. Imagine a demand model trained on prices in dollars while a new service sends prices in cents.
2. The model file is unchanged, yet inputs are multiplied by 100. An input-range check can detect the mismatch before relying on forecasts.
3. Restore the compatible preprocessing version and add the incident as a regression test.

This hypothetical failure shows why lifecycle management includes data contracts and dependencies.