Data Provenance and Versioning
Every result must know where its data came from and which version it used, or reproducibility and trust both break down.
Why provenance matters
A result is a claim about the world, and a claim is only as good as the data behind it. Provenance records where each piece of data came from, how it was processed, and which version was used. Without it, a result cannot be reproduced, audited, or trusted when the underlying data later changes.
What is tracked
- The raw source of each dataset and when it was captured.
- Every processing step applied to it, with the code version.
- Which version of the data fed which result.
- Who or what produced each artifact and when.
Versioning data, not just code
Code versioning is standard practice, but data changes too: a recalibration, a corrected input, a new nuclear-data release. Versioning data means a result can always be tied to the exact data it used, so a later data change does not silently invalidate old conclusions. It complements continuous integration for code.
Enabling reproduction
Provenance and versioning are what make the runbooks executable: a runbook can name the exact data version to fetch. They are also what let automated verification detect when a result should be re-run because its inputs changed.
For Kronos
The frozen numbers behind the Hyperion breeder and the burner, such as the tritium breeding ratio of 1.8, are tied through provenance to the data and code that produced them, so any of them can be traced to its source for the licensing evidence package.
Auditability
When a reviewer asks where a number came from, provenance provides a complete answer, which is what turns a claim into evidence.