A controller fails during one particular sequence of targets, noise, delay, and bad sensing. The proposed fix is usually tried on a new sequence. That is evidence about the fix, but not about the incident that justified it.
I wanted a smaller and stricter question: given the exact world the controller saw, would changing only the controller have changed the outcome?
Preserve the incident before touching the fix.
A useful recording contains inputs, not recollections. In refly, time advances in fixed one-millisecond ticks. Targets, noise values, sensor glitches, command-drop windows, and latency changes are ordered on a JSON-lines tape. A replay does not redraw noise from the same seed; it consumes the values that the original run consumed.
The distinction matters. A seed describes how one implementation might regenerate an input. A recorded value describes the input itself.
Bit-exact is a refusal rule.
The runtime hashes the plant state every 250 ticks using the exact floating-point bit patterns. During replay, each checkpoint is recomputed. The first mismatch stops the run instead of being rounded into an acceptable tolerance.
Replay is not “the path looks close.” It is “this state history agrees, or the comparison has no standing.”
The browser demonstration records 2,084 tape entries over 20 seconds and verifies 81 state checkpoints. Its record and replay panels show the same final 64-bit digest and the same sampled joint trace. That claim is deliberately bounded: same binary, same target, same IEEE-754 operations.
Then change one thing.
The counterfactual run keeps the tape and plant fixed, then replaces the controller tuning. The incident controller uses aggressive gain with almost no damping. The candidate lowers the gain, adds damping, and tightens the joint-rate command limit.
Under the recorded J3 sensor glitch, command drop, and 40-tick latency, worst tool-centre error falls from 196.9 mm to 60.1 mm. The proposed controller bounds that incident 3.3 times tighter. The result does not say the candidate is universally better; it says exactly which past failure it handles better, under exactly which model.
The page should not invent the result.
The live page loads the runtime as WebAssembly and calls its record, replay, and counterfactual APIs. Rust returns the tape, exact digests, metrics, and sampled robot state. JavaScript moves three copies of the public GLUON arm and exposes a synchronized scrubber. There is no second browser simulation that merely resembles the tested one.
This separation keeps presentation downstream of evidence. The visual can fail to load without changing a digest; changing a renderer cannot improve the controller.
Stop where the model stops.
The plant models first-order joint-velocity tracking with position and velocity limits. It does not model contacts, structural flexibility, motor current, firmware scheduling, fieldbus behaviour, or a physical safety case. The runtime is one process and the example is simulation only.
Those limits do not make the experiment empty. They make its claim inspectable: deterministic incident capture, enforced replay agreement, and a same-tape comparison between two controller configurations.
A fresh run can show that a fix works somewhere. Re-flying the recorded incident shows whether it answers the failure that asked for it.