Standing in for the WebSocket server. Intents stamp for the next clearing, so a change made now lands one beat later.
Three drawings. The first is the loop as designed, the second is the structural problem the simulation exposed on its first run, the third is the trap the whole design is built around. Everything here is drawn from the rules as implemented, not from the prose.
This is the point of building the watchable milestone before the playable one. Five hundred bot matches ran before any human saw the game, and they found three things that a polite friend playing one match would not have named — plus one bug of mine against the spec. Nothing below has been tuned away.
Your sell price is a multiple of the street price. The street price is the mean of sell prices. Your bid is a multiple of the auction price. The auction price is the marginal bid. Both loops are closed, so they drift to whatever their multiplier implies: down to the cost floor if the average multiplier is under 1, up until something caps it if over.
Measured on seed 12345: the street price fell 100¢ → 26¢ by beat 30 and the economy died, or — after flooring bots at marginal cost — rose 100¢ → 452¢ by beat 40 and locked. Same cause, opposite direction.
This is not a tuning error. There is no value of any existing constant that fixes it, because the system has no external reference at all. The proposed v1 adds two: buyers respond to the street price, and bids derive from what a carton actually sells for.
Total starting capacity for a duel is 16; total demand is 12. Capacity already exceeds every buyer in the market, so a unit of added capacity can never be sold and contributes nothing but upkeep. One of the four controls does nothing.
This follows directly from the relationship the balance doc names as load-bearing — capacity > supply > demand, "overcapacity chasing scarce customers". That relationship is what kills the control. Price competition does not actually require overcapacity; it requires contested share, which loyalty already supplies. v1 inverts it to capacity < supply < demand.
The design doc predicted this failure mode by name in
systems/production.md and called it the likelier of the two. It was right.
Across 480 recorded duels the eventual winner takes a lead they never lose 23% of the way through the match, and the mean final margin is 72% of the winner's valuation. ADR-0008 rejected rubber-banding on the bet that a trailing player could rationally take risks a leader cannot. At tuning-v0 that bet is not paying.
The ADR names the response order before touching the decision itself: raise shock magnitude so the world can reverse a lead, then steepen the leader's structural fragility. Neither has been tried yet — and both are downstream of Finding 1, since a match whose prices have already drifted to a corner cannot demonstrate much of anything.
loyalty.md says satisfaction gains from serving demand well. I
implemented only two non-positive terms, so the sole way to gain was pricing below the street —
and since the street price is the mean of prices, at most one brand can be below it.
Total loyalty was mathematically non-increasing, so every match ended with everyone on the
floor.
Fixed by adding an explicit service bonus: filling every buyer is worth +8 sentiment per beat. It is the only non-zero-sum source of loyalty in the game — everyone can serve well at once, but not everyone can be cheaper than average. Adding it changed the dominant strategy from Tracker to Premium, which is a useful reminder of how much this rests on untested constants.
| Strategy | Win rate | Reads as |
|---|---|---|
| Premium | 99.6% | Dominant. Margin funds the inventory buffer that keeps loyalty growing. |
| Tracker | 63.3% | The baseline participant. |
| Stockpiler | 47.3% | Rumour bets roughly break even at 75% reliability. |
| Passive | 21.5% | Correctly punished for not reacting. |
| Undercutter | 18.3% | Walks into the stockout trap, as designed. |
A strategy above ~60% against the field is a design finding, not a tuning task. Premium at 99.6% means the price axis currently has a right answer, which is the opposite of what a game about pricing wants.
| Property | State |
|---|---|
| Same seed reproduces a byte-identical match | verified · 38 checks pass |
| No floats anywhere in game state | verified by walking the state tree |
No Math.random, Date.now, Math.pow in the sim | verified by source scan |
| Rival inventory, bids and sentiment never reach a rival | verified on the filtered view |
| Rumours are truthful 75% of the time | verified · 0.749 over 2,272 rumours |
| Eight ticks produce exactly one beat of capacity | verified · integer remainder carried |
| Cash never goes negative; no player is eliminated | verified across seeds |
| The core loop is fun | unknown — a viewer cannot answer this |
| A human can keep up with four controls at a 2s beat | unknown — needs GAM-016 / GAM-017 |
Watching is not playing. At 0.5× with god view and a beat-by-beat explainer, this game looks far more comprehensible than it will at 1× with four controls and two seconds a decision. This bench answers whether the economy works. It structurally cannot answer whether the game is any good, and no amount of polish here will change that.