Most ML models fail in production for a reason that has nothing to do with the model. They fail because everything around the model, the part that actually keeps it running once real users show up, was never built. That is the production gap, and closing it is what this track exists to do.

Picture it in the concrete. A data scientist spends three weeks building a churn prediction model. It hits 94 percent accuracy on the test set. The demo goes perfectly. Everyone in the room is impressed. Six months later, that model has never made a single prediction for a real customer. It is sitting in a notebook on a laptop, exactly where it was born.

This is the most common story in machine learning, and it is not rare. Industry surveys have repeatedly put the share of models that never reach production somewhere between half and the vast majority. Gartner has estimated that only about half of models make it from prototype to production even at mature organizations. The exact number is argued about, but the direction is not. Most models never ship.

The natural reaction is to blame the model, or the data, or the algorithm. That reaction is wrong, and correcting it is the entire point of this track.

The hard part of machine learning in production was never the model. It is everything around the model.

Building the model is the part that gets taught in courses and the part that feels like the real work. But a trained model is only the engine. It cannot move anyone anywhere on its own. The discipline of building everything around that engine so it runs reliably, every day, at scale, is called ML platform engineering. That is what this track is about, and by the end of it you will be able to take a model that only exists in a notebook and turn it into a service the rest of a company can depend on.

Picture a beautifully built engine sitting on a workbench in a garage. It is precision engineered. It revs perfectly. It is also completely useless for getting you to work, because an engine on a bench does not move anyone anywhere.

To turn that engine into a car you can actually drive, you need a lot more:

• A chassis to mount the engine on
• A fuel system that feeds it continuously
• A transmission that connects it to the wheels
• A dashboard so the driver can see what is happening
• Brakes and warning lights for when something goes wrong
• A pit crew that services it so it keeps running

A trained model is the engine. The car is everything else. The data scientist builds the engine and cares about how well it runs on the bench, which we measure as accuracy. The ML platform engineer builds the car and cares about whether it keeps running on a real road, next week, under load, without a mechanic riding along.

Hold onto this picture. Every topic in this track is another part of the car. When we reach model serving, that is the transmission connecting the engine to the wheels. When we reach monitoring, that is the dashboard and the warning lights. When we reach retraining pipelines, that is the pit crew. The analogy is not decoration, it is the map.

Here is the gap made concrete. Everything that works quietly in a notebook becomes a real engineering problem the moment real users show up. The left side of this map is what a data scientist does on a laptop. The right side is the machinery each of those habits forces you to build. The empty space between them is the gap.

Read the same idea as a table, because the wording of each jump is where the engineering lives.

The deeper reason models stall is that building a model and running a model optimize for different things, and the second job barely resembles the first. A research or notebook workflow chases the highest accuracy it can get on a fixed dataset. A production workflow chases reliable answers on data that never stops moving.

Walk down the two columns and the mismatch jumps out. In research, the data is a static file that never moves, the model runs once when you press a button, minutes of latency are fine, the author operates it on a laptop, and failure means a cell throws a visible error. In production, the data is a live stream that drifts every week, the model runs continuously and unattended, you have tens of milliseconds per request, an on-call engineer operates it at three in the morning, and failure is silent: the model keeps returning confident numbers that are quietly wrong.

The notebook column is not wrong. Everything in it is true and necessary, and no model exists without that work. But each cell quietly assumes the world holds still. Production is the discipline of making the same model keep working after the world moves, which turns out to be a different job with different tools. That is why a brilliant model and a reliable service can be years apart, and why a strong data scientist and a strong platform engineer are complementary skills rather than the same skill.

A normal web application is a straight line. You deploy it, and it keeps doing the same correct thing until you change the code. A machine learning model is different. It starts decaying the moment the real world drifts away from the data it learned from. Fraud patterns change. Customer taste changes. Prices change. The model does not know any of this happened, and it will keep answering with total confidence as it slowly goes wrong.

