Red Team — Why This AI Will Be Bad

Status: Adversarial review · Subsystem: AI opponents · Posture: hostile Reviews: docs/design/00-direction.md, 01-decision-turn-model.md, turn-model.md (→ 10-turn-model.md, TM), combat.md (→ 11-combat.md, CB), economy.md (→ 12-economy.md, EC), victory.md (→ 14-victory.md, VC), units.md (→ 02-units-and-industry.md, US), and docs/spec/13-command.md (CM, 221 requirements, binding, not edited here)

0. What this document is, and how to read it

The project owner has named advanced AI opponents as the most important advancement they want. This document exists because that ambition is the most likely thing in the design to fail quietly, and because the failure will be invisible to the team that builds it until players find it in the first week.

I am not arguing the AI cannot be good. I am arguing that the specific systems this game has chosen — Orders and the Cascade, the Posture/Sanction command layer, break-and-retreat combat, Integration and Cadre, Vigil-based victory Tracks — each create a named, cheap, repeatable way to beat a competent-looking AI, and that most of those ways are spec-mandated behaviour, not implementation bugs. Some of the sharpest ones fall directly out of requirements in 13-command.md as written.

Three ground rules for reading it:

1. Every claim names a mechanism. "The AI will be exploitable" is worthless. "A single Recon unit held at range 3–5 forces every Cautious screening unit within its threat radius to Withdraw every turn, because CM-160 returns 400‰ for an unobserved strength and CM-690 compares that against a 700‰ threshold" is worth something.
2. Every failure names a detection and a design change. A red team that only predicts doom transfers no information. The detection is what stops the failure shipping; the design change is what stops it existing.
3. The design changes are cheap where I could make them cheap. Several are one-line amendments to 13-command.md. Where a change is expensive I say so and rank it against the others.

The single most important recommendation in this document is not any individual fix. It is §8.2: the Antagonist roster — thirteen deliberately stupid scripted opponents, one per exploit class, run nightly. Without them, self-play will look perfectly healthy while every exploit below is live, because self-play measures the AI against agents that share its blind spots.

1. The bill of indictment, ranked

Ranked by probability × damage × detection latency, where detection latency is how long a failure survives before anyone notices. Latency is the dangerous term: a failure found in week one is a bug, a failure found after ship is the AI's reputation.

2. Exploitability — the degenerate strategies, by mechanism

The design's own documents are unusually good at naming their balance risks. What follows is different: these are not balance problems between two humans. They are asymmetries between a human who adapts and an agent whose policy is fixed within a game, and most of them are cheap enough that a player finds them by accident.

2.1 Exploits against the command layer itself

These are the worst, because they are mandated by 13-command.md and therefore will be implemented faithfully and correctly, and will still lose games.

E1 — The 400‰ Blindfold (sharpest finding in this document)

The mechanism, in four requirements:

• CM-160: the predictor MUST set estimated = true whenever the knowledge view lacks a current observation of the target's strength, and in that case MUST return a conservative 400‰.
• CM-690: for Risk Cautious, "does not beat" uses the unit's Engagement per-mille — 700‰ by the Screen default (CM-740).
• CM-660: Cautious MUST push a Withdraw Reflex on contact with any visible enemy within threat radius that it does not beat.
• CM-500 step 2: a Survey unit MUST exclude any candidate within one turn's movement of a visible enemy it does not beat at its avoidance threshold — 700‰ when Engagement is Never, which is the Survey default.

Chain them. An enemy observed at observation level L1 (CB §10: type and owner known, strength not) yields estimated = true → predicted 400‰ → 400 < 700 → "does not beat" → Withdraw fires, and for a Survey unit the whole region within that enemy's reach is excluded from the candidate set.

The consequences are worse than they first look:

• The screen cannot respond. CM-1420 forbids a Reflex from initiating an attack. CM-160 forbids Favourable from authorising an attack on an estimated prediction unless engageOnEstimates is set (default false). So the screening unit may neither fight the probe nor ignore it.
• The screen loses its reaction. CM-480: a Screen derives Stance Hold only when it did not relocate at its previous activation, otherwise Advance. A screen forced to relocate every turn is permanently on Advance, which under TM §3.3 has no reaction capacity. The whole screen line stops being able to intercept anything.
• It is a liveness bug, not just an exploit. Scouts avoid unidentified contacts. Contacts stay unidentified because scouts avoid them. The AI's recon deadlocks against exactly the units it most needs to identify, and CM-140 then tells its routing and (if the team is careless, §6) its threat evaluation that the unexplored region is empty. The AI is confidently blind precisely where the enemy is.

Cost to the attacker: one Recon unit, held at Chebyshev 3–5, never closing to adjacency. In units.md's roster that is a Scout at 12 BP with move 5, so its threat radius is 5 (CM-680: last-known movement allowance clamped [1,6]). One scout suppresses a five-tile-radius disc of screen line and denies a survey region, indefinitely, and it costs less than a third of an Infantry.

Why it hurts the AI more than a human: a human notices a scout loitering and sends something to kill it, or hand-orders through the reflex (CM-070 guarantees they can). An AI whose action space is Postures and Sanctions is executing the rule correctly and has no representation of "this contact is a decoy that has cost me my entire screen for eleven turns."

Detection. Instrument two counters from the first playable build:

• withdrawReflexesTriggeredByEstimatedPrediction / withdrawReflexesTotal — should be well under 20%; if it exceeds 50% the Blindfold is live.
• surveyCandidatesExcludedByEstimatedPrediction / surveyCandidatesExcluded, and separately regionsWithZeroReachableCandidatesForNTurns, which is the deadlock signal and should be ~0.

Design change (cheap, and I would make it before anything else). CM-160's single conservative number is being asked to do two incompatible jobs. Split it:

The predictor returns a pair of integers: pLow, computed with the target assumed at maximum strength and best plausible grade, and pHigh, computed with the target at its last-observed or class-typical strength. Attack authorisation (Engagement Favourable, CM-580) uses pLow. Avoidance and self-preservation (Risk Cautious CM-660/690, Survey exclusion CM-500, TakeCover CM-1400) use pHigh. Both are produced by the same predictor at the same cost, because CB §9.1 already evaluates the exchange at three draws and binary-searches the break threshold — running it twice over two strength assumptions doubles a 0.45 µs call.

Add an escalation so a persistent unidentified contact cannot be free forever: a contact that has been visible for 3 consecutive turns without reaching L2 is treated as class-typical rather than unknown, and the AI raises a RecondNeeded obligation rather than avoiding it. And give the Van role's forced Cautious (CM-910) an exemption from the estimated-prediction path, or the vanguard — whose entire job is to find things — refuses to approach anything it has not already identified.

E2 — The Scarecrow: halting a column with a worthless unit

Mechanism. CM-1340 defines the Opportunity interruption as: "Do nothing. Halt, bank movement, and record a candidate order." CM-1370 lists "overwhelming odds — an adjacent enemy with predicted win probability ≥ 900‰ that Engagement forbids attacking." The March default Engagement is Defend (CM-740), which forbids initiating. So:

Park any sufficiently weak unit adjacent to a marching column and the column halts and does nothing for the activation.

Banked Movement (CM-1550–1600) returns the allowance next turn but not the position, and cannot return the tempo of an operation whose value depended on arriving with the rest of the force. Against a Concentrated Formation (CM-1000, cohesion radius 3) halting the commander desynchronises the members; halting a member pushes Regroup on it (CM-1010), which pops the column's forward progress for another turn.

Cost to the attacker: one expendable unit per column per turn, and the unit does not even have to survive — it only has to be adjacent at the moment of evaluation.

Worse in the modes this game is built for. CM-2010 (absent-player mode) says automated units resolve normally and Dispatch items persist. It does not suppress the Opportunity halt. So in correspondence play — the mode 01-decision-turn-model.md argues is the reason Orders and the Cascade was chosen — an absent player's entire army can be frozen by cheap probes, and the AI, which is never present to answer a card mid-Cascade, is in absent-player mode permanently.

Detection. opportunityHaltsPerUnitPerGame, and fractionOfMarchActivationsEndingInOpportunityHalt. Above 5% of March activations means the Scarecrow is live. Also worth plotting: medianTurnsLateOnArrival for Formation Marches, versus the same figure with Opportunity suppressed in a counterfactual replay — the deterministic core makes that comparison exact.

Design change. Amend the Opportunity row of CM-1340 so that halting is conditional rather than automatic:

