Skip to content

The ML lifecycle and MLOps#

The path from a training dataset to a model whose predictions people and systems use, and MLOps, the practices that make that path repeatable, traceable and safe to change.

Before reading

Training data management · Data contracts

Why it matters#

A model that works in a notebook is a long way from a model that runs every night, can be explained, and can be replaced without breaking anything. Without MLOps, models are trained by hand, deployed by copying files, and nobody can say which version is running or what data produced it. Treating models as versioned, tested products, with predictions as governed data, closes that gap.

How it works#

The lifecycle runs from data to predictions and back.

Training. A training run takes a versioned training set, a version of the code and its settings, and produces a model with evaluation results. Runs are automated as pipelines, scheduled or triggered by new data, so that retraining is routine rather than a project.

Experiment tracking records every run: parameters, code version, data version (such as the table tag), metrics, and the resulting model file. Runs can then be compared, and any result reproduced. MLflow is the most common open-source tool for tracking; MLflow 3, released in 2025, centres tracking and evaluation on generative AI applications as well as classic models. Cloud ML platforms offer equivalents.

Model registry. A registry stores models as named, versioned entries with their metrics, training data reference, owner and status, such as candidate, approved, production or retired (in MLflow, aliases such as @champion and tags). Promotion between statuses follows rules: a new version must beat the current one on the test set, pass fairness and robustness checks where relevant, and be approved by its owner. Deployment always takes a model from the registry, never from someone's laptop.

Packaging. The model is stored with what it needs to run: library versions, the feature list, the input and output schema. The schema works as a contract for the model, just as for a table.

Prediction. The approved model is deployed for batch scoring over tables or for online scoring behind an API, covered in Model serving and monitoring.

Predictions as data. Predictions are written as tables, with the model version and the time of scoring on every row. Once they are tables with contracts, the rest of the platform handles them: dashboards read them, reverse ETL sends them to operational tools, data APIs serve them, and lineage connects each prediction to the model version and training data behind it.

flowchart LR
  TS[(Versioned<br/>training set)] --> TR[Training pipeline]
  CODE[Code and settings<br/>in Git] --> TR
  TR --> EX[Experiment tracking:<br/>params, data version,<br/>metrics]
  TR --> R[Model registry:<br/>candidate to approved]
  R -->|approved version| SC[Scoring]
  SC --> P[(Predictions table:<br/>with model_version)]
  P --> U[Dashboards,<br/>CRM, APIs]
  P -.->|outcomes and drift| TR

MLOps applies the practices of the rest of this wiki to models: code in version control, CI that runs tests on training code and a small training run, environments for development and production, orchestration of training and scoring, observability with SLOs, and owners with clear decisions.

Key terms#

  • Training run One execution of training on a specific data version, code version and settings.
  • Experiment tracking Recording parameters, data, metrics and outputs of every run.
  • Model registry A catalog of model versions with metadata, status and approvals.
  • Promotion Moving a model version to a higher status, such as production, under defined rules.
  • Model signature The declared input and output schema of a model.
  • MLOps Practices for building, deploying and operating models reliably.

Example#

The shop forecasts daily demand per product for the next 14 days.

  • Training runs weekly from shop.ml_demand_training, tagged per run; MLflow records the tag, code commit and error.
  • The pipeline compares the candidate with the current version on a rolling holdout of the latest four weeks, then retrains the winner on all data up to that window before scoring. The fixed July to September test set is used only for the quarterly review, so weekly choices do not wear it out; the owner approves the first version of each quarter manually.
  • Nightly batch scoring writes shop.ml_demand_forecast: product_id, forecast_date, predicted_units, model_version, scored_at.
  • The stock planning dashboard reads the table; a reverse ETL sync sends it to the ordering system.
  • When planners question a forecast, lineage from the row leads to the model version, its run, and the tagged training data.

Pitfalls#

  • Models deployed from notebooks. No one can say which data or code produced them.
  • Predictions without a model version. Problems cannot be traced or rolled back.
  • Manual retraining. Models age silently because retraining is a project nobody schedules.
  • Registry statuses without rules. Promotion by habit lets worse models reach production.
  • Treating models as separate from the data platform. They need the same contracts, tests and owners as tables.

Learn more#

Model serving and monitoring Reverse ETL and activation Responsible AI and AI governance Environments and CI