We now know what MLOps is and what stages a model's lifecycle has. The next natural question is: how much of that cycle has my team automated, and who takes care of each part? To answer the first, there are the MLOps maturity models, which describe a team's evolution from a fully manual process to full automation. For the second, we need to understand the roles involved in an ML system and how they collaborate. This lesson gives you both: a thermometer to diagnose where you stand and a map of responsibilities so you know who to work with. And we'll place CineClick at its starting point: level 0.

1. Why talk about maturity levels
2. Level 0: manual process
3. Level 1: automated training pipeline
4. Level 2: full CI/CD for ML
5. Comparison table and self-assessment
6. The roles of an ML team
7. How they collaborate in practice: handoffs and shared ownership
8. CineClick: level 0 with a ticket to level 2

The maturity levels we'll cover are a synthesis, explained in our own words, of the models published by Google (three levels: 0, 1, and 2) and Microsoft (a more granular five-level scale that essentially describes the same journey with more steps). They are not an official standard or an exam to pass: they are a common language for answering very practical questions:

• Where are we today and what are we missing?
• What investment makes sense right now? (Jumping from 0 to 2 in one go usually fails.)
• What level does our case actually need? Not every team needs the top level.

The idea that orders the levels is simple: what is automated? At level 0, nothing. At level 1, training. At level 2, the integration and deployment of the pipelines themselves as well.

This is the starting point for almost every team, and there's no shame in it: it's the natural state when you're getting started. Its traits:

• The whole flow is manual and interactive: data is extracted by hand, training happens in notebooks, the "best model" is picked by eyeballing results.
• Disconnect between whoever trains and whoever operates: the data scientist hands over a model file (a .pkl, for example) and another team — or nobody — puts it into service. The deliverable is the artifact, not the process.
• Infrequent deployments: the model is updated a few times a year, because each update is a manual project.
• No model monitoring: at most, someone watches that the service doesn't go down. Nobody measures whether the predictions are still good.
• No systematic record-keeping: experiments, data, and decisions live in personal folders and in people's memory.

The characteristic risk of level 0 is silent degradation: since retraining is expensive and there is no monitoring, the model ages in production until the business notices something is wrong — weeks or months after it started failing.

When is it acceptable to stay here? For prototypes, proofs of concept, or one-off models. As soon as a model is used recurrently and the business depends on it, level 0 becomes a debt.

The qualitative leap of level 1 is this: what gets deployed is no longer a model, but a pipeline that produces models. Instead of delivering a .pkl, the team delivers an automated process that goes from data to validated model with no manual intervention.

What it means in practice:

• A training pipeline runnable end to end: data extraction and validation, preprocessing, training, model evaluation and validation, all chained and parameterized (building these pipelines is the topic of module 2, and their orchestration is completed in module 5).
• Continuous training (CT): the pipeline can run frequently — on a schedule or triggered by new data — and produce fresh models routinely.
• Symmetry between experimentation and production: the code used to experiment is the same code that runs in production, which requires the experimental phase to already work with modular, versioned code, not loose notebooks.
• Automatic data and model validation: the pipeline checks that incoming data looks as expected and that the new model clears thresholds before being published.
• Experiment and model tracking: every run is traced (module 3).

What level 1 does not solve: the pipeline itself is deployed by hand. If the team changes the pipeline code (a new feature, a different algorithm), testing and deploying that new pipeline version is still a manual process. With few pipelines and few changes, that's manageable; with many models or lots of change, the bottleneck that motivates level 2 appears.

At level 2, the lifecycle of the pipeline itself is also automated. This is the level of organizations that operate many models or need to iterate on them quickly and safely.

Its components, described without the detail that belongs to module 5:

