Replay & What-If Simulation
Recorded machine inputs are replayed against new procedure, twin, or policy versions to test changes safely before they touch hardware.
Test on the past, safely
The recorded event streams of past breeder shots and burner runs are a corpus of real (or simulated) scenarios. What-if replay feeds these historical inputs into a modified orchestration, a new procedure version, an updated twin, a tightened envelope, and observes what it would have done. Emitted commands are captured, never sent, so the machine is untouched. This is how orchestration changes are validated before deployment.
Two replay modes
# 1. FIDELITY replay: same versions -> must reproduce recorded commands (regression)
assert replay(shot, v_current).commands == recorded_commands(shot)
# 2. WHAT-IF replay: new version -> compare behavior, commands NOT sent
new = replay(shot, v_candidate)
diff = compare(new.commands, recorded_commands(shot))
report(diff) # would the candidate have mitigated sooner? stayed in envelope?
Questions it answers
- Would an updated twin have flagged this breeder disruption earlier (see disruption mitigation)?
- Does a tightened envelope reject any historically-approved command (a possible safety improvement or a false-positive regression)?
- Does a new burner plug-supervision policy avoid a past near-loss of confinement?
Closed loop with the twin
What-if replay can drive the digital twin forward under the candidate's commands to estimate outcomes the historical record does not contain, a full closed-loop simulation seeded by real inputs. This is central to developing orchestration for machines that are not built: the breeder and burner are design-and-simulation studies, so simulated and replayed scenarios are the only proving ground before FOAK.
Regression gate on deploy
Fidelity replay is a mandatory gate: any orchestration change must reproduce approved past decisions unless the diff is intended and reviewed. This turns the lineage record into an executable test suite for the control plane.