An Opportunity MUST NOT halt a unit whose active level is a player Task or a March carrying a follow-on order; for those it MUST be recorded and raised without halting. Where an Opportunity does halt, the same (class, causeEntityId) cause key MUST NOT halt the same unit again within 5 turns. For an AI seat and for absent-player mode, an Opportunity MUST resolve by the unit's pre-committed policy rather than halting.

The last clause is the load-bearing one and the design already has the vocabulary for it: an AI seat is by definition always absent from the Cascade.

E3 — The Decoy Priority Bug

CM-610: when more than one target satisfies Engagement, select by (1) highest predicted per-mille, (2) inside the assigned geometry over outside, (3) lowest creation sequence number.

Target value appears nowhere. An automated unit therefore always eats the safest available target, never the most valuable. Place a crippled Scout Troop adjacent to a Field Battery and the AI's armour attacks the scout, every time, for as long as you keep feeding it scouts. This is a one-line requirement producing an unlimited-duration tempo sink.

Design change. Replace criterion (1) with an integer expected-value comparison, cross-multiplied per CM-120:

value(t) = p(t) × worth(t) − (1000 − p(t)) × worth(self) × riskWeight / 1000

where worth is the units specification's build cost (already required by CM-2180 for the Dispatch S terms, so no new contract) and riskWeight is a per-Sanction integer defaulting to 1000. Ties then fall through to the existing chain. This also fixes the same bug for human players' automated units, which is where it will be first reported.

E4 — Threshold surfing

Every Sanction is an integer threshold with a published default: Favourable(700), presets 600/700/850; Prudent(334); Survey avoidance 700; Opportunity at 500‰ and 900‰; cohesion 3; Screen hysteresis 2; Posting re-target 5. The combat predictor is exact, deterministic, and shown to the human (CB §9.1: "the number shown to the player is not 'roughly 60%'. It is 597 per-mille, and it is right").

Therefore a human can compute the AI's decision boundary exactly, and construct positions that sit one per-mille either side of it. Present a target at 699‰ and the AI's screen will never attack it, so it becomes a permanent wall built out of a unit the AI could beat seven times in ten. Present one at 701‰ backed by a reaction-armed entrenched neighbour one tile back and the AI attacks into it, forever.

This is not a tuning problem. Moving 700 to 720 moves the boundary; it does not remove it. Any AI whose behaviour is a threshold function of a predictor the opponent also holds is exploitable at the boundary. The only structural answer is that the AI's own thresholds must not be the shipped Sanction defaults, and must carry a per-game secret offset — see §3.

E5 — Ford squatting: buying the top of the activation order

01-decision-turn-model.md amendment 2 trims Initiative to three terms: class base, posture, Forming Up. Class base is public data — units.md §2.2 is explicit that "there is no fog over rules, only over the map." Posture is observable at L2. Forming Up is inferable from when a unit first appeared. So a human in contact can compute the AI's activation order to within a few points.

Recon base is 60; March is +8. Sixty-eight is the top of the table and it is the cheapest thing on it. Since orders are policies evaluated at activation and a bare Move halts on contact (TM §3.2), one cheap fast unit dropped on a tile an AI operation depends on invalidates the operation, exactly as Ostry's 0644 dies in TM §4.3. The difference is that Ostry made a mistake once; an AI without conditional orders makes it every turn.

Detection. The design already proposes the right metric for humans (TM §8: stance-fallback rate above 8% means intents are too brittle). Apply it to the AI and invert the target: the AI's stance-fallback rate must be below the human median, because the AI can afford to enumerate conditions and a human cannot. If it is above, the AI is not using the conditional vocabulary and the design's central bet has failed on the AI side.

Second metric: fractionOfCommittedAIOrdersCarryingAtLeastOneCondition, compared against the human figure. TM §8 sets 20% among experienced humans as the floor; the AI should be near 100% on any order whose target is contestable.

E6 — Requisition steering: the opponent controls the AI's production routing

CM-1190's deficit round-robin allocates production to the eligible Posting with the greatest counter, where eligible means shortfall > 0, and CM-1250 computes shortfall as target − (present + inTransit + committed).

Kill units on the AI's highest-weight Posting and it stays perpetually eligible and absorbs its full weight share; every other front starves. So: attack the AI's strongest front to starve its weakest, then attack the weakest. The counters are authoritative game state (CM-1210) and deterministic, so the effect is exactly predictable to anyone who understands the rule, and the rule is in a public spec.

The symmetric version also works. CM-1230's 5-tile hysteresis means a front oscillating within 5 tiles never re-aims its reinforcement stream, so reinforcements march to a stale anchor; a front pushed past 5 tiles repeatedly re-aims every turn and the stream never arrives. Both are cheap to induce.

Design change. Damp the shortfall: count deliveries over a trailing window so a front that has just been reinforced is not immediately eligible again, and require the AI to hold a central reserve Posting whose weight rises with the variance of shortfall across fronts. The second is an AI-side policy, not a spec change, but it must be an explicit requirement or no one will build it — greedy allocation across many fronts is the classic "everywhere weak" failure and it is the AI's default behaviour, not an accident.

E7 — Contact flooding as compute denial

CM-1870 decides that deduplication and the Agency term are the only mitigations required against attention-flooding, on the grounds that flooding may be a legitimate emergent tactic. For a human that is a defensible call. For an AI it is a new attack class the design has not considered:

An AI runs under a wall-clock or fuel budget. More contacts mean more candidate targets, more predictor calls, more plan invalidations, more route recomputations (CM-1470 invalidates a cached route when its next two tiles become invalid — a unit stepping onto them does that). A human generating cheap contacts directly reduces the AI's search depth.

The player is setting the AI's difficulty from inside the game, downward, for the price of some scouts.

Design change. The AI's budget must be allocated by value, not consumed by event count: cluster contacts before reasoning about them (the same cause-key clustering CM-1700 already defines for the Dispatch), cap the number of individually-reasoned contacts per turn at a constant, and — critically — never let plan re-validation cost scale with contact count. Instrument aiPlanDepthAchieved per turn against contactCount; a negative slope is the attack working.

2.2 Exploits against the combat model

E8 — Retreat-tile denial (the Gravedigger)

CB §2.1 makes encirclement the real win condition of tactical play, and it is nearly free: a broken unit with no retreat tile is destroyed, and its whole stack with it (CB Step 8). CB §12 concedes this is the mechanic the author is least sure of, because four units can vanish in one clash.

The retreat destination is a published deterministic formula (CB Step 8) and CB explicitly shows the chosen tile in the attack preview so the player can plan around it. So a human can compute exactly where every AI stack will retreat to and pre-place a unit there — enemy-occupied tiles are excluded from the candidate set, so occupation removes candidates and can drive the set to empty.

Exchange rate: one cheap unit placed on the last retreat square converts a marginal attack into the destruction of an entire stack. Against the CB §7 example that is one Scout Troop for a Rifle Company plus everything stacked with it.

The AI will be blind to this in both directions, and for the same reason: retreat degree is a property of the position graph, not a feature of any tile or unit, and utility evaluators score tiles and units. The AI will neither notice its own stacks losing their last exit nor notice that one move would take an enemy stack's.

Detection. Split CB §13's existing metric by role: shareOfAILossesFromNoRetreatDestruction as victim, and shareOfAIKillsFromNoRetreatDestruction as perpetrator. The design's global target is 20–35% of losses from no-retreat destruction. If the AI is the victim in materially more than a third of such events across mixed human/AI games, or the perpetrator in materially fewer, it is blind.

Design change (AI side, and it is cheap). Maintain an integer retreat degree per friendly stack — the count of tiles passing CB Step 8's filter — incrementally, updated when any adjacent tile's occupancy changes. Two uses:

• Defensive: retreat degree ≤ 1 is a Commitment-ledger condition (CM-020) and must raise an obligation, not be scored.
• Offensive: an attack's value gains the full value of the target stack, not the expected losses, when the attack drives retreat degree to 0. This is the single largest missing term in any naive combat evaluation of this game.

E9 — The Kite: Withdraw screens as an infinite tempo sink

CB §6 and CB open question 1: a unit in Withdraw disengages with no dice for a flat parting loss of floor(1000 / tough) — 16 for a Scout Troop, 10 for a Rifle Company — plus +15 disorder, and recovers 4 strength per turn in the field. CB's own author flags that with depth behind it, a screen may trade space forever at a profit.

