Tuning Round 2 — The Two Levers
Date: 2026-09-15
Type: Solver, no playtest
Question: MAIL-SPIKE.md proposed two levers to remove mail's dominant
purchase order — make it situational, or give it a different lead time. Does
either work?
Answer: Neither, as specified. But the failure is informative and
yields a design rule worth more than a tuned number.
Result: no usable configuration
Success criteria were gap < 6pp between purchase orders, dead turns < 10%, survival 45–80%.
| Config | spear-1st | mail-1st | reactive | gap | dead |
|---|---|---|---|---|---|
| Baseline (cost 2, instant, flat) | 41.7% | 49.3% | — | +7.6% | 2.5% |
| Situational, cost 1 | 25.3% | 32.7% | 36.3% | +11.0% | 24.0% |
| Situational, cost 2 | 17.0% | 17.6% | 20.9% | +3.9% | 11.3% |
| Situational, cost 3 | 11.0% | 6.1% | 10.4% | +4.9% | 6.5% |
| Mail lead 1 | 17.7% | 20.1% | — | +2.4% | 10.9% |
| Mail lead 2 | 8.9% | 9.3% | — | +0.4% | 18.6% |
| Situational + lead 1, cost 2 | 8.3% | 10.1% | 10.1% | +1.9% | 15.3% |
**Every lever that closed the gap did so by making the game harder, not by making the choice more interesting.** Situational mail at cost 2 reaches a 3.9% gap — but survival collapses to 17%. Mail lead 1 reaches 2.4% at 18–20% survival. The decision stops being dominated because mail stops mattering, which is a different failure wearing the same number.
The finding that is worth keeping
Reading the raid type pays only when the reaction is instant.
| Situational config | Best fixed order | Reactive | Edge |
|---|---|---|---|
| cost 1, mail instant | 32.7% | 36.3% | +3.6% |
| cost 1, mail lead 1 | 23.1% | 19.9% | −3.3% |
| cost 2, mail instant | 17.6% | 20.9% | +3.3% |
| cost 2, mail lead 1 | 10.1% | 10.1% | 0.0% |
With instant mail, a player who reads the incoming raid type and buys accordingly beats both fixed orders. Add even one turn of lead time and the advantage disappears or inverts.
The rule: information the player cannot act on in time is not a decision.
This is the exact mirror of why spears work. Spears are a commitment — their 3-turn lead is what makes the choice meaningful, because you must decide before you know. Mail, if it is to be situational, must be a reaction — it needs to be fast precisely because its value comes from responding to information.
Two sinks, two different relationships with time. That is a more interesting design than two sinks differing only in price, and it came out of the levers failing rather than succeeding.
Where this leaves the second sink
Mail as currently specified (absorbs losses, capped at 2× carriers) **fixes the dead zone** — 42% → 2.5% — and that was the tester's actual complaint. What it has not achieved is a genuinely undominated choice.
Three honest options:
- Ship the dead-zone fix, accept the soft dominance. A 7.6pp edge toward buying mail first is not nothing, but it is far from the v1 situation where a single ratio won outright. Players would drift toward mail-first and still have a live allocation across the season. Lowest risk, least elegant.
- Make mail instant and situational, and re-tune difficulty separately. The +3.6% reactive edge says the mechanism works; the 25–33% survival says the difficulty curve needs its own pass. These are separable problems and were conflated in every config above.
- Test it with a human before tuning further. Every number here is solver output. The tester's complaint was about feel — having nothing to spend iron on — and 2.5% dead turns may already resolve it regardless of the gap.
Recommended: option 3, then 2. The solver has now said everything it can about purchase ordering. Whether a 7.6pp edge is felt as "mail is obviously correct" is a question only a player can answer, and the prototype exists to ask players questions.
Method note — five failed reconciliations
A rewritten harness (tune.py, then lever.py) reported 1–17% survival against the spike's 41.7%. Five hypotheses were tested and all five were wrong: missing repair path, RNG stream contamination, policy spend-ordering, plough-before-arms ordering, and mail pipelining.
The actual cause was found only by **re-running the spike's own code and printing its assumptions** — the spike gave mail no lead time at all, so the rewrite's "baseline (mail lead 3)" was never a baseline. It was a different game.
The fix was to stop rewriting and extend the working harness with exactly two new parameters, verifying the regression (41.7% / 49.3%) before testing anything. That regression check is now the first line of lever-tuning.py and should be run before trusting any future number from it.
**A harness that cannot reproduce a known result is not evidence, however plausible its output looks.**