Which of these is **not** in scope for MLflow?

Computing PSI drift on production traffic

Logging hyper-parameters of a training run

Computing PSI drift on production traffic

Promoting a model from Staging to Production

Packaging a sklearn pipeline as a pyfunc

What MLflow Is (and Isn't) — Semantic Web Academy

The four pillars

MLflow's mission, in one sentence

Keep the artefacts and metadata of every ML experiment together > for as long as you need them.

It is built around four pillars:

Pillar	What it solves
Tracking	Records params, metrics, artifacts, code version, environment per run.
Projects	Packages code + environment so anyone can `mlflow run .` and get the same result.
Models	Standard packaging (a flavor) so the same model can be loaded by sklearn, PyTorch, or as a generic `pyfunc`.
Registry	A versioned catalog: `None → Staging → Production → Archived`, with aliases, lineage and audit.

What MLflow is not:

not a feature store (use Feast/Tecton),
not an orchestrator (use Airflow/Prefect/Dagster),
not a monitoring tool (use Evidently/Arize/WhyLabs),
not opinionated about the model framework — that's the point.

Analogy

MLflow is the postal service of your ML stack. It does not manufacture the parcel (your model), nor does it ring the doorbell (serving), but everything that moves between teams passes through it: weighed, labelled, addressed and tracked.

Visualization

LayoutLabelsClick a node to focus its neighbourhood · drag to pan · scroll to zoom

input
tracking
models
registry
deploy

The lifecycle MLflow stitches together: training writes runs, runs produce models, models live in the registry, and the registry is what serving and downstream jobs read from.

Reading in progress · 0 of 3 activities done