Experiment Tracking and Metadata

Every training run, sweep, and evaluation is logged with its config, metrics, and artifacts, so the history of how a model came to be is fully queryable.

The lab notebook for models

Model development generates thousands of runs; without systematic tracking, the knowledge of what was tried and what worked evaporates. Kronos logs every run — training, HPO trial, evaluation, backtest — with its configuration, metrics, environment, and output artifacts into a central tracking store. This is the queryable lab notebook behind every model in the registry.

Tracking is distinct from the registry: the registry holds artifacts eligible to act on a machine; tracking holds the full experimental history, including the failures. A promoted model links back to the exact tracked run that produced it, and that run links to its HPO campaign, its dataset, and its code. The chain is unbroken from a deployed controller to the first exploratory experiment.

Tracked per run

• Config and hyperparameters, seed, code commit, container digest
• Metrics over training: loss, validation error, calibration
• Dataset and feature versions consumed
• Output artifacts and their hashes
• Links to parent campaign and to registry entry if promoted

with tracker.run(project='breeder/equilibrium') as run:
    run.log_params(cfg); run.log_data(dataset.id, features='v7')
    for epoch in range(E):
        run.log_metrics(epoch, train_loss, val_rmse, val_ece)
    run.log_artifact(model, hash=sha256(model))
    run.link(parent_campaign='hpo:2029Q3-eqsurr')

Tracking retains failed and abandoned runs deliberately, not only successes, because the record of what did not work is what stops a team from re-running dead ends and is often the fastest route to diagnosing a new failure. Runs are immutable once closed, so the history cannot be rewritten after the fact.

Experiment tracking is the substrate for meta-analysis: which architectures generalize, which features carry weight, where models systematically fail. It connects to model lineage upstream and to model cards downstream, since a model card is largely a human-readable summary of the tracked run that produced the model.