The Reproducibility Toolchain
A reproducibility toolchain pins code versions, environments, inputs, and randomness so a simulation result can be regenerated exactly by anyone later.
Reproducible by construction
A simulation result is scientifically meaningful only if it can be reproduced. The reproducibility toolchain is the set of practices and tools that let a result be regenerated exactly: version control for code, pinned dependency environments, recorded input decks, captured random seeds, and archived outputs with checksums. Reproducibility is not a nice-to-have; it is what separates a claim from an assertion.
The goal is that a third party, given the archive, obtains the same numbers, either bit-for-bit or within a stated tolerance for results that depend on floating-point ordering or parallel nondeterminism.
Pinning the environment
Results depend on compiler versions, library versions, and hardware. Containers or environment specifications freeze this stack so the same binaries can be rebuilt. Where exact bit-reproduction is impossible across machines, a two-tier standard is used: byte-identical on the reference platform, and agreement within tolerance on others.
Seeds and determinism
Monte Carlo and particle codes depend on random-number streams; recording the seeds makes stochastic runs repeatable. Parallel reductions can reorder floating-point sums, so reproducibility policies specify deterministic reduction modes or accept a documented tolerance.
Design relevance
The simulation evidence for the Hyperion breeder and the Aegis and MetroVolt burner is credible only because each key result is reproducible from an archived input deck and pinned environment. This discipline underpins the honest position that the machines are validated in simulation, with hardware net-gain claims deferred until FOAK first tritium around 2030.
- Version control, pinned environments, archived inputs
- Recorded seeds for stochastic codes
- Two-tier byte-vs-tolerance reproduction standard
- Turns a claim into a checkable result