The MLOps maturity curve is a lie — but it's useful

Maturity models describe a destination and imply a route. The destination is roughly right; the route is invented, and following it in order is how teams build automation for a model nobody uses.

Every vendor has one. Level 0: manual. Level 1: automated training. Level 2: automated deployment. Level 3: continuous, monitored, self-healing. A tidy staircase, usually with the vendor's product occupying the top step.

The staircase is not wrong about where you end up. It is wrong about the order, and the order is the only part that is actionable.

What the curve gets right

The capabilities are real. Reproducible training, automated deployment, monitoring, governed rollback — a team that has all of them ships more safely than a team that has none. Nothing on the list is padding.

It gives shared vocabulary. "We are at level 1" communicates more in a budget meeting than a paragraph of nuance, and that has genuine value when the audience is not technical.

It makes the invisible legible. Much of this work has no demo. A maturity model is one of the few ways to make "we cannot roll back" register with people who do not feel the risk.

What the curve gets wrong

It implies the levels are prerequisites. They are not. They are largely independent capabilities that a staircase drawing forces into a sequence. Monitoring does not require automated retraining. Rollback does not require a feature store. Presenting them as steps produces teams building level-2 automation before anyone has confirmed the model is worth deploying at all.

It is indexed on automation, not on risk. The levels measure how much of the pipeline runs without a human. That is a proxy — sometimes a good one — for what actually matters: how fast you detect a problem and how cheaply you undo it.

Maturity levels drawn as a staircase, compared with the same capabilities plotted by cost to acquire against risk reducedthe drawingmanualauto-trainauto-deploycontinuousimplies: in this orderwhat actually guides the ordercost to acquire →risk reduced ↑rollbackserved-input loggingoutput monitoringreproducible trainingautomated retraining
Figure 1 — The same capabilities, reordered by what they cost against how much risk they remove. The items in the top-left are cheap and decisive; automated retraining sits where it belongs, and it is the one most maturity models place in the spotlight.

It ignores the denominator. A level-3 platform serving one model used by nobody is worse than a level-0 notebook serving something people depend on. Maturity models measure the machinery, never the payload.

It has a vendor's interests in it. The top of the staircase is reliably the shape of a product. That does not make it wrong, but it explains why "buy a platform" appears earlier in the sequence than the evidence supports.

What to optimise for instead

Three questions, and they are worth more than a level:

How long until we know something broke? Detection time. If the answer is "when a user complains", nothing else on the list matters yet.

How long until it stops being broken? Recovery time. Usually this means: can you roll back, and have you ever tried.

How long until we can explain why? Diagnosis time. This is where logging what you actually served pays for itself, repeatedly.

These are the operational questions any on-call engineer would recognise. Machine learning does not get its own version of them — it just adds a few ways to fail that do not throw exceptions.

The order that survives contact

For a team shipping its first model, roughly:

  1. Ship something a human uses, manually if necessary. Everything downstream is guesswork until you know the model is worth operating.
  2. Log the inputs you served and the outputs you returned. The cheapest single capability, and a prerequisite for diagnosing anything.
  3. Make rollback real, and rehearse it. A rollback that has never been executed is a design, not a capability.
  4. Monitor the output distribution. Not accuracy — you rarely have labels in time. The shape of what the model emits moves before your metrics do.
  5. Make training reproducible. Pinned data, pinned code, recorded parameters. Needed the day you must explain a decision, which arrives sooner than expected.
  6. Automate deployment. Now, when there is something worth deploying often.
  7. Automate retraining. Last, deliberately. It is the step most likely to automate a mistake at scale, and it is the one maturity models put on the poster.

Steps 2 and 3 are the ones teams skip, and they are the two with the best ratio of effort to risk removed.

Where the curve is genuinely useful

Not as a roadmap — as a checklist you read backwards.

Start at the top step and ask, for each capability: what would go wrong if we never built this? Some answers are "nothing, at our scale, this year". Those are the ones the staircase would have had you build third.

Used that way, the maturity model stops being a route and becomes what it always was underneath: a reasonably complete list of the things that can hurt you, drawn in an order that suits whoever published it.

Take the list. Leave the order.