In the previous lesson we saw why most models die in the notebook and what MLOps brings to the table. Now it's time to draw the full map: what stages does a model go through, from the moment someone spots a business problem until its predictions are used — and watched — in production? Understanding this lifecycle is essential, because each module of the course equips one of its stages with tools and automation. We'll also meet an idea that structures all of MLOps: in ML we don't version one artifact but three (code, data, and model), and each evolves at its own pace.

1. Overview: a cycle, not a straight line
2. The lifecycle stages, one by one
3. The three versionable artifacts and their rates of change
4. Feedback loops
5. Classic software lifecycle vs. ML lifecycle

The key word is cycle. An ML project doesn't end when the model is deployed; in a sense, that's when it starts. The model in production generates data and evidence that feed the next lap: retraining, new features, even a redefinition of the problem.

This is the full cycle we'll unpack:

Notice that there are three paths back: routine retraining (with fresh data), returning to data preparation (when new features or fixes are needed), and, in extreme cases, returning to problem definition (when the business changes so much that the original framing no longer works).

Let's walk through each stage using CineClick as a conceptual illustration. Remember that here we describe what happens at each stage; the specific tools are covered in the modules indicated.

Everything starts (or should start) with a business question, not an algorithm. At CineClick, the question is: "we lose subscribers every month; can we find out who is going to leave so we can try to keep them?".

At this stage you decide:

