13 — Command at Scale

This document specifies how a player commands an empire of hundreds of units without spending the turn on clerical work: the order stack every unit carries, the six Postures that state a unit's standing job, the four Sanctions that let a player pre-decide what a unit may do on its own, Formations and Groups as command objects above the unit, Postings, Consignments and Requisitions that route production to the front without per-city clicks, the interruption model that governs what happens when a plan meets the world, and the Dispatch that surfaces the handful of units genuinely needing a person out of the hundreds that do not. It also fixes the boundary the whole subsystem exists to defend: which decisions belong to the player and which are arithmetic the game must stop charging the player to perform. Under the turn model of 10-turn-model.md an order is a policy evaluated at activation, not a recorded script; this document defines that policy vocabulary. It is therefore not a convenience layer — it is the mechanism that makes committing orders before seeing the turn a skill rather than a gamble, and it is named in docs/design/01-decision-turn-model.md as the single largest execution risk in the design.

Status: Draft v0.2 · Owner: unassigned · Depends on: docs/design/00-direction.md, docs/design/01-decision-turn-model.md, 10-turn-model.md (turn structure, initiative, activation order, Stance, reactions), the units specification (classes, movement, vision, strength), the combat specification (odds prediction, withdrawal, capture), the economy specification (production, supply, repair), 03-architecture.md (determinism, integer and Q16.16 arithmetic, seeded PRNG, canonical hashing), 04-ui-ux.md (client presentation)

Naming note, binding on this document only. Two vocabularies in this spec set both wanted the word posture. This document uses Posture for a unit's standing job (Hold, Garrison, Screen, Survey, March, Attach) and Stance for the per-turn tactical setting owned by 10-turn-model.md that sets a unit's initiative modifier and reaction capacity (March, Advance, Hold, Entrench). Where 10-turn-model.md names that setting differently, its name governs and every occurrence of "Stance" here refers to it. The source proposal also used Initiative for a Sanction; this document names that Sanction Leash, because Initiative is already the turn model's activation score and one word cannot carry both meanings.

1. The agency principle, and what it binds

Everything in this document descends from one line. It is stated first because it is the test every later requirement must pass, and because a subsystem that automates without a principle automates whatever was easiest to code.

A decision belongs to the player when two competent players would reasonably choose differently. Anything on which all competent players would agree is arithmetic, and making a player perform arithmetic is not depth — it is a tax on their time that the game collects and spends on nothing.

CM-010 The agency principle above MUST govern every automated decision in the simulation core. A behaviour that decides something on which two competent players holding the same information would reasonably differ MUST NOT be automated unconditionally; it MUST either be raised to the player as an Attention Event (§11) or be placed behind a Sanction (§5) that the player set in advance.

CM-020 Every automated decision MUST be classifiable into exactly one of three ledgers, and the classification MUST be recorded in the design record for that behaviour:

Rationale: the ledger classification is what makes the principle enforceable instead of decorative. Without it, "should this be automatic?" is settled per feature by whoever is writing that feature, and the answer drifts toward whatever the engine finds convenient. With it, adding an automated behaviour requires naming its ledger, and a Commitment-ledger entry that someone wants automatic must first be argued into the Sanctioned ledger — which forces the dial, the visibility, and the log entry that make delegation reversible.

CM-030 No automated behaviour MAY take an irreversible action that no Sanction authorises. For the purposes of this requirement the irreversible actions are exactly: initiating an attack; entering a tile in a way that changes a city's or work's ownership; abandoning a Garrison post; disbanding a unit; expending a limited-use capability; and unloading a carried unit onto a tile from which it has no legal move. Each MUST map to a named Sanction value in §5 or to an explicit player Task in §3.

CM-040 Automation MUST NOT silently stop. A unit that has made no progress against its Posture for two consecutive turns MUST raise a Stalled Attention Event (§11.3); a unit that is Idle MUST raise an Idle Attention Event on the turn it becomes Idle and every turn thereafter until it has a Posture.

Rationale: the worst automation failure is not a unit that dies, it is a unit that quietly does nothing for thirty turns while the player believes it is working. That failure is invisible, compounding, and destroys trust in the whole system the moment it is discovered — after which the player hand-orders everything and the subsystem has cost interface surface and delivered nothing.

CM-050 A player who commands every unit by hand MUST NOT be mechanically disadvantaged relative to a player who automates the same units to the same effect, and a player who automates MUST NOT be mechanically disadvantaged relative to one who hand-orders identically. Specifically: automation MUST NOT confer any combat, movement, vision, production, or information bonus, and MUST NOT cost a unit tempo that a hand-issued equivalent order would not cost (see Banked Movement, CM-1600).

Rationale: these are the two halves of the same contract and both must hold. If automation is stronger, agency is gone and the game plays itself. If automation is weaker, it is a trap, and a single bad outcome teaches the player never to use it again. Every default and every threshold in this document is calibrated against this requirement, and the Banked Movement rule exists solely because without it an automated unit that pauses to ask permission loses a turn a hand-ordered unit would not.

CM-060 Formations, Groups, Doctrines, Postings and Requisitions MUST NOT confer any combat, movement, vision, or production bonus of any kind. Their only benefit MUST be the reduction in orders issued and the role behaviours they express.

Rationale: the moment an aggregation confers a fighting advantage it stops being an offer and becomes a tax — every player must use it, and the choice evaporates. The command layer's value is that it saves clicks; if it also had to be used to win, we would have replaced micromanagement with mandatory bureaucracy.

CM-070 The command layer MUST be usable at any depth: a player MUST be able to issue every order by hand for the whole game, and the Dispatch (§11), Command View (§12) and audit trail (§12.3) MUST remain fully functional for such a player.

CM-080 A newly produced unit MUST require zero player input between its creation and the first genuinely open decision affecting it. Every unit MUST come into existence with a complete order stack derived from its producing city's Consignment (§8) and its type's default Doctrine (§6), and MUST NOT raise an Attention Event on its birth turn merely for existing.

CM-090 The number of Attention Events presented to a player per turn MUST NOT grow with the player's unit count. This is a measurable acceptance criterion: across a benchmark corpus the median count of presented items MUST be ≤ 5 and the 95th percentile ≤ 12, at every unit count from 20 to 400, with a regression slope against unit count statistically indistinguishable from zero.

2. Determinism, knowledge, and what automation may see

CM-100 All command-layer logic — Posture evaluation, Sanction tests, formation projection, reinforcement allocation, interruption handling, and every tie-break in this document — MUST live in the simulation core and MUST be identical for every player, every client, and every AI seat. A client MUST NOT be able to make its player's units decide better. Rationale: presentation quality is fair competition, like a better minimap; decision quality is not. If a better client made units fight better, the game is pay-to-win by build.

CM-110 The command layer MUST NOT draw from the seeded PRNG. Every automated choice MUST be a total, deterministic function of the acting player's knowledge view (CM-130) and the unit's committed order stack. Only combat resolution consumes randomness. Rationale: replay exactness aside, randomness in automation makes it feel capricious — a player who cannot predict what their own screen will do cannot delegate to it.

CM-120 The command layer MUST NOT use floating-point arithmetic, wall-clock time, entity allocation order, hash-map iteration order, or object identity in any decision. All scores, thresholds and probabilities MUST be integers, expressed per-mille where fractional (03-architecture.md AR-080 and the per-mille convention it establishes for Int). Where a ratio comparison is needed it MUST be performed by cross-multiplication rather than division.

CM-130 Automation MUST decide using only the knowledge view of the unit's owner: currently visible tiles and units, last-known observations with their observation age, last-known strength and composition estimates, and revealed terrain. It MUST NOT read the true world state for any tile or unit the owner cannot presently see and has not previously observed.

Rationale: fog-honest automation is the single largest guarantee in this document. It costs real competence — an automated column will sometimes walk into something a thoughtful player could have inferred — and that is the correct price. Automation that reads the true board is a wallhack the player did not ask for, it makes every automated success suspect, and it makes hand-ordering strictly worse, which violates CM-050 from the other direction. The visible consequence is that expert players will hand-order at the decisive point. That is the design working, not failing.

CM-140 For routing, an unrevealed tile MUST be treated as passable at an assumed movement cost equal to the cheapest cost the unit's movement class pays on any terrain it may enter, and as containing no enemy unit.

Rationale: this answers "what does a unit know about a multi-turn route through fog". Pessimistic routing (treating unknown as impassable) produces units that refuse to cross unexplored ground, which is exactly the behaviour a player would never choose. Optimistic routing produces units that set out and discover the truth, which is what a player does — and the Blocked handling in §9 catches the failure cleanly, suspending rather than destroying the order.

CM-150 Where a decision requires a combat prediction, the command layer MUST use the same deterministic predictor the client shows a player before a manual attack, evaluated over the knowledge view, returning an integer per-mille win probability in [0, 1000] together with an estimated flag.

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 value of 400‰. An Engagement Sanction of Favourable MUST NOT authorise an attack on an estimated prediction unless the unit's engageOnEstimates flag is set (default false). Engagement Free MUST ignore this restriction.

Rationale: 400 is below every offered preset, so the default behaviour of a unit that cannot see what it is attacking is not to attack. This is the cheapest possible guard against the most common automation disaster — a column that assaults a stale contact marker — and it costs nothing when the player does have eyes on the target. The flag exists because a raiding force deliberately operating blind is a legitimate style.

CM-170 Every tie in every command-layer selection MUST be resolved by an explicit, totally-ordered tie-break chain terminating in a value guaranteed unique. The terminal tie-breaks are:

CM-180 Order-stack contents, Postures, Sanction values, Doctrines, Formation and Group membership and orders, Postings, Consignments, Requisition rows and their allocation counters MUST be part of authoritative game state and MUST contribute to the canonical state hash. Attention Events, Dispatch ordering, adaptive player weights, snooze timers and Command View settings MUST NOT contribute to the canonical state hash.

Rationale: the split is what lets the ranking of attention improve over the product's life without invalidating a single saved game. What a unit will do is the game; which of those things you are shown first is the interface.

CM-190 Attention Events MUST nonetheless be emitted by the core, deterministically, and MUST be covered by a separate versioned advisory stream hash so that a divergence in what players are told is detectable in CI without coupling it to the rules hash.

3. The order stack

CM-200 Every unit MUST carry an order stack exactly three levels deep:

[2] Reflex    — pushed by the engine: Withdraw, Replenish, Regroup, Return to Post, Take Cover
[1] Task      — pushed by the player: a one-off instruction with an end condition
[0] Posture   — the standing order; the unit's job

CM-210 A unit MUST execute the topmost non-empty level of its stack at each activation. When a level's completion condition is met, or the level is cancelled, that level MUST be popped and the unit MUST resume the level below at its next evaluation within the same activation, without consuming an additional activation.

Ruled 2026-09-16 (Claude Code): a Reflex whose objective is already met completes at once. Sometimes a Reflex's pop condition (CM-1400) holds when the activation begins, and executing it produces no action. Then it pops at once, and the level below resumes in the same activation, as this requirement says of any completed level. CM-1400's "at the end of the first activation begun with no visible enemy …" still governs a Withdraw that has an enemy in view to put distance on: that Withdraw acts, and pops at the end. With no enemy in view there is nothing to withdraw from. Until this ruling, the activation was spent standing still. CM-660's Prudent test pushes a Withdraw on strength alone, so a weakened unit got one at every activation and never moved under its orders again while it stayed weak. Measured the same day over three Standard/4 games: 235 of 716 real fallbacks (10-turn-model.md TM-1440) were such Withdraws. One scout stood three turns on a 14-tile route until it was Stalled.

CM-220 Popping a level MUST NOT alter or clear the levels beneath it. A unit interrupted while executing a Posture MUST resume that Posture, with all its parameters intact, when the interrupting level pops.

Rationale: this is the single most important structural decision in the document. In the traditional model an interruption destroys the order and leaves a blank order-demanding object — at precisely the moment the player is busiest, which is why interruptions feel like punishment. Here a unit that withdraws under fire pops the Withdraw reflex when it is safe and goes back to screening the line it was screening, with no input at all. Suspension rather than destruction is what turns three hundred units into thirteen command objects.

CM-230 The stack depth MUST remain three. A behaviour that appears to need a fourth level MUST be expressed by projection (CM-880) or by an end condition on an existing level. Rationale: a deeper stack cannot be explained on a unit panel, and a player who cannot read the stack cannot audit the automation, which is the whole basis of trust here.

CM-240 The Posture level MUST NOT be empty except when the unit is deliberately Idle (CM-540). Setting a Posture MUST replace the previous Posture rather than stacking on it.

CM-250 A Task MUST carry: an action (move to, attack, garrison, load, unload, join formation, execute a named Posture once), a target or route, an explicit end condition, an optional pressHome flag, and an optional Stance override. A Task without an end condition MUST be rejected at submission.

CM-260 A Task MUST pop when its end condition is met, when it becomes permanently impossible (§9), or when the player cancels it. Task end conditions MUST be drawn from: onArrival, onTargetDestroyed, afterNTurns(n) with n in [1, 50], whileEnemyVisibleWithin(k) with k in [1, 16], and untilCancelled.

CM-270 An explicit player Task MUST be treated as its own authorisation for the action it names: the Engagement Sanction MUST NOT block an Attack Task, and the Seize Sanction MUST NOT block a Task that names a city as its destination.

Ruled 2026-09-16 (Claude Code): an Attack or works-strike Task out of reach closes on the cheapest reachable tile beside its target, and acts from there. The engine closed in along the path to the target minus its final step. The tile an attack aims at is occupied, and 01-game-rules.md GR-560 makes a hostile occupant's tile unenterable, so that path was never found and the unit never moved: in a real Small/2 game, an Attack on a visible infantry three tiles away left the attacker on its tile turn after turn, with no Clash and no fallback recorded. The approach is now the route to the cheapest tile within Chebyshev 1 of the target the unit can reach, ties by the lowest tile index (CM-1510). The action is named only when the move ends within reach, so a longer approach continues next turn instead of leaving a decision the engine cannot resolve.

CM-280 The Risk Sanction MUST continue to apply during a Task unless the Task sets pressHome = true, which MUST suppress Risk-driven Reflexes for the duration of that Task only.

Rationale: ordering an attack should not mean ordering a unit to die in it — a player's standing instruction about self-preservation is exactly the kind of thing they set once and expect to hold. But an assault that must go in regardless is a real order and the vocabulary must be able to say it. One boolean buys both, and its default (off) is the safe one.

CM-290 A Reflex MUST be pushed only by the engine, never by the player, and only for the causes enumerated in CM-1400. Exactly one Reflex MAY occupy the level at a time.

