The Animation Is a Replay

July 16, 2026 · ~3,000 words · 6 figures and a quiz · reading this as an AI agent? agents.md is for you

Here is the rule this page exists to prove: run the simulation flat out, keep the event log, and treat every animation as a replay of that log. Get that separation right and the engine stops mattering - which I can demonstrate, because this page runs the same factory on four engines across six execution paths: a TypeScript kernel, the same Rust kernel in WebAssembly and native x86-64, SimScript, and SimPy on native CPython and CPython compiled to WebAssembly. Four paths execute in your browser, two behind this site's API. One schema out of all six runs, one scrubber replaying all six, one throughput they all agree on.

The idea is the one from last time, carried one layer further. Last time: the diagram is a projection of the model. This time, applied to motion: the animation is a projection of the event log. A simulation's clock is not your clock. It jumps event to event as fast as the CPU allows - 14 days in about 12 milliseconds - and if you chain the engine to the animation you get those sad simulations that trickle along in real time because someone wanted to watch. Keep the layers apart - model → engine → event log → presentation, nobody reaching past their neighbor - and one run replays at any speed, scrubs, diffs, and renders in any viewer that reads the schema.

I said there was no library. Here are four engines.

The whole bench hangs off one small contract. Every engine emits this; the stats, the hashes, and the replayer read nothing else:

{ "header": { "engine": "simpy-4.1.2", "seed": 42, "schema": 1, "params": { ... } },
  "events": [ { "t": 12.4, "type": "arrive", "id": 3 },
              { "t": 13.1, "type": "code_start", "id": 3 }, ... ] }

The model is the factory from last post, unchanged: arrivals every 25 minutes on average, three coding agents at 45 minutes a pass, CI at 10 minutes failing a quarter of the time, failures looping back as rework, one reviewer at 30 minutes. I can do the first answer on paper: review caps the system at 48 deploys/day. Fig. 2 makes that arithmetic - and the exact point where it stops being true - visible.

Two hundred SimPy replications put 14-day runs at 47.3 ± 1.9 deploys/day - mean plus or minus run-to-run standard deviation, with a 3σ band from 41.6 to 53.0. Paper prediction, replicated distribution - now run the engines into them.

