Learning outcomes
- Version models prompts datasets and evaluations together
- Define promotion rollback and retirement controls
- Preserve lineage across deployments
Mental model
A model release is a versioned evidence bundle, not a weight file. It connects code, model, data, prompt, environment, evaluation, approval, deployment, monitoring, and rollback identity.
Theory
Log immutable artifacts with signatures, dependencies, source run, dataset references, and evaluation results. A registry gives versions stable identity and uses aliases or tags to represent deployment intent. Promotion should reference evidence and policy rather than manually copying an artifact into a production folder.
Deployment records bind the served endpoint to an artifact version and configuration. Monitor input shift, output quality proxies, system reliability, cost, safety signals, and user feedback. Define rollback before promotion and verify that previous versions, schemas, and data dependencies remain usable. Retirement includes traffic removal, retention decisions, credential cleanup, and documentation updates.
Alternatives and trade-offs
A repository and object store may be enough for a small team when lineage is disciplined. A registry improves collaboration and automation but does not define the organization's release policy. Continuous deployment speeds iteration; staged or canary promotion reduces blast radius for uncertain changes.
Failure modes and misconceptions
Mutable model names destroy reproducibility. Versioning weights without prompts and data leaves behavior unexplained. A rollback image that depends on removed schemas is not a rollback. Monitoring only service uptime misses quality drift. Keeping every artifact forever creates security and governance debt.
Knowledge check
Which non-model artifacts must be versioned with a release so an observed behavior can be reproduced?
Decision scenario
A classifier release registers model, tokenizer, feature contract, training dataset digest, evaluation report, container image, and owner. A champion alias moves only after gates pass, and the prior version remains deployable until the observation window closes.
Learning outcomes
- Explain MLOps Lifecycle as a system mechanism rather than a slogan.
- Compare its alternatives, trade-offs, and production failure modes.
- Apply the concept to a decision and identify evidence that would validate it.
Trade-offs
Using MLOps Lifecycle can improve capability or control, but it also introduces cost, latency, complexity, and failure modes that must be measured against an explicit objective.
Evidence assessment
Theory and decision mastery
Decision scenario
A production team must adopt MLOps Lifecycle while meeting quality, latency, security, and operating constraints.
Which decision process is most defensible?
Relationships
Primary sources
- Model Registry Workflows — MLflow, verified 2026-07-21
- Artificial Intelligence Risk Management Framework — NIST, verified 2026-07-16