A model repository stores each model instance produced during iterative development and links it to the information needed to evaluate, select, test, and use it. It is infrastructure to commission and adopt before intensive modeling begins, not a filing step to leave until deployment. section 5.5 section 5.6
For each model iteration, record:
- A unique identity linked to the model binary or specification used in testing and production. section 5.5
- The algorithm and its version, architecture, hyperparameters, features, and links to the training data or pipeline versions. section 5.5 section 7.4.2
- Development evaluation results, qualification test results, and the technical artifacts used to build the model. section 5.5
- The identities and status of pipelines supplying training, validation, and test data, with relevant pipeline test and monitoring information. section 5.5
Keep experiment tracking connected to the repository. A tracker records run parameters and performance; repository identifiers tie those outcomes to the actual model files and their supporting assets. Preserving that trail makes later investigations into stability, failures, and blind spots possible and gives model choices an evidence base. section 7.4.2 section 5.5
Delivery tickets
Before model development, commission a repository, identify the artifacts ML pipelines will use, and confirm where the repository can be hosted. During modeling, use it alongside an experiment tracker. Register foundation models and check that the intended version is used across pipelines and environments. section 2.7.1 section 5.5 section 5.5.1 section 7.4
Figure 7.8 The files stored in a model repository that we can use to understand which model is stored, how it was made, how it relates to the experiment tracking information, and to get it up and running again.
The file layout illustrates how a stored model connects to its construction details and experiment results, so the team can identify and run it again. section 7.4.2