Six rows, four hashes - two exact runtime pairs. The four engines draw randomness four different ways (mulberry32, PCG32, SimScript's seeded streams, the Mersenne Twister), so different engines disagree event by event while their statistics agree. Rust/native repeats Rust/WASM's 406362c5… hash across all 5,014 events. SimPy/server repeats SimPy/Pyodide's 3dab9d60… across all 5,276. That is the deployment boundary behaving twice. I expected Rust's native ln() to be the likelier place for a last-bit divergence; seed 42 did not give me one, so the honest claim is empirical and workload-specific, not a promise about every libm.

Two clocks

Look at the wall-ms column again: 14 simulated days, 10 to 200 milliseconds. The virtual clock owes your wristwatch nothing. That asymmetry is the entire case for the event log - you never slow a simulation down to watch it; you run it flat out, keep the log, and pick a replay speed after the fact. The first half of Fig. 4 will replay any row from Fig. 3. The second half lets salabim 26.0.8 run and draw a six-hour version of the factory with its own animation engine. Same process, two presentation architectures; the distinction is visible instead of theoretical.

Fig. 4 · Replay outside the engine, animation inside it log: ts-kernel · seed 42

▶ Play speed 1 min/s 1 h/s 1 day/s

sim clock: day 0, 00:00 wall clock this replay: 0.0 s ratio: –

0

waiting for review
at this instant

0

deployed
so far

0

events replayed
of 0

salabim's built-in renderer Render with salabim (~7.5 MB first use)

Nothing here is a JavaScript imitation.

coding queue3 agentsCI + rework1 reviewerdeployed

Click once to load Pyodide, Pillow, and salabim. The Python model will return its own animated WebP.

Opt-in: no salabim or Pillow bytes have loaded.

Top: hand-built SVG folds any Fig. 3 event log into queues, busy slots, and a deploy count; it has never heard of an engine. Bottom: genuine salabim 26.0.8 and Pillow run inside Pyodide, execute this six-hour factory model, and render 61 WebP frames at 10 fps. JavaScript displays the returned bytes and nothing else. The first path makes the renderer swappable; the second buys salabim's animation and monitoring vocabulary. Both are real, but they put the seam in different places.

You could write the kernel in an afternoon

The kernel under all of this is almost insultingly small: a priority queue ordered by (time, sequence), and a loop that pops. Here it is twice - the TypeScript running Fig. 3's inline row and the Rust that became the 47 KB wasm row. Press either toy button: five events, two at the same instant, popped in order - b1 beats b2 because of the sequence number, not luck. I have chased enough flaky behavior to promise you that tie-break is where deterministic engines are won and lost.

function makeKernel() {
  const heap = [];
  let seq = 0;
  const less = (a, b) =>
    a.t < b.t ||
    (a.t === b.t && a.seq < b.seq);
  return {
    schedule(t, event) {
      heap.push({ t, seq: seq++, event });
      // sift up
    },
    next() {
      // pop min by (t, seq), sift down
    }
  };
}
// The loop:
// while ((n = k.next()) && n.t < horizon)
//   handle(n.event) may k.schedule(...)

struct Scheduled<E> { t: f64, seq: u64, event: E }

impl<E> Ord for Scheduled<E> {
  fn cmp(&self, o: &Self) -> Ordering {
    o.t.total_cmp(&self.t)          // earliest first
     .then_with(|| o.seq.cmp(&self.seq))
  }
}

struct Kernel<E> {
  heap: BinaryHeap<Scheduled<E>>,
  seq: u64,
}
impl<E> Kernel<E> {
  fn schedule(&mut self, t: f64, event: E) {
    self.heap.push(Scheduled {
      t, seq: self.seq, event });
    self.seq += 1;
  }
  fn next(&mut self) -> Option<(f64, E)> {
    self.heap.pop().map(|s| (s.t, s.event))
  }
}

Which tool, when

My research notes rank the whole field, but the version worth keeping fits in a tree. And per last post's own rule, the picture is generated: a JSON decision model, serialized to DOT, drawn by the real dot compiled to WebAssembly. The generated source sits under the figure, where it belongs.

What I'll build

I built all four and ran both Rust and SimPy on both sides of HTTP so this choice could run on data instead of vibes. What the bench told me: my TypeScript kernel took the longest to trust, because the queue-and-rework logic is exactly where the subtle bugs live and every line of it was mine to get wrong. The Rust port was mechanical once the semantics existed - 47 KB in WASM, a persistent shared library on the server, fastest rows on the board. SimScript needed the least adapter code and brought the most opinions. SimPy read closest to the problem statement - the factory is 40 lines of Python that sound like the prose that specified it - and drags the whole scientific ecosystem behind it. So:

1. SimPy owns simulation semantics on the server for the software factory, behind a narrow SimulationRuntime interface (dispatch / step / runUntil / reset(seed)) so no framework becomes the domain model. Pyodide keeps the demo self-contained; the native API is the production-shaped path.
2. The model stays declarative - the same canonical JSON/YAML discipline as the last post; engines consume it, none of them owns it.
3. The event-log schema is the contract. Every run ships with seed and params in the header; every viewer, stat, and diff reads logs, never engine state.
4. The Rust core is the embedded engine, gated by conformance. The same crate now runs in the browser and behind the API; both paths must reproduce SimPy's statistics against these reference logs before either is trusted - the same conformance-corpus pattern that guards my CrMS charting engine across languages. Fig. 3 is that corpus's first six execution paths.
5. Replications before beliefs. Single runs demo; replicated distributions decide. The 200-run band in Fig. 3 came from SimPy in about 20 seconds of CPU.

The quiz at the door

Same rule as last time, which is Geoffrey Litt's rule for his agents before it was mine: no merge until you can pass the quiz. Five questions.

What's still open

Three things I have not solved. The number people will quote from this page is still a single row, even though the honest evidence is the replicated distribution behind it - replications-by-default is the fix, and none of the six buttons does it yet. Fig. 2 draws the analytical sweep, but the four-engine bench proves agreement only at p = 0.25; a conformance corpus worth the name runs every adapter across that sweep. And the native API is production-shaped, not production-finished: one 14-day run fits comfortably inside one HTTP request, while 200 replications should become a bounded background job that returns an artifact rather than holding a connection open.

Sources

For AI agents: agents.md carries the event-log schema, verified numbers, adapter rules, native API contract, checklist, and self-test without requiring a browser.