MLOps

WHAT IT IS MLOps is the engineering discipline for taking a machine-learning model from training to production and keeping it working: versioned data and features, reproducible training runs, automated evaluation, deployment through a tested pipeline, and monitoring that watches the model's inputs and outputs rather than only its uptime. It is /devops applied to a system whose behaviour depends on data as much as on code. **Not this:** MLOps is not ModelOps: it owns the engineering lifecycle of building and serving a model, not the governance of the portfolio of models an organisation is accountable for. WHY IT EXISTS A deployed model degrades without anyone changing it. The world moves, the input distribution shifts, and a model that was accurate at launch quietly becomes wrong — while every infrastructure dashboard stays green. Meanwhile the path from a notebook to production is, in most organisations, a person. MLOps exists because models fail in ways that application monitoring cannot see, and because a training run nobody can reproduce is a result nobody can defend. WHEN TO USE IT Adopt it as soon as a model influences a production decision. The threshold is not model count or team size — it is consequence. A single recommendation model serving real users needs reproducible training and drift monitoring more than ten experimental models nobody depends on. WHO OWNS IT Data science owns model quality and the evaluation criteria. ML engineering owns the pipelines, serving infrastructure and monitoring. The product owner owns the decision that the model is fit for its purpose and the threshold at which it must be pulled. Where a model carries regulatory or material business risk, an independent validation function reviews it — that is where MLOps hands off to /modelops rather than doing governance itself. WHAT GOOD LOOKS LIKE Any production model can be retrained from recorded data, code and configuration to the same result. Features are computed identically in training and serving, because the gap between them is the most expensive recurring bug in the field. Deployment is automated and includes an evaluation gate that can block a worse model from shipping. Inputs and predictions are monitored for drift with defined thresholds and an owner. Rollback to the previous model version is a routine operation, and someone has done it recently. HOW TO IMPLEMENT Start with reproducibility: version the training data alongside the code and record the configuration of every run. Add an evaluation step that compares a candidate against the incumbent on a held-out set and fails the pipeline rather than reporting into a void. Establish a model registry so "what is in production" has a single answer. Add input-distribution and prediction monitoring with thresholds and an owner. Automate the serving deployment last — automating an unreproducible process just makes it faster. The deployment safety practices in /devops and the alerting discipline in /observability-engineering transfer directly. HOW TO ASSESS YOURSELF Pick a production model and try to reproduce its training result; time how long it takes. Ask what would alert you if its accuracy halved overnight. Ask how you would roll back, and when that was last exercised. Take the scored self-assessment at /assess, then plan the gaps with /roadmaps.