So production machine learning is not a one-time deploy. It is a loop that has to run forever.

The platform's job is to run this loop with as little human effort as possible. Serve predictions. Watch how the model behaves on live data. Catch the moment it starts to decay. Retrain on fresh data. Redeploy the new version safely. A human steps in for decisions, not for plumbing. When people say a company has a mature ML platform, they mean this loop turns on its own.

To see why the loop is not optional, watch what happens to a model that ships and is then left alone. The accuracy falls while nothing looks broken, which is exactly what makes it dangerous.

This is the failure mode that catches teams by surprise, because every instinct from normal software says a healthy service is a correct service. A web bug crashes and pages someone within seconds. A decaying model raises no exception, keeps its latency flat, keeps the service green, and simply hands back worse answers on every request. In the example above, precision on real fraud fell sixteen points before anyone noticed, and the only thing that eventually raised the alarm was a business metric, chargebacks, not any engineering dashboard. The lag between the model going wrong and someone finding out is the whole danger, and closing that lag is what monitoring exists to do.

When a production model goes wrong, it almost never throws an exception. It keeps returning confident numbers that are quietly less correct than they used to be. There are four families of failure, and not one of them is a bug in the model. Each is a property of the world the model now lives in.

The first family is drift. The live inputs slide away from the training distribution, or the meaning of the label itself changes, and the model is left answering last year's world. The second is train-serve skew, and it is worth dwelling on because it is the most confusing one to debug. A feature gets computed one way when you train and a subtly different way when you serve, so the model is fed numbers at request time that it never actually saw in training.

Look closely at what went wrong there. The offline training path and the online serving path are two different bodies of code, written by different people at different times, and they compute the same feature to two different values: 42.10 versus 37.80. The model learned on the first and is fed the second in production, and your offline evaluation will never reveal the gap, because offline you only ever run the training path. This is exactly the failure a feature store exists to prevent, by making both paths read one shared definition instead of two copies that drift apart.

You can watch skew happen in miniature. The tiny program below computes the same feature the training way and the serving way, shows them diverge, and then shows a single shared definition collapsing the gap to zero. No machine learning library is involved, because the bug has nothing to do with the model.

People often assume MLOps is DevOps with a model dropped in. The difference is exactly one thing, and that one thing is what makes it hard.

In traditional DevOps, two things change over time: your code and your configuration. Both are things you control directly. When something breaks, it broke because a human changed code or config, and you can find that change in the history and reason about it.

In MLOps, a third thing changes on its own: the data.

Code you control. Data drifts whether you touch it or not. And when the data changes, the model's behavior changes without a single line of code changing.

This is why an ML platform needs machinery that a normal backend never needs. You have to version data, not just code, because the same code trained on different data is a different model. You have to version models and track exactly which data trained each one, so that when a model misbehaves you can reconstruct precisely how it was made. You have to monitor the statistical shape of live traffic, not just error rates and latency, because the failure hides in the distribution rather than in the logs. And you have to be able to retrain and redeploy automatically, because manual retraining does not keep pace with data that moves every week. It is DevOps standing on a floor that is quietly moving under your feet, and every extra piece of an ML platform exists to deal with that moving floor.

Nobody builds the whole platform on day one, and you should not try to. There is a well-known ladder for this, described in Google's widely cited MLOps guidance, and most teams can honestly place themselves on exactly one rung. The point of the ladder is direction, not a grade. Each rung automates one more thing a human was doing by hand.

At Level 0, everything is manual. A person runs a notebook, exports a model, and hands it to someone to deploy, and this happens rarely, weeks or months apart, with no monitoring and no automated retraining. At Level 1, the training pipeline runs itself: fresh data triggers a repeatable, automated retrain, and a feature store keeps the training and serving paths consistent. At Level 2, CI/CD builds, tests, and deploys the pipelines automatically, monitoring detects drift and triggers retraining, and new models roll out safely behind automated checks, so the full loop turns with a human only in the decisions.

