A logistics air-cargo team versions every training script, then cannot reproduce last month's delay model because the feature table and the saved weights were overwritten in place. What else needed a version history?
Select an answer to reveal the explanation.
Short Explanation
Versioning the script is like keeping the recipe while throwing away the flour and the finished loaf. You also need versions of the dataset and the trained model when those files get overwritten. Slides and a base image do not restore them.
Full Explanation
Reproducing a trained model takes the code, the data it was fit on, and the saved model itself. The air-cargo team versions only the scripts. When the feature table and the weights are overwritten in place, the code history can show how the training ran and still cannot restore the rows or the parameters that were replaced. Datasets and trained models need their own version history, with identifiers that the script can point to. Claiming that a source-code repository already captures tables and weight files confuses code history with data and artifact history. Briefing slides may record a metric, but a number on a slide is not the feature table and is not the weight file. A container base image pins dependencies for the runtime. Changing that image tag does not rewrite a feature table or a saved model, and it cannot recover files that were overwritten. Exam caveat: code, data, and model versions should be linked, so a later run can name which table and which weight file belonged with which script. Operational check: retrieve last month's feature table and weight file by version identifier and rerun the script until the delay scores match the archived run.