• The business objective: reduce monthly churn, say from 5% to 4%.
• The translation into an ML problem: binary classification — given a subscriber, predict whether they will churn within the next 30 days.
• The success metrics, on two levels: the ML metric (for example, recall on the "churns" class) and the business metric (cancellations prevented, revenue retained). A model can improve the first without moving the second; both must be defined before training anything.
• The operational constraints: do we need real-time predictions, or is a daily list enough? What latency and cost are acceptable? These decisions will shape the deployment pattern (we'll see this in module 4).

This is the cheapest stage to correct and the most expensive one to correct late: an excellent model answering the wrong question is an expensive failure.

Here you locate the sources (at CineClick: the subscriptions database, viewing logs, the support ticket system), extract them, clean them, and transform them into a training dataset with its features (tenure, weekly hours, tickets...) and its label (did they churn or not?).

Key points of this stage:

• It usually consumes most of the project's time (the folkloric figure that "80% of the time is data preparation" is exaggerated but points in the right direction).
• Defining the label is subtler than it looks: what counts as "churn"? Cancelling? Not renewing? What if they come back two months later?
• Here the first reproducibility requirement is born: the exact dataset used for training must be recoverable later. Versioning it is the job of module 2 (DVC).

The stage everyone associates with "doing ML": choosing algorithms, training, tuning hyperparameters, comparing results on a test set. It is an inherently iterative and experimental process: dozens or hundreds of runs with small variations.

From an MLOps standpoint, what matters is that every experiment gets recorded: which code, which data, which parameters, and which metrics. Without that record, "the best model" is a memory, not a fact. Experiment tracking is the subject of module 3 (MLflow).

Before deployment, the candidate model passes a quality gate that goes beyond "good metric on test":

• Technical validation: does it work with the real data format? Are its latency and size acceptable?
• Behavioral validation: does it perform acceptably on relevant subgroups (premium vs. basic plans, new vs. long-standing customers), or does its good overall metric hide subgroups where it fails?
• Comparison with the current model: is it really better than the one already in production (or than a simple business rule)?
• Review and approval: someone — a human — decides that the model is fit for purpose, and a record of that decision is kept. In module 3 we'll see how the model registry formalizes this promotion, and in module 5 how to automate part of these checks.

The validated model is integrated wherever the business needs it. For CineClick's churn it could be a nightly batch process that scores every subscriber, or an API responding in real time; the choice between batch, online, and streaming is precisely the opening of module 4, and packaging and scaling (FastAPI, Docker, Kubernetes) its main body.

The essential point at this stage, conceptually: deployment must be repeatable (not a manual ritual) and reversible (able to roll back to the previous model within minutes if something goes wrong).

The model is in production; now it must be watched on two planes:

• As a software service: is it alive? Does it respond in time? How many errors does it throw? (the same as any API).
• As a model: does the data it receives resemble the training data? Are its predictions still good? The latter is hard because the truth arrives late: to know whether a subscriber "was going to churn" you have to wait weeks.

Silent degradation — data drift and concept drift — and its detection are the heart of module 6.

Sooner or later the model goes stale and must be retrained with fresh data. Retraining can be triggered on a schedule (monthly), by a monitoring alert (drift crossed a threshold), or manually. It reuses stages 2–4: that's why they should be automated in a pipeline (modules 2 and 5), and that's why the cycle is a cycle. Module 6 covers when and how to automate it.

We already hinted in the previous lesson that an ML system has three changing artifacts. Now we can be precise: each has its own rate of evolution, and that asynchrony is the reason they need independent but linked versioning.

Three important observations:

• The model is a derived artifact: model = f(code, data, configuration). If you version the code and the exact data, you can regenerate the model; if you only keep the binary, you have a result without a recipe.
• They can change independently: CineClick can retrain the same code on June's data (new model, same code) or refactor the serving code without touching the model (new deployment, same model). Every combination needs its own traceability.
• The key audit question cuts across all three: "for the prediction the system made on day X, which model version was used, with what code was it trained, and on what data?". The entire tool chain of this course (Git for code, DVC for data, MLflow for models) exists to be able to answer it.

An ML system in production doesn't just consume data: it generates it. This is the trait that most sets its lifecycle apart from classic software, and it has a good side and a dangerous side.

The good side: the model in production produces the raw material for its own improvement.

1. CineClick's model scores every subscriber today with their churn risk.
2. Over the following weeks, reality "labels" those cases: some cancel, others don't.
3. Those pairs (features at prediction time, actual outcome) are new, perfectly labeled training examples.
4. The next retraining uses that data: the system learns from the present, not just the past.

For this loop to work you have to design it: log predictions with their features at the moment they are made, and later join each prediction to its actual outcome. If nothing is logged, the information is lost and every retraining starts from scratch.

The dangerous side: if the business acts on the predictions, the model contaminates its own future data. It's the hidden loop we saw in the previous lesson: retention calls the high-risk customers, many of them stay, and the future data says that profile "doesn't churn". A naive retraining would learn exactly the opposite of reality.

You don't need to solve this today (there are techniques: recording which customers received an intervention, keeping control groups...); what you do need from the design stage is to know that the loop exists and log the information needed to deal with it. We'll come back to it when we discuss retraining in module 6.

Let's close the map with a comparison of the two lifecycles, which sums up why the ML one needs extra disciplines:

The practical conclusion: plan an ML project as a permanent cycle, not as a project with an ending. Budgeting only up to the first deployment is the most common planning mistake among teams coming from traditional software.

• Mistake: starting at stage 3 (training) and skipping stage 1 (business). It's tempting to go straight to the model. Without a defined business metric you won't know whether the model is useful, only whether it is accurate. Write the business objective and its metric before the first line of code.
• Mistake: treating validation as "look at the accuracy on test". Pre-production validation includes subgroups, latency, comparison with the incumbent model, and explicit approval. A model with a better overall metric can be worse for the business if it fails on the segment that matters most.
• Mistake: not logging production predictions. Without that log there is no virtuous feedback loop: you won't be able to build fresh datasets or measure the model's real performance. Logging predictions (with their features and timestamp) is cheap today and priceless six months from now.
• Mistake: versioning only the model (the binary). A .pkl without the code and data that generated it is an unrecoverable black box. Version the recipe, not just the dish.
• Tip: draw the lifecycle of your current project and mark in red the stages that today are manual, undocumented, or nonexistent (typically: formal validation, monitoring, and retraining). That drawing is your personal MLOps roadmap, and it maps onto the maturity levels we'll see in the next lesson.

Put these activities of the CineClick team in chronological order and assign each one to its lifecycle stage:

• (a) It's detected that July's predictions are noticeably worse than March's.
• (b) It's agreed that the objective is to reduce monthly churn and that the ML metric will be recall on the "churns" class.
• (c) A process is launched that retrains the model on the last six months of data.
• (d) The dataset is built by joining subscriptions, viewing logs, and support tickets.
• (e) It's verified that the candidate model beats the current one also on the basic-plan customer segment, and a manager approves its move to production.
• (f) Three algorithms are tried with different hyperparameter combinations.
• (g) The approved model starts scoring subscribers every night.

CineClick's churn model has been in production for 3 months. The retention team has been offering a discount to every customer the model flags as high risk, and 60% of them have stayed. Now it's time to retrain. Explain: (1) what problem there is with using these 3 months of data directly as if nothing had happened, and (2) what information should have been recorded from the start in order to deal with it.

For each of these three changes at CineClick, state which of the three artifacts (code, data, model) get a new version, reasoning through the chain of effects:

1. An engineer fixes a bug in the function that computes weekly_hours (it was also counting hours with the player paused).
2. Month-end arrives and June's data is added for the scheduled retraining, with nothing else touched.
3. The prediction service code is refactored to make it faster, without changing the preprocessing or the training.

Solution 1:

Order: b → d → f → e → g → a → c

• (b) Stage 1, business problem definition.
• (d) Stage 2, data acquisition and preparation.
• (f) Stage 3, training and evaluation.
• (e) Stage 4, validation (subgroup behavior + human approval).
• (g) Stage 5, deployment (nightly batch pattern).
• (a) Stage 6, monitoring (degradation detection).
• (c) Stage 7, retraining, which reopens the cycle at stage 3 (or stage 2, if the data is also revisited).

Solution 2:

1. The problem: this is the dangerous feedback loop. Customers flagged as "high risk" received an intervention (the discount) that changed their behavior: many who were going to churn didn't. If you retrain on that data as-is, the model will learn that high-risk profiles "don't churn" — that is, it will learn to unlearn precisely the signal that made it useful. The model would degrade precisely because it worked.
2. What to record: at a minimum, (a) each customer's predictions with their features and date; (b) which customers received the intervention (the discount) and when; and ideally (c) a control group: a fraction of high-risk customers who were not offered the discount. With that information you can train excluding or correcting the intervened cases, and the control group additionally lets you measure the real effect of the campaign. Without that record, the 3 months of data are irrecoverably ambiguous.

Solution 3:

1. Code, data, and model — all three. The code changes (new version of the function). Recomputing weekly_hours makes the regenerated training dataset different (new data version). And with different data, retraining produces a different model (new model version). It's a perfect example of CACE: a "small fix" propagates new versions through the whole chain — which is why the three versioning systems must be linked.
2. Data and model. The code doesn't change; the data does (June is added) and so does the resulting model. This is the routine retraining case: same code, new recipe because of new ingredients.
3. Code only. The service is faster, but the preprocessing and training are untouched: the deployed model is still exactly the same binary, and the data isn't involved at all. The new service version must be deployed, but there's no need to retrain or revalidate the model (it is worth re-checking that the service returns the same predictions as before).

We've walked the complete map of a production model's lifecycle: business problem definition, data, training, validation, deployment, monitoring, and retraining — a cycle that feeds back into itself, not a line with an ending. We've seen that in ML three artifacts are versioned (code, data, model), evolving at different paces but needing to stay linked, and that the model in production generates the data for its own improvement... and sometimes for its own contamination, if the feedback loops aren't designed carefully.

This map tells us what needs to be done, but not how much of it is automated in a given team, nor who handles each stage. Those are exactly the two questions of the next lesson: the MLOps maturity levels — from the fully manual process to complete CI/CD — and the team roles that collaborate across the cycle. There we'll place CineClick at its starting point and chart where this course will take it.