Command at Scale

Every Last City — design proposal Scope: how a player commands a large empire. Standing orders, formations, multi-turn movement, reinforcement routing, production templates, the interruption model, and attention routing.

1. The problem, with numbers

By turn 200 a winning player has somewhere between 150 and 400 units. The genre's traditional command model is one order per unit per turn. Even at an optimistic four seconds per unit — select, read its situation, decide, click — 300 units is twenty minutes of pure clerical execution per turn, before a single strategic thought. A hundred more turns of that is thirty-three hours of data entry.

That is not a UI problem. It is a design problem, and it has three distinct components:

1. Execution volume. Most of those 300 units are doing something obvious: walking to the front, sitting in a city, watching a river line. Their orders contain no decision.
2. Attention scarcity. Buried in the 300 are perhaps five units whose situation genuinely requires the player. The traditional interface — a "cycle to next unit needing orders" key that walks units in index order — surfaces them in an order uncorrelated with their importance. You handle a scout in an empty desert before you notice the city about to fall.
3. Aggregation failure. The empire has no representation above the individual unit. A player thinks in fronts, columns, and objectives; the game only lets them speak in single units.

The traditional half-fixes — a sentry flag, an explore toggle — address (1) weakly and (2) and (3) not at all. Worse, they are unsanctioned: a sentried unit does something the player cannot tune, and a single bad outcome teaches the player never to use it again. An automation players do not trust is worse than no automation, because it costs interface surface and delivers nothing.

Design targets, stated so they can be failed

These are the claims this design makes. Each is measurable in playtesting (§13).

2. The line: what is the player's, and what is arithmetic

The assignment's hard problem is automation without loss of agency. Here is the cut, stated as a principle before it is stated as a list:

A decision belongs to the player when two competent players would reasonably choose differently. Everything 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.

Applied, that gives three categories.

The Commitment Ledger — always the player's

1. What the empire is trying to achieve. Objectives, fronts, which direction the weight goes.
2. Force structure. What gets built, in what proportion.
3. Committing to a battle you might lose, unless you pre-authorised that class of battle.
4. Taking or abandoning a city.
5. Spending anything scarce and irreplaceable.
6. Anything that changes the shape of the plan rather than executing it.

The Execution Ledger — safe to automate, unconditionally

1. Pathfinding, movement-point spending, terrain-cost arithmetic.
2. Repair, resupply, and refuel routing.
3. Loading and unloading transports on a stated route.
4. Maintaining a stated coverage — sitting in a city, watching a river line.
5. Turning a stated force structure into build orders against available production.
6. Self-preservation within a stated risk tolerance.

None of these has a decision in it. A player who does them by hand is not playing; they are being a pathfinder.

The sanctioned middle — the bridge

Between the two ledgers sit the actions that are decisions but that a player is willing to pre-decide: attacking, leaving a post, retreating, taking an empty city. These are governed by Sanctions (§3.2): rules the player writes once, in advance, scoped to a unit or a formation, visible on the unit's panel, revocable at any moment, and inspectable after the fact — every automated action taken under a sanction records which sanction permitted it and what the numbers were at the time.

This is the whole answer to "the game played itself." It did not. The player wrote the rule; 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. Delegation becomes gradual and reversible instead of a binary leap of faith.

Two further guarantees make the bridge load-bearing:

• Automation is fog-honest. Automated units decide using exactly the knowledge the player has — last-known observations, estimated strengths, unexplored tiles treated as unknown. Automation is never a wallhack. It will sometimes walk into something a player could have inferred; that is the price, and it is the right price to pay. It also means expert players will hand-order at the decisive point, which is not a failure of the design — it is the design working.
• The command layer draws no randomness. Every automated choice is a deterministic function of visible state: path ties break by lowest tile index, target ties by lowest unit sequence number. Only combat consumes the seeded PRNG. This keeps replays exact and keeps automation from feeling capricious.

3. Layer one: Postures and Sanctions

3.1 Postures — six standing orders, not twenty

A standing order is a Posture: a persistent statement of a unit's job that survives turns, interruptions, and the player's absence. Six primitives, each one sentence:

There is a seventh state, and it is deliberately not a Posture: Idle. Idle is not rest. A unit with no Posture raises an attention item every turn until it has one. There is no way to have a quietly forgotten unit.

Two of these deserve implementation-level definition, because they are the ones that look vague:

Screen. A Screen is assigned a line — an ordered list of two or more tiles defining a frontage — not a patrol path. Each activation, the unit scores every tile within its Initiative radius by how many line-tiles fall inside its vision radius; it moves to the best-scoring tile. Ties break by movement cost, then lowest tile index. Hysteresis: it only relocates if the candidate beats its current tile by 2 or more covered line-tiles, which stops units shuffling one square sideways every turn as fog moves. Several units on the same line naturally spread out, because a tile already covered by a comrade scores nothing extra. This is patrol expressed as a coverage goal rather than a route, and it is why a Screen degrades gracefully when you lose a unit: the survivors re-spread to cover the gap without being told.

Survey. Maximise newly revealed tiles per movement point inside the region, deterministically scored, avoiding tiles within one move of a known enemy the unit cannot beat. Terminates when the region has no reachable unrevealed tiles, which raises an Arrived event.

3.2 Sanctions — four orthogonal dials

Every Posture carries four Sanctions. They are what the player pre-decides. They are always visible on the unit panel in plain language.

Engagement — when may this unit start a fight?

Favourable takes an integer per-mille threshold, default 700. Presets: Trade 600, Even-handed 700, Careful 850. The justification 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 and not in a global setting. The prediction is the same deterministic function the UI shows the player on a manual attack, computed from fog-limited knowledge, and every automated attack logs it: "Attacked at 743‰ predicted; sanctioned at ≥700‰."

Initiative — how far may it leave its assigned geometry?

Tight 0 tiles · Local 4 tiles · Loose 12 tiles, or any integer the player types. Four is roughly two turns of movement for a typical ground unit, which lets a single screening unit cover a nine-tile frontage from its centre; twelve is three times that and is a scout's leash.

Risk — when does it break off and preserve itself?

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

Never · Undefended · Free. Default Undefended for mobile Postures. This is the one place where the default sits on the permissive side of the line, and the reason is target T5: if the default were Never, an automating player would watch an empty city and lose it while waiting to be asked, which punishes automation. Capturing a genuinely undefended city is a case where all competent players agree — so by the principle in §2, it is arithmetic. It remains a sanction nonetheless: visible, revocable, logged. The principle is preserved; only its default differs.

Posture defaults (every one overridable, and every one shown in plain words on the panel):

Garrison defaults to Expendable because a garrison that runs away is not a garrison; Screen pairs Favourable with Cautious because a screening force should pick off stragglers and evade columns, which is precisely what those two dials produce together.

3.3 The order stack

A unit does not have an order. It has a stack, three deep:

[2] Reflex    — pushed by the engine: Withdraw, Regroup, Take-cover
[1] Task      — pushed by the player: "go here first", "hit that"
[0] Posture   — the standing order; the unit's job

The unit executes the topmost non-empty level. When a level completes or is cancelled it pops and the unit resumes the level below. This is the single most important structural decision in the document, because it means interruption suspends a standing order instead of destroying it. In the traditional model, a unit interrupted by contact loses its order and becomes a blank order-demanding object — which is exactly the moment the player is busiest. 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.

Depth is capped at three because a deeper stack cannot be explained on a panel.

Each unit also carries a Fallback Posture — set once, default Hold / Defend / Tight / Prudent. It is the answer to "what do I do when I no longer know what to do," and it means an order that becomes impossible never yields surprising behaviour: the unit does the thing the player chose in advance, and says so.

4. Layer two: Formations and Groups

4.1 What a Formation is, and is not

A Formation is a named set of units with one commander and one order stack. It is a command relationship, not a physical merge. Members keep their own tiles, their own movement, their own combat. There is no super-unit and therefore no doom-stack; positioning still matters, and losing a formation is a series of events rather than one catastrophic die roll.

Members occupy role slots, and the formation's order translates into per-member orders by role:

A player who assigns roles once has, thereafter, expressed "advance with a vanguard, flanks out, and the train protected" in a single March order. Doing that by hand is ten orders a turn.

Span of control: 8 members. Beyond eight the formation must be split or promoted into a Group. Eight because a formation panel of eight rows is readable without scrolling, and because span-of- control practice across every real hierarchy clusters between three and nine. If the unit roster gives some unit types a command rating, span becomes per-commander data; eight is the default when it does not.

Groups. One level of nesting: a Group commands up to 5 Formations — 40 units under one order. Two echelons total, and no more, because a three-level tree cannot be navigated at speed and because 10 Groups already covers 400 units, which is past the top of the expected range (T4).

4.2 Pace — the choice that makes formations interesting

A Formation has a Pace, and this is a genuine strategic decision rather than a UI convenience:

• Concentrated. Members stay within the cohesion radius (default 3 tiles) of the formation anchor. A member that exceeds it receives a Regroup reflex. The formation therefore advances at the speed of its slowest member and arrives as a fist.
• Dispersed. Cohesion is unenforced. Each member moves at its own rate toward the objective. The formation arrives piecemeal but its fastest elements arrive far sooner.

That is the classic operational tradeoff — concentration versus tempo — expressed as one toggle, and it means the command layer adds a decision rather than only removing clicks.

4.3 Intent Freshness — command lag that emerges from the turn model

The turn model activates units in a single global queue ordered by creation sequence. That gives formations a command latency rule for free, and it is elegant enough to be worth adopting deliberately:

A formation member executes the formation's intent as of the last time its commander activated.

If the commander's sequence number is lower than the member's, the commander activates first this turn and the member executes this turn's intent — responsive. If the commander is newer than most of its members, those members activate before it and execute the intent from the commander's last activation — one turn stale.

The consequences are all good ones. Putting an old unit in charge makes a formation responsive; promoting a freshly built unit to command makes it sluggish. Players will deliberately preserve veteran commanders and will feel the cost when a commander dies and a new unit takes over. It is fully deterministic, costs nothing to compute, requires no new mechanism, and explains itself in one sentence. It also gives the turn model's seniority ordering a concrete, in-world meaning beyond "older units go first."

The risk is that it is invisible unless the UI shows it. The formation panel must state "Responsive" or "One turn behind" with the reason, always.

4.4 Why formations are not compulsory

Formations grant no combat bonus. This is deliberate. The moment formations confer a fighting advantage they stop being an offer and become a tax — every player must use them, and the "choice" evaporates. Their benefit is exactly what they are for: one order instead of eight, plus role behaviours that would otherwise be hand-simulated. A player may keep every unit independent, pay eight orders instead of one, and be tactically no worse off. That is target T5 and T6 holding simultaneously.

If the combat design wants co-ordinated attacks to combine, that belongs in combat and should key off physical adjacency and timing, not off formation membership — so that a hand-ordered set of units can achieve it identically. (Contract to the combat designer, §14.)

5. Layer three: production to the front

This is the largest single source of clicks in the classic model and the one with the least decision content in it. It is also where genuine operational-level command lives.

5.1 Postings and Consignments

A player defines a handful of named Postings — a destination anchor, a default Posture for arrivals, and an integer weight. Example: Northern Front (3), River Line (2), Home Defence (1).

Every city has a Consignment: the Posting its output reports to, or Manual. A unit produced in a consigned city is born with March to <anchor>, follow-on Attach to <formation> or the posting's default Posture. Zero clicks (T3).

Allocation is a deterministic integer scheduler. When a city's Consignment is Auto, the unit goes to the Posting with the largest accumulated deficit. Each allocation: add every Posting's weight to its counter, give the unit to the highest counter (ties break by lowest Posting id), then subtract the sum of all weights from the winner.

Worked, with Northern (3) and Home (1), total 4:

Four units delivered 3:1, counters back at zero, and the pattern repeats exactly. Integer, exact, replayable, and it produces a stable interleave rather than four units north then one home.

Moving anchors. A Posting's anchor may be a Formation rather than a tile. Reinforcements then march to wherever that formation is — but with hysteresis: the destination only re-targets when the formation has moved more than 5 tiles from the last target. Without it, a reinforcement stream chases a mobile army in circles and never arrives.

