01 / record
Faulted incident
Waiting for WASM
- Max error
- —
- RMS error
- —
- Final digest
—
Robotics / deterministic replay
Re-fly the incident. Then re-fly it with the fix.
This browser runs the real Rust runtime in WebAssembly: record a faulted 20-second GLUON tracking run, verify every replay checkpoint, then change only the controller and run the same tape again.
— tape records
— state checkpoints
1 kHz fixed-step time
— browser compute
Live evidence
One tape. Three runs.
Loading the runtime and arm meshes…
02 / replay
Bit-exact replay
Waiting for checkpoints
- Max error
- —
- RMS error
- —
- Final digest
—
03 / counterfactual
Modified controller
Same tape · new gains
- Max error
- —
- RMS error
- —
- Final digest
—
6–8 s J3 glitch
10–10.8 s drop
13–20 s latency
Input path: nominal
Evidence summary
Waiting for the runtime.
Inspect the recorded JSONL tape
The excerpt below is decoded from the WASM module's tape buffer, not copied into the page. Targets and all 81 digest lines remain in the downloaded file.
waiting for tape…The browser is an evidence surface.
It does not contain a JavaScript version of the experiment. Rust owns the simulation, tape, digests, replay check, and counterfactual; the page renders the returned state.
01Record
Every target, drawn noise value, sensor glitch, drop window, and latency change lands on an ordered tape. The core never reads wall-clock time.
02Replay
State is hashed over exact floating-point bits every 250 ticks. A mismatch refuses the replay; this run verifies all checkpoints and the full sampled state trace.
03Counterfactual
The tape stays fixed. Only proportional gain, damping, and command limit change, so the difference belongs to the proposed controller rather than a fresh incident.
04Scope
This is a same-binary, same-target determinism claim over a kinematic-level plant. It is sim-only, one process, and not evidence about contact dynamics or physical safety.
Read the engineering note Runtime source ↗ Kinematics source ↗