Against a human this eventually loses to a flanking manoeuvre. Against an AI whose Engagement Sanction fires on the visible screen and whose plan is "advance to objective," it is a treadmill: the AI attacks, the screen disengages, the AI advances one tile, repeat. The AI's own metrics look fine — it is winning every engagement and gaining ground.

Detection. tilesGainedPerAttackInitiated over a rolling 10-turn window per theatre. A healthy advance is well above 1; a kited advance converges toward 1 while attack count stays high. Also medianTurnsToReduceAContestedTile against CB §13's 2–4 target — a kited AI never reduces anything, so the tile count resolved goes to zero while combat volume stays high.

Design change (AI side). A plan-level correction, which is exactly what the Posture vocabulary cannot express (§4): when the ratio falls below threshold, fix the screen with minimum force and displace the main effort elsewhere. This requires the planner to represent "fixing force" as a role, which no Posture names.

E10 — The bombardment threshold: a silent, total waste of a production line

CB §7.2 gives the equilibrium plainly: one battery inflicts about +26 disorder per turn against a city's −45 recovery, so one battery accomplishes literally nothing. Three inflict about +75 against −45, netting +30. Artillery value is zero, zero, then large.

A utility evaluator with a per-unit value for a Field Battery — which is what a weighted feature sum produces — will build them, deploy them in ones and twos, and achieve exactly nothing, forever, at 90 Works each. This will not register as a loss. It registers as an AI that builds a reasonable-looking army and never takes cities, which is a symptom the team will attribute to almost anything else.

This is my favourite finding because of its evaluation properties: self-play will eventually fix it (the population discovers the threshold), and human review never will, because the build ratios look correct in aggregate while the deployment is wrong in every instance.

Detection. Per AI siege turn, the modal number of friendly batteries in range of the same target. The distribution should be bimodal at 0 and ≥3, with a near-empty 1–2 bucket. Any mass at 1–2 is the bug.

Design change. Represent artillery as a group asset with a minimum viable size, not as N units — a Formation with ≥3 Gun-role members — and forbid committing guns below threshold. This is one of the few places where reasoning in Formations genuinely helps rather than merely compressing.

E11 — Stack liability and the top-defender rule

CB open question 4: the top defender takes all losses; the rest add +100 defence each. Stacking is therefore cheap right up until the stack dies all at once.

Both AI errors follow from one bug — the AI's stack evaluation is not a function of the clash odds against the top defender:

• Defensively, the AI stacks because stacking is cheap by the arithmetic, and then loses four units to one encirclement (E8).
• Offensively, the AI sees "unfavourable" against a three-stack's top defender and never attacks, so a human's three-stack advances with impunity.

Design change. A stackLiability term: total value in the stack × probability that retreat degree reaches 0 within the horizon. It is the same incremental computation as E8 and pays for both.

E12 — The combined-arms timing trap (a design bug, not only an AI problem)

TM §3.1 puts Field guns and siege at base initiative 24 — deliberately last ("artillery answers a battle, it does not open one"). CB §7.1's central combined-arms demonstration is bombard-to-strip-resolve, then assault: 0‰ break becomes certain break because 29 points of resolve were removed first.

Within a single Cascade those two cannot be sequenced in that order. The guns act after the assault. So CB §7.1's flagship example is a two-turn operation, while CB Step 0's supporting-fire path (adjacent supporters at ×0.40) is the same-turn one and does something different.

This matters for the AI more than for a human, because a human reads CB §7.1, tries it, discovers the ordering, and adapts in one game. An AI's artillery doctrine is a weight vector, and if it is tuned against the assumption that bombardment precedes assault within a turn, it will be tuned against a sequence the engine cannot produce.

It also exposes an expressiveness hole: "assault next turn if the bombardment landed" is a two-turn conditional commitment, and the order vocabulary (six Postures, five Task end conditions, four Sanctions) cannot say it. See §4.

Recommendation to the design, not just to the AI: state explicitly in 11-combat.md which combined-arms path is which — same-turn support versus two-turn suppression — and confirm whether the initiative table intends artillery to be unable to prepare an assault in the same turn. If it does intend it, the AI needs multi-turn plan commitment as a first-class feature, and that is a planner requirement, not a tuning parameter.

2.3 Exploits against the economy

E13 — The Clerk: hunting Cadre and Depots

economy.md §6 makes the Administrative Cadre the anti-snowball engine and simultaneously the softest target in the game: Move 1, no attack, no defence, destroyed if an enemy enters its tile, may not move adjacent to a known enemy unless escorted. Cost escalates as roughly 37.5 N², so the 7th Cadre is 600 Works and 80 Manpower, and by the time it is walking to the front it also embodies twenty-odd turns of travel.

Killing it is worth more than killing an armoured battalion, and it is easier. economy.md §13.3 already flags Cadre exposure as unresolved.

Depots are the same shape: 60 Works, immobile once emplaced, and economy.md §7 states that a Depot chain "is exactly as strong as its weakest link, and cutting one collapses everything behind it." That is a graph articulation point, and killing one collapses supply for everything downstream — which by CB §8's supply table is worth more than three extra battalions.

Why the AI loses these specifically. Three compounding reasons:

1. Rear-area security is spatially diffuse and temporally low-urgency, which is exactly the region of the utility landscape a per-turn evaluator under-serves.
2. The attention system itself underweights it. CM-1720 gives UnitLost a stake of 10 + (unitCost ÷ 4) capped at 40 — so a 600-Works Cadre and a 40-Works Infantry both cap out at 40, and both rank below any CityThreatened at 100. If the AI's triage borrows the Dispatch's terms (a very plausible engineering shortcut, §5.4), the AI is told the Cadre does not matter.
3. "A hostile raider is living in my rear" is a persistent adversary model, not a per-turn threat, and nothing in the design gives the AI a place to keep one.

Detection. cadreLostPerGame and depotsLostPerGame, AI versus human, and meanCadreLifespanInTurns. Also worksLostToCadreAndDepotKills as a share of total Works produced — if that exceeds a few per cent, the Clerk is a winning strategy.

Design changes.

• Amend CM-1720 so UnitLost for units the economy marks as strategic (Cadre, Depot) is its own class with an uncapped or separately-capped S. Alternatively raise the cap to 70 and let cost do the work.
• AI side: a rear-security Posting whose Requisition scales with the count of Cadre in transit and the number of Depot articulation points, plus explicit raider tracking (§6).

E14 — The Ratchet: raid, degrade, abandon

units.md §2.2: a captured city drops one Industry level (minimum 1) and loses accumulated build progress. economy.md's Loyalty memory restores Integration on recapture but says nothing about Industry, and cannot — Industry is a different subsystem's state.

So a raid that touches a rear Arsenal for a single turn costs the AI 120 BP of upgrade plus all accumulated progress, permanently, and the AI gets nothing back by retaking it. cityStrike on the Bomber and Heavy Bomber does the same at range without needing to hold anything.

The compounding property is what makes this an AI killer: it is a monotone ratchet, and a per-turn evaluator sees each event as a small negative. Twelve small negatives are a collapsed industrial base, and nothing in a weighted feature sum notices a trend.

Detection. Per-player Industry-level histogram over time. A monotone decline in the AI's mean Industry across the mid-game, while its city count is flat or rising, is the Ratchet running.

Design change. The AI must carry trend features, not only level features: mean Industry, total Works, Cadre count, and integrated-city count, each as a signed delta over a 20-turn window, feeding a strategic-alarm term that reprioritises rear defence. And rear cities must be valued at replacement cost (120 BP plus the turns to rebuild) rather than current output, or garrisoning them will always score below reinforcing the front.

E15 — The Ferryman: Loyalty-memory city trading

economy.md §6 is explicit and deliberate: the original owner retaking a city restores Integration to their full remembered Loyalty and sets Unrest to 0. The invader who spent 25 cadre-turns making a Metropolis productive hands it all back the turn the defender walks in.

Do the arithmetic on a City (base Works 12) from the AI's side of a capture:

The exchange is roughly 6:1 in the defender's favour before a single combat loss is counted, and that is exactly the pressure release the economy wanted. But an AI valuing a city capture at VC §2.3's flat 100 Standing will take cities it should not, garrison them badly, and lose them back at full value to a defender who has been waiting for precisely that.

Design change (AI side). City valuation must be

value = expectedIntegratedWorks × P(hold ≥ N turns)
      − garrisonCost − cadreOpportunityCost
      − (recaptureValueToOriginalOwner × P(they retake it))