5.2 Standing Requisition — commanding force structure instead of build orders

The strongest abstraction in this document. A Posting carries a Requisition: the force structure the player wants there.

Northern Front — Requisition
  Heavy ground   6      have 4   in transit 1   short 1
  Light ground   4      have 4   in transit 0   short 0
  Air            2      have 0   in transit 0   short 2

Cities consigned to that Posting build whatever it is short of, most-short-first, subject to what they can build. When the front takes losses, production reacts without the player touching a city. When the Requisition is met, consigned cities fall through to the next Posting by weight, or to a player-set surplus rule.

Note carefully where the decision sits. Choosing the force structure is the decision — heavy or air, six or ten — and it is a good one, made once, visible as a single panel, and changed whenever the player's read of the front changes. Turning that structure into build orders is arithmetic. The cut is exactly on the line from §2.

5.3 Templates and repeat production

For players who want city-level control: a city's production is a queue plus a repeat rule, and a named Template is a saved build list ("Screening pair: 2 light, 1 scout") that can be assigned to a city and looped. Templates and Requisitions coexist; Templates are the manual tool, Requisitions the operational one.

5.4 Doctrines — the real click-killer

A Doctrine is a saved bundle of Posture + Sanctions + role, named by the player, applied with one click to any unit or selection. Each unit type has a default Doctrine, set once in a single panel.

Combined with Consignments, this closes T3 completely: a unit is born with a Doctrine from its type and a destination from its city, and requires no input at all from the moment it exists until something happens that needs a person. In a hundred-turn stretch producing 120 units, that is 120 units of clerical work that never occurs.

6. The interruption model

Automation is only as good as its behaviour when the plan breaks. Six interruption classes, with the unit's behaviour and the attention consequence specified for each.

Route policy — the anti-dithering rules

A March carries an ordered waypoint list, a cached route, a follow-on order, and its Sanctions.

• The route is recomputed at activation only if the cached next two tiles have become invalid. Otherwise the cache is followed. Cheap, and behaviour stays stable enough to watch.
• Newly revealed terrain offering a better route triggers a reroute only when the improvement clears 25% — integer test newCost × 4 ≤ oldCost × 3. Without hysteresis, units oscillate as fog lifts, which looks broken even when it is optimal.
• If no route exists at all, the March raises Blocked, suspended rather than cancelled, so that clearing the obstruction lets the original order resume untouched.

Held Movement

A unit that halts on an Opportunity or a Blocked event retains its unspent movement and may be reactivated once, out of order, at the player's request during the same turn — at its original queue position for conflict-resolution purposes. This exists solely to satisfy T5: without it, an automated unit that pauses to ask permission loses a turn relative to a hand-ordered one, and automation becomes a measurable disadvantage. That would be fatal.

The two trust rules

Everything above serves two rules, and they should be treated as inviolable:

1. Automation never takes an irreversible action the player did not sanction.
2. Automation never silently stops. A unit that has made no progress on its Posture for two consecutive turns raises an attention item. A unit that is Idle raises one immediately.

The second matters more than it looks. The single 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 mode is invisible, compounding, and destroys trust permanently the moment it is discovered.

Two supporting affordances

• Next intended action, always shown. Every automated unit displays one plain-language line: "Will move 4 tiles toward Rill Ford; will not engage." No modelling required, no prediction of opponents, and it converts automation from a black box into something a player can audit at a glance.
• "Why did this happen?" Any automated action can be interrogated after the fact and returns the sanction that permitted it and the numbers at the time. It is a trust feature for players and, not incidentally, the best debugging tool the team will have.

7. The Dispatch — attention routing

With 300 units, showing the player the five that need a decision is the more important half of this design. The mechanism is the Dispatch: a ranked, deduplicated, bounded, actionable queue.

Five properties, each load-bearing:

