Version Control for Analyses and Documents

Code, inputs, and documents live under version control so every result can be tied to the exact state that produced it.

A recoverable history of everything

Version control keeps a complete, recoverable history of the work: who changed what, when, and why. Applied to code, inputs, and documents alike, it means any published result can be tied to the exact state that produced it, and any change can be examined, reverted, or reproduced. It is the mechanical backbone of traceability and change control.

What we keep under version control

• Analysis code and the tests that guard it.
• Input files, configurations, and pinned environment manifests.
• Design documents and the frozen design point.
• The change history, with reasons attached to each change.

Ties to the rest of the standard

Version control is what makes the frozen-design methodology enforceable in practice. A freeze is a tagged, recoverable state; a change is a reviewed commit; a regression test runs against a known version. Without a version history, 'the number we froze last year' is a memory; with one, it is a state anyone can check out and re-run exactly.

It also underwrites reproducibility across the long timeline of a fusion program. Between the Q2 2027 construction start and FOAK first tritium around 2030 and the NOAK and BOAK machines that follow, the analysis will evolve. Version control is how we keep every stage recoverable, so a later measurement can be compared against precisely the design that predicted it. Kept comprehensively, the version history is the substrate every other standard writes to: the freeze is a tag in it, the change log is its record, and the reproducible result is a state anyone can check out and run again.