and the last term is the one nobody will remember to include. The AI must also be able to decide not to take a specific city — which the Seize Sanction cannot express (§4.2).

E16 — Loser's buttons pressed while winning

economy.md §5 designs Emergency Levy as a deliberately bad trade you take anyway when you are losing: 10 Population for 20 Manpower, permanently, +25 Unrest, 20-turn payback. Razing is the same shape. Works Expansion at a 75-turn payback (economy.md §10 concedes it may be a trap) is the mirror image — correct only if the game runs long enough.

These form a class: options whose correctness depends on a condition the AI has no term for — "am I about to lose?" and "how long will this game last?"

The second one is free and the design has already handed it over. The Ebb schedule (VC T1) is published from turn 1 and is a closed form; the Horizon is a hard backstop; VC §8.2's elimination arithmetic is exact for accumulative Tracks. An AI that maintains an integer horizon estimate — expected remaining turns — can price every one of these options correctly with arithmetic it already has. An AI that does not is leaving the design's best gift on the table and will press the loser's button while winning, which reads to a player as the AI being broken.

Detection. emergencyLevyUsesWhileTenureLeader should be ~0. worksExpansionCompletionsAfterHorizonMinus75 should be 0.

2.4 Exploits against the victory system

The victory design is the strongest document in the set and it is also the richest exploit surface, because almost everything in it is published in advance — the Ebb schedule, Landmark locations, the Tally calendar 24 turns ahead, Warrants 5 turns ahead. Published schedules are a gift to a planner and a gift to an ambusher, and the ambusher gets more out of them.

E17 — The Bellringer: farming Vigils

VC §2.2 makes the Vigil the anti-snowball mechanism, with a deliberately asymmetric risk: the leader must be airtight for V turns; the challenger needs one successful attack. VC §6.2 goes further — entering Alarm grants every player live vision of the contributing sites including garrisons, plus a 2-turn grace period.

An AI whose evaluation says "Dominion is my highest-value Track" pushes across the threshold, publishes the addresses of its own garrisons, gets one city taken, and resets the Vigil to zero (VC §4.7). Repeat. Each cycle the AI has spent an offensive and gained nothing, and each cycle the human has been handed free reconnaissance.

The correct play is frequently to sit at 89% and accumulate force, deliberately not progressing on the objective until it can hold the Vigil against a coordinated strike. That is a profoundly counter-intuitive behaviour for a progress-maximising evaluator, and it will not emerge from tuning.

Detection. AI Vigil break rate versus human. VC §13 targets 30–55% of started Vigils broken. If the AI sits above 75% while humans sit near 40%, the AI is entering Alarm prematurely. Also medianTurnsFromAIAlarmEntryToVigilBreak — a small number means the human is waiting for the bell.

Design change (AI side). Model Alarm entry as an explicit cost: crossing into Alarm grants each opponent vision of the contributing sites and reduces the AI's estimated hold probability by a term proportional to observed enemy mobile strength within reach of those sites. And give the planner a "hold at threshold − 1" mode, so the AI can accumulate before ringing the bell. That mode is a strategic behaviour a human would recognise immediately and no utility sum produces by itself.

E18 — The Herring: feints at Landmarks and Warrants

VC T5 publishes Landmark locations from turn 1 and weights them at +150 Standing on top of the city's 100. VC T13 publishes Warrants every 15 turns, announced 5 turns ahead with a 15-turn deadline.

Both are magnets. Both are abandonable by the attacker at no cost. So:

• Feint toward a Landmark the AI must defend; the AI moves its mobile reserve 40 tiles; take two ordinary cities elsewhere. The AI's Track evaluation is local to the objective and does not price the reserve's absence.
• Contest a Warrant until the AI commits, then leave. The AI's detachment is out of position for the remainder of the 15-turn window.

The Warrant case is materially worse than a one-off trick because the design has built a bait dispenser on a 15-turn metronome. Roughly nine Warrants land in the turn-60-to-130 stretch VC §9 is proudest of. Every one is a renewable opportunity to pull an AI's reserve out of position.

Detection. aiMobileForceDisplacementPerWarrantAnnounced, and warrantClaimRate for the AI versus the fraction of Warrants it committed force to. A large gap — committing often, claiming rarely — is the Herring.

Design change. Value a non-terminal objective at payout × P(win the contest) − cost of the detachment's absence, give the planner an explicit withdraw-from-contest decision when observed opposing commitment exceeds a threshold, and hard-cap the fraction of mobile force committed to non-terminal objectives (Warrants, Tallies) — I would start at 25% and tune it.

E19 — Ascendancy ambush: the calendar plus deterministic pathfinding

VC T6 rotates Lit Landmarks every 12 turns on a schedule published 24 turns ahead, and celebrates that "everyone can be there." Against a human that is a duel. Against an AI it is an ambush, because the human knows three things the AI does not know they know:

1. Where the AI must be (the Lit Landmark).
2. When (the Tally turn).
3. By which route — because pathfinding uses integer costs with deterministic tie-breaks on lowest tile index (CM-1510, AR-750), so given the AI's staging area the approach corridor is not merely predictable, it is computable to the tile.

Pre-place entrenched reaction units on that corridor and the AI's force arrives disordered or not at all.

Design change. AI strategic route selection must randomise among near-cost-equal routes from its own seeded stream. This is the clearest case in the whole document where determinism of the engine and predictability of the agent must be separated: the engine must be deterministic for replay; the agent must not be predictable to an opponent holding the same rules. Concretely: enumerate routes within 110% of the cheapest and choose by seeded draw (§3.3), keeping the choice replay-exact.

E20 — The Great Work as a 45-turn hostage

VC T7 requires 900 accumulated output — roughly 45 turns at 20/turn — on a Landmark, deliberately public and reachable, with capture halving stored progress and permitting a re-site after 5 turns.

An AI that commits is promising to hold one publicly-known tile for 45 turns. A human raids at turn 40. If the AI re-commits, it is baited into another 45. The commitment decision requires a long-horizon defensive holding estimate against an adaptive opponent, which is the single thing utility evaluators are worst at.

Design change. Gate Great Work commitment behind hard preconditions rather than a score: the site must be at least N tiles inside supplied territory, and the AI's mobile reserve must exceed the largest observed enemy strike force by a margin. Re-evaluate every 10 turns with an explicit abandon option, and never re-site more than once per game.

E21 — Verdict manipulation

VC §8.3 offers a Verdict when four conditions hold — leader Standing ≥ 2× second, leader also leads Tenure, lead held 12 turns, no non-leader in a Vigil — and states plainly that "the AIs' votes are deterministic functions of their evaluation and the seed."

That sentence is an invitation. In a multi-AI game a human can engineer the trigger:

• Standing is mostly cities × 100 plus Landmarks and Seats (VC §2.3), so the ratio is manipulable by attacking the second-place AI rather than the leader, suppressing the denominator.
• Condition 4 requires no non-leader in a Vigil, and Vigils are public in Alarm (VC §6.1), so the human can time the trigger to a window they can observe.

If AI vote policy is "concede when my evaluation says I cannot win," the human wins by scoreboard arithmetic without conquering anything.

Design change. AI Verdict policy must not be a function of current evaluation. It must require the elimination arithmetic of VC §8.2 to actually hold on every accumulative Track, plus a minimum number of consecutive turns of decline, and must abstain — which VC §8.3 already counts as "play on" — in any case where its own estimate falls inside a band of uncertainty. Abstention must be the default, not the evaluated outcome. VC §15's contract row for AI ("a deterministic Verdict vote policy derived from evaluation plus seed") should be amended to say so, because as written it invites exactly the wrong implementation.

2.5 Exploit summary and Antagonist mapping

3. The commit-blind problem

The question: does issuing orders blind make a deterministic AI baitable, and should it deliberately randomise?

The answers: yes, worse than it first appears, and yes — but narrowly, at the plan level, from a secret salt, and never over safety.

3.1 The asymmetry is learning, not blindness

The obvious reading is that commit-blindness hurts the AI because it cannot see the human's move. That reading is wrong: both sides commit against the same stable board (TM §3.6: "During Orders, nothing is happening"). Blindness is symmetric.

The asymmetry is this: the human learns the AI's policy across turns and across games; the AI does not learn the human's within a game. A human plays forty turns against the same decision function and builds a model of it. The AI plays turn 41 exactly as it played turn 1.

