1
Curious builder0 XP earned · 300 to level 2
0 daysFinish a lesson to begin
Badge collection0 of 6 unlocked
50 small wins to finish your pathNext lesson →
MLOps maturity levels
MLOps maturity levels are a three-rung ladder that describes how much of the lifecycle a team has automated: level 0 runs it by hand, level 1 runs the training pipeline automatically, and level 2 lets a commit rebuild, test and deploy that pipeline itself.
Last updated: 19 Oct, 2026 · MLOps
The MLOps lifecycle named the stages. The ladder answers the next question, which is which of them to automate first. The three levels are the ones Google Cloud's MLOps architecture guide sets out, and they are useful because each rung names a specific thing a person is still doing by hand.
Level 0: the manual process
- Every stage is run by a person, usually in a notebook, in the order they remember.
- The handover is a file. The data scientist passes a model artefact to an engineering team, which writes the serving code separately. The two halves can drift apart without anyone noticing.
- Releases are rare, a few a year, because each one costs a week of someone's attention.
- There is no active monitoring, so a model that has decayed looks exactly like one that has not.
Level 0 is not a failure. A model that only needs refitting once a year, on data that does not move, can live here for a long time. It becomes a problem the moment the data changes faster than the team can run the steps.
Level 1: an automated training pipeline
- The stages are code, split into components that a pipeline runs end to end, which is exactly the structure the next parts of this course build.
- The data is validated at the start of the run, so a schema change stops the pipeline instead of poisoning the model.
- Data and models are versioned, so the artefact can be traced back to the rows and the parameters that produced it.
- Retraining has a trigger, a schedule or a drift signal, and runs without a person starting it.
- The pipeline is the thing deployed, not only the model, so production can fit a fresh model on fresh data by itself.
Level 2: CI/CD for the pipeline
- A commit is the trigger. Changing a component runs the tests, builds the image and deploys the new pipeline, with no manual step in between.
- The pipeline itself is tested, not only the model: the components have unit tests, and an integration run proves the stages still fit together.
- Deployment is a decision with evidence. The new model is compared against the one serving traffic before it replaces it.
- Monitoring closes the loop, feeding drift back into the trigger that starts the next training run.
What changes between the rungs
| Level 0 | Level 1 | Level 2 | |
|---|---|---|---|
| What is deployed | A model file | A training pipeline | A pipeline built by CI/CD |
| Who starts a training run | A person | A schedule or a drift signal | A commit, a schedule or drift |
| Data validation | By eye, if at all | A stage in the pipeline | A stage, tested in CI |
| Releases per year | A handful | As often as the data moves | As often as the code changes |
| Monitoring | None | Drift feeds the retrain trigger | Drift feeds the whole loop |
| Typical gap | No record of any run | The pipeline is deployed by hand | Cost and governance |
Where the ladder is worth using
- Deciding what to do next, where the answer is the lowest rung you have not finished rather than the newest tool on a conference slide.
- Explaining a timeline, where moving from level 0 to level 1 is weeks of ordinary engineering and naming it as a rung makes it fundable.
- Judging a job or a team, where asking which rung they sit on gets a more honest answer than asking which tools they use.
Watch out. The rungs are not a scoreboard, and level 2 is not the goal for every project. A model retrained once a year gains nothing from a commit-triggered pipeline. The question each rung asks is whether a person is still doing a step by hand often enough for that to hurt, and a team that automates ahead of that answer has built a second system to maintain.
Related
- Previous: The MLOps lifecycle
- Next: The MLOps toolchain
- Reference: MLOps: continuous delivery and automation pipelines in machine learning
- See also: The Azure MLOps maturity model, a five-stage version of the same idea
Try it yourself
- Place a project you know on the ladder and write the one sentence that explains the rung.
- Name the step a person on that project still runs by hand most often.
- For the rung above yours, list what would have to exist before you could claim it.
This is what real progress feels like.