• Continuous integration (CI): every code change automatically triggers builds and tests — and in ML, tests go beyond code: data and model behavior are tested too.
• Continuous deployment (CD): new pipeline versions (and the models they produce) reach production through an automated process, with validations and no manual rituals.
• The whole cycle instrumented: service and model monitoring, with the possibility that a degradation alert automatically triggers a retraining (module 6).
• Frequent, low-risk deployments: updating a model goes from being "the project of the quarter" to a routine event, thanks to progressive release strategies (which we'll see in module 5).

An important nuance: level 2 does not mean "no humans". Critical decisions — approving a model for production, validating that a behavior is acceptable — still have human approval gates. What gets automated is everything mechanical around those decisions, so they can be informed, fast, and traceable.

To self-assess your team, ask these questions in order; the first "no" tells you your level:

1. Can you retrain and publish a model by running one automated process, with no manual steps? If not → level 0.
2. Does a change to the pipeline code reach production through CI/CD (automated tests + automated deployment)? If not → level 1.
3. If both are yes → level 2 (in practice, a spectrum within level 2: how much monitoring, how much automated retraining...).

Two tips on the diagnosis: be honest (the level is measured by what actually happens, not by what "we could do"), and remember that different models within the same organization can be at different levels — the level belongs to the system, not the company.

Maturity isn't built by tools but by people. These are the usual roles on a team operating ML in production. Note: these are roles, not necessarily separate people — on small teams one person covers several; in large organizations each role can be an entire team.

A few observations the table doesn't capture:

• The ML engineer is the hinge role and the "newest" one on the list: it was born precisely out of the notebook → production gap. They share a language with the data scientist (they understand models) and with platform (they understand systems). A large part of this course is, in fact, an ML engineer's syllabus.
• The data engineer works "upstream" of the model, but their work conditions everything else: most production ML incidents are, at root, data incidents.
• Business is not a decorative role: without someone defining what "working" means in euros or in retained customers, the team optimizes ML metrics in a vacuum. And as we saw, risk-acceptance and final-approval decisions are human, and usually theirs.

Knowing the roles isn't enough: the real problems appear at the boundaries between them. There are two ways to organize those boundaries:

The handoff model (relay race): each role works its stage and "throws the result over the wall" to the next. The data scientist hands a notebook to the ML engineer, who rewrites it and hands a container to platform, who deploys it. It's the default model in organizations that separate teams by specialty, and it has well-known problems:

• Information loss at every handoff: the ML engineer reimplements the preprocessing and something changes subtly; the production model doesn't behave like the notebook one.
• Slow cycles: every model improvement has to travel the whole relay chain.
• Nobody owns the end result: when the model fails in production, each team looks at the one next to it.

The shared ownership model: a cross-functional team owns the ML system end to end — from the data to the monitored prediction. The roles still exist, but they share the repository, the pipeline, and on-call responsibility. The practices that make it possible:

• Shared artifacts instead of deliverables: nobody hands over "a notebook"; everyone works on the same versioned repository, the same pipeline, and the same model registry. The shared tool is the contract.
• Explicit contracts wherever a boundary is unavoidable: for example, a data schema agreed and automatically validated between data engineering and the training pipeline — that way, data changes break a test, not the model in production.
• Cross review: the ML engineer reviews the data scientist's feature code; the data scientist reviews that the service implements the correct preprocessing.
• Shared operational responsibility: whoever builds the model takes part in watching it. Nothing improves the quality of a pipeline like its author receiving the alerts.

Maturity progression and collaboration reinforce each other: the tools of levels 1 and 2 (pipelines, registries, CI/CD) are exactly what replaces informal handoffs with shared, verifiable artifacts.

Let's run the diagnosis on CineClick using the self-assessment questions:

• Can they retrain and publish with an automated process? No: the model lives in a notebook on the data scientist's laptop, data is extracted by hand, and there is no deployment process at all. → Textbook level 0.
• Roles: there is a data scientist (our protagonist), a data engineer who maintains the platform's databases, and a small platform team that operates the CineClick website but has never deployed a model. There is no ML engineer... yet: that is the role you, as a student, will play throughout the course.

The course plan is, quite literally, the maturity ladder:

• Modules 2 and 3 build the foundations of level 1: structured, reproducible code, versioned data, a training pipeline, and tracked experiments and models.
• Module 4 adds what level 1 presupposes for serving: the model deployed as a real service.
• Module 5 makes the jump to level 2: CI/CD for code, data, and models, plus pipeline orchestration.
• Module 6 completes level 2 on the operations side: monitoring, drift, and automated retraining.

Don't memorize this plan: you'll see it laid out in detail (dataset, initial notebook, and tool stack included) in the next lesson.

• Mistake: trying to jump from level 0 to level 2 in one go. Building the whole platform at once, without first consolidating a reproducible pipeline, usually produces complex infrastructure that nobody uses. Climb the ladder one step at a time; this course is ordered that way on purpose.
• Mistake: treating level 2 as a universal goal. A team with a single model retrained twice a year can live perfectly well at a well-executed level 1. The right level depends on the number of models, the rate of change, and the cost of degradation — not on prestige.
• Mistake: confusing "we have the tools" with "we have the maturity". Installing an orchestrator and a model registry doesn't move you up a level if the actual process is still manual. The level is measured by how the last model reached production, not by the installed stack.
• Mistake: hiring roles without defining boundaries. Adding an ML engineer to a team that still works via notebook handoffs just adds one more handoff. First define the shared artifacts (repository, pipeline, registry) and the responsibilities over them.
• Tip: on small teams, don't worry about covering five roles with five people; worry about the five responsibilities having an explicit owner. A two-column table (responsibility → person) prevents the classic "I thought you were handling that".

Diagnose the maturity level of these three teams and justify your answer:

1. Team A: every Monday, a scheduled job retrains the model on the week's data, automatically validates that it beats the incumbent model and, if so, publishes it to the model registry. However, when the team wanted to add a new feature last month, it took three weeks: the modified pipeline had to be tested by hand on a staging machine and deployed by copying files.
2. Team B: the model is retrained "whenever someone has a spare moment": the data scientist downloads a database extract, runs her notebook, and if the metrics look good to her she sends the model file over internal chat to the engineer, who copies it to the server.
3. Team C: every push to the repository triggers code, data, and model tests; if they pass, the updated pipeline deploys itself, and drift alerts can trigger an automatic retraining that publishes the model after a recorded human approval.

At CineClick, the data scientist has created a highly predictive feature in her notebook: viewing_ratio (hours watched / hours of new content published on their plan). She hands the notebook to the future ML engineer to take it to production. Describe: (1) at least two problems this handoff, as framed, can cause; and (2) how a team with shared ownership and explicit contracts would organize it.

Assign each task to the role that should lead it (data scientist, data engineer, ML engineer, platform/DevOps, business/product owner). Some tasks may require collaboration between two roles; say so:

1. Deciding whether a 70% recall on the "churns" class is enough to launch the retention campaign.
2. Investigating why the model fails more on customers who pay with PayPal.
3. Guaranteeing that the support ticket table arrives complete every night with the agreed schema.
4. Reducing the startup time of the prediction service containers on the cluster.
5. Turning the notebook's preprocessing into a tested Python module used by both training and serving.

Solution 1:

1. Team A: level 1. Training is fully automated, validation and publishing included (which rules out level 0). But the evolution of the pipeline is manual — hand testing, deployment by copying files — which is exactly the limitation that defines the boundary with level 2. The three weeks to add a feature are the symptom of level 1's characteristic bottleneck.
2. Team B: level 0. Manual process end to end, training in a notebook, artifact handed over via chat, deployment by copying the file, no systematic validation or traceability. Textbook level 0, including the disconnect between whoever trains and whoever operates.
3. Team C: level 2. CI with code, data, and model tests; CD of the pipeline; and monitoring connected to retraining. Note that the human approval before publishing doesn't lower the level: level 2 automates the mechanical parts, it doesn't eliminate human decisions.

Solution 2:

1. Problems with the handoff: (a) Divergent reimplementation: the ML engineer will have to rewrite the viewing_ratio computation for production, and any subtle difference (hours over which time window? what counts as "new content"?) will make the production model see features different from the training ones and perform worse with no visible error. (b) Context loss: the decisions the data scientist made while exploring (why that formula, which edge cases she discarded, how she handled division by zero) don't travel with the notebook. (c) Slow cycle: every future tweak to the feature will repeat the whole relay.
2. With shared ownership: the feature would live from the start in the shared repository as a Python function with its tests (not in a notebook cell); the data scientist and the ML engineer would review each other's work; and the same code would be used in the training pipeline and in the prediction service, eliminating divergence by construction. If the computation depends on data prepared by the data engineer, there would be an automatically validated schema contract. (How to structure that shared code is precisely the topic module 2 opens with.)

Solution 3:

1. Business/product owner, with the data scientist's analysis of what that 70% means (how many customers it reaches, how many false positives it generates). The risk decision belongs to business; the numbers that inform it, to the data scientist.
2. Data scientist: this is model error analysis by subgroup. It may need the data engineer if the cause turns out to be a data quality problem in payment_method.
3. Data engineer: reliability, completeness, and schema of a data source is their natural turf.
4. Platform/DevOps, in collaboration with the ML engineer (who knows what's inside the container and can shrink its size or dependencies).
5. ML engineer: converting exploratory code into shared production code is their defining mission. Ideally with a review from the data scientist who authored the preprocessing.

In this lesson we've gained two maps. The first, vertical: the MLOps maturity levels — level 0 (everything manual, the model as a file somebody copies), level 1 (the automated training pipeline as the deliverable), and level 2 (CI/CD for the pipelines themselves too, with operations instrumented) — along with an honest self-assessment method. The second, horizontal: the team roles (data scientist, data engineer, ML engineer, platform, and business) and the difference between collaborating via handoffs, where information is lost at every wall, and doing it with shared ownership over common artifacts. And we've left CineClick diagnosed: level 0, no ML engineer, with a churn model trapped in a notebook — and with this course as the plan to take it to level 2.

With the fundamentals complete, it's time to come down from the map to the territory. In the next lesson we'll get to know the course project in detail: the business context of churn at CineClick, the churn_customers.csv dataset column by column, the data scientist's complete initial notebook — with all its sins — and the tool stack we'll use to transform it, module by module.