Commit-blindness converts that asymmetry from a nuisance into a proof. Orders and the Cascade makes each turn a simultaneous-move game. In a simultaneous-move game, a pure strategy known to the opponent is dominated by the opponent's best response. This is not a heuristic worry; it is the definition of exploitability. And CM-110 mandates that the command layer draw no randomness at all, so if the AI's behaviour is expressed through the command layer it is a pure strategy by construction.

Do the local subgames have pure equilibria? Sometimes — "attack the obviously weak position" is dominant. Often not. TM §4's Kelsey Ford is structurally matching-pennies: race for the ford, hold back and entrench, or go around. There is no dominant answer, so any fixed answer loses to a player who has learned it.

3.2 A necessary distinction the spec must make explicit

CM-110 says the command layer must not draw from the PRNG, and the rationale is correct: a player who cannot predict what their own screen will do cannot delegate to it.

But the AI is not the command layer. The AI is a player. A human player chooses which orders to submit by whatever process they like; the command layer then executes those orders deterministically. An AI seat must have exactly that latitude: it may draw from its own seeded stream when deciding what to submit, and the command layer then executes the submitted orders under CM-110 as usual.

If this distinction is not written down somewhere normative, someone will read CM-110 as binding on the AI, and the AI will ship as a pure strategy. I would put it in the AI specification as a first-section requirement:

The AI's order-selection process MAY consume a dedicated seeded stream. The orders it submits MUST be ordinary orders (CM-2040) and MUST be executed by the same deterministic command layer as any player's. Determinism of the game is preserved by the stream being seeded and logged; unpredictability to the opponent is preserved by the salt not being displayed.

3.3 The mixing mechanism, concretely

Mix over plans, not actions. Randomising individual unit orders produces an incoherent army and is strictly worse than determinism. Randomise which coherent operational plan is adopted:

Given candidate plans scored as integers, best = score[0] (descending):
  keep i where  score[i] × 1000 ≥ best × (1000 − EPS)          // EPS default 50 (5%)
  weight[i]  = score[i] − floor(best × (1000 − EPS) / 1000) + 1     // integer, ≥ 1
  r          = hash64(salt, turn, playerId, "plan") mod Σ weight[i]
  select the first i whose running weight sum exceeds r

Properties this has and needs:

• Integer and exact, per CM-120's arithmetic discipline.
• Positionally addressed, keyed on (salt, turn, playerId, slot) rather than drawn from a stream cursor — the same discipline CB Step 5 adopts for combat, and for the same reason: a cursor is corrupted by ordering, a positional address is not.
• Replay-exact, because the salt is recorded.
• Unpredictable, because the salt is not displayed.

The salt is the load-bearing detail and it is easy to get wrong. Game seeds are conventionally shown at setup. If the AI's mixing stream derives from the visible seed, a determined opponent with a copy of the binary can compute the AI's plan choice offline and mixing has bought nothing. So: a separate secret salt, generated at game creation, stored in the save for replay, never displayed. In single-player that is sufficient. In ranked AI-vs-human multiplayer, where replays must verify, it needs commit-reveal — the salt's hash is published at game start and the salt itself at game end. Flag that as an open question for the multiplayer spec rather than pretending it is solved.

3.4 Where mixing must not go, and what it costs

Never mix: retreat-degree checks, supply state, garrison thresholds, Cadre escort decisions, anything in the Commitment ledger. Mix over aggression and axis of advance, not over survival. A player who watches an AI randomly abandon a garrison concludes the AI is broken, and they are right.

Be honest about the cost. Against a non-adaptive opponent, mixing is a pure loss — the AI sometimes picks its second-best plan. The case for it is that against an adaptive opponent the exploitability loss exceeds the per-turn loss. That argues for two things: keep EPS small (5% is a reasonable start), and make the temperature adaptive — raise entropy when a cheap regret signal fires (repeated losses in similar positions), lower it when the AI is winning. A trailing count of "plans of this class that ended in net force loss" is enough; it costs nothing and it is the only online adaptation I would allow, because it changes how much the AI mixes, not what it believes.

3.5 Two things the AI must do with the Cascade, and one it must not

The turn model hands the AI three gifts and the AI must claim all three.

Claim 1 — simulate the Cascade. Initiative is frozen at the top of the Cascade, is a pure function of committed state, and produces a total order (TM §3.1). The AI can therefore roll the whole turn forward exactly for its own units, and over a small set of hypotheses for enemy orders. That is a bounded, exact lookahead and it is unusual — most 4X AIs cannot simulate their own turn, let alone the opponent's interleave. An AI that does not do this is throwing away the design's largest single advantage.

Claim 2 — use the conditional vocabulary harder than a human can. TM's Ostry lesson is that the order that carries no condition dies. An AI can afford to attach a condition to every contestable order; a human cannot. The AI's stance-fallback rate should therefore be below the human median (§2.1 E5). If it is above, the abstraction is buying the AI nothing and the central bet of 01-decision-turn-model.md has failed on the AI side specifically.

Claim 3 — model the opponent's activation order. With Initiative trimmed to three public-ish terms, the AI can compute the enemy's interleave nearly as well as a human can. Planning conditional on the interleave — "my ford unit acts at 68, theirs at 44, so I arrive first and they will find me there" — is exactly the reasoning TM §4.3 shows Meridian doing and Ostry failing to do.

The thing it must not do: consume the raw per-activation event stream. See §6.4 — that is a wallhack by construction and it is the easy implementation.

4. The abstraction trap

The brief lists the command abstraction first among the design's advantages: postures and sanctions collapse the branching factor, so an AI reasoning in the same vocabulary searches a far smaller space. That is half true, and the false half is dangerous because it will be used to set the AI's budget.

4.1 The vocabulary's limits are UI limits, not adequacy limits

The Posture/Sanction vocabulary was sized for a panel. CM-330 fixes exactly six Postures. CM-230 fixes the stack at three levels, with the rationale stated plainly: "a deeper stack cannot be explained on a unit panel." CM-320 requires the whole stack be readable in plain language. 13-command.md's open question 5 says the bet is that "Sanctions carry the conditionality that would otherwise need a condition grammar," and that if players try to express things the vocabulary cannot reach, the answer is more Task end conditions rather than a general grammar — because "a general grammar cannot be shown on a unit panel."

Those are all correct decisions for a human interface. If the AI's planning space is that same vocabulary, the AI has inherited a set of legibility constraints as strategic constraints, and there is no reason at all why the space of plans a good player conceives should be bounded by what fits on a panel.

4.2 Five things the vocabulary cannot say

1. Synchrony. "These three units strike this tile in this Cascade, or none of them do." A Formation March with Pace Concentrated enforces a cohesion radius of 3 (CM-1010) — proximity, not simultaneity. Combined arms via CB Step 0 support requires supporters adjacent to the target and not yet acted; whether that holds depends on the interleave, which no Posture references.

2. Refusal of a specific target. Seize is Never / Undefended / Free per unit (CM-700). There is no way to say "take cities, but not that one." Yet §2.3 E15 shows that refusing a specific city is frequently correct because of Loyalty memory, Unrest, and garrison cost. The vocabulary can express a policy over the class of cities and nothing over an individual one.

3. Feints, demonstrations, and fixing attacks. There is no way to say "be visible here so they hold three units here." And — this is the part that answers the brief's question directly — there is no way to recognise the opponent doing it, because a demonstration is indistinguishable from an attack that has not happened yet. The abstraction blinds the AI to exactly the tactic that beats it: §2.4's Herring works precisely because the AI has no noun for "this is a feint."

4. Graph properties. Retreat degree (E8), Depot-chain articulation points (E13), line integrity, corridor control, encirclement. Postures are per-unit policies over tiles; every one of these is a property of the position graph. The AI cannot state the plan "cut the Depot chain at its articulation vertex" in the order vocabulary, and if the planner shares the vocabulary it cannot conceive it either.

5. Timing. No Posture takes a turn number. "Be at the Iron Gate on turn 96" — the exact thing VC T6's published Tally calendar exists to enable — is inexpressible. The best the vocabulary offers is March, which arrives whenever it arrives, possibly sixteen turns early and exposed. The design's best feature has no order for it.

4.3 The consequence for how the AI must be built

Separate the plan representation from the output encoding.

