MLOps: what separates a model that works from a model that lasts

A model producing good predictions on a laptop is not a deliverable. It is a feasibility demonstration. What separates the two is a set of unspectacular and rarely budgeted components.

The seven components

1. Joint versioning of code, data and model. You must be able to answer "which model produced this prediction on 12 March, and what data was it trained on". Without that traceability, every incident diagnosis becomes an investigation.

2. A reproducible training pipeline. Retraining must not mean re-running a notebook in an order only its author knows. One command, a frozen environment, an identical result.

3. Tests on input data. Schema, value ranges, missing-value rates, category cardinality. Most production incidents come not from the model but from a silent upstream change, and these tests catch it before the prediction goes out.

4. Regression tests on predictions. A set of reference cases whose expected output is known. If a change alters the prediction on those cases, it must be explicitly justified.

5. Drift monitoring. Drift in the input data and drift in the relationship between inputs and output. With a threshold and a named alert: an alert that reaches nobody does not exist.

6. A fallback plan. The baseline stays implemented and switchable in one command. On the day the model has to be disabled, the question must not be "so what do we do now".

7. The model card. Assumptions, validity scope, known limits, populations where the model is less reliable, date of last validation. It is also what your compliance function will ask for.

The real cost

Industrialisation commonly costs as much as developing the model, sometimes more. That is not an overrun, it is the normal cost of the subject. A proposal that does not price it is incomplete, and the balance will arrive at the worst moment.

What not to over-engineer

You do not need to deploy a full MLOps platform for a first model. For a single use case with daily batch inference, a scheduler, a code repository, versioned model storage and a few automated tests are enough.

Full platforms earn their keep from several models in production and a dedicated team onwards. Deploying them too early produces complexity nobody uses, which itself becomes debt.

The end-of-assignment criterion

It must be verifiable by you rather than declarative: your internal team must be able to retrain the model end to end without our help, and demonstrate it in front of us before the assignment ends.

If that test fails, the handover has not happened, whatever the quality of the documentation delivered.