Exhibit — replays runs recorded against the live system. Actions here do not execute; the working console runs locally via node app/server.js. Runbook

00Market intelligence — the demand model

Every routing decision is arithmetic over this data. It arrived from an earlier scraping pipeline that failed silently on prices — the red bars are the hole that nothing was watching.

restaurants—
branches—
dishes—
ingredients—
price null-rate—

Most-demanded ingredients, exploded from dish recipes

01Run the factory

Two entry points, one pipeline. A human brief, or a signal. Stages stream live — each one is a span under a single factory.run trace and an entity in Port.


  

02Approve the rehearsal

Generated from the dispatch the factory just produced — this donor branch, this crate, this expiry window. You approve what the robot will do, not a JSON diff.

Run the factory to generate a dispatch.

02bRobot execution

The approved dispatch is executed physically here. The rehearsal above is the plan; this is the back-of-house it runs in — the robot drives to the donor branch, picks the near-expiry crate, and carries it through the service pass.

Open full screen ↗ Controls: 1 branches · 2 warehouse · 3 follow the robot · WASD fly · R restart
Click Load simulation — it is a few MB and plays itself in ~45s.

03Data contract & self-repair

The supplier feed is what routing depends on. Change the source page and the contract catches it; Bright Data repairs the collector behind a human gate.

supplier null-rate—
rows—
contract—

Either redesign changes the source page for real, via a commit. GitHub Pages takes ~90s to publish. Re-check the feed after that. The pill above is the truth — the collector adapts each time it is repaired, so neither markup is permanently "broken".