1. Bounded. At most 7 items shown, player-settable 3–15. Everything below the cut collapses into a one-line digest. A list of forty alerts conveys the same information as no list.
2. Actionable. Every item carries at least one one-click resolution and a snooze (default 5 turns). An item with no available action is not an item; it is a digest line.
3. Scored, not chronological. Ranked by an integer Urgency score, ties broken by unit sequence number so the ordering is deterministic and stable.
4. Deduplicated by cause. Ten units contacted by one enemy column produce one item — "Enemy column of 6 at Ash Ford — 10 of your units in contact" — not ten.
5. Sticky. Items persist until resolved or snoozed. A new turn does not clear them.

The Urgency score

U = S + T + A + P, all integers.

S — Stake (0–100): what is at risk or on offer.

Stake is signed in the sense that it covers gain as well as loss, but a city you may lose outranks a city you may take, because the loss is certain to matter and the gain may still be there next turn.

T — Tempo (0–60): how soon. Resolves this turn 60 · next turn 40 · within three turns 20 · beyond 5. Tempo outweighs a large distant stake deliberately: distant items will resurface, and a decision that expires this turn will not.

A — Agency (0–40): how much the player's choice changes the outcome. A genuine choice with divergent outcomes scores 40; a formality scores 5. This is the anti-noise term, and it is what demotes items where automation would have done the right thing anyway.

P — Player weight (−30…+30, default 0). A per-category adjustment. It adapts: dismissing or snoozing a category three times without acting decrements P by 10 (floor −30); acting on it immediately three times increments P by 5 (ceiling +30). A settings panel shows every current weight with a reset. Two safeguards: the floor means a category is demoted, never silenced, and city-loss-class items are exempt from adaptation entirely — the game must never learn to stop telling you your capital is about to fall.

Worked ranking — one turn, five items

The ranking a strong player would choose, produced by four integer terms. Note that item B — a unit literally sitting idle demanding orders, the thing a traditional cycler would show you first because of its low index — correctly lands last.

The turn-end gate

Ending a turn with unresolved items above a threshold produces a warning, never a block: "3 items above urgency 120 unresolved — end turn anyway?" with a "stop warning above N" setting. Blocking is patronising. Not warning is negligent.

Where the Dispatch lives

The simulation core emits Attention Events. The client ranks and presents them. This split matters for three reasons: the core stays deterministic and its state hash unaffected by a player's personalised weights; the ranking can be improved without invalidating replays; and adaptive weights are per-player UI state rather than game state.

The corollary must be enforced in the other direction: automation logic lives in the core and is identical for every player. A better client may present attention better — that is UI quality, like a better minimap. A better client must never make units fight better, or the game is pay-to-win.

8. Command View — the map at empire scale

The Dispatch must not become a list you read instead of looking at the map. Two ties:

• Every item pins to a map location; hovering flies the camera there; resolving it returns you.
• A Command View zoom level where individual units disappear and the map renders Formations and Groups as single markers with a posture glyph, a strength bar, an arrow showing current intent, and Dispatch pins overlaid.

On a map two thousand tiles to a side, individual unit icons are meaningless — this is not a nicety, it is the only zoom level at which a late-game empire is legible at all. Command View is where the player actually plays turn 200: ten markers, five pins, and the fronts drawn as lines.

9. A worked turn — turn 203, 287 units

The empire: 4 Groups, 11 Formations, 9 Postings, 34 independent units (garrisons, ferries, scouts). Top-level command objects: 13.

The player opens the turn in Command View. The Dispatch shows four items.

1. U=180 — "Riverport threatened." Enemy armour column, six markers, two tiles out. Offered actions: Reinforce from 2nd Column (arrives in 1 turn) · Evacuate garrison · Hold and accept. The player picks reinforce. One click. 2nd Column's March order is pushed as a Task above its Posture; it will pop back to screening the river line when it arrives.
2. U=170 — "Thorn Wells undefended, Infantry 88 adjacent." Infantry 88 was on Survey with Seize: Never because the player set that Doctrine for scouts. The card offers Take it — and Held Movement means taking it costs nothing, because the unit halted with its movement intact. One click.
3. U=130 — "3rd Column blocked at Ash Ford." Offered: Force the crossing (predicted 610‰, below their sanctioned 700‰, which is why they stopped) · Reroute via Elk Bridge (+3 turns) · New objective. The player reroutes. One click.
4. U=45 — "Scout 44 idle." The player drags a new Survey region. One drag.