CM-300 When a second Reflex becomes eligible while one is active, the higher-priority Reflex MUST replace the active one and the replaced Reflex MUST be discarded, not queued. Reflex priority MUST be, highest first: Withdraw, Replenish, Regroup, ReturnToPost, TakeCover.

Rationale: survival outranks sustainment; a unit that cannot sustain itself cannot usefully hold formation; cohesion outranks returning to a post because the formation is the more immediate obligation; cover is last because it is the weakest and most easily re-derived. Discarding rather than queueing keeps the level at depth one and keeps the panel readable — and a discarded reflex whose cause still holds will simply be re-pushed at the next activation.

CM-310 Every unit MUST carry a Fallback Posture: a complete Posture-plus-Sanctions tuple, set once per unit, defaulting to Hold / Engagement Defend / Leash 0 / Risk Prudent(334) / Seize Never. The Fallback Posture MUST be adopted whenever an order becomes Impossible (§9) and MUST be shown on the unit panel.

Rationale: it is the answer to "what do I do when I no longer know what to do", chosen by the player in advance. It means an order that becomes impossible never produces surprising behaviour, and it means an absent player's units do something coherent instead of freezing.

CM-320 The complete order stack, including the Fallback Posture and all Sanction values, MUST be inspectable on the unit panel in plain language at all times, and MUST be editable at any level without disturbing the others.

4. Postures

CM-330 The Posture vocabulary MUST consist of exactly six Postures plus the Idle state. Adding a seventh Posture is a rules change requiring a commandLogicVersion bump (CM-2130).

Rationale: six, not twenty. Each is one sentence a player can hold in their head, and between them they cover every job a unit actually has in this game. A larger vocabulary would look richer and would be used less, because a player who cannot remember what the eleventh Posture does will not choose it. Richness lives in the Sanctions, which are four orthogonal dials rather than a longer list — four dials over six Postures is 6 × 4 axes of expression, which is far more than twenty named behaviours and far easier to learn.

CM-340 A Posture MUST be an order-policy in the sense of 10-turn-model.md: stored on the unit, evaluated when the Cascade reaches that unit, against the world as it then is, and persisting across turns until it completes or the player changes it. A Posture MUST NOT be stored as a recorded sequence of steps.

CM-350 Posture assignment MUST be validated at submission and rejected with a named, localisable reason when statically illegal — a Screen line shorter than two tiles, an empty Survey region, a Garrison target that is not a city or work, a March with zero waypoints, an Attach to a formation at its span limit, or a Posture the unit's class may not hold. An order that is legal at submission and unachievable at activation MUST NOT be treated as an error (§9).

CM-360 Every unit class MUST be able to hold Hold, March and Attach. Garrison MUST require the ability to occupy the target city or work. Screen MUST require a movement allowance of at least 1. The units specification owns any further per-class restriction.

4.1 Hold

CM-370 Under Hold a unit MUST remain on its assigned tile, MUST NOT voluntarily leave it, and MUST defend it. The assigned tile is the tile it occupied when Hold was issued, or the tile named in the order.

Ruled 2026-09-16 (Claude Code): a Hold left behind by a Task is re-issued where the unit stands. A Hold that names no tile sometimes governs a unit that stands off its assigned tile without having been displaced. Only the unit's own Task can have carried it there, because CM-380's three causes mark a displacement and a voluntary move does not (the ruling of 2026-09-05). So the Hold that resumes when the Task ends is a Hold issued where the unit stands, and that tile becomes the assigned tile. A Hold that names a tile keeps it, and a displaced unit still returns under CM-380. Until this ruling the Hold kept pointing at a tile the unit would never walk back to under its own Hold Stance (CM-390, 10-turn-model.md TM-690). 10-turn-model.md TM-1440 counted each such activation a fallback, and CM-1440 raised Stalled every turn. In a 100-turn Standard/4 game those were 367 of 583 real fallbacks, mostly heavy armour and Depots the Floor had sent somewhere. Measured the same day over 150 turns of one Standard/4 game with the rule off and on: real fallbacks fell from 1,489 to 682 (22.55% to 9.53% of activations), and Stalled from 1,009 to 390, of which those on a unit under a bare Hold fell from 848 to 31.

CM-380 A Hold unit that is displaced by a Reflex, a retreat, or an external effect MUST push a ReturnToPost Reflex, and MUST be permitted to move to its assigned tile regardless of its Leash value.

Rationale: the Leash constrains where a unit may choose to go, not where it may go back to. A Leash of 0 that forbade a displaced garrison from walking home would make the tightest setting the most fragile one, which is precisely backwards.

Ruling, 2026-09-05: the three causes are exhaustive, and a voluntary move is not one of them. The implementation currently pushes ReturnToPost on a purely positional test — any Hold or Garrison unit standing off its assigned tile — so a Task that legitimately moves such a unit is answered by a Reflex that shadows the Task and walks the unit back a tile a turn. A unit that visibly argues with its own orders reads as a defect to the player, and nothing in this requirement's list admits it.

displaced is a property of how the unit left, not of where it now stands, and it persists until the unit regains its post rather than resetting each Cascade. The engine must therefore record the cause: a Reflex that moved the unit, a retreat or rout (11-combat.md CB-1040), or an external effect. A unit that walked off under a Task is not displaced and pushes nothing.

Code follow-up, applied 2026-09-07: the displaced marker is a persisted, hashed field on the unit — set by a Reflex's route, a retreat or rout, or an external effect, and cleared when the unit lands on its assigned tile — and the ReturnToPost push test reads it together with the off-post test. A voluntary walk-off sets nothing and pushes nothing.

CM-390 A Hold unit MUST derive Stance Hold, or Stance Entrench when it has occupied its assigned tile without moving for at least one complete turn and its Engagement is Never or Defend.

Rationale: entrenching costs initiative and buys defence and a reaction, which is exactly the trade a unit whose job is to stay put should take — and the one-turn delay makes it a consequence of having actually held rather than a free bonus for declaring an intention.

4.2 Garrison

CM-400 Under Garrison a unit MUST occupy the named city or work, MUST defend it, MUST return to it by the cheapest route when displaced (via ReturnToPost, permitted regardless of Leash), and MUST accept repair or resupply while stationary and undamaged-elsewhere-idle if the economy specification offers it at that place.

CM-410 A Garrison unit MUST NOT abandon its place under any Sanction. Abandoning a garrison is a Commitment-ledger action (CM-020) and MUST require an explicit player Task or a Posture change.

CM-420 A Garrison unit whose place is captured or destroyed MUST treat the order as Impossible (§9) and adopt its Fallback Posture.

CM-430 Garrison MUST derive Stance Hold while in place and Stance Advance while returning to place.

4.3 Screen

CM-440 A Screen order MUST carry a line: an ordered list of 2 to 64 tiles defining a frontage. The tiles need not be contiguous and need not be passable to the screening unit.

CM-450 A line tile MUST be considered covered at an instant if it lies within the vision radius of any unit belonging to the screening unit's owner, evaluated at that unit's position as of that instant in the Cascade.

CM-460 At each activation a screening unit MUST select its destination as follows, using only integer arithmetic:

1. Build the candidate set: tiles the unit can legally reach within its remaining movement allowance this activation, that lie within Leash tiles (Chebyshev) of the nearest line tile, and that it may legally occupy under stacking rules. The unit's current tile is always a candidate.
2. Exclude candidates that the Risk Sanction forbids (CM-680).
3. Truncate the candidate set to at most 256 entries, ordered by ascending movement cost then ascending tile index (CM-2180).
4. Score each candidate as the number of line tiles that would be covered from it and are not already covered by another friendly unit at that instant.
5. Select the highest score; ties break by lowest movement cost to reach, then by lowest tile index.
6. Apply hysteresis: the unit MUST relocate only if the selected candidate's score is at least 2 greater than the score of its current tile. Otherwise it MUST remain in place.

CM-470 When no candidate covers any line tile, a screening unit MUST move along the cheapest route toward the lowest-indexed uncovered line tile, spending at most its remaining allowance, and MUST NOT be considered stalled while the remaining route cost is decreasing.

Rationale for the whole of §4.3: a Screen is a coverage goal, not a patrol route, and that is what makes it degrade gracefully. Several units on the same line spread out for free, because a tile a comrade already covers scores nothing extra; when one dies the survivors re-spread to cover the gap without being told. The hysteresis threshold of 2 is the load-bearing number: at 1, units shuffle one square sideways every turn as fog moves, which looks broken even when it is optimal, and shuffling costs the reaction a Hold stance would have given them. At 3 or more the line responds too slowly to a genuine gap. Two is one more tile of coverage than the noise floor and one less than a real gap.

CM-480 Screen MUST derive Stance Hold when the unit did not relocate at its previous activation, and Stance Advance otherwise. Rationale: a screen that has settled is exactly the thing that should hold a reaction, and paying the initiative cost for it is the correct trade; a screen still finding its position cannot also be watching.

4.4 Survey

CM-490 A Survey order MUST carry a region: a set of 1 to 4096 tiles.

CM-500 At each activation a surveying unit MUST select its destination as follows:

1. Build and truncate the candidate set as in CM-460 steps 1–3, substituting the region for the line and using Leash measured from the region boundary.
2. Exclude any candidate within one turn's known movement of a visible enemy the unit does not beat at its avoidance threshold, where the avoidance threshold is the unit's Favourable per-mille value if Engagement is Favourable, 700‰ if Engagement is Never or Defend, and avoidance is disabled entirely if Engagement is Free.
3. Score each candidate as the count of currently-unrevealed region tiles that standing there would reveal.
4. Prefer the candidate maximising revealed tiles per movement point, compared by cross-multiplication: candidate A beats B when scoreA × (costB + 1) > scoreB × (costA + 1). Ties break by lower cost, then by lowest tile index.

CM-510 A Survey MUST raise an Arrived interruption when the region contains no reachable unrevealed tile.

CM-520 Survey MUST derive Stance March. Rationale: coverage per turn is the entire job, the unit is deliberately not fighting, and a scout that keeps a reaction it will never profitably spend has bought nothing with the initiative it gave up.

4.5 March and Ferry

CM-530 A March order MUST carry: an ordered list of 1 to 16 waypoints; a cached route; a follow-on order (a complete Posture tuple, or Fallback, or Attach to a named formation); and a loop mode of Once, Shuttle, or Circuit. Shuttle and Circuit together constitute the Ferry variant.

CM-535 A Ferry unit with carrying capacity MUST, on reaching a terminal waypoint, first unload every carried unit whose destination is that waypoint, then load waiting units bound along the route up to its remaining capacity, in ascending creation sequence number. Loading and unloading on a stated route is Execution-ledger work (CM-020) and MUST require no player input.

Ruled 2026-09-16, when it was first built. CM-530's loop modes had long moved a carrier back and forth between its waypoints, and nothing boarded or landed on the way — while 06-ai.md's floor gave every Transport a Shuttle on the strength of this requirement, so every AI transport crossed empty. The readings below are binding.

1. Every waypoint of a Ferry's route is a terminal, and the Ferry calls at one only where it has business: cargo to land there, or a unit there waiting to board. A waypoint placed only to steer is passed through. To call is to end the activation's movement on the waypoint and make the exchange at the start of the next activation, standing on it. A route is planned before it is walked, and nothing can board a ship that has not arrived. A call that exchanged anything consumes its terminal at once, so a Shuttle at the end of its line turns about in the same activation.

2. A unit's destination is its own order's: the target of a MoveTo, Garrison or Attack Task, or the next waypoint of a Once March. Its stop is the route waypoint nearest that destination, ties by the lower tile index. Cargo "whose destination is that waypoint" is cargo whose stop it is. A unit with no destination is bound nowhere and never boards.

3. A waiting unit is one of the Ferry owner's land units standing where 01-game-rules.md GR-640 lets it embark — on the carrier's Port tile, or on land beside the water tile the carrier is on, with the diagonal respecting GR-490. It is bound along the route when its stop is strictly nearer its destination than the terminal it stands at. That is read geometrically, not by asking whether the unit could walk: under fog CM-140 makes every unrevealed tile passable, so almost any destination looks walkable early in a game, and a Ferry that boarded only the provably stranded would carry nobody. A unit of another player, allied or not, is never boarded by automation it did not order.

4. Landing follows the Unload Task's GR-640 legality: the carrier's Port tile, or a land tile beside it that the cargo may enter, with the diagonal respecting GR-490. Of those, the cargo lands on the one nearest its destination, ties by the lower tile index. Only land cargo is ferried, because GR-640 speaks of land units. A Ferry landing is not a displacement under CM-380: the unit boarded because its own order was bound there, so it left its post by that order. If it were marked displaced, it would push ReturnToPost over the order and try to walk home across the water it had just crossed — which is what the first test run did.

CM-540 A unit with an empty Posture level MUST be Idle. Idle MUST NOT be reachable except by the player explicitly clearing a Posture, MUST NOT be a resting state, and MUST raise an Idle Attention Event every turn until a Posture is set. Rationale: there is to be no way to have a quietly forgotten unit. Idle is deliberately uncomfortable.

CM-550 March MUST derive Stance March when the unit's Engagement is Never or Defend, and Stance Advance when it is Favourable or Free. Rationale: a column that is authorised to fight on the way must be able to fight on the way, and Stance March forfeits that; a column that is not authorised to fight should buy the movement and initiative instead.

CM-560 A player MUST be able to override any unit's derived Stance for a turn as an annotation on the Task level, and the override MUST be shown on the unit panel with the derived value it replaced.

Ruled 2026-09-16 (Claude Code): the client adds this annotation itself to an order that walks, where the unit's Stance is derived. A player's MoveTo, Load or Unload carries Advance unless the unit has a Stance the player set with SetStance. The starting force holds under a Hold Posture, so its Stance is a derived Hold, and 10-turn-model.md TM-690 refused the first order anybody gave — select a unit, send it somewhere — from 2026-09-08 until this ruling. The client's Attack and WorksStrike already carried the annotation, as does every Constraint Floor MoveTo. A Stance the player set is left alone: a chosen March or Advance walks on its own terms, and a chosen Hold or Entrench is refused with the message that says how to change it, because walking a unit out of a dig-in the player ordered would undo their decision. The panel's Task level names the annotation beside the derived Stance it replaced, as this requirement asks.

5. Sanctions

CM-570 Every Posture MUST carry exactly four Sanctions — Engagement, Leash, Risk, Seize — which MUST be displayed in plain language on the unit panel whenever the unit is selected, and MUST be editable individually without changing the Posture.

Rationale: this is the whole answer to "the game played itself". It did not: the player wrote the rule and the game applied it. When a Sanction produces a bad outcome the player does not lose faith in automation, they tighten one enum — because they can see exactly which clause fired and what the numbers were. Delegation becomes gradual and reversible instead of a binary leap of faith, and that is the difference between an automation feature players use and one they abandon after the first disaster.

