Reproducibility

Maturity: verified

Reproducibility requires recording the inputs, identities, lineage, and runtime choices needed to understand how a result was produced and what can be repeated.

Reproducibility scope

The current bounded path provides strong identity and lineage evidence. It does not promise bit-identical reruns or exact general-training resume.

Recorded identities

The application records:

  • full resolved-config and resume-compatible training-contract hashes;

  • logical run ID and distinct attempt ID;

  • canonical dataset name, snapshot ID, split, and split fingerprint;

  • selected model, objective, and optimizer implementation keys;

  • checkpoint parent URI and producing attempt;

  • optional source, container, provider-job, and launch-config identities;

  • per-artifact SHA-256 hashes and byte counts in the terminal manifest.

Determinism controls

The bounded runner calls torch.manual_seed(config.seed) before model construction, uses an ordered canonical split, sets shuffle=False, and restarts the loader at its beginning if more bounded steps are requested than one pass supplies.

Reproducibility limitations

The current contract does not persist random-number-generator state, loader or sampler position, scheduler or mixed-precision state, worker seed derivation, backend determinism settings, package lock identity in the attempt manifest, or distributed rank state. A resume restores model and optimizer state at a known completed step but begins a fresh loader iterator.

Treat the accepted one-step and resume-to-step-two evidence as an integration proof for the bounded application. The current application does not support broader train/validation or exact-resume claims.

See Also