Checkpoints and forking
Run to day sixty, then ask two questions of the same market, with everything before the fork identical rather than statistically similar.
mark = tf.Checkpoint.of(engine, universe=universe, seed=42) calm, hiked = mark.branch(2) # two engines, identical up to day 60 hiked.pin_macro(corporate_bond_yield=0.09) # calm and hiked now diverge only from here
Two mechanisms for different jobs
| Cost | Survives the process | |
|---|---|---|
| tf.branch(engine, 2, ...) | < 1 ms | no |
| Checkpoint.resume() | 2.7 s | yes |
branch copies engine state, every column plus the generator position, in constant time. Checkpoint replays the order log, three orders of magnitude slower, and is what you want when the fork has to outlive the process. Cite the log in a published result, since that is what someone else can re-run. Both figures are for a sixty-day, forty-instrument run; read them as an order of magnitude, since replay cost scales with the order log.
Why it refuses instead of loading wrong
A Checkpoint records the universe fingerprint and refuses to load against a roster that changed, because restoring across two same-named universes gives right prices and wrong fair values: plausible everywhere visible, wrong in the one place that drives everything.
What restore_state cannot catch
The low-level restore_state holds no fundamentals, so it can only verify roster order, size, and the model fingerprint the snapshot was taken under. Restoring a pt-v14 snapshot into a pt-v1 engine raises a ValidationError naming both. What it cannot see is a roster whose tickers still match but whose fundamentals do not - prefer branch and Checkpoint, which check that.