Model Versioning

Model versioning records which model artifact, code, configuration, data boundary, and runtime produced a result. It is the serving-time counterpart of run artifact and the public counterpart of a model card.

A useful model version is a tuple:

$$v=(\theta ,c,d,\varphi ,\psi ,e)$$

where $\theta$ is the checkpoint or weights, $c$ is code/config, $d$ is the data or benchmark boundary, $\varphi$ is preprocessing, $\psi$ is postprocessing, and $e$ is the environment.

What Must Travel Together

• Checkpoint or exported model artifact.
• Architecture and runtime configuration.
• Tokenizer, featurizer, graph builder, structure preparation, or normalization state.
• Postprocessing and validity checks.
• Intended task and inference contract.
• Evaluation evidence and limitations.
• Environment constraints: precision, library versions, hardware class, memory envelope, and context length when relevant.

Version Compatibility

Two versions may share weights but differ in preprocessing or runtime. They should still be treated as different deployed versions:

$$f_v(x)={\psi }_v(f_{{\theta }_v}({\varphi }_v(x)))$$

Changing ${\varphi }_v$ or ${\psi }_v$ can change outputs even when ${\theta }_v$ is unchanged.

Checks

• Can an output be traced back to one exact version?
• Are preprocessing and postprocessing versioned with the checkpoint?
• Is the model version distinct from a git commit when external artifacts are involved?
• Is the version linked to evaluation evidence without exposing private paths or unpublished metrics?
• Can deployment strategy roll back to the previous version?

Related

• Run artifact
• Model card
• Inference contract
• Deployment strategy
• Reproducibility
• Project artifact release