5.1 Engagement — when may this unit start a fight?

CM-580 Engagement MUST take one of four values:

CM-590 Favourable(N) MUST accept any integer N in [1, 999]. The default MUST be 700. The offered presets MUST be Trade 600, Even-handed 700, Careful 850.

Rationale for 700: a unit that fights ten sanctioned engagements at 700‰ wins seven and loses three. That is a good trade for a cheap screening unit and a bad one for something expensive, which is exactly why the number lives on the unit rather than in a global setting. It is also high enough that a player watching automation win seven fights in a row does not conclude the automation is reckless, and low enough that a screen actually picks off stragglers rather than standing inert — the failure mode at 850 as a default would be a screen that never fights, which reads as broken.

CM-600 An automated attack MUST record the predicted per-mille value and the threshold that permitted it, in the form "Attacked at 743‰ predicted; sanctioned at ≥700‰" (CM-2020).

CM-610 When more than one target satisfies Engagement in the same activation, the target MUST be selected by: (1) highest predicted per-mille; (2) a target inside the unit's assigned geometry over one outside it; (3) lowest target creation sequence number.

CM-620 Engagement Never MUST cause the unit to prefer, among otherwise-equal candidate destinations, the one maximising the Chebyshev distance to the nearest visible enemy.

5.2 Leash — how far may it leave its assigned geometry?

CM-630 Leash MUST be an integer Chebyshev radius in [0, 64], measured from the unit's assigned geometry: its assigned tile for Hold and Garrison, the nearest line tile for Screen, the region boundary for Survey, the cached route for March, and the Command Reference Point for Attach.

CM-640 The offered presets MUST be Tight 0, Local 4, Loose 12, and the player MUST be able to type any integer in range.

Rationale: 4 is roughly two turns of movement for a typical ground unit, which lets one screening unit cover a nine-tile frontage from its centre; 12 is three times that and is a scout's leash — far enough to follow a promising direction, short enough that the unit is still recognisably where you put it. Tight 0 exists so that "stay exactly there" is expressible without inventing a Posture for it.

CM-650 A Leash MUST constrain voluntary movement only. ReturnToPost, Regroup, and Withdraw Reflexes MUST be permitted to exceed it, and the excess MUST be shown on the unit panel while it persists.

5.3 Risk — when does it break off and preserve itself?

CM-660 Risk MUST take one of three values:

CM-670 Prudent(N) MUST accept any integer N in [1, 999]. The default 334 expresses "reduced to a third of strength or less".

CM-680 Threat radius MUST be defined, for a visible enemy e, as the last-known movement allowance of e clamped to [1, 6]. Where no movement allowance is known, the threat radius MUST be 2.

Rationale: threat is "can it reach me before I act again", which is the enemy's movement, not an arbitrary constant. Clamping at 6 keeps a single very fast unit from making a whole theatre nervous; the fallback of 2 is one more than adjacency and is the conservative default for an unidentified contact.

CM-690 For Cautious, "does not beat" MUST use the unit's Engagement per-mille value when Engagement is Favourable, and 700‰ when Engagement is Never or Defend. Cautious with Engagement Free MUST apply only the Prudent(N) test.

Rationale: Screen pairs Favourable with Cautious by default, and that pairing is the whole behaviour of a screening force — pick off stragglers, evade columns. Neither dial produces it alone.

5.4 Seize — may it take an undefended city it walks past?

CM-700 Seize MUST take one of three values:

CM-710 The default for Survey and March MUST be Undefended; for Hold, Garrison and Screen it MUST be Never.

Rationale: this is the one default sitting on the permissive side of the line, and CM-050 is the reason. If the default were Never, an automating player would watch an empty city and lose it while waiting to be asked — which makes automation measurably worse than hand-play and poisons the whole system. Capturing a genuinely undefended city is a case where all competent players agree, so by CM-010 it is arithmetic. It remains a Sanction nonetheless: visible, revocable, logged. The principle is preserved; only its default differs. The honest cost is that fog-honesty means "undefended in the knowledge view" is sometimes wrong, and a unit will occasionally walk into a garrison it could not see. That is the price of CM-130 and it is the right price.

CM-720 Seize: Free MUST NOT authorise an attack that Engagement forbids. The two Sanctions MUST both be satisfied.

CM-730 After a sanctioned capture the capturing unit MUST push a Task Garrison <place> until relieved, MUST raise a CityTaken Attention Event offering release it back to its Posture and requisition a garrison, and the capture MUST insert a shortfall entry for one garrison-capable unit into the Requisition of the Posting the unit is posted to, if any.

Rationale: leaving a captured city empty loses it, so the unit must hold. Permanently converting a scout into a garrison is a Commitment-ledger decision, so the player must be asked. Raising a Requisition entry converts the nag into a request production can actually satisfy, which is the difference between an item that resolves itself and one that sits in the Dispatch forever.