Digest line below: "14 minor contacts · 3 arrivals · 2 repairs complete · 6 units produced and consigned." All handled; none needed a person.

Then the player does the thing they actually came for: they look at Command View, decide the Northern Front is being fed too slowly, and change its Posting weight from 3 to 5 and its Requisition from six heavy to nine. Two edits. Production across eleven cities reorganises without another click.

Total interactions: nine. Turn time: three or four minutes, nearly all of it spent looking at the map and thinking about the north. That is target T2.

10. Why this beats the classic approach

Point by point against the traditional model — per-unit orders, a couple of sticky flags, and a "next unit needing orders" cycler.

The deepest difference is category rather than degree: the classic model has no vocabulary above the unit, so a player who thinks in fronts must translate every thought into three hundred individual instructions and re-translate the results back. This design gives the player nouns at the altitude they actually think at — front, column, line, requisition — and does the translation itself.

11. Tradeoffs and honest costs

Automation quality becomes gameplay-critical engineering. A mediocre Screen implementation makes the entire design feel broken, and it must be deterministic, fog-limited, and fast enough for 300 units on a four-million-tile map every turn. This is the largest cost in the proposal and it is not small.

Automation logic is part of the rules. Because it must be deterministic and core-side, changing how a Screen picks its tile is a balance change and it breaks replay compatibility. Automation behaviour must be versioned with the ruleset and recorded in the replay header. Living with this is the price of automation that cannot cheat.

Learnability surface. Six Postures × four Sanctions is real complexity. Mitigation: Sanctions are hidden behind three named presets on first exposure and revealed progressively; defaults are sane; and the Dispatch teaches by showing "stopped because sanctioned at ≥700‰, predicted 610‰." It remains a genuine cost for a new player and the onboarding must carry it.

Fog-honest automation is weaker than a good player. It will sometimes do something a player could have avoided by integrating knowledge it cannot use. This is deliberate and correct, but it means automation has a competence ceiling and expert players will hand-order at decisive points.

The Dispatch is an attack surface in multiplayer. An opponent who generates many cheap low-stake contacts can attempt to flood a player's attention. Deduplication by cause and the Agency term blunt this, but it is a real vector and probably an emergent tactic. It may even be a legitimate one — worth watching rather than pre-emptively patching.

Intent Freshness is elegant and potentially mysterious. Emergent command lag from creation order is a lovely rule that will confuse anyone who is not told. The formation panel must state it in words, every time, or the mechanic becomes a bug report.

Two echelons only. Players who want deep hierarchies will not get them. Deliberate: three levels cannot be navigated at speed, and two covers 400 units.

Formations grant no combat bonus, which means some players will ignore them entirely. That is the intended shape of the offer, but it does mean the feature's value depends entirely on the command savings being real.

12. What could go wrong

Trust collapse. One spectacular automated loss — a column walks into an ambush — and the player hand-orders forever after. This is the primary failure mode and everything in §6 exists to prevent it: conservative defaults, fog-honesty, the next-intended-action line, and the "why did this happen" replay so that a bad outcome produces a tightened dial rather than an abandoned system.

The Dispatch becomes a to-do list. If items feel mandatory and there are fifteen of them, the player is back to clerical work with extra ceremony. The dangerous signal is high item count combined with high action rate — that means junk is passing the filter and the player is dutifully processing it.

Automation dominance. If an empire run purely on Requisitions and Sanctions beats a hand-played one, agency is gone and the game plays itself. This is directly testable (§13, M8) and the acceptance criterion is sharp.

The silent stall. Units doing nothing for many turns while the player believes otherwise. Guarded by the two-turn progress rule; must be instrumented anyway, because the guard itself can have bugs and this failure is invisible without measurement.

Requisition thrash. A front oscillating between shortfall and surplus could make cities flip production every turn. Mitigation: production commitments do not cancel mid-build, and shortfall is evaluated including in-transit units. Worth watching in playtest.