• The AI plans in a richer internal language: objectives with deadlines, corridors, fixing forces, retreat-degree constraints, synchrony groups, refusals.
• Each turn it compiles the current plan down to Posture + Sanction + Task orders. Every unit ends the compilation holding ordinary orders, indistinguishable from a human's, executed by the same command layer (CM-100, CM-2040).
• The compilation is lossy, and the AI must know it is. After compiling, it simulates its own compiled orders through the Cascade (§3.5) and checks the plan survives. If the compilation cannot express the plan, the planner must be told, and must choose a different plan rather than submit a compiled shadow of one it liked better.

That last step is the difference between an AI that plans and an AI that hopes, and it costs one extra rollout of orders it has already computed.

4.4 The uncomfortable corollary about budget

Postures collapse the branching factor of issuing orders. They do not collapse the branching factor of planning, because good plans live above the vocabulary.

An AI that searches only over Posture assignments is searching a small space of mostly-bad plans, and it will be fast and weak. Anyone who costs the AI on the assumption that "Postures make the search small" will underfund the planner, and the planner is where the strength is. I would put that sentence in the AI specification's introduction, because the branching-factor argument is seductive, correct-sounding, and about to be used to justify a small budget.

4.5 And the AI must be allowed to hand-order

CM-070 guarantees a human may issue every order by hand for the whole game. If the AI is restricted to Postures — for elegance, for "fairness," or because it reads better — it is playing with a handicap the human does not have, and every §2.1 exploit against the command layer gets a free multiplier.

The AI must have access to the Task level and to per-unit orders exactly as a human does. Say it explicitly, or somebody will implement "the AI only uses Postures" as a virtue.

5. Scaling failure

5.1 The generic causes, and which apply here

AIs collapse at 40 cities and 300 units for three reasons, and all three apply:

1. Per-unit evaluation is O(units × candidates), and all the intelligence lives in the constant. So under budget pressure the constant is what gets cut, and the AI gets dumber exactly as the position gets harder.
2. Global allocation degrades with plan count. With 9 Postings and 11 Formations (the worked empire in command.md §9), distributing a scarce reserve across many fronts is a knapsack that greedy solves badly, and greedy's characteristic failure is "everywhere weak."
3. Priority inversion. With 40 cities each production decision is individually marginal, so the AI optimises the aggregate and misses the one city that decides the game.

5.2 The Turtle Fixed Point (the most likely single failure of this AI)

Here is the specific shape I expect collapse to take, and it will not look like collapse.

The AI holds 40 cities and 300 units. Its Requisitions are perpetually short because twelve fronts are taking losses (CM-1250). Its Cadre are perpetually in transit. Its production is largely consumed by garrison Militia — economy.md §8 puts the Blitzer's garrison bill at 94 points, 47 Militia, 1,128 Works and 470 Manpower sunk. Every candidate offensive scores below the defensive value of holding what it has, because holding is safe and the economy actively rewards consolidation: economy.md §8's headline result is that twenty digested cities beat forty raw ones.

The AI finds that gradient and stops. It becomes a defensive machine that never loses a battle and never wins a game.

This will look healthy in self-play, because both sides do it and the games are balanced and long. It will look pathetic against a human, who simply concentrates against one point of a line that is everywhere adequate and nowhere strong.

Detection. Two metrics, both cheap:

• turnsSinceAIInitiatedAnAttackOfThreeOrMoreUnits — a rising staircase is the tell.
• aiMobileForceAsShareOfTotalForce, where mobile excludes Militia and Garrison-Postured units. Below 25% and staying there is the Turtle.

And one counterfactual, which the deterministic core makes exact: replay AI-vs-AI games with the Ebb disabled. If game length is unchanged, the AI was never responding to the clock in the first place.

Prevention. The AI needs a tempo obligation, and the victory system already provides one for free. The Ebb schedule is published from turn 1 and is closed-form (VC T1): D(t) = D_start − floor((D_start − 501) × (t − Ds) / (H − Ds)). So the AI can compute, exactly, the turn on which its current holdings would suffice — VC §6.4's "count backwards to a date" readout, which the design already builds for humans.

The victory system is not a scoring term for this AI. It is the planner's objective function and its schedule. An AI that treats victory as a term in a weighted sum will turtle. An AI that treats it as a deadline will compute "I hold 22, the floor is 25, I need three more cities before turn 200" and generate an offensive because it has to.

5.3 Cost structure of the things that actually scale

Two of these deserve emphasis.

Supply must have an incremental oracle or the AI cannot play the game's best move. economy.md §8's most striking result is that cutting the road does more than three extra battalions. An AI that cannot cheaply evaluate "what does supply look like if I take this tile" is structurally unable to plan an encirclement or a Depot cut — and a naive implementation that recomputes propagation per candidate will be either unusably slow or quietly supply-blind. Supply-blind is far worse, and far more likely, because it is invisible.

Cadre assignment is a scheduling problem, and greedy gets it backwards. With 22 un-integrated cities and 7 Cadre, "which Cadre goes where, in what order" is an assignment problem over a 25-turn horizon. Integration rates differ sharply by class (economy.md §6: Town +12, City +8, Metropolis +4 → 9, 13, and 25 turns to full). Greedy-by-value sends Cadre to Metropolises and burns 25 turns each. The correct play is frequently Towns first: 2.7 Towns integrate in the time one Metropolis does. The fix is one line — value by rate, not total:

priority = integratedValueGain × 1000 / (turnsToIntegrate + travelTurns)

That single expression probably beats every hand-tuned weight the team will produce for this subsystem, and it is the kind of thing self-play discovers slowly and a designer discovers instantly.

5.4 A specific engineering shortcut that must be forbidden

The Dispatch already exists: it ranks items by an integer Urgency score, deduplicates them, and bounds them (CM-1640 to CM-1790). It is sitting right there, and it is exactly the shape of a triage the AI needs.

The AI must not use it. The Dispatch's terms are tuned for human working memory — seven items, S capped at 100, UnitLost capped at 40 regardless of cost, Tempo deliberately outweighing distant stake because "a distant item will resurface" (CM-1750). Every one of those calibrations is correct for a person and wrong for an agent whose constraint is compute, not attention. §2.3 E13 shows the concrete damage: borrow the Dispatch's S terms and the AI is told that losing a 600-Works Cadre and a 40-Works Infantry are the same event.

CM-1630 already says automation logic must not depend on Attention Events. Extend that to the AI explicitly: the AI's internal triage MUST be a separate function with its own terms, and MUST NOT be the Dispatch's Urgency score.

6. Fog and belief

Is this design prone to paranoia or obliviousness? Both, in different places, and the pressure is asymmetric — oblivious by construction, paranoid by accident.

6.1 Oblivious by construction: CM-140 leaking out of routing

CM-140 is a good requirement with a good rationale: an unrevealed tile is treated as passable at the cheapest cost the unit's movement class pays, and as containing no enemy. Pessimistic routing produces units that refuse to cross unexplored ground, which is behaviour no player would ever choose.

The danger is that the same assumption reaches evaluation. An AI that asks "is my flank safe?" over a knowledge view where unknown = empty concludes its flank is always safe. Every unexplored region is a free approach corridor in the AI's model and an actual approach corridor in reality. Combine with the 400‰ Blindfold (E1), which creates unexplored regions precisely where enemies are, and you get an AI that is confidently, systematically, structurally blind.

I expect this to be the source of most "the AI got flanked by an army that walked through the obvious gap" reports, and I expect it to be diagnosed as a pathfinding or scouting bug rather than as a belief-representation bug.

Design change: two priors, not one.

• Routing keeps CM-140's optimistic prior. It is correct there.
• Threat evaluation uses a pessimistic occupancy prior driven by force accounting. The AI can estimate the enemy's cumulative production from what it has observed of their cities and Industry (which units.md §2.2 makes visible when you have vision on the city). Maintain an integer:

unaccountedEnemyStrength = estimatedBuilt − observedAlive − knownDestroyed

and distribute it over unobserved tiles weighted by reachability from last-known positions and from enemy cities. This is a particle filter reduced to its cheapest useful form: a per-chunk integer expectation, updated incrementally as observations arrive. Cost is trivial and the behavioural difference is enormous — the AI stops treating fog as emptiness and starts treating it as somewhere the missing army is.

6.2 Paranoid by accident: stale contacts as points

CM-130 gives automation last-known observations with observation age. What it does not specify is how age is used, and both naive answers are bad:

• Markers never expire → the AI defends against ghosts, pinning units against an enemy that left thirty turns ago. That is paranoia, and it is a garrison sink that compounds with the Turtle Fixed Point (§5.2).
• Markers expire immediately → obliviousness, and the AI is repeatedly surprised by forces it has already seen.

Design change. A contact of age k is not a point; it is a disc of radius ≈ k × lastKnownMovement, capped at some horizon. Then the AI defends against a region threat with an economical mobile reserve rather than against a point threat with a static garrison. That is also what a good human does, and it changes the shape of the AI's defence from "a unit at every remembered contact" to "a reserve that can reach any of them."

This is, in my view, the single most valuable belief-representation decision available, and it is cheap: one integer per contact and a radius comparison.

6.3 Two fog inversions the AI must handle as step changes

VC §6.2's Alarm grants every player live vision of the leader's contributing sites, with a 2-turn grace period after it clears. That is a step change in information, and it cuts both ways:

• When a human enters Alarm, the AI is handed perfect information about a set of high-value sites and must immediately re-plan. An AI whose planning cadence is "incrementally, every turn" will not notice that a step change in information warrants a step change in plan — it will drift toward the new optimum over ten turns and arrive after the grace period expired.
• When the AI enters Alarm, it must know its own garrisons are now public and re-price its hold probability accordingly (§2.4 E17).

