MLOps in 8 Slides

This post traces a model's journey through an MLOps pipeline so the tooling stops feeling like alphabet soup. The payoff is that once you see the stages — validation, tracking, registry, CI/CD, serving, monitoring — each tool you encounter slots into a stage with an obvious job. The cover frames the pipeline as a conveyor belt: raw data in one end, a monitored, served model out the other, running itself on a trigger.

The pipeline diagram lays out the end-to-end flow as six stages: ingest raw data, validate it against schema and quality rules, train while tracking the run, register the resulting model with a version and stage, deploy it to serve an API, and monitor it for drift and performance. Each stage hands a clean artifact to the next, and the whole sequence is what 'a pipeline' actually means.

Seeing the stages explicitly is the organizing idea for the entire post — every following slide zooms into one of these boxes. The deeper point is that each stage exists to remove one source of 'it worked on my machine' from the path to production. Validation removes bad data, tracking removes lost results, the registry removes ambiguity about what's live, and so on.

The first stage is data validation, and it comes before training for a reason: bad data is the number-one cause of bad models. The pipeline checks incoming data against an expected schema — correct columns, correct types, sane value ranges, and an acceptable null rate — and stops if the data fails. Catching a problem here costs minutes; catching it after a model has trained on garbage and shipped costs weeks.

The principle is fail-fast at the boundary. The earlier in the pipeline you reject bad input, the cheaper the failure. Data validation is the ML equivalent of input validation in a normal API: an unglamorous gate that prevents a huge class of downstream disasters, and the first thing the build post implements.

The second stage is experiment tracking. Every training run logs its parameters, metrics, code version, and data version to a tracking server, so the question 'which run got 0.94 AUC?' has a definite answer instead of living in someone's memory or a lost notebook. Tracking turns scattered, ad-hoc experimentation into a searchable, comparable, reproducible history.

The value compounds over a project's life. Without tracking, you re-run experiments you've already done, can't tell which change caused an improvement, and can't reproduce your best result. With it, model development becomes cumulative — each run builds on a recorded past rather than starting from a guess. It's the practice that makes the rest of the loop's reproducibility possible.

The code shows experiment tracking in practice with MLflow. Inside a start_run context, the snippet logs the hyperparameters that define the run, including the data version, then trains the model, evaluates it, logs the resulting AUC as a metric, and logs the trained model itself as an artifact — all captured under one run in one place.

The thing to notice is how little ceremony this takes: a few log calls wrap ordinary training code and suddenly every run is recorded with its params, metrics, and artifact tied together. This is the runnable embodiment of the previous slide. Logging the data version alongside the params is what connects this back to the three-artifacts discipline — the run is only reproducible if the data it saw is pinned too.

The third stage is the model registry. A run that wins gets promoted into a versioned catalog of trained models, organized by stages such as Staging and Production. The registry is the single source of truth for the question 'what model is live right now?', and it turns promotion and rollback into a metadata change rather than a risky file copy.

This is where reproducibility meets operations. The registry decouples 'a model exists' from 'a model is serving traffic' — many versions can sit in the catalog while exactly one holds the Production stage. That separation is what makes safe promotion and instant rollback possible: changing what's live is just moving a stage label, not redeploying files, which the build and mistakes posts both lean on.

The flow diagram introduces CI/CD/CT, the ML extension of familiar DevOps automation. CI tests the code and the data. CD deploys the model. CT — continuous training — is the piece unique to ML: the pipeline retrains automatically, and the monitoring loop is what triggers it. The final node closes the circle: monitoring detects decay and kicks off retraining.

The added 'T' is the conceptual payoff. Traditional software has CI/CD because code changes; ML adds CT because the world changes even when the code doesn't. A model can need redeployment with no code change at all, simply because fresh data produced a better model. Recognizing that continuous training is a first-class part of the automation is what distinguishes ML CI/CD from the software version.

The fourth stage is serving. A registered model gets wrapped in a serving layer — typically a REST endpoint, often inside a container — so applications consume it like any other API. The serving layer handles loading the correct model version from the registry, batching requests for efficiency, and scaling under load. The calling application sends features and gets a prediction back, with no knowledge of how the model was trained.

This separation of concerns is the point. The app depends on a stable prediction interface, not on the model's internals, so the model can be retrained, swapped, or rolled back behind that interface without the app changing. Serving is the boundary that lets the messy, cyclical world of model development stay invisible to the clean, request-response world of the application.

The code shows a minimal serving endpoint with FastAPI. It loads the Production-staged model directly from the registry by name, then exposes a /predict route that accepts features and returns a prediction. The app calling this endpoint never touches MLflow, training code, or model files — it just makes an HTTP call.

Two details carry the lesson. First, the model is loaded by its registry stage ('Production'), not a hard-coded file path, so promoting a new version changes what this endpoint serves without touching the serving code. Second, the interface is a plain JSON API, which is why any application — in any language — can use the model. This snippet is the concrete bridge between the registry and the application.

The fifth stage closes the loop: monitoring that feeds retraining. In production the pipeline watches input drift, the distribution of predictions, and — once ground-truth labels eventually arrive — live accuracy. When any monitored metric crosses a threshold, it triggers the retraining pipeline: the whole loop runs again, producing a fresh model that gets tracked, registered, and deployed.

This feedback loop is what keeps the system from the silent rot described in the why-post. Without it, every earlier stage just produces a model that will slowly decay. With it, the pipeline becomes self-maintaining: degradation is detected and answered automatically. The monitor-triggers-retrain connection is the single most important arrow in MLOps, because it's the one that makes the whole thing a living loop rather than a one-shot deploy.

The cycle diagram shows the self-healing loop in full: serve live predictions, monitor drift and accuracy, trigger when a threshold is crossed, retrain a new model, validate whether it's actually better, and then either promote it or roll back. The loop's job is to keep a fresh, validated model in production without a human in the path for routine refreshes.

The validate-then-promote-or-roll-back step is what keeps the loop safe. Retraining doesn't blindly ship a new model; it ships only if the new one beats the current one on a held-out check, otherwise it keeps the incumbent. This guardrail is what lets automation be trusted — the loop can run unattended precisely because it won't promote a regression. The build post implements exactly this gate.

Tracing a model through validation, tracking, the registry, CI/CD/CT, serving, and the monitor-retrain loop gives you a model of why each tool exists rather than a list to memorize. Every stage removes one source of unreproducibility or silent failure from the path to production, and the cycle back from monitoring to retraining is what makes the system self-maintaining.

The next post turns this map into running code — a tiny but complete pipeline that validates data, tracks a run, registers and gates the model, serves it, and checks for drift — so the stages stop being a diagram and become something you can execute.