Ruled 2026-09-16: the garrison that is pushed off its city. A retreat or a Reflex can move the capturer off the city it holds, and the Task never said what happens next. First the unit's walk home, under the Hold its Posture derived, ended the game on 10-turn-model.md TM-690's invariant. Then, once the policy refused that walk, it waited where it was. Now it walks home and holds: the Garrison Task derives Advance while off its place (TM-710 clause 2, CM-430's returning case) and adds nothing once there. If the city is lost, the Task is Impossible under CM-1340's own "garrison place captured" row. That row was checked until then only for the Garrison Posture. So the unit adopts its Fallback and its owner is told, rather than the Task walking it back into a city its owner no longer holds. That entry would be an irreversible action, and no Sanction authorised it (CM-030).

5.5 Defaults, presets, and precedence

CM-740 Posture defaults MUST be exactly:

Rationale: Garrison is Expendable because a garrison that runs away is not a garrison — the one place where "never withdraw" is the correct default, because the alternative loses the thing being garrisoned. March's Leash of 2 rather than 4 keeps a column recognisably on its route; a marching unit that wanders four tiles for an opportunity is a column that arrives late.

CM-750 Three named presets MUST be offered, applied as transforms over the Posture defaults rather than as absolute tuples:

Rationale: four dials over six Postures is real learnability cost. Presets are the progressive-disclosure answer: a new player picks one of three words, an experienced player opens the dials. Expressing presets as transforms rather than absolutes preserves the Posture-specific reasoning behind each default — Careful applied to a Garrison must not quietly make it withdraw.

CM-760 Sanction precedence MUST be, strongest first: an explicit per-unit override; a Formation projection (CM-880); the unit type's default Doctrine; the Posture default. The effective value and the level that supplied it MUST both be shown on the unit panel.

6. Doctrines

CM-770 A Doctrine MUST be a named, player-created bundle of: a Posture template, all four Sanction values, an optional Formation role, and an optional Stance override. Doctrines MUST be part of authoritative game state (CM-180).

CM-780 A Doctrine MUST be applicable in one action to a unit, to a multi-unit selection, to a Formation, or as the default for a unit type.

CM-790 Every unit type MUST have a default Doctrine, settable in one panel, applied automatically at unit creation.

CM-800 Editing a Doctrine MUST NOT retroactively change units already created under it. The editor MUST offer an explicit apply to the N units currently on this Doctrine action stating N.

Rationale: silently retasking three hundred units because a dial moved is exactly the kind of unsanctioned mass action CM-030 forbids, and it is the fastest possible way to destroy trust in the system. Making the retroactive apply explicit and counted costs one click and makes the consequence legible before it happens.

CM-810 A Doctrine MUST NOT be able to express a Posture parameter that is unit-specific — a specific Screen line, Survey region, or March route. A Doctrine's Posture template MUST supply those from the Posting (§8) or leave the unit Idle if none is available.

CM-820 Deleting a Doctrine MUST NOT alter any unit currently running it; such units MUST retain their current effective values as per-unit overrides.

CM-830 The client MUST show, for every Doctrine, the count of units currently running it and a one-action selection of those units.

7. Formations and Groups

7.1 Definition

CM-840 A Formation MUST be a named set of units with one designated commander and one order stack, and MUST be a command relationship only: members MUST retain their own tiles, movement, vision, combat resolution and losses. No super-unit representation may exist.

Rationale: no doom-stack. Positioning still matters, and losing a formation is a series of events a player can watch and react to rather than one catastrophic roll. It is also why CM-060 can forbid a combat bonus without gutting the feature — the benefit is one order instead of eight, and that is enough.

CM-850 A Formation MUST have a span of control of 8 members. Adding a ninth MUST be rejected at submission with a named reason and an offer to split the Formation or promote it into a Group.

Rationale: eight rows is a formation panel readable without scrolling, and span-of-control practice across every real hierarchy clusters between three and nine. If the units specification later gives some unit types a command rating, span becomes per-commander data and 8 becomes the default when it does not.

Note, 2026-09-11, on the rationale's conditional. 02-units-and-industry.md's class schema does carry a commandRating field — and it is null on all 23 shipped classes, and nothing reads it. So the flat 8 is not a placeholder waiting for a rating; it is the rule on this requirement's own terms ("8 becomes the default when it does not"). Two things are still needed before span could become per-commander data, and neither exists: a roster that states a rating, and a requirement stating how span derives from it — a formula, a range, and what a rating of 0 means. The engine holds the 8 in one named constant used in one place, so that derivation replaces a single expression when it is stated (turn/orders-vocab.ts).

CM-860 A Group MUST command up to 5 Formations and MUST NOT contain units directly. Nesting MUST be exactly two echelons: units in Formations, Formations in Groups. A Group MUST NOT contain a Group.

Note, 2026-09-11. Implemented, which makes CM-850's refusal honest for the first time: that clause offers "an offer to split the Formation or promote it into a Group", and until this increment there was no Group to promote it into. A Group whose membership falls to zero is deleted, on the CM-1110 reading — that requirement names a Formation and says nothing about a Group, and the same answer is taken for the same reason: a command object with nothing to command is an entity a player can select, name and order, and which does nothing. Succession follows CM-170's "lowest entity id", which that table already states for Groups.

Rationale: two echelons cover 40 units per Group and 400 units in ten Groups, which is past the top of the expected late-game range. A third level cannot be navigated at speed, and the whole point is that the empire is never more than about ten top-level objects.

CM-870 A Formation MUST be able to hold Postures Hold, Screen, Survey, March (including Ferry loop modes) and Attach. Garrison MUST be unit-only. A Group MUST be able to hold Hold, Screen and March.

7.2 Projection

CM-880 A unit whose Posture is Attach MUST derive its effective Posture-level order by projection: the Formation's entire order stack collapses to a single projected order occupying the member's Posture level. The member's Task and Reflex levels MUST remain available and MUST outrank the projection.

Rationale: this keeps the stack at three (CM-230) while letting a formation member simultaneously carry a formation intent, a personal order, and a reflex. It also produces the behaviour a player expects without being told: an order given directly to a unit overrides its formation's, and a reflex overrides both.

Consequence recorded 2026-09-11, because it crosses into 10-turn-model.md and neither document states it. A member's derived Stance follows the projection. TM-710 derives a unit's Stance from its Posture and names no derivation for Attach, so a member fell to precedence 3 and derived Advance — and Advance permits initiating combat where March does not (TM-670). A Van projected to March would therefore have been allowed to attack, which TM-670 forbids for a March and CM-910 forbids for a Van twice over. Since this requirement makes the projection the member's Posture level, the derivation reads the projected kind, which is a pure function of the Formation's intent kind and the member's role and needs no map — so it is available at the freeze where TM-710 step 1 runs (turn/stance.ts). The Advance fallback survives only for a member whose Formation projects nothing at all.

CM-890 Projection MUST assign each member a per-role order according to the following table:

Gap, flagged for the spec owner 2026-09-11. CM-870 permits a Formation to hold Survey, and this table has no Survey column — so a Formation may legally be ordered to Survey and no rule says what its members then do. Refusing the order would contradict CM-870's MUST, so the engine accepts it and the projection resolves to nothing: the members hold position, and a test pins that rather than leaving it to be met as a bug (turn/formations.test.ts). A Survey column, or a sentence excluding Survey from CM-870's list, closes it.

Readings recorded 2026-09-11 (also at the implementation site, turn/projection.ts), because the cells' words do not determine these:

1. "1–2 tiles" is a range, not a distance. CM-920 makes the target "the cheapest legal tile at the stated offset", so 1 and 2 are both candidates and the cheaper wins, with the lower tile index breaking a tie. Read as "2, falling back to 1" the range would be decorative, and rough ground between the anchor and the post could not pull the post in — which is the only reason to state a range at all. The Rear's "1–2" and the Train's "at least 2" then differ as the table intends, and "at least 2" is implemented as the range 2–3 rather than unbounded, because an unbounded range has no cheapest element on an open map.

2. The March offsets displace the destination, not the whole route. A Van "March the route offset 1–2 tiles ahead" takes the Formation's route with its last waypoint pushed further along the final segment's direction; the intermediate waypoints are the Formation's. Giving each role its own parallel route would be five routes and five sets of terrain luck, and a Formation marching one route is the feature. The Train's "MUST NOT lead" is then structural rather than checked: a reciprocal offset of 2 or more cannot place it ahead of the destination.

3. "Behind" is the reciprocal of the facing — direction (d + 4) mod 8 in GR-160's fixed order — and "ahead" is the facing itself. "Offset perpendicular" is a quarter turn, (d + 2) mod 8; which of the two perpendiculars is "outward" is not stated, so it is the one whose first line tile has the lower index, which is CM-920's own tie-break rather than an arbitrary choice.

CM-900 Role slot counts MUST be constrained: Main ≥ 1, Van ≤ 2, Rear ≤ 2, Flank ≤ 4, Train ≤ 4, total ≤ 8. A Formation created without an explicit assignment MUST place every member in Main.

CM-910 The Van role MUST force Engagement Defend and Risk Cautious on its members regardless of Doctrine, and this MUST be shown on those units' panels as a role override.

Rationale: the vanguard is there to find things, not to fight them. A Van that engages is a Van that is dead before it has reported, and the whole value of the role is the report.

CM-920 Offsets in CM-890 MUST be resolved to concrete tiles deterministically: the offset direction is the direction of the next route segment (for March) or the Formation's stored facing (for Hold and Screen); the target tile is the cheapest legal tile at the stated offset; ties break by lowest tile index.

Reading recorded 2026-09-11. "Cheapest" is measured from the origin — the anchor, the line tile or the route's destination — and not from the member. The clause says "the cheapest legal tile", which is a property of the tile; measuring the cost to reach it from whichever unit is asking would make a role's post move when the unit holding the role was replaced, and would let the Rear and the Train resolve to the same tile from opposite sides. The mover is still the member, because what ground costs depends on the class crossing it. Measured from the member first, and the tests caught it: the Rear and the Train landed on each other. "Legal" is read as on the map and occupiable under the stacking rules (CM-460 step 1's own test), evaluated in the knowledge view (CM-130) — a Formation cannot post its Van onto ground the player has never seen. A property sweep pins all of it (turn/projection.test.ts).

CM-930 A Formation MUST store a facing: one of the eight movement directions, defaulting to the direction of the Formation's most recent movement and settable by the player.

7.3 The Command Reference Point and Intent Freshness

CM-940 A Formation MUST have exactly one commander, a designated member. On the commander's death, succession MUST pass to the surviving member with the lowest creation sequence number whose role is not Train; if every survivor is Train, to the lowest creation sequence number among them.

Rationale: sequence number is unique, so succession is total and needs no further tie-break; and an older commander is a more responsive one under CM-960, so the rule that is easiest to compute is also the one that produces the better formation.

CM-950 The Command Reference Point (CRP) MUST be the commander's tile as of the commander's last completed activation. Cohesion, offsets, and Leash for Attach MUST all be measured from the CRP.

CM-960 A Formation member MUST execute the Formation's intent as of the commander's last completed activation. Concretely: the engine MUST snapshot the Formation's projected intent and CRP at each commander activation; a member activating after the commander in the current Cascade MUST read this turn's snapshot, and a member activating before it MUST read the previous snapshot.

CM-970 A Formation created or re-ordered during an Orders phase MUST have its snapshot taken at commit time with the current turn's epoch, so that every member is responsive on the Formation's first turn.

CM-980 Where the commander died before activating in the current Cascade, members MUST continue to read the last snapshot taken by the dead commander until the successor completes an activation.

CM-990 The Formation panel MUST state, at all times and in words, whether the Formation is Responsive (commander activates before the majority of members) or One turn behind (it does not), together with the reason.

Reading, flagged for the spec owner, 2026-09-11 (recorded at the implementation site in turn/formations.ts). "The majority of members" does not say whether the commander is one of them, and the two readings differ for every even-sized Formation. The derivation reads it as strictly more than half of the other members: the commander is excluded from the set it is compared against, because including it makes a Formation of one unanswerable and makes a two-member Formation turn on whether a commander counts as its own majority. A Formation whose commander is its only member is therefore Responsive — there is nobody to be behind. The derivation also answers two states the requirement does not name, because a panel that must speak "at all times" needs them: a Formation with no snapshot yet, and one whose commander is dead (CM-980's window). The panel words are the client's; what landed here is the derivation and its test.

Rationale: command lag falls out of the initiative ordering for free and is elegant enough to adopt deliberately — putting an old unit in charge makes a Formation responsive; promoting a freshly built unit to command makes it sluggish; losing a veteran commander has a felt cost beyond the unit. It is fully deterministic, costs nothing to compute, and explains itself in one sentence. Its one risk is that it is invisible unless the UI says so, at which point a lovely rule becomes a bug report. Hence the MUST on the panel.

7.4 Pace and cohesion

CM-1000 A Formation MUST have a Pace of Concentrated or Dispersed, defaulting to Concentrated.

CM-1010 Under Concentrated, a member whose Chebyshev distance from the CRP exceeds the Formation's cohesion radius MUST be pushed a Regroup Reflex. The cohesion radius MUST default to 3 and be settable in [1, 8].

CM-1020 Under Dispersed, cohesion MUST NOT be enforced and Regroup MUST NOT be pushed for cohesion reasons.

Rationale: this is the classic operational trade — concentration versus tempo — expressed as one toggle. Concentrated advances at the speed of its slowest member and arrives as a fist; Dispersed arrives piecemeal but its fastest elements arrive far sooner. It means the command layer adds a decision rather than only removing clicks, which is the difference between a strategy feature and an accessibility feature.

CM-1030 A Regroup Reflex MUST move the unit along the cheapest route toward the CRP and MUST pop when the unit is within the cohesion radius.

Readings recorded 2026-09-11. The route stops at the first tile inside the radius, rather than running to the CRP: that tile is where this requirement pops the Reflex, so walking past it is a member the Formation has to pull back next turn. And the Reflex also pops where cohesion stops applying at all — the unit left the Formation, or the Formation's Pace turned Dispersed (CM-1020) — which is CM-300's "the cause still holds; the Reflex stays" read in the other direction; the alternative is a unit walking toward a command point that no longer commands it. The pop's timing is CM-1400's and is unchanged: the condition is evaluated at the start of an activation, so a unit that arrives inside the radius during one activation pops at the end of the next (pinned, because a first draft of the test expected it a turn earlier).

CM-1040 A member that cannot reach the cohesion radius within two turns of movement MUST raise a FormationStrung Attention Event once per occurrence, deduplicated by Formation.

Readings recorded 2026-09-11 (and at the implementation site, turn/formations.ts and turn/interruption.ts).

1. "Two turns of movement" is this member's two turns — twice its own effective allowance, not the Formation's slowest member's. The requirement's subject is the member ("A member that cannot reach…") and the event names a member; CM-1000's rationale about a Concentrated Formation advancing "at the speed of its slowest member" describes what emerges from cohesion, not whose allowance measures it. The other reading would report a fast scout as strung because the Train it shares a Formation with is slow, which inverts the event's meaning.

2. The measure is steps along the route the Regroup will actually take. CM-1030 sends the unit "along the cheapest route toward the CRP" and pops it inside the radius, so reachability is measured along that route, stopping at the first tile that satisfies the pop. The alternative — the cheapest route to any of the up-to-289 tiles within a radius of 8 — is 289 route queries per strung member per activation against 03-architecture.md AR-770's throughput budget, and it would measure a route the Reflex is not going to take.

3. "Deduplicated by Formation" is delivered through the cause key, and it constrains the cause tile. CM-1700 merges items on (class, causeEntityId, causeTileClusterId), so the Formation id in causeEntity is not sufficient on its own: members strung in different directions, each raising the event at its own tile, would share a class and an entity and differ in the tile, and the player would get one item per member about one Formation. The event is therefore raised at the Formation's CRP, which every member shares, and CM-1710's union then gives the merged item all of the affected units. A test asserts the single cause key across two members strung on opposite sides (turn/formations-cohesion.test.ts).

7.5 Under-strength Formations

CM-1050 A Formation on Screen MUST be considered under-strength when, after every member has activated, the count of uncovered line tiles u and the line length L satisfy u × 4 > L.

CM-1060 An under-strength Screen MUST NOT fail. It MUST provide partial coverage per CM-460, MUST raise a single sticky FormationUnderStrength Attention Event, and MUST insert a shortfall entry into the Requisition (§8.4) of the Posting the Formation is posted to, if any.

Rationale: the alternative answers are both worse. Failing the order strands the formation. Raising a fresh item every turn is a nag the player learns to dismiss, which trains them to dismiss the category. Converting the shortfall into a Requisition entry means production reacts and the item resolves itself, which is the only outcome that respects the player's time.

Readings recorded 2026-09-11, when this requirement was implemented. Two.

1. "The Posting the Formation is posted to" is the Posting anchored on it. That relationship is not defined anywhere else: CM-1140 posts units, and CM-1130's anchor points a Posting at a Formation, which is the opposite direction. The anchor is the only link between the two objects the document creates, and it is the one that makes this clause do what its rationale says — a Posting anchored on the short Formation is exactly the Posting whose output goes there.

2. The shortfall is reported, not written into the player's table. CM-1240's rows are the player's own targets and CM-1280 makes editing them the player's act; an engine that raised a target behind their back would be changing a standing decision, which CM-010's agency principle refuses. So the event carries the shortfall and its resolutions offer the edit — one of them naming the anchored Posting where there is one. The single sticky item this clause asks for is CM-1700's merge doing the work: keyed on the Formation, so a Formation short for six turns is one item with a since.

7.6 Group behaviour

CM-1070 A Group's order MUST project to its member Formations exactly as a Formation's projects to its units, using the same five roles applied at Formation granularity.

Note, 2026-09-11. "Exactly as" is read as a constraint on the implementation and not only on the behaviour: CM-890's fifteen-cell table has one implementation, called with the Group in the Formation's place. A second copy at this echelon would be two answers to one question, and the first time they disagreed the game would be wrong in a way no test that read only one of them could see. The four readings this clause needed are recorded at CM-1080, which is where the questions arise.

Readings recorded 2026-09-11, when this requirement was implemented. Four, and each of them is a question this clause raises and does not answer.

1. The member's stand-in for CM-920's offset resolution is the member Formation's commander. CM-890's table resolves to concrete tiles, and CM-920 makes "cheapest legal tile" depend on what the mover pays for the ground — a question about a unit. A Formation is not a unit and has no tile: by CM-950 its position is a CRP, which is its commander's tile as of that commander's last completed activation. So the unit whose legality and cost decide a Formation's post is the unit that defines where the Formation is, and the projection is called with that commander in the member slot. The alternative — averaging the members, or using the geometric centre of the Formation — invents a position the specification does not define and that no rule anywhere else reads.

2. CM-900's role slots lift with the roles, and the total becomes CM-860's five. This requirement says "the same five roles"; CM-900 states its counts for a Formation and ends with "total ≤ 8", which is CM-850's span written out. The per-role caps carry over unchanged and the total becomes five. The alternative reading — the same five names with no counts — admits a Group of five Vans, every one of them forced to Defend and Cautious by CM-910, which is an army that cannot fight and which no requirement asked for. Main ≥ 1 is what gives a Group a body to be a vanguard of.

3. Cohesion does not lift. CM-1000's Pace, CM-1010's radius, CM-1030's Regroup push and CM-1040's FormationStrung are stated throughout §7.5 in terms of a Formation's members, which are units standing on tiles. A Group's members are Formations whose position is a derived point, and a Regroup pushed on a Formation for being far from its Group's CRP would be a second cohesion mechanism with no requirement behind it. So a Group carries no Pace and no cohesion radius, and a Group whose Formations are flung across the map is a thing a player can see and nothing the engine corrects. This is the reading most worth revisiting: CM-1050's under-strength Screen test is stated at the Formation echelon and has an obvious analogue here, and §8's Postings may want one.

4. Membership is a back reference, not an Attach Posture. CM-870 lists Attach among a Formation's five kinds and an earlier comment in the engine claimed that was how a Formation joins a Group, by analogy with CM-880's unit-level Attach. It is not, and the analogy was the wrong one: attachTarget is a string, so at this echelon "23" could name a Formation or a Group with nothing to tell them apart; CM-860 fixes the nesting at two echelons, so a Formation's only possible attachment is a Group and a second encoding of that adds nothing; and keeping a Formation's own Posture intact while its Group overlays a projection is what makes CM-1090's "MUST NOT leave members Idle" true by construction when the Formation leaves — there is no Attach left naming nothing, which is exactly the case CM-1100 needs a conversion for one echelon down. What Attach means for a Formation is a question §7 does not answer, and the engine no longer pretends to.

CM-1080 A Group's CRP MUST be the CRP of its commanding Formation, and Intent Freshness (CM-960) MUST apply at both echelons independently. A Group order therefore MAY be up to two commander activations stale at a unit, and the Formation panel MUST say so when it is.

CM-1090 Disbanding a Formation MUST set every member's Posture to the Formation's projected order at the moment of disbanding, converted to a per-unit Posture with the member's effective Sanctions. It MUST NOT leave members Idle.

Ruling, 2026-09-11. "The member's effective Sanctions" are the projection's. Flagged as a reading earlier the same day, when a Formation could hold only Hold and the question was invisible, and settled here now that CM-880's projection has landed — which is the increment the note said would settle it, because it is where a member's effective Sanctions first exist as a computed thing. CM-740 omits Attach from its defaults table precisely because a member's Sanctions are the projection's, and CM-910's Van override is the proof they are computed rather than stored: a Van's Defend/Cautious are effective Sanctions that appear nowhere else. So a departing member keeps the order it was actually executing, role override included, for exactly as long as it held that role — the unit leaves carrying the orders it had a moment earlier, and the player changes them if they want something else. Where the projection resolves to nothing, the fallback is a Hold on the unit's own tile with CM-740's defaults, because this requirement's one hard MUST is that the member is not left Idle.

CM-1100 Removing a unit from a Formation MUST set that unit's Posture to its projected order at the moment of removal, by the same conversion.

CM-1110 A Formation whose membership falls to zero MUST be deleted, and its Posting reference (if any) MUST be retargeted per CM-1230.

Note, 2026-09-11, added with F5. The deletion has two sides now. CM-1120 records a Formation’s Group membership on both the Group’s member list and the Formation, so a deletion that clears one and not the other leaves a Group naming a Formation that no longer exists. The engine shipped exactly that for four hours: the F5 state invariants threw on the next assertion after a single-member Formation’s only unit died while it was in a Group. It is one function now, and where the deleted Formation was its Group’s commanding one, CM-940’s succession runs at that echelon too — and the Group is deleted in turn where that was its last member.

CM-1120 A unit MUST belong to at most one Formation, and a Formation to at most one Group.

8. Postings, Consignments, and Requisitions

This is the largest single source of clicks in the traditional model and the one with the least decision content in it. It is also where genuine operational-level command lives: choosing the force structure is the decision, and turning that structure into build orders is arithmetic.

8.1 Postings

CM-1130 A Posting MUST carry: an id, a player-set name, an anchor (a tile or a Formation reference), a default arrival Doctrine or Posture, an integer weight in [1, 10], a Requisition table (§8.4), and a surplus rule.

CM-1140 Every unit MUST carry a postedTo field naming a Posting or none. It MUST be set at creation from the producing city's Consignment, MUST persist through arrival, and MUST change only by explicit player action or by CM-1230.

Rationale: Posting membership must be a stored fact, not a geometric inference. Inferring it from proximity would make a front's strength wobble as units moved, which makes Requisition shortfalls oscillate and production thrash — and a stored field is one integer per unit and exactly reproducible.

CM-1150 The client MUST warn, without blocking, when a player creates a 13th Posting, and MUST offer a review of existing Postings.

Rationale: a player with fifteen Postings has rebuilt the micromanagement problem one level up. Twelve is comfortable headroom over the ten top-level command objects a person can hold; the warning is a nudge, not a rule, because a hard cap on how a player organises their own empire is exactly the patronising design this document rejects elsewhere.

8.2 Consignments

CM-1160 Every city MUST carry a Consignment: a Posting id, Auto, or Manual. The default for a starting city MUST be Auto. A newly captured city MUST default to Auto.

Rationale: capturing a city should not generate clerical work (CM-080). Auto routes its output through the scheduler, which is the answer a player would give if asked, so we do not ask.

CM-1170 A unit produced in a city consigned to Posting P MUST be created with postedTo = P, a Posture of March to P's anchor, and a follow-on order taken from P's default Doctrine or Posture. This MUST require zero player input.

Ruled 2026-09-16 (Claude Code): a garrisonOnly unit is not posted. 02-units-and-industry.md US-520 says such a unit "MUST NOT be given a March … Posture", and this requirement gives every consigned unit one. The more specific MUST NOT governs. A garrisonOnly unit produced in a consigned or Auto city is Reserved at Source instead, as CM-1220 defines: a Garrison on its producing city. That is the job the class exists for. A Manual city is unchanged (CM-1180). Measured the same day: in a 150-turn Standard/4 game, Militia under a March they could never execute were one of the two largest groups of real fallbacks under TM-1440. Each was a garrison its city lost, counted as in transit toward a front it could never reach.

Ruled 2026-09-17 (Claude Code): the March carries its follow-on, and the Posting fills in what CM-810 says a Doctrine cannot. Until then the March was given no follow-on. CM-530 requires one, checkMarchFollowOn calls a March without one MarchMissingFollowOn, and the engine takes no action for it. So a unit produced away from its Posting's target never set off, and production following a requisition never reached the front, for a player or the AI. The follow-on's source is the Posting's arrival Doctrine, else its arrival Posture, else the class default Doctrine (CM-1180's "type default"). With none of these, the unit arrives and holds on the target. CM-810's parameters come from the Posting, which names one tile. That tile places a Hold and garrisons a city standing there, and a Formation anchor names what an Attach attaches to. A Screen line, a Survey region or a March route is not a Posting's to draw. Such a template arrives on Fallback, the nearest a follow-on can come to CM-810's "leave the unit Idle": the unit is not left with nothing (CM-310), and ArrivedNoFollowOn tells the player it has no job. A unit produced on the target has already arrived. It adopts an arrival order the Posting names at once, and otherwise keeps the order it was born with.

Ruled 2026-09-20 (Codex): a stream arrives as far as physics delivers it. GR-720 gives every tile a surface stacking limit — an open land or water tile holds one ground unit, a Fort two, a city six — and any March to such a tile ends by entering it. A Posting anchored on an open tile can therefore never have more than one of its units stand on the anchor: the first takes the tile; every later route dies at that same step (CM-1500 advances each unit as far as its best partial route allows); and CM-1250 then counts the rest inTransit for the life of the game — a stream that is never short and never gets anything. Measured 2026-09-17: a Posting four tiles from its capital with three Infantry queued delivers exactly one, the other two sitting Blocked short of it in transit for good (the standing finding of that date). Ruling (the owner delegates such calls): a unit has completed its arrival March when it stands on the anchor — or when no legal route remains for it to stand there and it halts with no step remaining toward the destination. A complete route to a tile must end by entering it, so an anchor at its stacking limit admits nobody from anywhere; "still walking" and "arrived" are then one fact apart — whether the unit is further than that, or standing where CM-1500's partial routes ran out. The clause is evaluated exactly where Blocked would otherwise have fired on the route's death (CM-1340), and supersedes it for this case: a March whose last waypoint it can no longer enter because the tile's stacking limit is full, with nothing left to advance, completes rather than suspends. On such completion the CM-1250 latch sets, present counting a unit delivered anywhere in the line it stopped — which keeps the Requisition honest against a tile that will never be empty again; the follow-on adopts at once, as CM-1340's Arrived row already does for a reached waypoint — and where the Posting names one tile for CM-810, that parameter is the tile the unit stands on when it completes: its Hold lands on that stop-tile rather than the anchor, so a delivered unit holds in place (a satisfied posture; CM-1450 records it as progressing) instead of re-marching at an occupied post and raising Blocked every turn; and no Attention Event is raised — this is the steady state any stream aimed at a limit-bound tile ends in, the Posting's arithmetic already says what was delivered where, and one event per queued unit would make Dispatch report weather. A unit that reaches the anchor completes by the first disjunctive, unchanged; an enemy on the anchor makes no refusal this clause names — entry there is refused by contact, not by a full stack, so Contact's and Blocked's rows own that March exactly as before. Where the anchor is a Formation it means its current target under CM-1230. Nothing walks back onto a freed anchor afterwards: the latch is history, cleared only when postedTo changes (the Reading below), and each unit's Hold has its own tile now — the front keeps the shape physics gave it unless the player reshapes it. The client forms Postings on cities, which have room; this bites where CM-1230 leaves a Posting on an open-tile target after its anchor Formation is gone, or where a hand-made SetPostingAnchor names open ground.

CM-1180 A unit produced in a Manual city MUST be created with its type's default Doctrine and postedTo = none, and MUST NOT be Idle.

8.3 The allocation scheduler

CM-1190 When a city's Consignment is Auto, the destination Posting MUST be chosen by the following deterministic integer scheduler. Let E be the set of eligible Postings — those whose Requisition has a shortfall greater than zero — and W the sum of their weights. For each allocation, in order:

1. For each Posting p ∈ E, counter[p] += weight[p].
2. For each Posting q ∉ E, clamp counter[q] to at most W.
3. Select the Posting in E with the greatest counter; ties break by lowest Posting id.
4. counter[winner] -= W.

CM-1200 Worked example, normative as a test vector. Postings Northern (weight 3, id 1) and Home (weight 1, id 2), both eligible, counters starting at zero:

Four units delivered 3:1, counters returned to zero, and the pattern repeats exactly.

Rationale: this is a deficit round-robin and it produces a stable interleave — three north, one home, interleaved — rather than three units north followed by one home. Integer, exact, replayable, and it degrades sensibly when weights change mid-game because the counters carry the accumulated debt.

CM-1210 Counters MUST be authoritative game state (CM-180). A Posting created mid-game MUST start at counter zero; a deleted Posting's counter MUST be discarded.

Rationale for the clamp in CM-1190 step 2: without it, a Posting that is ineligible for twenty allocations accumulates twenty rounds of credit and then absorbs the next several units in a burst the player did not ask for. Clamping to the current eligible weight sum bounds the catch-up to a single allocation, which is the intended "you were owed one".

CM-1220 When E is empty, the producing city's surplus rule MUST apply. The surplus rule MUST be one of ReserveAtSource (the unit adopts its type Doctrine and Postures Garrison on the producing city), OverflowTo(P) (allocated to P regardless of shortfall), or HoldProduction (the city's production queue pauses and raises a ProductionIdle Attention Event). The default MUST be ReserveAtSource.

Readings recorded 2026-09-11, when §8 was implemented. Three, and the first is a collision.

1. There are two surplus rules, on two objects, with two readers — and CM-1130 and this clause each name one of them. CM-1130 puts a surplus rule on the Posting; this requirement says "the producing city's surplus rule MUST apply". Both are honoured, because they answer different questions. An Auto city whose eligible set is empty has no Posting to take a rule from — that is what an empty set means — so the rule that applies there has to be the city's, which is what this clause says. The Posting's own rule is CM-1260's fall-through ("then to the surplus rule") for a city consigned directly to it. The alternative readings both fail: one field cannot serve both cases, and dropping either leaves a clause with nothing to read it. The Posting's field therefore has no reader until CM-1260 lands, and the engine says so where it is declared rather than letting it be a field nobody uses.

2. HoldProduction raises the event and does not pause the queue, yet. This clause says the city's "production queue pauses and raises a ProductionIdle Attention Event". The event is raised. The pause is a property of the build selection — what a city starts next — which is CM-1260, and by the time the surplus rule is consulted the unit already exists and cannot be un-produced. Pausing an already-empty queue would be a no-op dressed as a rule, so the half that is real is built and the half that needs CM-1260 waits for it.

3. An Auto city consulted the scheduler; a consigned city does not. CM-1190 opens with "When a city's Consignment is Auto", so a city consigned to P sends its output to P regardless of shortfall — a player who consigned a city has already said where its output goes, and running the scheduler for them would overrule a standing decision.

CM-1230 A Posting anchored on a Formation MUST re-target its arrival destination only when that Formation's CRP has moved more than 5 tiles (Chebyshev) from the last target used. If the anchor Formation is deleted, the Posting's anchor MUST become the last target tile and a PostingAnchorLost Attention Event MUST be raised.

Note, 2026-09-11. The "last target used" is stored, which this clause requires by naming it and which is what makes the rule hysteresis rather than a rolling window: the five tiles are measured from the aim point, not from where the Formation was last turn. It is re-evaluated once per turn, at the Reckoning — a rule with hysteresis whose aim point could move mid-Cascade would give two answers within one turn. And where the anchor Formation is deleted before any target was ever used, the Posting is left with no destination and the event says a destination is needed: substituting a tile nobody chose would be a reinforcement stream walking somewhere the player never named.

Rationale: without hysteresis a reinforcement stream chases a mobile army in circles and never arrives — the classic failure of "reinforce the front" automation. Five tiles is roughly two turns of movement for the formation being chased, so the stream re-aims about as often as the front meaningfully moves and no more.

8.4 Requisitions

CM-1240 A Requisition MUST be an ordered table of rows, each carrying a unit-class key and an integer target count in [0, 99].

CM-1250 For each row the shortfall MUST be computed as target − (present + inTransit + committed), where present counts units with postedTo = P that have completed their arrival March, inTransit counts units with postedTo = P that have not, and committed counts in-progress production items in cities consigned to P whose output matches the row.

Rationale: counting in-transit and in-production units is what stops Requisition thrash. A front that is four short and has four on the road is not short, and a system that thought it was would build four more and then four more again.

Reading, 2026-09-11. "Completed their arrival March" is a stored latch, not a test on the current order. It is a fact about history: a unit that arrived and was then sent somewhere else is still present at its Posting. Inferring it from the live Posture would make such a unit read as in transit again, and the shortfall would oscillate — which is exactly what this rationale forbids, and it is CM-1140's rationale applied one field over ("a stored fact, not a geometric inference"). So the unit carries the arrival as well as the Posting, set at the tile change that reaches the Posting's destination and cleared only when the Posting changes. All three terms are counted from the state on every read rather than tracked: a tracked counter has to be decremented on death, on capture, on a re-post, on a cancelled queue item and on a completed one, and the first path that forgets leaves a shortfall nobody can audit against the board.

Ruled 2026-09-20 (Codex), at CM-1170: an anchor whose stacking limit is full still delivers. Where the destination tile cannot hold more than it already does — chiefly GR-720's open tile holding the delivered stream on it — "completed their arrival March" includes completing where a unit halted short of it under CM-1500; the latch sets at that completion and present counts the line delivered. The stored-latch reading above is untouched: set once, cleared only when the Posting changes.

And eligibility under CM-1190 is any row short, not the sum: a front that has all its infantry and none of its artillery is short of artillery. Summing the rows would let a surplus in one hide a shortfall in another, which is the reading that stops the scheduler reinforcing a front that needs one specific thing.

CM-1260 A city consigned to Posting P MUST select its next build item as the buildable unit class matching the row with the greatest shortfall; ties break by lowest row index. Where no row's shortfall is buildable at that city, the city MUST fall through to the next row it can build, then to the surplus rule.

Notes, 2026-09-11, when this requirement was implemented. Three.

1. "Buildable" is US-360's gate and not a second one. The selection calls buildBlockFor over the roster record — the same function a player's own QueueProduction passes through — because a second buildability test would let the engine enqueue something the Ledger then refuses, and the city would sit idle holding an order it can never start.

2. The fall-through is to "the next row it can build", which is not the next row by shortfall. A city that cannot build the shortest class does not stop; it takes the next class in the table it can build, short or not, because a row the front has a target for is better than nothing. Only when no row at all is buildable does the surplus rule apply — and that clause is the only reader of CM-1130's Posting-level surplus rule, which was declared with this requirement's name against it and had no reader until now.

3. The selection runs once per Ledger phase, before the Works step, and only into an empty queue. Before the Works step because EC-610's empty-queue cap would otherwise discard a governed city's Works for want of an order the engine was about to give it; only into an empty queue because CM-1270 forbids retargeting an item in progress, and "the next build selection" of CM-1280 is therefore the moment the current item finishes.

CM-1270 A production item already in progress MUST NOT be cancelled or retargeted because a shortfall changed. Rationale: a front oscillating between shortfall and surplus would otherwise make cities flip production every turn and complete nothing.

CM-1280 Editing a Requisition MUST NOT require touching any city, and MUST take effect at the next build selection in every consigned city.

CM-1290 The Requisition panel MUST display, per row, target, present, inTransit, committed and shortfall as integers.

CM-1300 The command layer MUST NOT impose any cap, tax, upkeep, or efficiency penalty that scales with the number of units, Formations, Groups, Postings or orders a player commands.

Rationale: command capacity is a tempting place to hide the anti-snowball brake the design direction asks for, and it is the wrong place. A brake there punishes the player for automating, which violates CM-050 and makes the whole subsystem a trap. Whatever visible brake the game needs belongs in logistics, upkeep, or territorial strain, where the player can see it and plan around it.

8.5 Templates

CM-1310 A city MUST support a production Template: a named, saved, ordered build list with an optional repeat flag, assignable to a city and to multiple cities at once.

CM-1320 Templates and Requisitions MUST coexist: a city with a Template MUST follow the Template; a city consigned to a Posting without a Template MUST follow CM-1260. A city MUST NOT be governed by both simultaneously.

Readings recorded 2026-09-11, when §8.5 was implemented. Four.

1. "Not governed by both simultaneously" is about governance, not about storage. A city may carry a Template and a Consignment; the precedence is evaluated at each build and the Template wins. Clearing one when the other is set would lose a standing decision the player made and never revoked — a player who assigns a Template for three turns and removes it expects the Consignment they set last week to still be there, and an engine that had silently dropped it would have them re-set it without ever being told it was gone. This requirement's own first clause says the two "MUST coexist", and CM-1330's "which of Template, Requisition, or manual queue is currently governing" implies the same thing from the other end: the word is a function of state, so the state has to hold enough to compute it.

2. The Template cursor is per city, not per Template. CM-1310 makes a Template "assignable to a city and to multiple cities at once", and a cursor on the Template would make two cities sharing one list take alternate items — which is not what assigning the same list to two cities means. A count greater than one is consumed one build at a time for the same reason: "two infantry then a gun" is three builds, and an ordered build list with a count is a list.

3. A Template whose next item this city cannot build stops the city rather than skipping. CM-1320 says a city with a Template "MUST follow the Template", so silently building something else would be a different army from the one the list names. The cursor holds and the city starts nothing that phase. This is the reading most worth revisiting: it means a Template naming one class a city cannot build stalls that city indefinitely, and the panel should say so — CM-1330's word is "Template" and the city is idle, which a player will read as a bug before they read it as obedience.

4. A finished list hands over. Without CM-1310's repeat flag the Template is spent once its last item is built, and the city's Consignment — which reading 1 kept — takes over from the next selection. The alternative, a city frozen after its list, is a standing decision with no way out short of the player noticing.

CM-1330 The client MUST show, for every city, which of Template, Requisition, or manual queue is currently governing its production, in one word.

9. The interruption model

Automation is only as good as its behaviour when the plan breaks.

CM-1340 The engine MUST recognise exactly six interruption classes, with the behaviour and attention consequences in the table below. Each MUST be evaluated at the acting unit's activation, in the order listed.

Ruled 2026-09-16 (Claude Code): a displaced Hold whose post is a City its owner no longer holds is Impossible. A capturer holds the city it took, through CM-730's Garrison Task and then the Hold that CM-370's ruling of the same day re-issues on the city. A revolt or a retreat that pushes it out leaves it displaced, and CM-380's ReturnToPost then aims at a city its owner has lost. That Reflex can never finish. Entering the city would be a capture no Hold Sanction authorises (CM-030), and a hostile occupant refuses the entry outright (01-game-rules.md GR-560). It never pops, and a Reflex outranks every Task above the Posture, so no order could reach the unit. The post is the same garrison place this row names as captured, so the Hold is Impossible. The Fallback Posture is adopted where the unit stands, and its owner is told. The adoption is a new post, so CM-380's displaced marker clears as it does on regaining one; left set, the next Task to carry the unit away would end in a walk back to that tile. A post on open ground is not a place that can be captured: an enemy standing on it can move, and it is Blocked's business. A post in a City its owner still holds is walked back to. Measured the same day over 150 turns of one Standard/4 game: 155 of 682 real fallbacks were such Reflexes, mostly heavy armour beside a city held by neutral Militia after a revolt.

CM-1350 Contact radius MUST be the acting unit's vision radius.

CM-1360 A contact MUST be considered to block the order when the enemy occupies a tile on the cached route within the unit's remaining movement, occupies a Screen line tile the unit was moving to cover, occupies the unit's Garrison place, or occupies a Survey candidate that scored highest.

CM-1370 An Opportunity MUST be detected only for the following, and the engine MUST NOT invent further categories without a commandLogicVersion bump:

CM-1380 Every Opportunity Attention Event MUST carry a precomputed candidate order that the player may accept verbatim in one action; accepting MUST push that order as a Task.

CM-1390 An interruption MUST NOT clear any level of the order stack except as CM-1340 states. Blocked in particular MUST suspend rather than cancel, so that clearing the obstruction lets the original order resume untouched.

9.1 Reflexes

CM-1400 The Reflex set MUST be exactly:

CM-1410 TakeCover tile selection MUST break ties by lowest movement cost, then lowest tile index, and MUST use the defensive value the combat specification defines for that unit class on that terrain.

CM-1420 A Reflex MUST NOT initiate an attack. Rationale: a reflex is the engine acting without the player having said anything about this situation; initiating combat there would be exactly the unsanctioned irreversible action CM-030 forbids.

9.2 Progress and the stall detector

CM-1430 The engine MUST evaluate progress for every unit at every activation, per the following definitions, and MUST record the result:

CM-1440 A unit that is not progressing for two consecutive turns MUST raise a Stalled Attention Event. The event MUST name the level that is not progressing and the specific reason.

CM-1450 A unit whose last activation was a no-op because its Posture is satisfied — a Hold unit standing on its tile, a settled Screen — MUST be recorded as progressing and MUST NOT raise Stalled.

CM-1460 Stall detection MUST be instrumented independently of the Attention Event: the engine MUST expose a per-turn count of units with no progress for ≥ 3 turns, for telemetry and for CI regression. Rationale: the guard itself can have bugs, and this failure mode is invisible without measurement.

10. Route policy and Banked Movement

CM-1470 A March MUST carry a cached route. The route MUST be recomputed at activation only when the cached next two tiles have become invalid — impassable, occupied beyond stacking, or outside the map.

Rationale: recomputing every activation is both wasteful and visually unstable; a unit whose path is recomputed constantly appears to change its mind, which reads as broken even when each recomputation is optimal.

CM-1480 Newly revealed terrain offering a cheaper route MUST trigger a reroute only when the improvement clears 25%, by the integer test newCost × 4 ≤ oldCost × 3.

Rationale: without hysteresis units oscillate as fog lifts. Twenty-five per cent is large enough that only a genuinely better route wins and small enough that a real road discovered halfway is taken.

CM-1490 A route MUST be recomputed at most once per activation. A second failure in the same activation MUST raise Blocked.

CM-1500 When no route to the next waypoint exists at all, the March MUST raise Blocked, MUST advance as far as the best partial route allows, and MUST remain suspended rather than cancelled.

CM-1510 Route cost comparison and path tie-breaking MUST use integer terrain costs and MUST break ties by lowest tile index, consistent with 03-architecture.md AR-750.

CM-1520 Waypoints MUST be consumed in order. A waypoint that becomes permanently unreachable — outside the map, or on terrain the unit's class may never enter — MUST be dropped with a Blocked event naming it; a waypoint that is temporarily unreachable MUST NOT be dropped.

*Ruled 2026-09-21 (Codex CLI, the turn model's owner — settling the standing item of 2026-09-10, whose evidence is that day's entry of 12:35): the route policy governs Tasks as well. A Task whose action moves a unit to a named tile (MoveTo, Garrison) is one waypoint worth of this section's routing discipline, and the clauses above read over it exactly as they read over a March: where no full route exists, the order advances as far as its best partial route allows (CM-1500), remains standing — suspended in the March's words — and raises Blocked so the seat sees the stall — except where a visible enemy stands on the waypoint or target: that contact owns its own answer (CM-1360's blocking contact, and the posting ruling of 2026-09-20 keeps its "nobody walks in"), so no advance runs toward it and the unit stands where it is; a March keeps standing under that Blocked as before, and a Task waits until CM-1440's stall detector speaks. The advance applies to road problems; a contact is not one. The asymmetry this closes was measured, not hypothetical: until 2026-09-21 a stalled Task raised nothing while on-map (the Impossible case covers only a target that left the map), and twelve Heavy Armour were recorded holding such an order for up to 39 turns of invisible no-op. CM-1520's second clause already reached Tasks by documented reading — its temporary/permanent distinction is what keeps an unreachable-but-open target from being dropped — so the drop itself lands there too: a Task whose one waypoint sits on terrain the class may never enter (or left the map in the meantime) is dropped with the Blocked naming it, and a move-order with nothing left to move to adopts its Fallback Posture — the bookkeeping of CM-1340's Impossible case for an off-map target, differing only in the event this clause names.

Two corollaries, pinned by tests. First: dropping waypoints is what empties a route, and a Once March whose last remaining waypoint is dropped completes where it stands — the follow-on adopts there, which is CM-1170's own words for a unit that "halts with no step remaining toward the destination" applied at CM-1520; a Fallback follow-on raises its own arrival event as usual. A looped March whose drop leaves waypoints to march between them simply continues. Second: "terrain the unit's class may never enter" is only sayable of terrain the seat knows — an unrevealed tile reads through CM-140's fog at the cheapest cost the class pays, so a waypoint can be dropped where its terrain has been revealed or recorded and nothing more; that keeps CM-1530's replan-on-contact intact (a bridge discovered later opens a route, it does not resurrect a dropped order — a drop is permanent, as the clause says). CM-1530 A March route passing through unrevealed terrain MUST be planned under CM-140 and MUST be replanned on contact with the truth under CM-1480 and CM-1500.

CM-1540 The remaining route MUST be displayable on the map for any selected unit, including the portion planned through unrevealed terrain, which MUST be visually distinguished as provisional.

10.1 Banked Movement

CM-1550 A unit that halts on an Opportunity or a Blocked interruption with unspent movement MUST bank that unspent movement.

CM-1560 Banked movement MUST be added to the unit's normal allowance at its next activation only, MUST be capped at the unit's normal allowance (so a unit may spend at most twice its allowance in one activation), MUST NOT accumulate across more than one turn, and MUST be discarded unused at the end of that next activation.

CM-1570 Banked movement MUST NOT be granted for any other interruption class, and MUST NOT be granted twice for the same halt.

CM-1580 Banked movement MUST NOT alter the unit's Stance, initiative, reaction capacity, or exposure to opponents' reactions.

CM-1590 The unit panel and the Opportunity card MUST state the banked amount in movement points.

CM-1600 Rationale, stated normatively because the requirement above exists only to serve it: without banked movement, an automated unit that pauses to ask permission arrives one turn later than a hand-ordered unit that did not need to ask, and automation becomes a measurable tempo disadvantage — which fails CM-050 and, with it, the whole subsystem. The source design placed this as an out-of-order re-activation within the same turn; under Orders and the Cascade there is no player input during resolution, so the same guarantee is delivered by banking the movement forward. The unit reaches the same tile on the same turn it would have reached had it not stopped to ask, and no mid-Cascade prompt is required. The cap at one extra allowance bounds the effect to exactly the turn that was lost.

11. Attention Events and the Dispatch

With three hundred units, showing the player the five that need a decision is the more important half of this design.

11.1 Split of responsibility

CM-1610 The simulation core MUST emit Attention Events deterministically, each carrying: a class, a cause key (CM-1700), the affected entities, the integer terms S, T and A (§11.4), a plain-language summary, and an ordered list of offered resolutions.

CM-1620 The client MUST compute the presented ranking, apply the adaptive player weight P, deduplicate, bound, and present. The core MUST NOT compute P and MUST NOT order the Dispatch.

CM-1630 Automation logic MUST NOT depend on Attention Events in any way. A player who never opens the Dispatch MUST get identical unit behaviour to one who reads every item.

11.2 Properties of the Dispatch

CM-1640 The Dispatch MUST show at most 7 items, player-settable in [3, 15]. Everything below the cut MUST collapse into a one-line digest with per-class counts. Rationale: a list of forty alerts conveys the same information as no list.

CM-1650 Every presented item MUST carry at least one one-action resolution and a snooze. An item with no available action MUST NOT be presented as an item; it MUST be a digest line.

CM-1660 Items MUST be ranked by the integer Urgency score U = S + T + A + P, ties broken by lowest affected-unit creation sequence number.

CM-1670 Items MUST be sticky: an item MUST persist across turns until it is resolved, snoozed, or its underlying condition ceases to hold. A new turn MUST NOT clear the Dispatch.

CM-1680 An item whose condition ceases to hold MUST be retired and MUST appear once in the digest as retired, naming what happened.

CM-1690 Snoozing MUST suppress the item's cause key for a player-set number of turns, default 5, range [1, 20]. A snoozed cause MUST re-raise immediately if its S term increases by 30 or more since the snooze.

Rationale: the escalation override is what makes snooze safe. Without it, a player who snoozes "enemy scouts near the river" also snoozes the army that follows them.

11.3 Deduplication and the event catalogue

CM-1700 Every Attention Event MUST carry a cause key of (class, causeEntityId, causeTileClusterId). Items with equal cause keys MUST merge into one presented item.

CM-1710 A merged item's S, T and A MUST each be the maximum across its members, never the sum, and its affected-entity list MUST be the union.

Rationale: ten units contacted by one enemy column are one item — "enemy column of 6 at Ash Ford; 10 of your units in contact" — not ten. Taking the maximum rather than the sum is what stops deduplication from re-inflating the very thing it merged, which would defeat the purpose and put the merged item at the top of the list purely for being numerous.

CM-1720 The Attention Event classes MUST be exactly the following, with the stated default terms. A specification that owns a system defines its own classes and their terms in its own text, and this catalogue MUST carry every one of them, citing the owning requirement rather than restating its numbers — so the catalogue is one closed list and each class has one place its terms can change.

Ruling, 2026-09-11, corrected the same day — the first version of it contradicted a MUST I had not read. This clause said "the classes MUST be exactly the following" and the engine raises thirty-two. Twelve of them are 12-economy.md's, defined in that document's own terms table with its own adaptability column and its own resolution obligations (EC-1900, EC-1910, EC-1920, EC-1940): RevoltImminent, CadreLost, CadreThreatened, UnrestRising, GarrisonShort, SupplyCut, AwaitingLevy, IntegrationStalled, CadreUnassigned and LevyReturned — and the last two are 02-units-and-industry.md's: ProductionStalled (US-1060) and ProductionOverflow (US-1240), which US-2170 already assigns exactly as this ruling would ("13-command.md MUST surface the ProductionStalled condition of US-1060 and the ProductionOverflow condition of US-1240 through the Dispatch"). So the split is twenty here, ten in 12-economy.md and two in 02-units-and-industry.md; the first draft of this ruling put the last two in the economy's column, and the test written to enforce the ruling corrected it on its first run (scripts/test/attention-classes.test.ts). Every economic and industrial Attention Event the engine has raised since the E2 increment was in breach of a MUST in this document, and nothing could notice, because the classes are a union type and a union type does not read a specification.

The first version of this ruling left the classes where they were defined and reworded the clause to admit them, reasoning from the division the set uses elsewhere — 12-economy.md owns strength recovery over 11-combat.md (EC-2290); this document owns the order vocabulary over 10-turn-model.md (CM-230). That was wrong, and the requirement that says so was already written. EC-2310 directs this document by name: "13-command.md MUST extend the Attention Event catalogue of CM-1720 with the ten economic classes of EC-1900 and their terms … Until it does, the economy's obligations under EC-1900 are unmet and the visibility test of EC-020 is not satisfied for Unrest, Integration or Reach." A precedent does not overrule a directed MUST, and reasoning from one instead of reading the other is how a ruling comes to contradict the thing it was ruling on.

So the catalogue carries all thirty-two rows — 12-economy.md's ten by EC-2310, and 02-units-and-industry.md's two by US-2170's "MUST surface … through the Dispatch". What survives from the division is the part that was sound: an imported row cites its owner and does not restate its numbers. That is what stops the catalogue becoming a second place a class's terms can be changed, which is the failure mode importing them would otherwise create — and it is the same mechanism EC-1910 already uses, exempting RevoltImminent by citing CM-1780 rather than restating it. The term rules of CM-1740 through CM-1790 remain this document's and apply to every class whoever defines it.

The last fourteen rows are imported and not restated, per this requirement's own clause: the terms are the owning document's and a reader changes them there. The two above the economy's ten are 02-units-and-industry.md's, imported by US-2170's "MUST surface … through the Dispatch"; the ten are 12-economy.md's, imported by EC-2310; and the last two are 14-victory.md's, imported by VC-3150's "MUST add two Attention Event classes to the catalogue of CM-1720": S12 raised VerdictOffered at the Seal in its increment, and §13.4's Alarm half (S14), landed 2026-09-15, has now raised its sister, VictoryAlarm, so both rows of VC-3150 are present. RevoltImminent's non-adaptability is EC-1910's, and VerdictOffered's and VictoryAlarm's are VC-3150's; all three are recorded in the Adaptable column because CM-1780's adaptation is this document's mechanism and a reader of CM-1780 must be able to see the exemption from here.

Amended 2026-09-11, and the amendment is the smaller half of the entry. CityThreatened was raised by nothing. It is this table's highest-stake class — S 100, CM-1740's ceiling — and one of only two CM-1790 exempts from the adaptive weight, on the stated ground that "the game must never learn to stop telling you your capital is about to fall". A requirement went to the trouble of protecting it from being tuned out, and no call site emitted it, so a player had never once been told a city of theirs may fall — the single most important thing §11 exists to say, silent since the Dispatch was built, because a class nobody raises is a class no test misses. Found by scripts/test/attention-classes.test.ts, which also established that nothing blocked it: every input was already in the knowledge view. It is raised at 10-turn-model.md TM-1930 step 7 (turn/threat.ts), one item per own city per player.

The A cell above changes with it, from "40 with ≥2 responses, else 5" to the three cases CM-1760 actually states — the 2026-09-11 ruling at CM-1760 settled that the rule governs and this column mirrors it, and a two-case cell for a three-case rule is exactly the drift that ruling was about. A threatened city with one response computes 20, not 5.

Three readings, because no requirement states the trigger — CM-1720 names the class, CM-1750 gives the Tempo, CM-1740 says only that "a city that may be lost MUST outrank a city that may be taken":

1. Any visible hostile unit in reach threatens the city, and the trigger does not test whether that unit could actually capture it. It cannot: the observation stream synthesises an observed enemy with no capability list at all (world/knowledge.ts), so GR-930's capture capability is not admitted at any fidelity, and reading the true world for it would be exactly the leak TM-2210 forbids — a player must not learn of an enemy from a warning about it. The cost is that a Cadre or a Depot walking past a city raises a threat; the alternative costs a player the warning that matters, and the whole reason this class is non-adaptable is that the specification already decided which of those two errors it prefers.

2. "In reach" is CM-680's threat radius, reused unchanged: the enemy's last-known movement allowance clamped to [1, 6], or 2 where the allowance is unknown (a Contact below fidelity 2, where GR-1260 withholds the class and with it the movement). The Withdraw and TakeCover Reflexes have measured threat that way since the interruption increment, and a second threat model in the same engine would be two answers to "is this enemy close".

3. The class is raised for three of CM-1750's four bands and never the fourth. A T of 5 beside an S of 100 would place an enemy ten turns away near the top of the Dispatch every turn of the game, which is the noise CM-090 obliges this system to avoid; a threat four turns out is a map, not a threat. So 60, 40 and 20 are emitted and the far band is deliberately silent. This is the one reading that could be argued the other way — it trades a warning a player might want for the credibility of the list — and it is recorded here rather than left in the code so that arguing it means amending a requirement.

A consequence worth stating plainly, since it will look like a gap: a player can lose a city to an enemy they never saw, and get no warning at all. That is the fog working. Every enemy this class considers comes from the owner's own knowledge view, which is what TM-2210 and CM-130 require and is the reason the raiser is handed a view builder rather than reaching for the world.

Ruling, 2026-09-05, opening this catalogue to a twentieth class. CB-1140 raises a Routed Attention and this list was closed at nineteen, so the combat increment shipped placeholder terms against a class the catalogue did not admit. Mapping a rout onto an existing class was rejected: it would collapse the distinction between a unit that broke and a unit that was lost, and those demand different responses — the first can be rallied.

The terms are derived from CM-1740, CM-1750 and CM-1760 rather than chosen. Stake takes AttackedAndWithdrew's shape, five higher at the base because a rout is the involuntary version of the same event and leaves the unit disordered as well as displaced. Tempo is 40: the rout has already happened, and it is the response that is due next turn. Agency is 40 by CM-1760's own rule — a routed unit offers rallying it, pulling it further back, or committing others to the gap it left, which differ in kind. The placeholder had A 5, which CM-1760 reserves for items whose only resolutions are acknowledge and snooze; that was the clearest sign the class needed ruling on rather than approximating.

CM-1730 Opportunity S values MUST be: free city in reach 70; weak city adjacent 50; overwhelming odds 30; repair in reach 25.

11.4 The Urgency terms

CM-1740 S — Stake, in [0, 100] — MUST measure what is at risk or on offer, per CM-1720 and CM-1730. A city that may be lost MUST outrank a city that may be taken. Rationale: the loss is certain to matter and the gain may still be there next turn.

CM-1750 T — Tempo, in [0, 60] — MUST be assigned by when the matter resolves: 60 this turn, 40 next turn, 20 within three turns, 5 beyond that.

Rationale: tempo deliberately outweighs a large distant stake. A distant item will resurface; a decision that expires this turn will not.

Note, 2026-09-11. A class MAY decline to be raised in the 5 band, and CityThreatened does — its ruling at CM-1720 gives the reason. The band is still this requirement's: a class that raises in it MUST use 5, and one that does not raise in it is silent rather than borrowing 20.

CM-1760 A — Agency, in [0, 40] — MUST be computed from the number and kind of resolutions the item offers: 40 when it offers two or more resolutions whose immediate effects differ in kind (move, fight, abandon, build, produce); 20 when it offers exactly one non-trivial resolution; 5 when its only resolutions are acknowledge and snooze. The per-class values in CM-1720 are the normative defaults derived by this rule.

Rationale: Agency is the anti-noise term, and defining it by the offered resolutions rather than by an estimate of how much the outcome matters makes it objective and computable. It correctly demotes items where automation would have done the right thing anyway, because those items have nothing to offer but acknowledgement.

Ruling, 2026-09-11. This rule governs and CM-1720's A column is its mirror — which this requirement's own last sentence already says ("the normative defaults derived by this rule"), and which is the third time this specification set has settled a rule-against-table collision the same way: EC-400 against US-825 and EC-1080 against EC-1030 both hold that the procedure governs and the table mirrors it. Parked on the standing list as a contradiction and measured here rather than argued: every A the engine emits was compared against the resolutions the emitting call actually offers, and eleven emission sites disagree with the rule, not the five the register recorded — and counting them was itself a place to be careful, because the first count of this table said nine.

Three consequences follow, and only the first is a number change.

1. The three unproducible values are corrected to what the rule yields, because a value outside {5, 20, 40} is not a defensible default under a MUST that computes the term from three cases: Stalled 25 → 20, Impossible 30 → 20, FirstContact 30 → 5.

1b. 12-economy.md's ten-class table was measured against this rule too, and it is the healthier of the two. Eight of its ten carry A 40, CadreLost carries 20 and LevyReturned carries 5 — all three legal values, none unproducible — and EC-1920 is the reason: that requirement obliges every economic event to carry at least one one-action resolution and names four of them specifically. A rule that makes the resolutions an obligation produces a term that agrees with itself, which is the argument for this rule rather than an observation about that table. Whether each of the eight earns 40 under the "differ in kind" test is a question for whoever writes those resolution lists, and it is on the work list with the measurement rather than ruled here from the outside.

2. Where a class's resolutions are thinner than the class deserves, the list is the defect and the number is the symptom — so the remaining disagreements are NOT resolved by rewriting the column. A UnitLost that offers only Acknowledge computes to 5 correctly and is a Dispatch item telling a player nothing, and this rule's own rationale says Agency "correctly demotes items where automation would have done the right thing anyway" — which a lost unit is not. The six classes whose lists are worth a look are UnitLost, AttackedAndWithdrew, FirstContact, Idle, ArrivedNoFollowOn and Opportunity; the work item is in SESSION.md with this measurement, and it is a Dispatch design pass rather than a ruling.

3. CityTaken is two items and the table cannot hold both. The captor is offered a choice and the former owner is offered acknowledgement, so one class computes 40 on one player's stream and 5 on the other's. The per-class row is therefore a default for the richer case, and CM-1720's CityThreatened row shows the shape a conditional cell takes when the document means to say so ("40 with ≥2 responses, 20 with one, 5 with none" — that row was itself corrected the same day, from a two-case cell for this three-case rule). A CityTaken row in that form would say what is true; it is not changed here because which side's number the table means is the spec owner's call and both readings are behaviourally identical today (nothing reads A but the Dispatch's ordering).

Nothing hashed moves. Attention Events are derived and explicitly excluded from the state hash (03-architecture.md AR-250), so this whole disagreement has only ever been visible in the order of one list — which is how it drifted this far.

Ruled and built 2026-09-17: the design pass consequence 2 asked for is done, and no class disagrees with this rule any more. Six lists were enriched and two numbers moved, and which of the two happened to a class was decided by asking what a player can actually be offered rather than by what made the arithmetic agree:

On the two numbers. FormationStrung is the case where the list was already right: three resolutions across two kinds is this rule's 40 and the column said 20, so the column moved — "the rule governs and the column is its mirror", applied to the one class where the mirror was the only thing wrong. CityTaken is consequence 3's open question, answered: the row is split, the captor keeps 40 and the former owner takes 20. A conditional cell was the other candidate and it would have been worse, because the condition is not a property of the item — it is which player's stream the item is on, and a reader of one row cannot tell which. Splitting says the true thing plainly: the two sides of a capture do not carry the same agency, because the captor chooses what the garrison does next and the former owner is told. The former owner's 20 is the one non-trivial resolution a panel can honestly offer them — what the loss cost, in the Ledger — and not the 5 an acknowledge-only list would have earned, which is the outcome consequence 2 wrote itself to prevent.

FirstContact is off the list because it never disagreed: it emits the 5 its acknowledge-only list computes. It is still the one class of the six whose list was left alone, on the reading that a first sighting genuinely offers nothing a click can do — a Survey wants a region and a withdrawal wants a destination, and inventing a one-click answer for it would be the panel having an opinion about a player's reconnaissance.

Ruled the same day, an hour later, and this one is a correction to the 2026-09-11 sweep itself: its table was not exhaustive, and three more classes were wrong behind it. That table said "every class the engine raises" and the test built from it checked one direction only — every row is raised somewhere — so the seven classes it had missed were never compared to anything. Measured 2026-09-17: the engine raises 24 classes against the table's 16, and the absentees carried:

So two more unproducible values survived the sweep that was written to find exactly them, for three months, because the sweep's own measurement was short — which is the argument for the test this ruling adds rather than for the numbers it corrects: the measurement table is now asserted complete in both directions, so a class the engine raises and nobody has compared cannot exist again.

VictoryAlarm is measured and left alone on purpose. Its terms belong to 14-victory.md, which is in flight, and a class's numbers are its own document's to move — the same principle that gave 12-economy.md its ten classes (CM-1720's own note: "an imported row cites its owner and does not restate its numbers"). The finding goes to that document with both readings named: either the alarm's one non-trivial resolution earns 20, or its list is thinner than the class deserves and the fix is the list — which is the same choice this pass made six times, and it should be made by whoever owns the Bellwethers.

Ruled 2026-09-17, on the last two classes CM-1720 declared and nothing raised.

1. ScreenDegraded is built, and the number it needed was already being computed and thrown away. turn/requisition.ts reads every Screen's coverage to raise CM-1060's FormationUnderStrength on the structural case — CM-1050's uncovered × 4 > length, where the Formation does not have the units — and did nothing with the other side of that test. The other side is the item worth raising: a Screen that does have the units and is not covering its line. CM-460 names the three reasons — the units are out of position, the terrain is in the way, or step 2's Risk Sanction forbids the tiles that would cover it — and CM-010 forbids the engine from fixing any of them by itself, which is exactly the shape of a thing a player must be told. Its T is 40 by CM-1750: CM-460's re-spread closes a gap at the Screen's next activation, so next turn is when the matter resolves without intervention. Its A is the 40 that send more units (move) and shorten the screen line (abandon) earn.

2. CityAvailable is superseded and deliberately never raised. CM-1370's "free city in reach" is the same event: a city with no enemy in the knowledge view that Seize: Never forbids taking, raised as an Opportunity with the same stake this class carries (70, CM-1730) and the candidate Task that takes it (CM-1380), which this class never had. Two classes for one condition would mean two items for one city, ranked separately, with only one of them carrying the order that answers it. So the row stays as the record of a name that was superseded, and the engine raises the Opportunity. scripts/test/attention-classes.test.ts keeps it in its declared-and-unraised list with this ruling in place of the open question it held before — which is the difference between an absence somebody decided and one nobody has looked at.

Ruled the same day, on the question the imported classes forced: a resolution that names none of the five kinds contributes no kind. The parenthetical of this requirement lists them — move, fight, abandon, build, produce — and eleven of the fourteen imported classes turned out to carry 40 while offering a single resolution, most often a look: "Review the garrison", "Centre on the broken link", "Review production". A look is not trivial — it is not acknowledgement, and a player who is shown where their supply broke has been given something — so it earns the 20 of one non-trivial resolution. What it cannot do is be one of the two whose immediate effects differ in kind, because its immediate effect is nothing: the player is looking at a screen, and no part of the world has moved. Two looks are therefore 20 and not 40, and so are a look and an act.

Rationale, and it is this requirement's own: A is defined "by the offered resolutions rather than by an estimate of how much the outcome matters" so that it is objective and computable. The alternative reading — count a look as a kind when the client happens to make it a single click — makes the core's term depend on a client's implementation, which inverts CM-1620 ("the core owns the events, the client owns the presentation") and would move A every time a panel gained a button. The kinds are properties of the act a label names, and a label that names no act has none. The client has been drawing the same line since the resolution map landed: it marks a control that only navigates as a journey and not as an order, and actsOnClick answers false for it.

CM-1770 P — Player weight, in [−30, +30], default 0 — MUST be a per-class adjustment held client-side.

CM-1780 P MUST adapt: dismissing or snoozing a class three times without acting MUST decrement its P by 10, floor −30; acting on a class immediately three times MUST increment its P by 5, ceiling +30. The counters MUST reset whenever P changes.

CM-1790 Classes marked non-adaptable in CM-1720 MUST be exempt from CM-1780 entirely. Rationale: the game must never learn to stop telling you your capital is about to fall.

Amended 2026-09-11. RevoltImminent is exempt on the same grounds, which EC-2310's second clause requires of this document in as many words ("MUST exempt RevoltImminent from the adaptive weight of CM-1780 as CM-1790 exempts CityThreatened") and which nothing here carried. EC-1910 states the exemption from the economy's side and gives the reason — "the game must never learn to stop telling a player they are about to lose a city" — which is CityThreatened's reason exactly, one cause down: a revolt is how a city is lost without anybody attacking it.

CM-1800 Adaptation MUST be enabled by default, MUST be disableable with a single setting, and every current P value MUST be visible in a settings panel with a per-class and a global reset.

Rationale: learned weights are powerful and slightly sinister, and the honest objection is that the game should not decide what you care about. The floor at −30 answers it directly — a class is demoted, never silenced — and the exemption protects the case where being wrong is unrecoverable. Default-on rather than opt-in because a feature whose entire value is that it quietly reduces noise is a feature nobody will ever go and switch on, and the visible panel plus reset makes the decision reversible the moment a player disagrees with it.

11.5 Worked ranking, normative as a test vector

CM-1810 The following ranking MUST be reproduced exactly by a conforming implementation given the stated terms:

Rationale: note where the idle scout lands. It is the item a traditional "cycle to next unit needing orders" key would present first, because it has the lowest unit index and is loudly demanding attention. Four integer terms correctly put it last.

11.6 The turn-end gate

CM-1820 Ending a turn with unresolved items above an urgency threshold MUST produce a warning and never a block, naming the count and the threshold: "3 items above urgency 120 unresolved — end turn anyway?"

CM-1830 The threshold MUST default to 120, MUST be settable, and MUST be disableable. Rationale: blocking is patronising; not warning is negligent.

CM-1840 The turn-end warning MUST be suppressible for the remainder of a game in one action, and that state MUST be per-player client state.

11.7 Multiplayer considerations

CM-1850 Attention Events MUST be generated per player from that player's fog-filtered view only, and MUST NOT reveal any entity, tile, or fact the player could not otherwise observe.

CM-1860 The Dispatch MUST NOT be an information channel: an item's existence, class, or terms MUST NOT be inferable by an opponent, and the client MUST NOT emit any network traffic whose timing or volume varies with Dispatch content.

CM-1870 Deduplication by cause key and the Agency term MUST be the only mitigations required against attention-flooding by an opponent generating many cheap contacts. Rationale: flooding a player's attention with cheap probes is a real vector and probably an emergent tactic; it may well be a legitimate one. It is worth watching rather than pre-emptively patched, and the two structural mitigations already blunt it.

12. Presentation contracts and audit

12.1 Command View

CM-1880 The client MUST provide a Command View zoom level at which individual unit icons are replaced by Formation and Group markers, each rendering a Posture glyph, a strength bar, an arrow showing current intent, and any Dispatch pins in that area.

CM-1890 Every Dispatch item MUST pin to a map location. Hovering an item MUST move the camera to it; resolving an item MUST return the camera to where it was.

CM-1900 Command View MUST be usable to issue every Formation, Group, and Posting order without leaving it.

Rationale: on a very large map individual unit icons are meaningless, and this is not a nicety — it is the only zoom level at which a late-game empire is legible at all. It is also the tie that keeps the Dispatch from becoming a list a player reads instead of looking at the map.

12.2 Next intended action

CM-1910 Every unit under a Posture MUST display one plain-language line stating its next intended action and its Engagement clause, for example: "Will move 4 tiles toward Rill Ford; will not engage."

CM-1920 The next-intended-action line MUST be a pure function of the unit's committed order stack and the owner's knowledge view. It MUST NOT simulate opponents and MUST NOT predict combat outcomes beyond the predictor of CM-150.

CM-1930 Where the line cannot be computed — an order whose next step depends on a contact not yet made — it MUST say so explicitly rather than being blank.

12.3 The audit trail

CM-1940 Every automated action MUST emit a CommandDecisionRecord carrying: the unit id, the turn and activation index, a snapshot of the order stack, the Sanction clause that permitted the action, every integer input to the decision (predicted per-mille, candidate scores, thresholds, movement costs), the chosen option, and the runner-up option with its score.

CM-1950 A CommandDecisionRecord MUST be retrievable from the UI for any automated action for at least the 20 most recent turns, and MUST be retained for the whole game in a replay.

CM-1960 The record MUST be renderable as one sentence naming the clause and the numbers, in the form of CM-600.

Rationale: this is a trust feature for players and, not incidentally, the best debugging tool the team will have. It is what converts a bad automated outcome from "the automation is broken, I will never use it again" into "the threshold was too low, I will raise it" — which is the difference between a subsystem players adopt and one they abandon.

CM-1970 CommandDecisionRecords MUST NOT contribute to the canonical state hash and MUST be reproducible from a replay rather than stored in the order log.

12.4 Progressive disclosure

CM-1980 On first exposure the client MUST present Sanctions only as the three named presets of CM-750, and MUST reveal the four individual dials at a disclosure tier the player can also enable immediately.

CM-1990 Formations, Groups, Postings and Requisitions MUST each be independently disclosable, and the game MUST be fully playable with none of them enabled.

CM-2000 Where automation declines an action, the message MUST teach the reason in numbers — "stopped because sanctioned at ≥700‰; predicted 610‰" — rather than stating that it stopped.

13. Absent players, persistence, and versioning

CM-2010 In absent-player mode — a correspondence turn nobody attended, a disconnected live player, or an explicit away setting — automated units MUST resolve normally, units with no Posture MUST adopt their Fallback Posture for that turn only, and Dispatch items MUST persist to the player's next session rather than being consumed.

CM-2020 A unit that adopted its Fallback Posture under CM-2010 MUST NOT have its stored Posture changed, and MUST raise no Attention Event for having done so beyond a single per-turn digest line.

Protocol ruling (2026-09-21): the authority identifies absent-player mode by setting absent: true on that player's TurnTimeout record. An ordinary TurnTimeout closes an order stream but does not by itself assert that the player was absent; this preserves the same terminator for attended human and AI turns.

CM-2030 Order stacks, Sanctions, Doctrines, Formations, Groups, Postings, Consignments, Requisitions and allocation counters MUST survive save, load, replay, and a switch between play modes without alteration.

CM-2040 All of the above MUST be expressible as ordinary orders in the authoritative order log. The command layer MUST NOT introduce any state that reaches the simulation by a path other than the order log.

CM-2050 Automation behaviour MUST be versioned with the ruleset by an integer commandLogicVersion recorded in the replay header and in every save.

CM-2060 Any change to a Posture algorithm, a Sanction test, a tie-break, a threshold, a default, the Reflex set, the interruption table, or the allocation scheduler MUST bump commandLogicVersion.

CM-2070 A replay whose recorded commandLogicVersion differs from the build's MUST be replayed under the recorded version where that version is available, and MUST be reported as incompatible rather than replayed approximately where it is not.

Rationale: because automation must be deterministic and core-side, changing how a Screen picks its tile is a balance change and it breaks replay compatibility. That is the price of automation that cannot cheat, and the versioning is how we pay it honestly instead of discovering it as a desync three releases later.

CM-2080 Attention Event generation MUST be versioned separately by an advisoryVersion, and a change to advisoryVersion alone MUST NOT invalidate a replay.

14. Performance and scale bounds

CM-2090 Command-layer evaluation for one unit's activation MUST complete within a bounded candidate set: Screen, Survey, TakeCover and Withdraw MUST each evaluate at most 256 candidate tiles, selected by ascending movement cost then ascending tile index and truncated at that bound.

Rationale: an unbounded search over a leash radius on a very large map is the one place this subsystem could quietly become the frame budget. Truncating a deterministically-ordered list keeps the bound and keeps the determinism, and 256 tiles is more than a Leash of 12 can reach for any movement allowance in the expected roster.

CM-2100 The command layer MUST resolve 400 units' activations, including all Posture evaluation, Sanction tests, projection and interruption handling, within 50 ms on the project's reference hardware, excluding pathfinding, which is bounded by 03-architecture.md AR-750.

CM-2110 Route caching MUST be the default: an activation that does not invalidate its cached next two tiles MUST perform no pathfinding.

CM-2120 Requisition shortfall computation MUST be incremental: a unit's creation, arrival, death, or re-posting MUST update the affected rows in constant time rather than triggering a scan.

CM-2130 The Dispatch MUST rank and present within 16 ms for up to 200 concurrent live Attention Events.

15. Contracts on other documents

These are obligations this specification places on subsystems it does not own. They are recorded here so that a change on either side is detectable.

CM-2140 10-turn-model.md MUST provide: a unit's activation index within the current Cascade, readable during that Cascade, so that Intent Freshness (CM-960) can distinguish members activating before and after their commander; the creation sequence number as a totally-ordered tiebreak available to both core and client; and a definition of Stance whose values the derivations in §4 can target. It MUST also guarantee that a unit under a Posture occupies its activation slot, resolves, and yields without any player prompt.

CM-2150 The combat specification MUST provide the deterministic per-mille win predictor of CM-150 and CM-160, evaluated over a fog-limited knowledge view, identical to the value shown to a player before a manual attack; a per-terrain defensive value for CM-1410; and a capture-probability prediction for CM-1370.

CM-2160 Where the combat specification allows co-ordinated attacks to combine, the combination MUST key off physical adjacency and timing, never off Formation or Group membership, so that a hand-ordered set of units achieves an identical result. Rationale: this is what lets CM-060 forbid a formation combat bonus without forbidding combined arms.

CM-2170 The units specification MUST provide, per class: movement allowance and movement class, vision radius, current and maximum strength, whether the class may occupy a city, and optionally a command rating which, where present, replaces the default span of 8 in CM-850.

CM-2180 The economy specification MUST provide: a city production queue that does not cancel a committed in-progress item (CM-1270); critical and restore thresholds for supply, fuel and ammunition for the Replenish Reflex; repair and resupply site locations; and unit cost for the S terms in CM-1720.

Ruled 2026-09-21 (Codex). This contract is read through the economy that actually exists, not as authority to introduce the third resource EC-180 expressly forbids. There are no per-unit fuel or ammunition stocks, so those two threshold clauses are vacuous. For the one logistics state 12-economy.md does own, Isolated is the critical threshold and Supplied is the restore threshold; Extended is deliberately between them. Friendly Cities and emplaced Depots are the resupply sites produced by the Reach fill and the high-rate repair sites of EC-1730. Field recovery remains a passive Ledger rate, not a destination worth raising an Opportunity for. Unit cost is the class's list Works price, which CM-1720's UnitLost arithmetic already reads. This resolves the former contradiction in which command required fuel and ammunition thresholds while EC-180 prohibited those states, and replaces the production knowledge view's inert always-false supply seam with the fog-honest Reach answer.

Ruled 2026-09-25 (Claude Code), amending the ruling above on the owner's standing delegation (P3 in docs/design/02-spec-rulings.md). The critical threshold is Isolated for a third consecutive phase — isolatedTurns ≥ 3 (EC-1740) — not the first Isolated phase. The restore threshold stays Supplied, and a Replenish already running keeps its way home through Extended as before. Under the first reading no unit could spend any of EC-1740's budget: the Reflex turned every unit for home on its first Isolated phase, although attrition is 5%, then 10%, then 15%, and a unit dies only at the sixth. On a Small map, where neighbouring cities stand 14–17 tiles apart and farther than a city's supply reaches, that made the first capture unreachable for anyone who had not first carried a Depot out. The AI's units walked out and back for a hundred turns, and a human's would have too. Measured with the change patched into the compiled core (Small/2, the default quick game, eight seeds): the seeds where the AI had taken nothing by turn 25 took their first city. AI panel 53 held / 0 decided → 53 / 1; ai-passive unchanged at 3 of 9. Two phases read 51 / 1, so three is the threshold. Code follow-up landed 2026-10-08: world/knowledge.ts's supply answers an Isolated unit with isolatedTurns < 3 as not critical, and a Replenish already running is owed its way home whatever the count (contracts-15.test.ts, "ruling P3"). It moved eleven corpus trajectories and reference-game.elc (artifacts/README.md).

CM-2190 The economy specification, and not this one, MUST own any visible anti-snowball brake the design requires. CM-1300 forbids placing it in command capacity.

CM-2200 04-ui-ux.md MUST own the presentation of the Command View (CM-1880), the unit and Formation panels, the Dispatch surface, and the progressive-disclosure tiers of §12.4, implementing the content requirements this document states.

Open questions

1. Is the Screen coverage heuristic good enough? CM-460 is defined precisely enough to build, but whether it feels like a screen — whether units spread the way a player would place them — is unknowable without playing it. This is the highest-risk piece of automation logic in the document, and the hysteresis constant of 2 and the 256-candidate truncation are the two values most likely to need retuning.

2. Does Seize: Undefended defaulting on cause regret? CM-710 argues that all competent players take a free city, so it is arithmetic. But capturing reveals your position and creates a garrison obligation, and CM-730 makes that obligation concrete. If playtest shows players routinely turning it off, the default is wrong and the Opportunity card plus Banked Movement is the better answer on its own.

3. Is adaptive P right as a default? CM-1800 decides default-on with a floor, an exemption, and a visible reset. The opposing case — that a game quietly learning what you care about is unwelcome regardless of guardrails — is not refuted by anything here, only guarded against. The measurement that would settle it is whether players who leave adaptation on dismiss fewer items over a hundred turns than those who turn it off.

4. Is a soft warning at 13 Postings the right cap? CM-1150 warns and never blocks. It is possible that the real answer is not a cap at all but a Posting hierarchy, which this document has deliberately refused on the same grounds as the two-echelon limit.

5. How large should the conditional vocabulary become? The Task end conditions of CM-260 are five, and the Postures six. The turn-model design flags conditional expressiveness as the design's largest execution risk. This document's bet is that Sanctions carry the conditionality that would otherwise need a condition grammar. If playtest shows players trying to express conditions that no Posture-plus-Sanction combination reaches, the answer is a sixth and seventh Task end condition rather than a general expression language, because a general grammar cannot be shown on a unit panel and CM-320 requires that it can.

6. Should a Formation be able to hold Garrison? CM-870 says no, on the grounds that a formation garrisoning several places is a Posting with extra steps. A player defending a cluster of four cities with one command object may disagree.

7. What is the right retention for CommandDecisionRecords outside a replay? CM-1950 says 20 turns. That is a memory decision as much as a design one, and the number should be revisited once the record's actual size is known.

8. Does the Van role's forced Defend/Cautious (CM-910) need an escape? A player who wants an aggressive vanguard currently cannot have one without removing the role. The counter-argument is that an aggressive vanguard is simply a Main element placed forward, which the vocabulary already expresses.

Built from source 47fa2827eff0 · VERSION.json