Design change. Make Alarm-state transitions (own and others') an explicit re-plan trigger, in the same class as "plan invalidated" and "major loss." This is cheap and it is exactly the sort of event-driven replanning that a per-turn incremental evaluator misses.

6.4 The leak that would make everything moot

TM §3.6 identifies a real fog leak in the Cascade and closes it properly: a per-activation stream in real time would let a player infer that something happened from a gap, and correlate gaps with initiative bands to deduce enemy composition. So the server emits, per player, a compacted stream of observable events only — no gaps, no timing that maps back to activation indices.

The AI runs in-process. The raw per-activation stream is right there, and consuming it is easier than consuming the compacted one. If anyone does that, the AI is cheating by construction, in a way that is invisible to inspection and that would make every strength measurement in the project meaningless.

This is the cheapest and most decisive anti-cheat test available, and I would make it a CI gate:

The AI's input MUST be byte-identical to the compacted, per-player observable stream a network client receives for the same seat. CI MUST assert this equality over the benchmark corpus. A divergence is a release blocker.

Same for the knowledge view: CM-130's constraint on the command layer must be restated as a constraint on the AI seat, and tested by the same equality.

7. Performance reality

7.1 The arithmetic, honestly

The reference hardware (AR-700) is 4 cores at ~3 GHz. Budgets must also be met at 2× on a 2019-class mobile ARM device and 2× in a browser tab. The browser build is the primary delivery target and the core is TypeScript, not WASM (AR-850) — so the AI is TypeScript in a Worker, with no SIMD (AR-860).

The superseded AI spec's soft budget (AI-400) was 2 s + 10 ms × ownUnits, saturating at 15 s at 1,300 units. At the 2× mobile multiplier that is 30 seconds per AI seat, and in a solo game against five AI opponents, two and a half minutes of thinking per turn. Nobody plays that on a phone. The real mobile budget is 1–2 seconds per AI seat, total — call it 0.5–1.0 s of reference-hardware work.

What fits:

That last row deserves a sentence of its own, because it kills a family of proposals: any learned evaluator must be budgeted against a few hundred evaluations per turn on mobile, not thousands. There is no SIMD, no WASM in the core path, and no GPU. MCTS-style search over a neural evaluator is not on the table for the mobile build. A learned evaluator used once per plan over a dozen plans is fine; one used per node is not.

Second: the old AI spec's WASM plugin framework (AI-380 onward) is in tension with AR-850's decision to drop WASM from the core. A WASM AI plugin talking to a TypeScript core needs a core replica or a heavy ABI, and the determinism surface multiplies (AI-700 already contemplates validating across four-plus WASM engines). That tension needs resolving before the AI architecture is fixed, and the resolution has large consequences for what the shipped AI can be.

7.2 The cut order, and where the cliffs are

Under budget pressure a team cuts in this order. I am confident of the order because it is the order of visibility, not the order of value:

1. Cascade rollout depth — 3 turns → 1 → 0.
2. Plan hypothesis count — 8 → 1.
3. Opponent modelling — dropped.
4. Belief maintenance (the unaccounted-strength prior, contact discs) — dropped, because it is the least visible.

The first two are phase changes, not degradations:

• At rollout depth 0 the AI is a greedy per-unit scorer and every exploit in §2 becomes trivially available at once.
• At one hypothesis the AI is deterministic (§3), and therefore maximally exploitable in a simultaneous-move game.

So the honest answer to "does it degrade gracefully on a phone" is no, not as currently shaped, because the AI's strength lives in exactly the two components that are easiest and most tempting to scale down, and both have cliffs rather than slopes.

7.3 Two design changes that make degradation graceful

Change the quality knob from depth of search to breadth of a plan library.

Precompute, offline in self-play, a library of parameterised operational plans: envelopment, fixing attack plus flank, screen-and-displace, siege set-piece, corridor cut, Depot raid, reserve consolidation. Each carries a cheap applicability test and a cheap scoring function.

• Full budget: evaluate 30 plans with a 3-turn rollout each.
• Phone budget: evaluate 6 plans with a 1-turn rollout each.

The AI is narrower, not dumber. The floor is "a competent operational plan, executed coherently" rather than "greedy per-unit scoring." That is the difference between a mobile AI that feels like a weaker opponent and one that feels broken.

This also fixes the difficulty-tier problem in §8.6 for free.

Amortise across turns. The AI is idle during the Cascade, during every other player's Orders phase, and — in correspondence play — for days. Mirror what the command layer already does for routes (CM-1470: recompute only when the cached next two tiles are invalid):

• Plan continuation is the default: keep last turn's plan, re-validate cheaply (≤ 20 ms), and only re-plan when validation fails.
• Full re-plan on a schedule (every k turns) or on a trigger: plan invalidated, major loss, Alarm-state change (§6.3), Warrant announced, front collapsed.

This turns a per-turn cost into an occasional cost and is the only way the 3-turn rollout survives on a phone at all.

7.4 What must be measured, and when

That last row is the one I would gate the mobile build on. It converts an argument into a number.

8. Evaluation blindness — how all of this ships anyway

This is the most dangerous section, because it is the mechanism by which every failure above survives to release.

8.1 Self-play measures relative strength, and blind spots are shared

Two AIs that both never buy reactions, never encircle, never cut supply, and both turtle will produce a perfectly balanced 50% win rate, healthy-looking game lengths, a clean ELO ladder, and green dashboards. The blind spot is shared, so it is invisible. AI-610's tier monotonicity (each tier beats the one below at ≥ 60% over ≥ 1,000 games) is satisfied trivially by a ladder of equally-blind agents differing only in search depth.

Every game-balance metric in the design set — TM §8's stance-fallback and posture distribution, CB §13's encirclement share and artillery ratio, economy.md §11's Cadre curve and Gini coefficient, VC §13's dead-time fraction — measures whether the game is working. Not one of them measures whether the AI is good. That gap is the whole problem, and it is currently unfilled anywhere in the document set.

8.2 The fix: Antagonists

For each named exploit class, write a fixed, deliberately stupid, scripted agent that does only that one thing. Each is on the order of a hundred lines. Run them nightly against every AI tier.

The pass condition is not "the AI wins." It is:

winRate(AI vs Antagonist_i) ≥ winRate(AI vs mirror) − 10 points, over ≥ 1,000 games per cell.

A gap larger than that names the exploit — you know immediately which representational hole you have, because the Antagonist only knows how to do one thing.

A new Antagonist is required whenever a human playtester finds a repeatable exploit. That rule is what keeps the suite alive; without it the roster ossifies at fourteen and the fifteenth exploit ships.

8.3 The league, and a stronger promotion gate

Self-play against a single incumbent overfits to the incumbent. AI-660's promotion gate — ≥ 55% against the incumbent over ≥ 1,000 games at p < 0.05 — is necessary and nowhere near sufficient.

Promotion should require all four:

1. ≥ 55% against the incumbent (the existing gate);
2. no regression against any Antagonist beyond the 10-point band;
3. no regression against any league member — the current AI, the previous three releases, and a set of deliberately skewed personas (all-armour, all-guns, turtle, rusher);
4. no regression on the exploit-specific behavioural metrics in §11.

Condition 2 is the one that catches "we improved the evaluation and accidentally deleted the reaction-valuation term."

8.4 There is no measurement of AI strength against humans anywhere in the design set

There must be, from the earliest playable build:

• A rated human ladder with a fixed benchmark AI build as the anchor, so AI strength is measured in the same units as human strength and regressions are visible as rating movement rather than as vibes.
• The uncomfortable metric: the fraction of human wins against the top AI tier in which the human made a repeated, identifiable mistake. If a human beats the top tier while playing badly, the AI is bad in a specific, findable way, and the replay names it.

8.5 Exploit mining from replays

The brief's fourth property — games are event-sourced, so every game is a replayable log — is not merely training data. It is an exploit detector, and this is exactly what it is for.

Build an offline miner that scans uploaded replays for repeated patterns preceding AI losses: an n-gram over (AI action class, opponent action class, outcome) sequences, flagging sequences whose conditional human win rate is anomalously high. Run it over public-beta replays. Every hit becomes a candidate Antagonist.

This costs a weekend and it is the only mechanism in the plan that finds the exploits nobody predicted — including the ones I have missed in §2.

8.6 Two traps that will hide the problem permanently

The cheat lever. The superseded spec sanctions handicap tiers beyond the top AI tier (AI-640: "Overlord + 2 extra cities + production advantage"). The moment the top tier loses to good humans, the team's instinct will be to reach for those, and the metrics go green because the cheating AI wins. This converts a strength problem into a fairness problem and hides the strength problem forever.

Hard rule: no handicap tier may ship until the un-handicapped top tier's win rate against the human ladder has been measured and recorded. The brief's own constraint — difficulty comes from better play — dies quietly the day this rule is not in place.

Determinism CI is not strength CI. AI-700's cross-engine determinism matrix is excellent and proves nothing whatsoever about play quality. A team with a fully green CI board will believe the AI is finished. Name the distinction in the AI spec so nobody has to learn it the expensive way.

8.7 One second-order consequence worth naming

VC §5 ships an estimated game length on the setup screen — median_turns[track][map_class][players] with 20th/80th percentiles, generated from ≥ 2,000 headless self-play games per cell — and linter rules L2 and L9 depend on the same data.

If the AI that generates that table is blind in the ways described above, the game's own setup screen lies to players, the Setup Linter fires on the wrong conditions, and nobody will ever connect either symptom to the AI. VC §12 already flags that the calibration table goes stale; the sharper risk is that it was never accurate, because the population that produced it could not play.

9. Difficulty tiers are built on the wrong axis

AI-610 scales difficulty by planning horizon, candidate breadth, and utility noise. Every failure in §2 is a representational failure, not a depth failure — more search over a model with no term for retreat degree finds no better answer, and more search over a threat model where fog is empty finds no flank.

So a depth-scaled ladder will compress at the top: Recruit and Overlord lose to A1 Blindfold, A4 Gravedigger, and A5 Clerk in exactly the same way, and the ladder is flat precisely where it is supposed to be steepest.

Scale difficulty by which failure modes are corrected instead. This is better on every axis, including AI-620's requirement that low tiers "fail plausibly, not absurdly."

A Recruit built this way fails like a beginner — no rear security, no screens, over-extends, walks into pockets — which is what AI-620 asks for and what a depth-scaled Recruit never delivers. And each tier's increment is separately testable against the Antagonist that targets it, which makes the ladder falsifiable rather than asserted.

10. The design set is not yet self-consistent, and the AI pays for it

This is not an AI failure. It is a project failure that will be charged to the AI.

Two combat models. units.md §3.2 specifies a repeated-round race — share = clamp(A × 1000 / (A + D), 50, 950), one hit per round until a side reaches zero, bounded by strikeRun — and tunes the entire 20-unit roster against it (§5.1's two laws, §5.2–5.4's worked examples). combat.md specifies the Clash: a single exchange, strength and disorder in 0–100, break checks, retreat, encirclement. These are not variants of each other. The roster's counter relationships (submarine vs sonar, bomber vs flak, infantry vs armour in the open) were validated under a resolution procedure that is not the one shipping.

Two economies. units.md has Industry 1–4, build points, and upkeep = ceil(cost / 20) charged per turn. economy.md has Works and Manpower, explicitly rejects per-unit upkeep ("Manpower-as-a-stock prices units once, at commissioning... A large surviving army costs nothing per turn"), and adds Integration, Unrest, Cadre and Reach. Also not variants.

Why this lands on the AI specifically:

• The AI's evaluation function is a function of all of these. Unit worth, city worth, the value of a battery, the cost of a capture — every weight.
• Self-play tuning against the wrong model produces confident, well-tested, wrong weights, and the confidence is the dangerous part. A tuned weight vector carries a promotion-gate p-value and a release note. It looks like knowledge.
• The first tuning cycle is thrown away, and with it the victory-length calibration table (VC §5), the linter thresholds (L2, L9), and any Antagonist calibration done against the old numbers.

Recommendation. The AI specification must declare version-pinned dependencies on 11-combat.md, 12-economy.md and 02-units-and-industry.md, and must not begin weight tuning until those three are consistent. Structural work — the planner, the belief filter, the Cascade rollout, the Antagonist harness — can and should proceed immediately, because none of it depends on the constants. Tuning cannot.

The smaller inconsistency worth flagging in the same breath: units.md §8's closing note reasons about the AI's position under the withdrawn creation-order activation queue ("newly built units always act last... high-tier units are structurally initiative-poor"). Under the settled model that counterweight is bounded to four turns of Forming Up (01-decision-turn-model.md). Any tech-pacing argument built on the old assumption needs redoing, and the AI's build-order weights are downstream of it.

11. The twelve changes, prioritised

Ordered by value ÷ cost. The first four are cheap and I would make them before writing a line of AI code.

12. Tripwires — the metrics that must exist before the AI is believed

Each row catches a specific failure above. All are computable from the event-sourced log; several exploit the deterministic core to run counterfactual replays, which is a testing asset most projects do not have and this one should use aggressively.

13. Where I am probably wrong

An adversary who cannot be wrong is not useful.

The Blindfold may be less severe than I claim, if estimated is interpreted narrowly — CB §10's L2 (adjacent: posture and works visible, strength ±15) is arguably a current observation, so a contact that approaches to adjacency resolves. My reading is that a contact held at range 3–5 never reaches L2 and therefore never resolves, which is the whole exploit. If the fog design makes L2 easier to reach than CB §10 suggests, the exploit shrinks. It does not vanish: the Survey exclusion (CM-500) still keeps the scout away, so the AI still cannot get to L2.

Mixing may be overkill for single-player. Most players will not exploit a deterministic AI systematically; they will lose to it and enjoy losing. The argument for mixing is strongest for the top tiers and for the small population of players who will grind an exploit — which is also the population that writes reviews and forum posts. I hold this position less strongly than the others, and the honest test is A10 Threshold's win rate with mixing on and off.

The Turtle Fixed Point might be a balance problem rather than an AI problem. economy.md §10 already worries that consolidation may be too dominant, and offers dials (raise the un-integrated Works floor from 20%, halve garrison requirements). If those dials move, the gradient the AI is following changes, and the AI stops turtling without anyone touching it. But the AI-side fix — treating victory as a schedule — is worth doing regardless, because an AI that cannot compute its own deadline is weak for other reasons too.

I may be over-crediting the Cascade rollout. I claim it is the design's largest advantage. It depends on enemy-order hypotheses being cheap and roughly right; if the hypothesis set is bad, a 3-turn rollout is 3 turns of confidently wrong. The mitigation is that even a self-only rollout — simulating my own orders against a static enemy — catches most compilation failures (§4.3), and that is worth having on its own.

The performance numbers are derived, not measured, and they inherit 03-architecture.md's own open question 21: AR-740, AR-760 and AR-770 were made consistent by derivation rather than by profiling, and the roadmap's Phase 1 re-baseline is where they meet a measurement. If the simulation-only per-order cost lands above 100 µs, the AI's rollout budget moves with it and §7's arithmetic must be redone. Nothing in §7's conclusions changes — route caching is still a precondition, the cliffs are still cliffs — but the specific counts do.

And the largest thing I cannot settle from a desk: whether an AI reasoning through a compiled Posture plan feels like an opponent. Every argument here is about strength. A strong AI that plays like a spreadsheet is a different failure than a weak one, and it is not one a red team catches. It is caught by a human sitting down and saying "that was a real war," and nothing in this document substitutes for that.