Artifact and Code Tracking
The proof behind the scoreboard
Metrics promise a result; artifacts deliver the proof. Tracking stores the model binaries, plots and data previews a run produced, linked to the code commit that created them.
What you will learn
- Log model, plots and reports as run artifacts
- Link each artifact to the exact code commit
- Use artifact lineage to rebuild or replay any run
What is this?
Artifact and code tracking stores the files a run produced — serialized models, evaluation plots, feature importance, configs — in an artifact store, and records the git commit plus environment so the byte-level recipe is recoverable. Metrics tell you which run won; artifacts let you deploy and audit it.
Why do you need it?
- A metric is a summary; auditors, serving and rollback need the actual bytes.
- Plots and reports become reviewable evidence without re-running the model.
- Linking code commit to artifact makes 'what shipped' answerable from one record.
- Replayability: a data scientist can rebuild any past run from tracked code and artifacts.
Mental model
A photo finishing lab
Artifact tracking
The lab number on the print tells the technician which negative, what paper, what chemicals produced that photo. Artifacts + code hash are the negative and the chemistry; the print is the served model.
How it works
- During a run, the code calls mlflow.log_artifact (or log_model) to upload files into the artifact store.
- MLflow auto-snapshots git commit and environment for each run when code is attached to a repo.
- Artifact URIs become part of the run record; the registry references them later for serving.
- Content-addressed or versioned storage keeps files immutable.
- Serving and review tools pull artifacts by URI with the run ID as the key.
Artifact lineage from run to deployment.
Examples
Log everything a reviewer needs
with mlflow.start_run(): mlflow.sklearn.log_model(model, "model") # the deployable mlflow.log_artifact("plots/pr_curve.png") # evidence mlflow.log_artifact("reports/eval.html") # report mlflow.log_artifact("confusion_matrix.png") # commit + env are snapshotted automatically in a git repoModel, plots and report all ride the same run so one URI gives you everything for review, audit and serving.
In production
- Serving pulls the artifact URI from the winning run, so production bytes == reviewed bytes.
- A model review board opens the run's plots and reports without re-running training.
- A rollback loads the archived run's artifact because the old binary is still addressable.
Best practices
- Attach the deployable model to every run that logs a relevant metric.
- Name artifacts consistently so automation can find them ('model', 'eval_report').
- Store plots (PR curve, confusion matrix) — they are the reviewable proof.
- Version the artifact store and apply retention policies.
Common mistakes
- Storing artifacts on the training machine's scratch disk.
- Logging the model once globally, not per run — mixing bytes across runs.
- Keeping only final metrics; when auditors ask for proof the plots are gone.
- Unversioned artifact store so 'model_final.pkl' gets overwritten.
Debugging tips
- Deployment can't find the artifact? Confirm the artifact URI is absolute and the store is reachable.
- Model loads but predictions are weird? Corrupted or overwritten artifact — verify content hash against the run.
- Audit request pending? Pull the run's commit + artifact URIs to reconstruct the recipe.
Interview checkpoint
Hands-on lab
- Initialize a git repo so the run records its commit
- Log a model and a report file as artifacts
- Re-download the artifact bytes from the run record
Track Code and Artifacts Together
25 min · intermediate
Quick quiz
Attaching the git commit to a run is enough to reproduce the model byte-for-byte.
A model review needs the PR curve and the exact binary that scored it. Where should both live?