13. Playtest instrumentation

Every target in §1 is measurable. These are the metrics, and the ones with numbers attached are pass/fail.

M8 is the one I would build first. It is the sharpest possible statement of the agency contract: a player who thinks harder must win, and a player with less time must still be able to play.

14. What this design needs from the activation queue

The turn model is another designer's remit. These are the contracts it must satisfy for this design to work. They are stated as needs, not as specifications of the queue.

1. Automated units resolve without a prompt. A unit under a Posture must occupy its queue slot, act, and pass on, without the walk ever blocking on a human.
2. Commander activation state is inspectable. At a unit's activation, the design needs to know whether its formation commander has already activated this turn. Intent Freshness (§4.3) depends on the ordering being readable, not merely walked.
3. Deterministic tie-break by sequence number, available to the client for Dispatch ordering as well as to the core.
4. A pre-walk hook where the client can present the Dispatch and the player can retask before any unit activates. Retasking a unit whose slot has not yet come up applies this turn; retasking one whose slot has passed applies next turn — and the UI must say which.
5. Held Movement (§6). A unit that halted on an Opportunity or Blocked event must be re-activatable once, out of order, within the same turn, resolving conflicts at its original sequence position. Without this, automation costs tempo and target T5 fails.
6. Newly built units enter the queue already holding their Consignment order and must not require attention on their birth turn (T3).
7. A "player absent" mode for asynchronous play: automated units resolve normally, unautomated units adopt their Fallback Posture, and Dispatch items persist to the next session rather than being consumed.
8. If the queue resolves as overlapping windows rather than strict global order (the open question in the direction document), then Dispatch items generated by opponents' concurrent activations must surface only as fog permits, and Urgency must be recomputable mid-turn as new items arrive. This design works under either reading; overlapping windows simply makes the Dispatch a live feed rather than a turn-start briefing.

Two contracts fall outside the queue:

• To the combat designer: if co-ordinated attacks combine, they must key off physical adjacency and timing rather than formation membership, so that hand-ordered units achieve identical results (§4.4).
• To the economy designer: this document deliberately does not introduce a growth brake. Command capacity is a tempting place to hide one, and it is the wrong place — a brake there would punish players for automating, violating T5. The visible anti-snowball mechanism the direction document asks for belongs in logistics, upkeep, or territorial strain.
• To the unit-roster designer: an optional per-type command rating would let span of control vary by unit; the default is a uniform span of 8.

15. Open questions I could not settle

1. Is the Screen's coverage heuristic good enough? It is defined precisely enough to build, but whether it feels like a screen — whether the 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.

2. Should a formation be able to hold a Posture its members cannot? A formation ordered to Screen a 30-tile line with 8 units cannot cover it. Does the order fail, degrade to partial coverage with an attention item, or auto-request reinforcement against the Posting? I lean toward partial coverage plus a persistent low-urgency item, but I am not sure that is not just a nag.

3. Intent Freshness and the queue's open question. If the turn model chooses overlapping windows, "has the commander activated this turn" becomes genuinely ambiguous mid-turn. The rule may need restating in terms of the last completed commander activation. I cannot settle this before the queue semantics are settled.

4. How much should the Dispatch adapt? Learned weights are powerful and slightly sinister. The floor at −30 and the city-loss exemption are guardrails, but I do not know whether players will experience adaptation as helpful or as the game deciding what they care about. It may be better as an opt-in.

5. The right number of Postings. I have assumed a handful. A player with fifteen Postings has rebuilt the micromanagement problem one level up. Should there be a soft cap, and if so what enforces it?

6. Does Seize: Undefended defaulting on cause regret? The argument in §3.2 is that all competent players take a free city, but capturing reveals your position and creates a garrison obligation. If playtest shows players routinely turning it off, the default is wrong and the Opportunity card plus Held Movement is the better answer on its own.

7. Whether Order-stack depth 3 is enough for the case of a formation member that is simultaneously executing a formation Task, a personal reflex, and a Posture. I think it is, but the Attach posture's inheritance may effectively need a fourth conceptual level, and I would rather discover that in a prototype than argue it here.