Using Determinism and Replay

Overview

What happened is recoverable as a fact, or it is not. There is no "mostly recoverable."

This pack treats replay — the ability to re-run a system from recorded inputs and observe identical behaviour — as a property of architecture, not a property of effort. A system either has a named determinism class, governed seeds, isolated RNGs, a snapshot strategy that matches its tick rate, a divergence-detection protocol that points at the first differing operation, and replay infrastructure that distinguishes read-only investigation from branching counterfactuals — or it has a stack of fragile assumptions that survive only as long as nobody touches them.

This is the architectural counterpart to verification-of-an-existing-simulation:

• yzmir-simulation-foundations:check-determinism answers does this specific simulation hold under repeated runs? — a verification command that scans for known violation patterns (unseeded RNGs, dict iteration, wall-clock leaks).
• axiom-determinism-and-replay (this pack) answers how do I design a system whose determinism is a load-bearing property? — seed-propagation rules, RNG ownership, snapshot cadence, divergence localisation protocol, replay-loop architecture, the distinction between "logically equivalent" and "bit-exact" recovery.
• The two cross-link. If check-determinism finds violations in a system that already shipped without this pack, this pack tells you what to design into the next version. If you are designing a new substrate, run this pack first; check-determinism then becomes a regression check.

When to Use

Use this pack when: