Versioning Models and Derived Artifacts
Model versioning ties a trained or fitted model to the exact data, code, and parameters that produced it, so results can be reproduced and audited.
A model is a function of its inputs
Any fitted model, whether a machine-learning network or a physics surrogate, is the product of specific training data, code, hyperparameters, and a random seed. Change any of these and the model changes. Model versioning records the full recipe so a model can be regenerated, compared, and rolled back with confidence.
What a version must capture
- The exact training and validation datasets, by content hash or version id.
- The code and library versions used to train.
- Hyperparameters, configuration, and random seeds.
- The resulting model artifact, itself content-addressed.
- Evaluation metrics measured on a fixed test set.
The reproducibility triangle
A reproducible result stands on three legs: versioned data, versioned code, and a recorded environment. A model version links all three. Missing any leg breaks reproduction: the same code on different data, or the same data with a different library version, can yield a different model.
Lineage and registries
A model registry catalogs model versions with their metadata, metrics, and status. Combined with provenance, it answers which data trained a model, which experiments produced it, and what changed between versions. This is essential when a model informs a design decision that must later be defended.
Determinism
True reproducibility requires controlling nondeterminism: fixed seeds, and awareness that some parallel operations produce results that vary slightly between runs. Where exact bit-for-bit reproduction is not achievable, the tolerance must be stated and results checked within it. For scientific surrogate models supporting a fusion program, the discipline is the same as for the deposited datasets: fixed inputs, recorded environment, and verifiable outputs.