Experiment Run: The Immutable Training Receipt

WHY IT EXISTS: Before experiment tracking, machine learning work was reproduced by hand. A researcher would tweak a learning rate, run training overnight, and record the accuracy on a sticky note. Two weeks later no one could remember which code commit, data slice, or random seed produced the best model. Experiment runs exist to eliminate that amnesia by making every training execution a self-documenting, queryable record.

THE MENTAL MODEL: Think of an experiment run as a receipt for a specific training job. Just as a grocery receipt lists what you bought, how much you paid, and which store you visited, a run records what you changed, what happened during training, and what files were produced. The receipt is immutable once printed; you do not go back and edit it to show a lower loss. You simply start a new run.

HOW IT WORKS: When you initialize a run, the tracking client captures the git commit hash, the command used to launch the script, environment variables, and dependency versions. During training, you explicitly log scalars like loss and accuracy, plus hyperparameters such as batch size and learning rate. At the end, the run stores artifacts including model weights, evaluation plots, and dataset pointers. Most platforms assign a unique run ID and organize runs under an experiment name so you can filter and sort them in a web dashboard.

WHEN TO USE IT: Use a run every time you execute a training script that you might need to compare, reproduce, or debug later. This includes hyperparameter sweeps, architecture ablations, retraining pipelines on new data, and failed jobs that you need to diagnose. If the result matters to anyone besides the current terminal session, it deserves a run.

WHEN NOT TO USE IT: Do not use a run for lightweight inference on a model that is already in production; that is usually the domain of model monitoring or prediction logging, not experiment tracking. Also avoid creating a run for every step inside a single training loop, such as logging each mini-batch as its own run, because that destroys the granularity that makes runs useful and explodes storage costs.

ONE CANONICAL EXAMPLE: A computer vision team is tuning a ResNet classifier. Engineer A starts run 7a3f with learning rate 0.01 and batch size 32, logging validation accuracy every epoch. Engineer B starts run 9c2d with learning rate 0.001 and batch size 64. After both jobs finish, the team opens the experiment dashboard, sees that 7a3f plateaued at 89 percent accuracy while 9c2d reached 94 percent, and clicks into 9c2d to download the exact checkpoint and confirm it used the same data preprocessing code. Without the runs, they would be comparing spreadsheets and guessing.