You do not have to reach Level 2 to win. The single most valuable jump for most teams is from 0 to 1, from hand-run notebooks to an automated training pipeline, because that is the move that turns a one-off model into a repeatable capability. Every lesson in this track is a rung on this ladder, and knowing which rung you are standing on tells you what to build next.

If the surrounding platform feels like a lot of machinery for one model, that reaction has a famous name. In 2015, a team at Google led by D. Sculley published a paper called "Hidden Technical Debt in Machine Learning Systems," and it contains the single most quoted picture in the field.

The finding is blunt. In a real machine learning system, the model code is the tiny black box in the center. Everything around it, data collection, feature extraction, data verification, configuration, process management, serving infrastructure, monitoring, analysis tooling, resource management, is the actual system, and collectively it dwarfs the model in both lines of code and engineering effort. The part almost nobody plans for is the part that turns out to be the system.

This is why "the model is done" and "the system is done" are years apart, and why it is so easy to underestimate a machine learning project. The course that taught you to train a model built the black box. This track builds everything around it, because that surrounding platform is where models actually go to fail, and it is also where the durable engineering value lives. The model is often replaced or retrained many times over; the platform outlives every model that runs on it.

Put the pieces together and you get the map for this entire track. Here is the whole platform on one canvas. Follow the numbered path to see how a model travels from a notebook experiment to a monitored production service, with data and compute as shared rails that feed every stage.

Each component solves one specific failure of the notebook world, and each has a real industry-standard tool behind it.

Closing the production gap is expensive, so the honest first question is whether a given model should cross it at all. Not every model deserves a platform. A one-off analysis that answers a question once does not need serving, retraining, or drift monitoring, and building all of that around it would be waste dressed up as rigor.

Start with one question: does this model make a repeated, automated decision, the same kind of prediction many times a day feeding a real product or process? If the answer is no, if it is a board deck or a sizing study or a one-time segmentation that you run, read, and act on once, then a notebook and a written result is the right amount of engineering. If someone will rerun it monthly on fresh data, wrap it in a simple pipeline and stop there, without serving or drift monitoring.

If the answer is yes, if it scores fraud or ranks recommendations or sets prices thousands of times a day without a human reading each prediction, then it earns real infrastructure. Ask one more question: does the data it learns from keep changing? If it does, you need the full loop, serving and a feature store and monitoring and retraining. If the data is stable, you can start with serving and monitoring and add retraining only when drift actually shows up.

The rule of thumb is to match the machinery to the decision, not to the hype. Productionizing pays for itself exactly when a repeated, automated decision meets data that drifts, because that is the only regime where the platform's cost is clearly justified. Build the loop where it earns its keep, and leave a good one-off analysis as the notebook it deserves to be.

None of this is theoretical. Every company running machine learning at scale eventually built exactly this kind of platform, usually after feeling the pain of deploying models by hand.

Uber built Michelangelo, an internal ML platform that standardized the whole lifecycle from feature engineering to training to serving. It let hundreds of teams ship models without each one reinventing the plumbing, and it powered everything from arrival-time estimates to fraud detection.

Netflix built Metaflow, a framework for building and running data science workflows, which they later open sourced. It let scientists write normal Python while the platform handled scaling, scheduling, and moving work to the cloud.

Meta built FBLearner Flow, which ran millions of modeling experiments and served predictions across the company. At its peak it was training and serving a huge share of Meta's production models through one platform.

Airbnb built Bighead, and Spotify built its own ML platform on top of Kubeflow, both for the same reason. The model was never the bottleneck. The path from a good model to a reliable production service was the bottleneck, and a platform is what removes it.

The lesson from all of them is the same. If you want machine learning to be a repeatable capability rather than a series of one-off heroics, you build the platform. That is what you are going to learn to do here, one part of the car at a time.