Why architecture matters here
Untracked experiments waste time. A team runs the "same" experiment three times because the first two weren't logged. A model can't be reproduced because the training data version isn't recorded. A promising result vanishes because the notebook was cleared.
The architecture matters because tracking is a substrate — it enables all the other ML platform capabilities. Registry needs tracked runs; monitoring needs registry entries; governance needs lineage.
With the pieces in place, ML becomes engineering rather than art.
The architecture: every piece explained
The top strip is the run pipeline. Experiment is code + config + data. Tracker — MLflow, W&B — records run metadata, hyperparameters, and metrics. Data version — DVC or Iceberg snapshot — pins the exact input. Model registry stores artifacts with lineage back to the training run.
The middle row is science. Reproducibility requires random seed, environment (containers, dep versions), and hardware specification. Comparison UI shows runs side-by-side to diagnose changes. Automation covers hyperparameter sweeps and AutoML. Governance adds approval workflow before models can leave dev.
The lower rows are integration and ops. Notebook + IDE integration logs during development. Cost + carbon accounting per run helps prioritize expensive experiments. Ops sets retention, archival, and access control per project.
End-to-end flow
End-to-end: a research engineer runs a fine-tuning experiment. MLflow captures hyperparameters, code commit, container image, seed, and training metrics. DVC records the training data version. Metrics stream to the tracker; the run appears in the comparison UI next to yesterday's run. Result is 1.5% better; the engineer registers the model in the registry with lineage. A sweep is triggered to explore three learning rates; the best is promoted for downstream evaluation. Cost dashboard shows this experiment used $84 of GPU. Governance approves promotion to staging.