Three mechanisms
Because the task stream is seeded, all three mechanisms face the exact same demand at the exact same moments. Any difference in the results comes from coordination alone.
What gets measured
| METRIC | MEANING |
|---|---|
| Throughput | Tasks completed as a share of tasks created. |
| Energy cost / value | Credits spent on electricity per credit of value produced. Lower is more disciplined. |
| Fairness | 100 × (1 − wealth Gini). How evenly the earnings spread across the fleet. |
| Resilience | Completion rate during and after the charger outage, relative to before it. |
| Avg task price | The average winning bid. What labor cost under this mechanism. |
| Failed / expired | Deadline misses and abandonments; tasks that never found a taker. |
| Value produced | Total credits paid out for completed work. |
The outage test
With the charging crisis enabled, a charger fails partway through every run. Resilience compares the fleet's completion rate before the 150 second mark against everything after it, so a mechanism that shrugs off the outage scores near 100% and one that collapses into a charging queue scores much lower. This is where the mechanisms separate most sharply: the central scheduler has perfect knowledge but a fixed contract price, while the auction reprices the shock into every bid within seconds.
No mechanism wins everything. Central scheduling is hard to beat on raw throughput when nothing goes wrong, and the queue's naive fairness is real. The interesting output is the tradeoff surface. Change the sliders and the scarcity, and watch where each mechanism cracks.
How it runs
The lab runs the engine headless: no rendering, no interpolation, just step() in a tight loop inside a Web Worker. A few milliseconds of wall time buys a couple of sim-minutes of warehouse time, so a 3 × 10 minute comparison returns in about a second, and the live floor keeps ticking undisturbed while it works.