Versioning a trained model: the artefact together with the code, data, parameters and environment that produced it

Goal

Answer, for any prediction served in production, which model made it, from which code, data and settings it was built, how it scored, and how to roll back to the previous one. Dataset versioning itself is covered in the article on provenance for small datasets; this protocol covers the model side and its links.

Prerequisites

Code in version control, a dataset with a stable identifier (checksum, DVC pointer or snapshot name), a fixed test split, and a place to store artefacts with metadata: a registry such as MLflow's Model Registry, which its documentation describes as a centralised store with lineage to the run that produced a model, versioning and aliasing, or a disciplined object-storage layout with a manifest file.

Steps

1. Train only from a committed state; refuse to register a model built from a dirty working tree. Record the commit hash.
2. Record the dataset identifier, the split identifier and the full hyperparameter set as the run's parameters.
3. Record the exact dependency versions of the training environment. The scikit-learn persistence guide notes that loading an estimator under a different scikit-learn version raises an InconsistentVersionWarning and that a model trained with older versions of the library and its dependencies may need retraining in an updated environment, so the environment is part of the version.
4. Evaluate on the fixed test split and store the metrics with the run; store the input and output schema (a signature) so that serving code can validate requests.
5. Serialise the model in a format chosen for the serving context; the guide's comparison lists pickle-based formats as executing arbitrary code on load and ONNX or skops as safer alternatives. Store the artefact under an immutable version number.
6. Promote by alias (champion, challenger), never by overwriting the file behind an existing version; serving reads the alias, rollback is an alias change.
7. Log the model version with every prediction so that production behaviour can be joined back to the registry.

Expected result

Every served prediction resolves to a version, every version to a commit, a dataset, parameters, metrics and an environment; rollback takes one alias change.

Limits and test basis

The protocol adds bookkeeping to every training run and needs storage for artefacts. It does not make training deterministic (see reproducibility of an ML experiment). No timing or outcome of following it is claimed.