10 — The Turn Model: Orders and the Cascade

This document specifies the spine of the simulation: the three phases of a turn (Orders, the Cascade, the Reckoning), the Initiative score and the total activation order it produces, Stance as the per-turn tactical setting that buys initiative and reaction capacity, what it means to resolve an order "against the world as it is at that instant", the reaction system that lets a stationary defender interrupt a mover, where newly built units enter the order and what happens to destroyed and displaced ones mid-Cascade, what happens when an order is unachievable at evaluation time, orders as data in the authoritative log, deadlines and stalls and substitution, and the fog rules that govern what a player sees during each phase. It owns when and how orders are evaluated; 13-command.md owns what an order can say. Everything specified here is integer arithmetic over committed state, computed identically on every client, every server, and every AI seat.

Status: Draft v0.2 · Owner: unassigned · Depends on: docs/design/00-direction.md, docs/design/01-decision-turn-model.md, docs/design/turn-model.md, 01-game-rules.md (map, adjacency, movement allowance, terrain, visibility, capture), 02-units-and-industry.md (unit classes, movement allowance, vision, production), 03-architecture.md (determinism, Int/Fixed arithmetic, canonical hashing, the order log), 11-combat.md (combat and reaction resolution, veterancy, disruption, defensive modifiers), 12-economy.md (supply state, upkeep, production completion), 13-command.md (the order vocabulary: Postures, Sanctions, the order stack, Reflexes, Attention Events), 14-victory.md (end-of-game evaluation), 04-ui-ux.md (playback presentation), 05-multiplayer.md (transport, presence, desync detection), 06-ai.md (AI seats and substitution)

Naming note. 13-command.md's own naming note, binding on that document, defers to this one for the name and semantics of the per-turn tactical setting. That name is Stance, its values are March, Advance, Hold and Entrench, and §6 below is its definition. Every occurrence of "Stance" in 13-command.md refers to it. This document uses Posture only in 13-command.md's sense — a unit's standing job — and never for the per-turn setting.

1. The shape of a turn

TM-010 A game MUST proceed as a sequence of numbered turns. Turn numbers MUST be consecutive integers beginning at 1, MUST increase monotonically, and MUST NOT be skipped, repeated, or rolled back.

TM-020 Each turn MUST consist of exactly three phases, executed in this order and no other:

Rationale: the two-phase idea of the binding decision is three phases in implementation, because the post-Cascade bookkeeping is a distinct, input-free, strictly-ordered step that several other documents write into, and giving it a name means every one of them can say when its effect lands without inventing its own ordering. Naming it also makes the one property that matters testable in isolation: phases 2 and 3 together are a pure function of the committed state at the close of phase 1.

TM-030 The Orders phase of turn T MUST see the world exactly as the Reckoning of turn T−1 left it. No state visible to any player MAY change between the close of a Reckoning and the close of the following Orders phase, except each player's own order stacks, production queues, and other per-player commitments (TM-350).

TM-040 The Cascade and the Reckoning MUST be a pure function of (the game state at the close of the Orders phase, the ruleset, the PRNG state). They MUST NOT read wall-clock time, network state, player presence, client identity, or any input arriving after the Orders phase closed.

TM-050 No player input MAY be solicited or accepted during the Cascade or the Reckoning, in any game mode, for any reason. An implementation MUST NOT introduce a mid-Cascade prompt, confirmation, opportunity dialog, or "commit the escort?" interrupt.

Rationale: this is a load-bearing decision, not a simplification. A mid-Cascade prompt breaks parity between live and correspondence play — the correspondence player is not there to answer it — and reintroduces exactly the blocking the model exists to remove. Everything a prompt would ask is instead expressible in advance through 13-command.md's Sanctions, and where it genuinely is not, the answer is a richer Sanction vocabulary, not a prompt. 13-command.md CM-1600 already re-expresses the one case that motivated a prompt (an automated unit pausing to ask) as banked movement, which delivers the same tempo guarantee with no input at all.

TM-060 A turn MUST be atomic in the authoritative log: the log MUST record what each player committed and the fact that the turn closed, and MUST NOT record the Cascade's or the Reckoning's derived results (§16.2).

TM-070 Turn 1 MUST have a full Orders phase. Setup MUST complete, and every starting unit MUST have a complete order stack (13-command.md CM-080), before turn 1's Orders phase opens.

TM-080 The game MUST end only at the close of a Reckoning, when 14-victory.md's evaluation (TM-1990) reports an end condition. A game MUST NOT end mid-Cascade, and a player who has been eliminated mid-Cascade MUST have their remaining units resolve normally for the remainder of that Cascade unless a rule in 01-game-rules.md destroys them.

TM-090 The phase MUST be an explicit, authoritative state value on the game — Setup, Orders, Cascade, Reckoning, Ended — and MUST contribute to the canonical state hash. Every order the core accepts MUST name the turn it was issued for, and MUST be rejected if the game is not in the Orders phase of that turn (TM-260).

2. Determinism obligations of this document

These restate, for the turn model specifically, the general discipline of 03-architecture.md AR-070 through AR-110. They are here because the turn model is where the whole determinism argument either holds or does not.

TM-100 Every quantity this document defines — Initiative, Stance modifiers, Forming Up, creation sequence, activation index, reaction capacity, reaction reach, entrenchment — MUST be an integer. No value defined here MAY be a Fixed (03-architecture.md AR-080) or a float, and no comparison defined here MAY be performed by division.

TM-110 The Cascade MUST NOT draw from the seeded PRNG except through combat resolution, which 11-combat.md owns. Activation ordering, reaction eligibility, reaction selection, order evaluation, movement, and every tie-break in this document MUST be deterministic functions of committed state.

TM-120 Every ordering this document defines MUST be total. Where a comparison can tie, the tie-break chain MUST terminate in the unit's creation sequence number (§7), which is unique across all entities and all players and is therefore guaranteed to resolve it.

TM-130 No iteration that influences state MAY depend on collection insertion order, hash-map iteration order, object identity, or allocation order (03-architecture.md AR-090, AR-110). Every set this document tells the engine to iterate MUST first be sorted by an explicitly stated key.

TM-140 The Cascade MUST terminate. The activation order is frozen and finite (TM-1140), each slot MUST be visited exactly once, and no rule MAY re-enter, re-queue, append to, or re-sort the order once frozen.

TM-150 Initiative MUST NOT be recomputed at any point during a Cascade, for any reason, by any rule in any document. A change to a unit's Stance, veterancy, supply, disruption, command state, or age during a Cascade MUST NOT alter that unit's position in the current activation order.

TM-160 Reaction eligibility MUST be determined by the explicit sort of TM-1620 and MUST NOT depend on the order in which units are stored, spatially indexed, or discovered.

TM-170 Order-policy evaluation MUST read only: the unit's committed order stack, the true game state at the current instant (for legality and resolution), and the owner's knowledge view at the current instant (for decisions, 13-command.md CM-130). It MUST NOT read wall-clock time, the pre-Cascade snapshot, the frozen order beyond the acting unit's own activation index, or any unit's unexecuted order except through the Formation intent snapshot of 13-command.md CM-960.

Rationale: the last clause is the one that is easy to get wrong. Letting unit A's policy read unit B's pending order would be perfectly deterministic and would still be wrong, because it makes the outcome depend on a fact the world does not yet contain, and it silently turns every friendly order into a shared plan the engine coordinates rather than one the player wrote. The Formation intent snapshot is the single sanctioned channel for shared intent, and it is a snapshot precisely so that it carries a fact from a completed activation rather than a promise about a future one.

TM-180 The Reckoning MUST execute its steps in exactly the order of TM-1930 and MUST NOT interleave them.

TM-190 Wall-clock time MUST NOT enter the simulation core at any point. Deadlines, reserve clocks, presence, and disconnect detection MUST be computed by the host and MUST reach the core only as explicit logged orders (§5.5).

3. Orders as data

TM-200 Everything a player does during an Orders phase MUST be expressed as one or more order records appended to the authoritative order log. There MUST be no other path by which player intent reaches the simulation.

TM-210 An order record MUST carry, at minimum: a kind (a string literal from the enumerated order union of 03-architecture.md AR-245), the turn it is issued for, the issuing player, a monotonically increasing log sequence number assigned by the authority, and a kind-specific payload.

TM-220 The order kinds this document owns MUST be exactly:

Other documents own other order kinds; the union is enumerated in one place per 03-architecture.md AR-245.

TM-230 Order records MUST be applied in ascending log sequence number. A player's own successive edits to the same unit and level MUST therefore resolve last-write-wins, which is the only interleaving effect the log may have.

TM-240 The outcome of an Orders phase MUST be independent of how different players' submissions interleave. This MUST hold structurally rather than by convention: an order record MUST only be able to mutate state belonging to its issuing player, so any two records from different players commute.

Rationale: this is the requirement that makes concurrent ordering honest. Under it there is no race to submit, submitting earlier buys nothing, and a player on a 180 ms connection is in exactly the position of a player on 20 ms. The binding decision rejected reading (B) literally for precisely the reason this requirement forecloses, and stating it as a structural property rather than a hope is what lets a test prove it: shuffle the log within a turn, preserving each player's internal order, and the turn hash must not move.

TM-250 An order record that is illegal when issued MUST be rejected at submission with a typed, named, localisable rejection (03-architecture.md AR-140, AR-320), and MUST NOT be appended to the log. Statically illegal orders include those 13-command.md CM-350 enumerates, a Stance the unit may not take (TM-750), a Task without an end condition (13-command.md CM-250), and any order naming an entity the issuing player does not own or cannot observe.

TM-260 An order record naming a turn other than the current one, or arriving when the game is not in the Orders phase, MUST be rejected. It MUST NOT be queued for the next phase.

Rationale: silently deferring a late order is the single most confusing thing a turn-based game can do, because the player's mental model of when their instruction takes effect is off by a turn and nothing tells them. Rejecting is loud, is correct, and lets the client re-offer the order for the new turn with the player's knowledge of what has since happened.

TM-270 An order that is legal when issued and unachievable at activation MUST NOT be treated as an error at any point: not at submission, not at activation, not in the log. §10 governs it.

TM-280 An order MUST persist across turns. A unit's order stack MUST carry forward unchanged into the next Orders phase, and MUST change only when the player changes it, when a level's end condition is met, or when this document or 13-command.md pops or replaces a level.

Rationale: persistence is not a convenience, it is the property that makes turn 150 survivable. The Orders phase is about changing orders; a player with 150 units touches the twenty that need new instructions. It is also what makes a deadline humane and an absent player harmless — an army that continues a coherent plan is a far better failure mode than an army that freezes.

TM-290 Committing orders MUST NOT be required. A player who submits no order records at all MUST have a well-defined turn: every unit executes its persisted order stack.

TM-300 The turn record written to the log for each turn MUST consist of: the turn number; every order record accepted during that turn's Orders phase, in log sequence order; and, per player, a terminal commit marker of exactly one of Committed, TimedOut, Absent, or Substituted.

TM-310 The Cascade and the Reckoning MUST NOT be written to the log. They MUST be recomputed on replay from the turn record and the prior state.

Rationale: logging a derived result lets a divergence hide inside the log instead of tripping on it. If the log carried the Cascade's outcome, a replay that computed a different outcome would happily overwrite reality with the recording and the bug would surface three turns later as an inexplicable state. Recomputing means a divergence fails immediately, at the hash comparison, where it is findable.

TM-320 All state this document defines — phase, turn number, per-player commit markers, consecutiveMissedTurns, substitution state, the global creation counter, every unit's Stance, Stance override, Forming Up age, entrenchment, reaction capacity spent, and disruption — MUST be authoritative game state and MUST contribute to the canonical state hash. The frozen activation order, the activation cursor, playback pacing, and presence data MUST NOT.

4. The Orders phase

TM-330 During an Orders phase every player MUST be able to issue and revise orders concurrently, at their own pace, in whatever order suits them, without being blocked by, waiting for, or being able to observe the decisions of any other player.

TM-340 The board MUST be stable for the whole of an Orders phase. No unit MAY move, no combat MAY occur, no city MAY change hands, and no fog MAY lift or fall during an Orders phase.

TM-350 The only state an Orders phase MAY mutate is per-player: order stacks, Stance settings, production queues, Doctrines, Formations, Groups, Postings, Consignments, Requisitions (13-command.md §6–§8), and any per-player expenditure the economy defines. It MUST NOT mutate shared world state.

TM-360 A player MUST be able to revise any order any number of times before the phase closes. There MUST be no cost, penalty, or record of revision beyond the log itself.

TM-370 A player MUST be able to see, live and exactly, the Initiative each of their own units will carry into the coming Cascade, and MUST be able to see it change as they change Stance or Posture (TM-1090).

Rationale: initiative is only a skill if it is legible before you commit. It is exactly computable during Orders — every term is either committed state from the last Reckoning or a choice the player is making right now — so there is no excuse for showing it approximately, and showing it exactly turns "should this column march or hold?" into a decision with a visible consequence rather than a feel.

TM-380 A player MUST be able to see the relative activation order of their own units before committing. They MUST NOT be shown the global activation order, any opponent's position in it, or any opponent's exact Initiative (TM-2130).

TM-390 CommitOrders MUST mark the issuing player ready. It MUST NOT freeze their orders while the phase remains open, and MUST NOT confer any advantage.

TM-400 The Orders phase MUST close immediately when every player position that is expected to act has committed, without waiting for any deadline.

TM-410 A player position controlled by an AI seat MUST commit within the same phase as a human seat and MUST NOT be granted extra time, extra information, or extra order records (06-ai.md owns the seat contract).

TM-420 A player MUST be able to RevokeCommit while the phase is still open. A RevokeCommit arriving after CloseOrders MUST be rejected.

TM-430 The Orders phase MUST close by exactly one CloseOrders record, issued by the authority, after every player has either committed, timed out, or been marked absent or substituted.

TM-440 During the Orders phase each player MUST be shown presence: for every other player position, whether it has committed, whether it is currently connected, and how much time remains. Presence MUST be ephemeral, non-authoritative, MUST NOT contribute to any hash, and MUST NOT carry any fact about the game world.

Rationale: presence is the only thing worth streaming during Orders and it is safe precisely because it is content-free. Knowing that Karsk has committed tells you nothing about what Karsk committed, so it cannot be mined, and it removes the single worst experience in an asynchronous game — not knowing whether you are waiting for a person or for a crash.

TM-450 No player MAY be shown any indication of another player's orders, order count, unit selection, camera position, or edit activity.

TM-460 In hotseat play the Orders phases of the players sharing a machine MUST be taken in sequence, and the client MUST fully occlude the previous player's view before handing over. The rules MUST NOT differ in any respect from concurrent play; only the input schedule differs, and the resulting turn record and every hash MUST be identical to the same orders submitted concurrently.

TM-470 A player MUST be able to enter an Orders phase, leave, and return within the same phase without losing committed orders, and MUST have their uncommitted client-side staging restored where the client offers staging (04-ui-ux.md owns staging).

5. Deadlines, stalls, absence, and substitution

5.1 Deadlines

TM-480 An Orders deadline MUST be a per-game configuration value in whole seconds, or the value None. It MUST be set at setup, MUST be visible to every player, and MUST be changeable mid-game only by unanimous consent of the connected human players, recorded as an order.

TM-490 The default deadline MUST be exactly:

TM-500 In a solo or two-human-player game the Orders deadline MUST default to None and MUST NOT be imposed unless a player explicitly asks for one at setup or by unanimous consent afterwards.

Rationale: this is amendment 1 of the binding decision and it is the correct shape of the tradeoff. The scaling argument that produced this whole model is about the eight-player case; most play of a game like this is one person against AI opponents, where waiting is not a problem and a clock is pure tax. A design that charges the common case to solve the rare one has mispriced itself.

TM-510 Each player MUST hold a reserve bank of whole seconds, per game, defaulting per TM-490. When a player has not committed at the deadline, the host MUST draw down that player's reserve in whole seconds until they commit or the reserve reaches zero. The reserve MUST NOT refill.

TM-520 When a player's reserve reaches zero and they have not committed, the host MUST issue TurnTimeout for that player and proceed to CloseOrders.

TM-530 A TurnTimeout MUST NOT alter the player's order stacks. Their units MUST execute their persisted orders and Stances normally.

TM-540 A player who is timed out MUST NOT be penalised in any rules-visible way beyond the loss of the opportunity to revise. There MUST be no forfeited movement, no production penalty, and no initiative penalty for a timeout.

TM-550 Deadline and reserve arithmetic MUST be performed entirely by the host and MUST NOT enter the core (TM-190). The core MUST see only the TurnTimeout and CloseOrders records.

Rationale: a clock is wall-clock time, wall-clock time is banned from the simulation, and every attempt to smuggle one in ends the same way — a replay that diverges because it ran faster than the original. Reducing the clock to two logged facts makes the replay exact and makes the whole timing subsystem replaceable without touching the rules.

5.2 What a stall costs

TM-560 A player who has not committed MUST NOT block any other player from issuing, revising, or committing orders at any point.

Rationale: this is the model's central practical claim and it is worth stating as a requirement rather than leaving it as an emergent property. Under strict sequential turns, a player who overruns by five minutes costs each of seven others five minutes. Here, a player who overruns costs the others only their excess over the second-slowest player, which is usually near zero. Slowness stops being externalised, and that is the difference between a game that survives eight players and one that does not.

5.3 Absence, disconnection, and substitution

TM-570 Each player position MUST carry an integer consecutiveMissedTurns, incremented at each CloseOrders at which that position's commit marker is TimedOut or Absent, and reset to zero on any Committed marker. It MUST be authoritative state.

TM-580 When a position's consecutiveMissedTurns reaches 3, the host MUST offer the remaining human players a vote to substitute an AI seat for that position. In ranked play the substitution MUST occur automatically at that threshold without a vote.

TM-590 A substitution MUST take effect only at a turn boundary, MUST be recorded as a SubstitutePlayer order, and MUST NOT alter any unit's order stack. The AI substitute MUST take over the position's existing orders and MUST be bound by 13-command.md CM-2010's absent-player rules until it has taken a full Orders phase.

TM-600 A substituted player MUST be able to reclaim their position on reconnection, recorded as a ResumePlayer order taking effect at the next turn boundary. Their Dispatch items MUST have persisted (13-command.md CM-2010).

TM-610 An absent position — one explicitly marked away, or disconnected — MUST resolve exactly as a timed-out position resolves. Absence MUST NOT change any rule.

TM-620 A game MUST be able to be adjourned: the authority halts at a turn boundary and the game resumes from the identical state and log later. Adjournment MUST NOT be possible mid-Cascade or mid-Reckoning.

6. Stance

Stance is the one tactical decision a player makes about a unit every single turn. It is deliberately small — four values on one axis — because it must be legible at a glance across two hundred units, and it is deliberately consequential, because it is the lever by which a player steers the activation order and buys the ability to interfere with an opponent's.

TM-630 Every unit MUST carry exactly one committed Stance for each turn, taking one of exactly four values: March, Advance, Hold, Entrench. Adding a fifth Stance is a rules change requiring a RulesVersion bump (03-architecture.md AR-880).

TM-640 The complete effect of Stance MUST be exactly the following, and no document MAY attach a further effect to a Stance value without amending this table:

TM-650 Advance MUST be the default Stance and MUST be the value used wherever this document or 13-command.md speaks of a unit's Stance without qualification.

TM-660 Stance March MUST add exactly +1 to the unit's movement allowance for that turn, as an integer, applied before any other movement modifier.

Rationale: +1 flat, not a percentage, and the asymmetry is deliberate. For a one-point infantry battalion it doubles the day's march; for six-point cavalry it is a seventeen per cent gain on top of speed the unit already had. March is therefore the slow unit's stance, which is the right shape — a road column of infantry putting its head down and covering ground is exactly what the stance describes, while cavalry already buys the initiative and the safety of moving before the world reacts. A percentage would have handed the largest absolute gain to the units that least need it.

TM-670 A unit in Stance March MUST NOT initiate combat. If its committed order requires an attack, the movement component MUST execute and the attack component MUST NOT; the unit halts on contact per TM-1400.

TM-680 Stance March MUST NOT prevent a unit from entering an undefended city or work and changing its ownership where 13-command.md's Seize Sanction authorises it. Capture without combat is not the initiation of combat.

TM-690 A unit in Stance Hold or Entrench MUST NOT move voluntarily. It MUST NOT advance into a tile vacated by an enemy it defeated. It MAY be moved by a Reflex (13-command.md CM-1400), by a retreat, or by any external effect, and such movement MUST NOT be blocked by this requirement.

TM-700 Entrenchment MUST be an integer per-unit counter entrenchment in [0, 3]. It MUST be incremented by 1 during the Reckoning of any turn in which the unit's committed Stance was Entrench and the unit did not change tile during that turn's Cascade. It MUST be set to 0 immediately whenever the unit changes tile for any reason, and at the close of any Reckoning in which its committed Stance was not Entrench. A unit is established when entrenchment ≥ 1.

Rationale: entrenching costs a turn and it should. The establishing turn buys the defensive treatment of Hold for the initiative cost of Entrench, which is a strictly worse deal for that one turn and is the point — a player who wants defence this turn takes Hold, and a player who wants the strongest defensive position in the game from next turn pays for it in tempo now. The counter runs to 3 rather than stopping at 1 so 11-combat.md may scale the defensive bonus with time dug in if it wishes; this document uses only the established/not-established distinction.

6.1 Setting Stance

TM-710 A unit's committed Stance MUST be determined during the Orders phase by the following precedence, strongest first:

1. An explicit player Stance override on the unit for this turn (SetStance, and 13-command.md CM-560's Task-level annotation).
2. The Stance derived from the unit's active Posture per 13-command.md CM-390, CM-430, CM-480, CM-520 and CM-550.
3. Advance.

TM-720 A Stance override MUST persist until the player clears it (SetStance with Derived) or replaces it. It MUST NOT expire automatically at the end of a turn.

Rationale: the source proposal made the override per-turn. That is wrong for the same reason blank orders are wrong: a player who told a unit to dig in and revisits the map two turns later would find it marching, and would have to re-issue the same instruction every turn — which is exactly the per-unit-per-turn tax this whole model exists to remove. An override is a standing exception to a derivation, and standing exceptions persist. The unit panel showing both the override and the derived value it replaced (13-command.md CM-560) is what keeps it from becoming a forgotten setting.

TM-730 The effective Stance and, where it differs, the derived Stance it overrode MUST both be shown on the unit panel at all times.

TM-740 Committed Stance MUST be frozen at CloseOrders and MUST NOT change during the Cascade.

TM-750 A SetStance MUST be rejected at submission when: the Stance is March and the unit's movement allowance is 0; the Stance is March and the unit's Task level carries an Attack action; or the unit's class may not take that Stance per 02-units-and-industry.md.

6.2 Effective Stance during the Cascade

TM-760 A Reflex pushed during a Cascade MAY set a unit's effective Stance (13-command.md CM-1400 forces Advance for Withdraw and Hold for TakeCover). Effective Stance MUST govern only voluntary movement permission and the defensive treatment 11-combat.md applies.

TM-770 A change to effective Stance during a Cascade MUST NOT alter the unit's Initiative (TM-150), MUST NOT alter its position in the frozen order, and MUST NOT grant or remove reaction capacity for the current turn.

Rationale: this is the boundary between this document and 13-command.md's Reflexes, and it is the one place where the two vocabularies could have collided. Reactions are bought during Orders, at a stated price in initiative, and they must not be obtainable for free mid-Cascade by an engine-pushed Reflex — a March column that took cover under fire would otherwise acquire an overwatch shot it never paid for. Equally, a Hold unit driven off its tile by a Withdraw Reflex should not lose the reaction it already paid for. Committed Stance sets the price and the capacity; effective Stance governs what the unit may do with its feet. Splitting them costs one field and closes both holes.

TM-780 A unit's committed Stance MUST be restored as its effective Stance when the Reflex that changed it pops.

TM-790 Effective Stance MUST NOT be settable by the player during a Cascade, because no player input exists during a Cascade (TM-050).

TM-800 Where 13-command.md derives a Stance from a Posture and the player has not overridden it, the derivation MUST be evaluated at CloseOrders against committed state, never lazily at activation.

7. The creation sequence

TM-810 The game MUST maintain exactly one global creation counter: a monotonically increasing integer, shared by every entity kind and every player, never decremented, never reset, and never reused.

TM-820 Every unit, city, work, and other addressable entity MUST receive a creation sequence number from that counter at the instant it comes into existence. The number MUST be unique across the whole game.

TM-830 A creation sequence number MUST be immutable for the life of the entity. It MUST NOT change on capture, on transfer of ownership, on repair, on upgrade, or on any other event.

TM-840 A destroyed entity's creation sequence number MUST NOT be reissued.

TM-850 During setup, creation sequence numbers MUST be assigned in a fully specified order: all map-fixed entities in ascending tile index, then, for each player position in ascending player index, that position's starting cities in ascending tile index, then that position's starting units in ascending tile index, ties within a tile broken by the order the scenario or generator enumerates them (01-game-rules.md owns setup and MUST make that enumeration deterministic).

TM-860 During a Reckoning, units completing production MUST draw creation sequence numbers in ascending producing-city creation sequence number; where one city completes more than one unit in the same Reckoning, in the order the city's production queue enumerates them (12-economy.md owns the queue order and MUST make it deterministic).

Rationale: one monotonic counter for every entity in the game, consumed in a stated order, is most of the determinism argument for entity creation, and it is why no rule anywhere in this specification needs a special case for two things happening at once. It is also why the tiebreak in §8 can be trusted: uniqueness is not a hope about the data, it is a property of how the data is made.

TM-870 The creation sequence number MUST be readable by both the simulation core and the client, and MUST be usable as a terminal tie-break wherever any document needs one (13-command.md CM-170, CM-2140).

TM-880 The creation sequence number MUST NOT confer any advantage of its own. It MUST be used only as a tie-break, and this document MUST NOT be extended to give it any other rules effect.

Rationale: raw creation order as the activation order was the originating proposal and it fails for a reason worth recording where the counter is defined, so nobody re-introduces it. A player who built earlier would hold permanently lower numbers on everything, forever; whatever "acts first" is worth, they would hold it for two hundred turns, and no decision either player made could take it away. That is the worst kind of advantage — invisible, compounding, and unearnable. Worse, creation order interleaves players only by accident: if one player built heavily on turns 1–10 and another on turns 11–20, the queue reads as all of the first player then all of the second, which is strict sequential turns arrived at by a rule that promised the opposite. The sequence number survives as the tiebreak — the thing it is genuinely good at, because it is unique — and nothing else.

8. Initiative

TM-890 Initiative MUST be an integer score computed for every unit at the start of every Cascade, used solely as the sort key for the activation order, and frozen for the duration of that Cascade (TM-150).

TM-900 Initiative MUST be the sum of the terms in the following table, evaluated in the order listed, each term an integer:

TM-910 The sum MUST be computed as a single left-to-right integer addition over the terms in the order of TM-900. The result MUST satisfy −64 ≤ initiative ≤ 128; a value outside that range MUST raise a typed DeterminismError (03-architecture.md AR-080) rather than being clamped.

Rationale: the range assert is a tripwire, not a rule. Under the values this document and its neighbours specify, initiative cannot leave roughly [−14, 82]; a value outside the assert range means a modifier somewhere has been given a magnitude nobody reasoned about, and it is far better to find that in CI than to discover it as an activation order that stopped making sense. Clamping is banned for the reason 03-architecture.md AR-080 bans saturation generally: a clamped value is a plausible-looking wrong number that will survive review.

TM-920 Initiative MUST have no floor and no ceiling within the assert range. It is a sort key, not a resource, and MUST NOT be spent, stored, accumulated, or transferred.

8.1 Class base

TM-930 Every unit class MUST carry an integer base initiative in [24, 64]. 02-units-and-industry.md owns the per-class value and MUST use the family default below unless it records a reason to differ:

Rationale for the shape: class span is 40 points, from 24 to 64. Stance spans 20 (+8 to −12), and at full disclosure condition can subtract a further 18 or add 10 — so a unit's state and its owner's choices together span 56, more than its class does. That is the intended feel and it is the whole argument for the system: what a unit is sets the expectation, and what has happened to it and what you told it to do can overturn the expectation. A veteran field gun in March (24 + 8 + 6 = 38) outranks a broken, unsupplied line battalion (40 − 8 − 10 = 22) by a wide margin, and both numbers are ones a player can work out on the panel.

TM-940 A unit class whose family is not listed MUST be assigned a base within [24, 64] and the assignment MUST be recorded with its reason in 02-units-and-industry.md.

8.2 Forming Up

TM-950 Every unit MUST carry an integer age in [0, 4], set to 0 when the unit enters play and incremented by 1 during each Reckoning until it reaches 4, where it MUST stop.

TM-960 The Forming Up term MUST be −max(0, 8 − 2 × age), giving exactly −8, −6, −4, −2, 0 on the unit's first, second, third, fourth and every subsequent turn.

TM-970 Units placed at setup MUST begin with age = 4 and therefore no Forming Up penalty.

Rationale: a scenario's starting forces are established formations, not a batch of units raised the night before. Starting every game with every unit at −8 would flatten turn 1's activation order into pure class base and would make the opening turn the one turn where the initiative system does nothing.

TM-980 A unit that changes owner MUST have its age reset to 0 and MUST serve a full Forming Up period under its new owner.

Rationale: this settles a question the source design left open. Thematically it is obvious — the unit has changed sides, it does not know its new officers, and four turns of clumsiness is exactly right. Mechanically it makes capturing units slightly less attractive, and that is a feature rather than a cost: a capture that delivered a fully-effective formation instantly would make capture strictly better than production at the same price, and the whole loop of this game is that cities produce and units capture cities, not that units capture units. Four turns is a real price and a recoverable one.

TM-990 Forming Up MUST NOT be extended, shortened, or waived by any other rule. It is bounded at four turns by design and a longer penalty MUST NOT be introduced.

Rationale: this is the inverted seniority term and the bound is the whole point of the inversion. Under raw creation order, a player who lost an army and rebuilt was behind forever, unrecoverably. Here the same arithmetic — old units act before new ones — produces a penalty that expires. A player who loses an army is behind for four turns on the units they rebuilt, not for the rest of the game. The lasting seniority advantage in this design is veterancy, which is earned by fighting rather than by existing, and a reward for having played well is the only kind of accumulating advantage a game should hand out.

8.3 Terms 4 to 7

TM-1000 The Veterancy and Disrupted terms MUST read state 11-combat.md owns. The Disrupted flag MUST clear during the Reckoning of the turn after the turn on which it was set, so a disrupted unit is penalised in exactly one Cascade.

TM-1010 The In command term MUST apply exactly when, at the instant initiative is computed, the unit's Posture is Attach and its Chebyshev distance from its Formation's Command Reference Point (13-command.md CM-950) is less than or equal to that Formation's cohesion radius (13-command.md CM-1010). It MUST apply to the commander itself on the same test.

Rationale: reusing the CRP and the cohesion radius means the command term costs no new entity, no new geometry, and no new player concept — a player who has understood that a formation holds together already understands why holding together makes it quicker. It also gives Pace Dispersed a real cost to weigh against its tempo advantage, which is the trade 13-command.md CM-1000 wanted and could not price on its own.

TM-1020 The Out of supply term MUST read the supply state 12-economy.md owns, as of the close of the Orders phase.

8.4 Progressive disclosure tiers

TM-1030 The active set of initiative terms MUST be governed by an integer Initiative Tier in [1, 3], set at setup, part of the ruleset, contributing to the canonical state hash, and fixed for the life of the game.

TM-1040 The tiers MUST be exactly:

TM-1050 Tier 1 MUST be the default for every game shape.

Rationale: this is amendment 2 of the binding decision. Nine modifiers was too many to introduce at once and it fought the escalating-complexity goal directly. Three terms is what a player can hold in their head while choosing a Stance: what this unit is, what I just told it to do, and whether it is new. The other four terms are not removed — they are earned, in the same way every other system in this design is earned, and each arrives attached to a system the player has by then already met. Veterancy arrives with combat; supply arrives with logistics; command arrives with formations. A term that arrives with the system that produces it explains itself.

TM-1060 A term that is inactive at the current tier MUST contribute 0 to initiative. It MUST NOT be removed from the game: veterancy grades, disruption, supply state and command state MUST continue to exist, be tracked, and have their non-initiative effects, at every tier.

TM-1070 The Initiative Tier MUST NOT change during a game. Changing it would change every activation order from that point and would make a replay of the earlier turns incomparable with the later ones.

TM-1080 The client MUST show, on the initiative readout, exactly which terms are active at the current tier and the integer contribution of each.

Rationale: at Tier 1 the class span of 40 exceeds the choice span of 28 (+8 March down to −12 Entrench, plus up to −8 Forming Up), so class dominates — which is correct for a player still learning, because it makes the order predictable from the unit roster alone. At Tier 3 the balance inverts and choice dominates class. That inversion is the progression: the system starts as a property of your army and becomes a property of your decisions.

8.5 Visibility of initiative

TM-1090 A player MUST be shown the exact integer initiative, and every active term's contribution, for every unit they own, at all times.

TM-1100 A player MUST be shown, for any currently visible enemy unit, a coarse three-band initiative estimate and nothing more precise:

TM-1110 The band MUST be computed from the enemy unit's true initiative for the coming Cascade, and MUST NOT be shown at all for a unit the player cannot currently see. A remembered contact MUST show the band as of the last observation, marked stale.

Rationale: this settles the source design's open question. Showing the exact number leaks veterancy grade, supply state, and disruption in one integer, which is a great deal of information for free. Showing nothing makes planning against an opponent pure guesswork and quietly removes the reason to think about the order at all. Three bands is the right granularity because it answers the only question a player actually asks — "will this thing move before my column does?" — while leaving the composition of the number private. The band boundaries are placed so that Stance shows through it: line infantry is Steady in Advance, Slow in Hold, and stays Steady in March, which teaches the system by being observable.

TM-1120 The global activation order MUST NOT be shown to any player before or during a Cascade. A player MUST be shown only the relative order of their own units (TM-380) and, during playback, the order in which the units they observed acted (TM-2170).

9. The Cascade

9.1 Freezing the order

TM-1130 On CloseOrders, the engine MUST perform the following steps, in this order, before any unit acts:

1. Compute committed Stance for every unit (TM-710).
2. Reset every unit's spent-reaction counter to 0 and set its reaction capacity from its committed Stance (TM-640).
3. Compute Initiative for every unit (TM-900) at the current Initiative Tier.
4. Build the activation roster and sort it (TM-1140, TM-1150).
5. Compute and record the activation-order hash (TM-2380).
6. Set the activation cursor to 0.

TM-1140 The activation roster MUST contain exactly those units that, at the instant of step 4, are alive, are on the map, and are not embarked in a transport (TM-1830). It MUST contain units of every owner, including AI seats and any Neutral owner the ruleset defines.

TM-1150 The roster MUST be sorted by descending Initiative, ties broken by ascending creation sequence number. The sort MUST be performed with an explicit comparator (03-architecture.md AR-085 bans a comparator-less sort) and MUST be a total order.

TM-1160 The sorted roster MUST be frozen: it MUST NOT be re-sorted, appended to, compacted, or re-entered for the remainder of that Cascade (TM-140, TM-150).

TM-1170 Each entry in the frozen roster MUST carry an activation index: its 0-based position. The activation index of any unit, and the cursor's current index, MUST be readable by simulation-core logic during that Cascade (13-command.md CM-2140 requires this for Intent Freshness).

TM-1180 Cities, works, and other non-moving site occupants MUST NOT appear in the activation roster. Their effects resolve during the Reckoning (§13).

9.2 The sweep

TM-1190 The Cascade MUST visit each activation index exactly once, in ascending index order, and MUST fully resolve each activation — including any reaction it provokes and every consequence of that reaction — before beginning the next.

TM-1200 There MUST be exactly one activation per unit per turn. A unit MUST spend its movement allowance, resolve its order, and yield. The engine MUST NOT walk the roster more than once per Cascade, and MUST NOT resolve movement one step per pass across all units.

Rationale: stepping every unit one movement point per pass is physically honest and it is the wrong model here, for four reasons. It dilutes initiative into nothing, because a one-point unit acts once and a six-point unit acts six times, so "who goes first" collapses into "who has more movement points" — a statistic the game already has, and the whole initiative system becomes a rounding error on movement allowance. It makes a turn unreadable: with 1,200 units and up to six points each, a turn is over 7,000 activation evaluations with no coherent narrative in any of them, and no way to say "the cavalry rode from the ford to the ridge and took the outpost", because under stepping that sentence never happened as a unit of anything. It multiplies the replay and the event stream by a balance number, which is a bad coupling. And it makes combat structurally awkward — fight mid-move, on which step, at what strength. The one thing stepping genuinely bought is interception, and §11 recovers that with one rule and one column of a table rather than a sixfold multiplication of the entire simulation.

TM-1210 An activation MUST be atomic with respect to other activations. No other unit's activation may begin, resume, or interleave inside it. The only nesting permitted inside an activation is a reaction (§11), and a reaction MUST NOT itself contain an activation.

TM-1220 Movement points unspent at the end of an activation MUST be discarded, except where 13-command.md CM-1550 banks them.

TM-1230 A unit whose order produces no action MUST still be considered to have activated. A no-op activation MUST NOT be an error, MUST NOT be logged as a failure, and MUST NOT raise an Attention Event on its own (13-command.md CM-1450).

9.3 "The world as it is at that instant"

TM-1240 The Cascade state MUST be the single authoritative game state, mutated in place by each activation in index order. There MUST be no second, speculative, or pending copy of the world at any point in a Cascade.

TM-1250 The instant of activation i MUST be defined as the state immediately after activation i−1 and all of its consequences — movement, reactions, combat, destruction, capture, displacement — have fully resolved, and immediately before activation i begins. Activation 0's instant is the state at the close of TM-1130.

TM-1260 At its instant, the acting unit's order policy MUST decide using only its owner's knowledge view at that instant (13-command.md CM-130), recomputed for that instant (TM-2140).

TM-1270 At its instant, the resolution of whatever the policy decided — movement legality, stacking, terrain cost, combat, capture, reaction triggering — MUST use the true state at that instant, not the knowledge view.

Rationale: the split is the whole of fog-honest simulation in two requirements. A unit decides on what its owner can see and then meets the world as it actually is. A column ordered to take a ford that a hidden garrison holds will set out, because its owner did not know, and will halt on contact, because the garrison is really there. Collapsing the two — deciding on the true state — is a wallhack the player never asked for; collapsing them the other way — resolving against the knowledge view — is a hallucination. Neither is a shortcut anyone should take, and separating them costs one parameter.

TM-1280 Nothing that happened after activation i in the frozen order MAY influence activation i. Nothing that happened before it MAY be hidden from it, other than by fog.

TM-1290 The activation of a unit MUST NOT be conditioned on, delayed by, or reordered because of any other unit's order, intent, or expected action.

TM-1300 Because resolution is a strict total order, the engine MUST NOT contain any rule for simultaneous movement conflicts: no swap-through rule, no double-occupancy rule, no mutual-destruction tie-break, and no move-cancellation rule. Where two units contest a tile, the one with the higher initiative activates first and the other finds it occupied.

Rationale: this is the load-bearing insight from the originating design and it survives intact. The canonical failure of simultaneous resolution — A at X moves to Y, B at Y moves to X, and they pass through each other or deadlock — cannot occur here. Whichever of A and B activates first finds the other still standing in the destination tile, so the move halts on contact. There is no case to special-case, no tie to break, and no rule to write. The ordering is the conflict resolver, and a requirement forbidding the addition of such rules is worth its space, because an engineer meeting the swap case for the first time will reach for one.

TM-1310 The high-initiative unit acts on less information and the low-initiative unit acts on more. No rule MAY compensate for either, and no document MAY treat low initiative as a penalty requiring offset.

Rationale: this is the second counterweight in the system and it is easy to lose by accident. Acting first means acting on a board where almost nothing has moved this turn; acting last means acting on a board where everything else has already committed. Seniority buys the first strike; youth buys knowing where everyone went. Neither is strictly better, and players will learn to hold young or low-initiative units back as a reserve precisely because they resolve with full information — which is an emergent role for exactly the units a naive seniority rule would have written off. If a later document "fixes" low initiative, it destroys this.

9.4 What one activation does

TM-1320 An activation MUST proceed as:

1. Skip tests (TM-1770, TM-1830, TM-1870). If any fires, the activation ends immediately with no effect.
2. Recompute the owner's knowledge view for this instant (TM-2140).
3. Evaluate the topmost non-empty order-stack level (13-command.md CM-210), producing a decision.
4. Execute movement, tile by tile, with the entry procedure of TM-1560 applied at each tile entered.
5. Execute any non-movement component the order produced and the world still permits — attack, capture, load, unload, garrison — from the tile the unit actually occupies.
6. Record progress (13-command.md CM-1430) and emit the activation's events.

TM-1330 Events emitted by an activation MUST be emitted in the sub-order of TM-1320 and, within movement, in tile-entry order. Event order MUST be part of the deterministic contract.

TM-1340 A unit MUST NOT be able to act twice in one Cascade by any route: not by a Reflex pop, not by a completed order falling through to the level below (13-command.md CM-210 resumes within the same activation), not by banked movement (13-command.md CM-1560 spends it at the next activation), and not by being displaced back to an earlier index.

TM-1350 The Cascade MUST end when the cursor passes the last index. Nothing else MAY end it.

10. Order evaluation at activation

TM-1360 An order MUST be a policy stored on the unit and evaluated when the Cascade reaches that unit, against the world as it then is. An order MUST NOT be stored, transmitted, or resolved as a recorded sequence of steps (13-command.md CM-340).

TM-1370 Conditions attached to an order MUST be evaluated at activation, against the owner's knowledge view at that instant, never at submission.

Rationale: this is what makes committing before seeing survivable, and it is meaningfully less blind than simultaneous orders. A late-initiative unit's "advance if the ford is clear" is evaluated on a board where the entire first half of the turn has already happened. That reactivity arrives declaratively, in advance, with no human present — which is why correspondence play gets exactly the same game as live play rather than a degraded one. 13-command.md owns the vocabulary that makes this expressive, and the binding decision names the thinness of that vocabulary as the single largest execution risk in the design.

TM-1380 Move is not attack. A movement order MUST halt on contact with an enemy and MUST NOT initiate combat. Initiating combat MUST require an order that names an attack, or a Sanction that authorises one (13-command.md CM-580).

Rationale: this costs a little friction at the moment of ordering and prevents an enormous amount of accidental suicide. It also means a movement order that goes stale degrades safely rather than catastrophically — the failure mode of a two-turn-old march order is a column standing in front of something, not a column throwing itself at it.

10.1 The four unachievability cases

TM-1390 When an order is unachievable at the moment it is evaluated, the engine MUST resolve it by exactly one of the four cases below. These MUST be evaluated in the order listed, and the first that applies MUST govern.

TM-1400 When an order's policy can produce no action at all, the unit MUST take no action, MUST retain its order stack unchanged, and MUST remain in its committed Stance. This MUST NOT be an error, MUST NOT clear any stack level, and MUST NOT consume anything.

TM-1410 Where the situation meets 13-command.md CM-1340's Impossible class — the order's referent has ceased to exist rather than merely become unreachable — the unit MUST adopt its Fallback Posture per 13-command.md CM-310. The four cases above MUST NOT be used to route around that classification.

TM-1420 Where the situation meets 13-command.md CM-1340's Blocked class, the order MUST be suspended, not cancelled (13-command.md CM-1390), so that clearing the obstruction lets the original order resume untouched.

TM-1430 No unit-turn MAY be lost to a technicality. Every activation MUST either execute an action, execute a partial action, or be a deliberate and recorded no-op.

Rationale: the distinction that matters here is between two things a naive engine conflates. An order that is illegal when issued is a mistake and is rejected loudly at submission (TM-250) — fail loudly is the right engineering rule and it applies there. An order that was legal when issued and is unachievable at activation is not a bug and not a mistake; it is the game. The world changed between the order and its execution, which is the entire premise of the model. Treating the second as an error is how a turn model acquires a category of "wasted" unit-turns that players cannot predict, cannot prevent, and rightly resent.

TM-1440 The stance-fallback rate — the fraction of activations in which TM-1400 fired — MUST be instrumented per game and exposed for telemetry and CI regression.

Rationale: this is the fastest diagnostic in playtesting and it is cheap. It is a direct proxy for "is the player's intent surviving contact with the turn". A sustained rate above roughly 8% of activations means either that intents are too brittle or that the conditional vocabulary is too thin, and it responds immediately to changes in that vocabulary. If this number is healthy the model is working; if it is not, nothing else about the model matters.

10.2 Persistence and multi-turn orders

TM-1450 An order MUST persist until it completes, becomes Impossible, or the player changes it. Reaching the end of a Cascade MUST NOT clear, expire, or degrade any order.

TM-1460 A multi-turn order whose route passes through unrevealed terrain MUST be planned under 13-command.md CM-140 — unrevealed tiles treated as passable at the unit's cheapest movement cost and as containing no enemy — and MUST be replanned on contact with the truth under 13-command.md CM-1480 and CM-1500.

Rationale: this answers the source design's open question about what a unit "knows" about its own route. Pessimistic routing produces units that refuse to cross unexplored ground, which no player would ever choose; optimistic routing produces units that set out and discover the truth, which is what a player does. The Blocked handling catches the failure cleanly by suspending rather than destroying the order, so the cost of being wrong is a halt and a re-plan, not a lost order.

TM-1470 A unit MUST NOT accumulate a backlog of orders. Exactly one order stack exists per unit, exactly three levels deep (13-command.md CM-200), and there MUST be no queue behind it.

10.3 Movement resolution within an activation

TM-1480 Movement MUST be resolved tile by tile in route order, deducting the integer terrain cost of each tile entered (01-game-rules.md owns terrain costs; 03-architecture.md AR-750 owns pathfinding and its tie-breaks).

TM-1490 A unit MUST halt immediately, retaining its remaining movement for the purposes of TM-1220 and 13-command.md CM-1550, when: it enters a tile adjacent to an enemy it was ordered to halt on contact with; a reaction fires against it (§11); the next tile in its route has become unenterable and no re-path exists; or its remaining allowance is less than the next tile's cost.

TM-1500 A unit MUST NOT pass through a tile occupied by a hostile unit. Whether it may pass through a tile occupied by a friendly unit, and the stacking limit, are owned by 01-game-rules.md.

TM-1510 Where movement takes a unit into a tile that changes ownership of a city or work, the capture MUST resolve inside the activation, at the moment of entry, and MUST be visible to the ordering rules of every later activation in the same Cascade.

TM-1520 A unit that has halted for any reason MUST NOT resume movement later in the same activation.

11. Reactions

Full activation buys a readable turn and a meaningful initiative system, and it costs one thing: a fast unit completes a six-tile run before a slow unit has moved at all, so it cannot be intercepted mid-move. Reactions are the whole of the answer, and they cost one rule and one column of the Stance table rather than a sixfold multiplication of the simulation.

11.1 Capacity

TM-1530 Reaction capacity MUST be an integer per-unit allowance for the turn, set at CloseOrders from committed Stance (TM-640): March 0, Advance 0, Hold 1, Entrench 1 while establishing and 2 once established (TM-700).

TM-1540 Reaction capacity MUST be live for the entire Cascade — before, during, and after the reacting unit's own activation — and MUST NOT be consumed by the reactor's own activation.

Rationale: this is what makes low initiative something other than a pure penalty, and it is the mechanism by which a defender who acts last can still meaningfully affect an attacker who acted first. Without it, buying a low position in the order would buy only better information, and the defensive stances would be strictly dominated. With it, the tactical shape the design direction asks for falls out on its own: if you want to intercept, somebody has to be standing still. A player who puts every unit in March gets the whole top of the activation order and a line that cannot catch anything.

TM-1550 Capacity MUST NOT refresh within a turn, MUST NOT carry over between turns, and MUST NOT be transferable between units.

11.2 The trigger

TM-1560 At each tile a moving unit enters, the engine MUST perform this procedure in exactly this order:

1. Apply the tile's entry effects (01-game-rules.md owns them).
2. If the mover was destroyed by step 1, the activation ends; no reaction occurs.
3. Build the eligible reactor set (TM-1570).
4. If the set is empty, movement continues.
5. Otherwise select exactly one reactor (TM-1620) and resolve the reaction (TM-1630).

TM-1570 A unit r MUST be in the eligible reactor set for a mover m entering tile t when all of the following hold at that instant:

1. r is hostile to m's owner (01-game-rules.md and 14-victory.md own the hostility relation; absent a team rule, every position is hostile to every other).
2. r is alive, on the map, and not embarked.
3. r's spent-reaction count is strictly less than its reaction capacity.
4. The Chebyshev distance from r's tile to t is less than or equal to r's reaction reach (TM-1580).
5. r's owner currently observes tile t (01-game-rules.md owns visibility).
6. r has not already reacted to m during m's current activation.

TM-1580 Reaction reach MUST be an integer per-class value in [1, 3], defaulting to 1. 02-units-and-industry.md owns any value above 1 and MUST record its reason.

Rationale: reach 1 is the rule; the reach field exists because "a battery whose guns cover the ford" is a real and desirable behaviour that the model should be able to express without a rules change, and because a single integer is a cheap way to leave room for it. The cap of 3 is what keeps it from becoming a zone of denial that nothing can cross: at reach 3 a single unit already interdicts a 7×7 area once per turn, and anything beyond that stops being interception and becomes terrain.

TM-1590 The mover's starting tile MUST NOT be treated as entered. A unit that begins its activation adjacent to a reactor and does not move MUST NOT be reacted to.

TM-1600 There MUST be no zone of control. A unit that begins adjacent to a reactor and whose first step breaks contact MUST NOT be reacted to, and adjacency alone MUST NOT constrain movement, cost movement, or force a halt.

Rationale: this is a decision, not an oversight. Reactions exist to make interception possible, not to make disengagement impossible, and a zone of control would quietly turn every stationary unit into a wall that fast units cannot manoeuvre around — which is the opposite of the tactical texture wanted here. The consequence a player must learn is legible in one sentence: a picket catches what walks past it, not what walks away from it, and stopping a determined withdrawal takes a second unit.

TM-1610 A reaction MUST NOT trigger another reaction. Movement caused by a reaction, retreat, or displacement MUST NOT be treated as tile entry for the purposes of TM-1560.

11.3 Selection and resolution

TM-1620 Where the eligible reactor set holds more than one unit, exactly one MUST react, selected by: (1) highest Initiative; (2) lowest creation sequence number. Because initiative is frozen and creation sequence is unique, this is total.

TM-1630 When a reaction fires the engine MUST, in this order:

1. Halt the mover on the tile it just entered.
2. Increment the reactor's spent-reaction count by 1.
3. Resolve the reaction (11-combat.md owns what a reaction actually does).
4. If the mover survives, evaluate the remainder of its order from the halting tile, executing only non-movement components (TM-1320 step 5).
5. End the mover's activation.

TM-1640 A halted mover MUST forfeit its remaining movement for that activation and MUST NOT bank it. 13-command.md CM-1570 already restricts banking to the Opportunity and Blocked interruption classes; a reaction halt is neither.

Rationale: being intercepted has to cost something or the whole stance economy collapses. If a reaction merely delayed a mover, the defender would have paid six or twelve points of initiative and given up their movement to buy an inconvenience, and no player would ever take Hold. Forfeiting the run is the price that makes a picket line worth building.

TM-1650 A reactor MUST NOT change tile as a result of reacting.

TM-1660 A reaction MUST NOT consume the reactor's activation. A reactor that has not yet activated MUST activate normally at its own index; a reactor that has already activated is unaffected.

TM-1670 A unit MUST NOT react during its own activation, and MUST NOT react to a friendly unit's movement.

TM-1680 Exactly one reaction MAY fire per mover per activation. Because TM-1630 ends the mover's activation, this follows from the procedure and MUST NOT be relaxed by any other rule.

TM-1690 A unit that is spent (TM-1830) MUST still be able to react if it has capacity.

TM-1700 A unit in Stance March MUST be able to be reacted to and MUST NOT be able to react. A unit in Stance Advance likewise MUST NOT be able to react.

TM-1710 A reaction MUST be recorded in the Cascade's event stream as an observable event for every player who observes either participant's tile at that instant (§14).

TM-1720 A reaction MUST NOT be initiated by, or subject to, any Sanction. It is a defensive act by a unit standing on ground it was told to hold, and 13-command.md CM-1420's prohibition on Reflexes initiating attacks does not apply to it.

Rationale: the boundary is worth stating explicitly, because both documents talk about a unit fighting without a fresh order. 13-command.md CM-030 forbids automation taking an irreversible action no Sanction authorises, and initiating an attack is exactly such an action. A reaction is not an initiation — the enemy walked into the unit's field of fire, and the player authorised precisely that by paying initiative for a defensive Stance. Requiring a Sanction on top would mean a player who chose Hold and gave up their movement could still watch a column walk past unmolested, which makes the Stance a trap.

TM-1730 A reaction MUST NOT be declinable. If the eligible set is non-empty, a reaction fires.

Rationale: an optional reaction would need a decision, a decision needs either a player (forbidden by TM-050) or a Sanction (forbidden by TM-1720), and the third option — an engine heuristic deciding when overwatch is worth spending — is exactly the kind of automated judgement 13-command.md CM-010 says must not be made on the player's behalf. Making it mandatory makes it predictable: a player who put a unit in Hold knows exactly what it will do, and can position accordingly.

TM-1740 Reaction capacity, spent counts, and reach MUST be visible on the unit panel, and the reach of a visible enemy unit MUST be shown to a player who has observed that unit's class.

TM-1750 The distribution of Stance across all activations MUST be instrumented. Sustained March usage above 40% of activations indicates its costs are too low, and the levers are its defensive penalty and its vulnerability to reactions — never the +8.

12. Birth, death, displacement, and carriage

12.1 Creation

TM-1760 A unit MUST NOT be created during a Cascade. Production MUST resolve during the Reckoning (TM-1930 step 4), and a unit completed in turn T MUST first activate in turn T+1.

Rationale: uniform, predictable, and plannable, and it gives production timing real weight — "that garrison arrives one turn too late" is a sentence a player should be able to say and act on. The alternative considered was letting new units enter the current Cascade at the tail with a restricted action set; it was rejected because it adds rules and edge cases to buy one turn of production latency, which is better bought by tuning production time.

TM-1770 A unit created during the Reckoning of turn T MUST enter turn T+1's activation roster normally, with age = 0 and therefore a Forming Up penalty of −8, which places it low in the order.

TM-1780 A unit created during a Reckoning MUST have reaction capacity 0 for the remainder of that turn and MUST NOT be able to react before its first Orders phase.

12.2 Destruction

TM-1790 A unit destroyed at any point during a Cascade MUST have its remaining activation slot skipped. The roster MUST NOT be compacted, re-sorted, or shortened.

Rationale: freezing the order is exactly what makes this safe, and it is why TM-1160 exists. A mutating sort during iteration is one of the few classes of bug that produces a plausible result on every test and a divergence in production, and it is precisely the kind of thing a codebase assembled from many small contributions gets subtly wrong. Tombstoning a slot is one boolean and it is unbreakable.

TM-1800 A skipped slot MUST produce no event, no Attention Event, and no log entry. Its destruction was already an event at the moment it happened.

TM-1810 A unit destroyed after its own activation MUST have no retroactive effect on that activation. Everything it did stands.

TM-1820 The destruction of a unit MUST NOT alter any other unit's activation index.

12.3 Carriage, landing, and spent units

TM-1830 A unit embarked in a transport MUST NOT appear in the activation roster. It MUST be acted upon as part of its transport's activation.

TM-1840 A unit that is unloaded during a Cascade MUST be spent for that turn: its own activation slot, if it has not yet been reached, MUST be skipped, and it MUST NOT receive a second activation.

Rationale: without this, an amphibious force gets a free move on the beach — landing during the transport's activation and then moving again at its own index, which turns a landing into a landing plus an advance and makes seaborne assault strictly better than the same force arriving overland. Marking the landed unit spent costs one flag.

TM-1850 A spent unit MUST retain its reaction capacity and MAY react (TM-1690).

TM-1860 A unit that boards a transport during a Cascade after having already activated MUST NOT activate again. A unit that boards before its own index MUST have that slot skipped.

12.4 Displacement and ownership change

TM-1870 A unit that changes owner during a Cascade MUST: retain its creation sequence number (TM-830); have its age reset to 0 (TM-980); have its order stack replaced by its new owner's default Doctrine for its type (13-command.md CM-790); be skipped for the remainder of that Cascade if its slot has not yet been reached; and have reaction capacity 0 for the remainder of that turn.

Rationale: a captured unit carrying its previous owner's orders into the same turn is the sort of thing that is funny once and is a bug report every other time. Zeroing its participation for the remainder of the turn is the honest reading of "it changed sides in the middle of a battle", and it costs the new owner exactly one turn of use — which is the same price TM-980 charges everywhere else.

TM-1880 A unit displaced by a retreat, a push, an unload, or any other effect MUST have its order evaluated from wherever it actually is (TM-1390 case 2), with no penalty and no re-issue.

TM-1890 Displacement MUST NOT change a unit's activation index, and MUST NOT grant it a second activation even if it is displaced to a position earlier in the order.

TM-1900 Displacement MUST set entrenchment to 0 (TM-700).

TM-1910 A unit whose owner is eliminated mid-Cascade MUST continue to resolve normally for the remainder of that Cascade unless 01-game-rules.md destroys or transfers it, and the game MUST NOT end before the Reckoning (TM-080).

TM-1920 Where 01-game-rules.md permits a unit to be created mid-Cascade by any mechanism other than production — a split, a spawn, a scenario trigger — that mechanism MUST be specified to place the unit outside the activation roster for the current Cascade, and this document's Cascade rules MUST NOT be amended to admit it.

13. The Reckoning

TM-1930 The Reckoning MUST execute exactly these steps, in exactly this order, with no interleaving:

TM-1940 Step 4 MUST complete before step 5, so that a unit created this turn has age = 0 at the start of the next turn rather than 1.

TM-1950 Step 8 MUST occur after step 4, so that a victory condition satisfied by a unit or work completing this turn is recognised on the turn it completes rather than the turn after.

TM-1960 No step of the Reckoning MAY solicit player input (TM-050).

TM-1970 No step of the Reckoning MAY move a unit, initiate combat, or change tile ownership. Those are Cascade effects. A Reckoning step that needs one MUST instead set state the next Cascade acts on.

Rationale: keeping the Reckoning free of spatial effects is what lets the Cascade be the single place where the world changes shape, and therefore the single place a player has to watch to understand what happened. A Reckoning that could move units would mean things happening between the animation and the next Orders phase — invisible, unexplained, and the source of every "why is my unit not where I left it" report.

TM-1980 Where two Reckoning steps owned by different documents both write the same field, this document's ordering MUST govern and the conflict MUST be resolved by moving one of them, never by making the write order implicit.

TM-1990 The Reckoning MUST be the only place a game ends (TM-080).

TM-2000 A unit's reaction capacity MUST be reset at CloseOrders (TM-1130 step 2), not during the Reckoning, so that a Stance changed during the Orders phase sets the capacity that Orders phase intended.

TM-2010 All Reckoning arithmetic MUST be integer and MUST NOT draw from the PRNG except where 11-combat.md and 12-economy.md explicitly do so.

TM-2020 The Reckoning MUST be as reproducible as the Cascade: given the same state at the close of a Cascade, it MUST produce a bit-identical result on every supported runtime (03-architecture.md AR-070).

TM-2030 The Reckoning MUST NOT be logged (TM-310).

TM-2040 The canonical state hash computed at step 9 MUST be the value 05-multiplayer.md compares across peers for desync detection.

14. Fog

14.1 During Orders

TM-2050 During an Orders phase every player MUST see the world exactly as their knowledge view stood at the close of the previous Cascade, fog-filtered, and that view MUST NOT change for the duration of the phase.

TM-2060 No opponent action MAY be "in progress" during an Orders phase, because no action is in progress for anyone (TM-340). There MUST be no partial reveal, no half-glimpsed movement, and no information that arrives during the phase.

Rationale: this is a real improvement over sequential turns and it is worth naming. Under sequential turns, the information you act on depends on where you sit in the turn order — the last player sees a board seven others have already rearranged, and the first sees nothing. Here every player thinks against the same stable snapshot of their own knowledge, and there is no incentive to stall in the hope of seeing something, because there is nothing to see.

TM-2070 Presence data (TM-440) MUST be the only information transmitted to a player during an Orders phase that changes during it, and it MUST carry no fact about the game world.

TM-2080 A player's own units' initiative (TM-1090) and their relative order (TM-380) MUST be computable client-side from the player's own committed state, so that showing them requires no server round-trip and leaks nothing.

14.2 During the Cascade

TM-2090 Visibility MUST be evaluated per activation, not once per turn.

Rationale: this is the requirement that makes the Cascade worth watching, and it is expensive enough that it will be tempting to cut. If an enemy column crosses your scout's field of view and then leaves it, you must see the transit — a column emerging from a treeline, crossing your line of sight, and gone. Evaluate fog once per turn and the player sees only where things ended up, which means the replay is a lie: it shows a world in which nothing moved through anywhere. The drama of watching a turn unfold is entirely made of transits, and there is no cheaper way to have them.

TM-2100 A player MUST observe an event if and only if their knowledge view, evaluated at the instant that event occurred, included the tile or entity the event concerns.

TM-2110 The observable event categories MUST be exactly: movement of a unit into or out of an observed tile; combat, including reactions, in an observed tile; destruction of a unit in an observed tile; capture of an observed city or work; a unit becoming visible or ceasing to be visible; and terrain or works changes in an observed tile.

TM-2120 A player MUST NOT be able to observe, infer, or receive: any event in a tile they do not observe; any activation index; any unit's order, Posture, Sanction values, or condition; the size of the activation roster; the number of activations that occurred; or the identity of a player who acted where they could not see.

TM-2130 An observed enemy unit's initiative MUST be disclosed only as the coarse band of TM-1100.

TM-2140 The engine MUST recompute each player's knowledge view incrementally rather than from scratch at each activation, and the incremental result MUST be provably identical to a full recomputation (03-architecture.md AR-480, AR-950(d)).

14.3 The event stream and the timing leak

TM-2150 The server MUST emit, per player per Cascade, a compacted observation stream: an ordered list of exactly those events that player observed, and nothing else.

TM-2160 The stream MUST NOT contain gaps, placeholders, activation indices, per-event timestamps, or any field whose value varies with unobserved activity.

Rationale: without compaction the stream leaks by omission. A client receiving a per-activation feed could infer that something happened from a gap where it saw nothing, and by correlating gaps with the initiative bands it does know, deduce roughly what class of unit acted and when — which over a few turns is a reasonable census of an opponent's army composition, obtained entirely from things the player could not see. Emitting only observable events, with no ordinal that maps back to the roster, closes it completely.

TM-2170 In a game with two or more human players the stream MUST be transmitted as a single payload after the Cascade has fully completed, never incrementally, so that transmission timing carries no information about when in the Cascade an event occurred.

TM-2180 In a solo or hotseat game the stream MAY be delivered incrementally, because no opponent exists to whom timing could leak. AI seats MUST NOT read the stream at all; they read the state through the same core interfaces every seat uses (06-ai.md).

TM-2190 The relative order of events within a player's stream MUST be the Cascade order restricted to that player's observations. This discloses the relative activation order of units the player observed, and that disclosure is deliberate and permitted.

Rationale: a player who watches two enemy units act learns which of them was quicker. That is exactly the information a person standing on the hill would have, it is information about units they can see, and hiding it would mean shuffling the playback — which would make the replay incoherent and would break the one thing the animation is for. The disclosure is bounded: it says nothing about units they did not observe, and nothing about the absolute position of anything in the order.

TM-2200 The client MUST animate the stream at its own pace and MUST NOT be able to affect the simulation by doing so.

TM-2210 Attention Events MUST be generated per player from that player's fog-filtered view only (13-command.md CM-1850), and MUST NOT be able to carry a fact the observation stream withheld.

TM-2220 Fog non-leakage MUST be property-tested: mutating any state invisible to player P MUST leave P's knowledge view and P's observation stream byte-identical (03-architecture.md AR-950(c)).

TM-2230 A player MUST be able to review the previous Cascade's observation stream during the following Orders phase, at their own pace, without any effect on the simulation.

15. Playback

TM-2240 The Cascade MUST be computed to completion before any playback begins. Playback MUST be presentation of a finished result and MUST NOT be a live simulation.

TM-2250 In a solo, two-player, or hotseat game the Cascade MUST be able to run instantly, with playback skippable entirely, and MUST offer optional step-through: advancing one observed event at a time under the player's control.

Rationale: amendment 1 of the binding decision, and the honest reading of what most play of this game will be. One person against AI opponents does not need a clock and does want the tactile pleasure of seeing each result land. Step-through gives back nearly all of the feel of moving a unit and watching what happens, at zero cost to the model, because the outcome is already fixed before the first frame.

TM-2260 Step-through MUST NOT alter any outcome, MUST NOT reveal anything the observation stream withheld, and MUST NOT be available as a means of pausing a game with more than one human player.

TM-2270 Playback MUST be skippable at any point, and skipping MUST land the player on the identical end state.

TM-2280 Playback duration MUST NOT scale linearly with roster size. Where a Cascade produces more observed events than can be shown in a bounded time, the client MUST cluster or summarise (04-ui-ux.md owns the presentation), and MUST provide a written after-action summary of what the player observed.

Rationale: a sixty-second animation is a pleasure at turn 20 and an obstacle at turn 150. The failure signal to watch is the skip rate: if more than half of players are skipping playback by turn 100, the answer is clustering and a written report, not a longer animation.

TM-2290 The client MUST be able to replay any past Cascade from the log, reproducing the identical observation stream for the player whose seat is being viewed.

TM-2300 A spectator seat MUST receive an observation stream constructed by the same rules, for whatever view the game's spectator policy grants (05-multiplayer.md owns the policy).

TM-2310 Playback MUST identify, for each observed event, which unit acted, so that a player can attribute what they saw. Where the acting unit is not itself observed — a reaction fired from an unobserved tile, where 11-combat.md makes the shot observable — the actor MUST be shown as unknown rather than omitted.

TM-2320 The client MUST show, after playback, the count of the player's own activations that fell back to no action under TM-1400, with a one-action route to the units concerned.

Rationale: the stance-fallback rate is the model's key diagnostic (TM-1440) and the player is the person best placed to fix their own instance of it. Telling them "four of your units had nothing they could do" turns an invisible waste into a specific, actionable list, and it teaches the conditional vocabulary faster than any tutorial.

TM-2330 Playback pacing, clustering, skip state, and step-through state MUST be client state and MUST NOT contribute to any hash.

TM-2340 The client MUST be able to show the frozen activation order for the player's own units after a Cascade, with each unit's initiative and every term that produced it.

TM-2350 Where a player's unit was skipped (TM-1790, TM-1840, TM-1870), the client MUST say which reason applied.

16. Determinism hazards, hashes, and the log

16.1 The named hazards

TM-2360 The following MUST each be covered by an explicit test in the CI determinism corpus, because each is a way this specific model fails:

16.2 Hashes

TM-2370 At CloseOrders, before any unit acts, the engine MUST compute the activation-order hash: the canonical hash (03-architecture.md AR-130) over the frozen roster, encoded as, for each index in ascending order, the triple (creationSequence, initiative, ownerIndex).

TM-2380 The activation-order hash MUST be exchanged between peers and compared before the Cascade runs, and any mismatch MUST be reported as a desync immediately (05-multiplayer.md owns the exchange).

Rationale: a few hundred bytes, and it catches the single most likely class of desync in this model — an initiative modifier applied in a different order, an inactive tier term contributing on one build, a sort without a comparator — and it catches it before any state has diverged. A desync detected at the top of the Cascade names the bug; the same desync detected three turns later at the state hash names nothing at all.

TM-2390 The activation-order hash MUST NOT be part of the canonical state hash, because the frozen roster is derived state (TM-320). It MUST be carried on its own channel.

TM-2400 The canonical state hash and the turn hash MUST be computed at Reckoning step 9 and MUST be the values compared for save integrity, replay verification, and desync detection.

16.3 The log and replay

TM-2410 Replaying the turn record of turn T against the state at the close of turn T−1 MUST reproduce turn T's Cascade, Reckoning, every event, every hash, and every player's observation stream, bit-identically.

TM-2420 A replay MUST NOT invoke AI code (06-ai.md AI-350). AI seats' orders are in the log like any other player's.

TM-2430 A replay MUST NOT consult any wall-clock value, deadline, or reserve bank. The TurnTimeout and CloseOrders records carry everything the replay needs.

TM-2440 The turn record MUST be sufficient on its own. No state may reach the simulation by any path other than the order log (13-command.md CM-2040 states the same obligation for the command layer).

TM-2450 A change to any rule in this document — a Stance value, a class base, a tier's term set, the Forming Up formula, a tie-break, the reaction procedure, or the Reckoning order — MUST bump RulesVersion (03-architecture.md AR-880).

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

TM-2470 The turn number, phase, and per-player commit markers MUST be recoverable from the log alone, without replaying the Cascade.

17. Performance

TM-2480 Computing a Cascade of 1,200 activations — freezing the order, evaluating every order policy, resolving all movement and reactions, and producing every player's observation stream — MUST complete within 200 ms on the project's reference hardware, excluding pathfinding (bounded by 03-architecture.md AR-750) and combat resolution (bounded by 11-combat.md).

TM-2490 Computing initiative for 1,200 units and sorting the roster MUST complete within 5 ms on reference hardware.

TM-2500 Per-activation visibility MUST be incremental (TM-2140). A full visibility recomputation per activation MUST NOT be the shipping implementation.

Rationale: this is the one genuinely expensive thing the model asks for and it must be named as engineering rather than discovered as a frame-rate problem. On a very large map with 1,200 units, recomputing every player's visibility 1,200 times per turn is not viable; incremental visibility is. Cutting per-activation fog instead would be cheap and would hollow out the Cascade (TM-2090), so the cost is paid here.

TM-2510 The Cascade MUST be able to run in a worker thread without behavioural difference (03-architecture.md AR-010 makes the core host-agnostic).

TM-2520 The activation roster MUST be allocated once per Cascade and MUST NOT grow during it.

TM-2530 Reaction eligibility MUST be answerable from a spatial index bounded by the maximum reaction reach (3), not by a scan over all units.

TM-2540 The observation stream for one player for one Cascade MUST be bounded by the number of events that player observed, and MUST NOT carry per-activation records for unobserved activity (TM-2160).

18. Rolling planning

A refinement to build after the base model is stable, not with it.

TM-2550 The engine MAY open rolling planning: once a unit has activated in the Cascade of turn T, everything relevant about it for turn T+1 is already known, so the client MAY allow the player to begin revising that unit's orders for T+1 immediately, while the rest of turn T's Cascade plays back.

TM-2560 Rolling planning MUST be early access to the next Orders phase, never a commitment. The formal Orders phase for T+1 MUST still open when the Cascade and Reckoning of T complete, and every order staged under rolling planning MUST remain fully revisable then.

TM-2570 An order staged under rolling planning MUST NOT reach the core until the Orders phase for T+1 has opened, and MUST be rejected under TM-260 if submitted earlier.

TM-2580 Rolling planning MUST NOT reveal anything the observation stream withholds, and MUST NOT reveal the acting unit's activation index.

TM-2590 Rolling planning MUST be disableable, and disabling it MUST have no rules effect.

TM-2600 Rolling planning MUST NOT be available in a game where it would let a player act on information about the current Cascade before another player has seen the same playback. Where the observation streams have been transmitted (TM-2170) this is satisfied by construction, since every player holds their whole stream before playback begins.

19. Contracts on other documents

Obligations this specification places on subsystems it does not own, recorded so a change on either side is detectable.

TM-2610 01-game-rules.md MUST provide: 8-directional adjacency and Chebyshev distance including map wrap, used by the reaction reach test (TM-1570); integer terrain movement costs and the movement allowance to which TM-660 adds +1; tile-entry effects and their ordering relative to TM-1560 step 1; the visibility predicate used by TM-1570 clause 5 and TM-2100; stacking legality; capture semantics for TM-1510; and a deterministic setup enumeration for TM-850. It MUST NOT define a turn structure, an activation order, or a simultaneous-movement conflict rule (TM-1300).

TM-2620 02-units-and-industry.md MUST provide, per unit class: an integer base initiative in [24, 64] (TM-930), defaulting to the family table and recording any deviation; a movement allowance; a vision radius; a reaction reach in [1, 3] defaulting to 1 (TM-1580); and any per-class restriction on which Stances the class may take (TM-750). It MUST NOT attach any further effect to a Stance value (TM-640).

TM-2630 11-combat.md MUST provide: the resolution of a reaction, given a reactor, a mover, and the tile the mover halted on (TM-1630 step 3); the defensive treatment associated with each Stance and with entrenchment (TM-640, TM-700); the veterancy grade in [0, 3] that feeds initiative term 4; the disruption flag that feeds term 5, set at Reckoning step 1 and cleared per TM-1000; and the deterministic per-mille win predictor 13-command.md CM-150 requires. It MUST NOT initiate a reaction outside the procedure of TM-1560, and MUST NOT alter initiative.

TM-2640 12-economy.md MUST provide: the supply state that feeds initiative term 7 (TM-1020); a production queue whose completion order within a city is deterministic (TM-860); and Reckoning steps 2, 3 and 4 in the order TM-1930 fixes. Production MUST complete only during the Reckoning (TM-1760), and no economy effect may move a unit or change tile ownership (TM-1970).

TM-2650 13-command.md is satisfied by this document as follows: CM-2140's three requirements are met by TM-1170 (activation index readable during the Cascade), TM-870 (creation sequence as a totally-ordered tiebreak available to core and client), TM-630 and TM-640 (Stance and its four values, which CM-390, CM-430, CM-480, CM-520 and CM-550 target), and TM-050 with TM-1230 (a unit under a Posture occupies its slot, resolves, and yields with no player prompt).

TM-2660 13-command.md MUST continue to own the order vocabulary: the three-level order stack, the six Postures, the four Sanctions, Doctrines, Formations, Groups, Postings, Consignments, Requisitions, the Reflex set, the six interruption classes, and Attention Events. This document MUST NOT define an order type, a condition type, or an automation behaviour.

TM-2670 Where 13-command.md's Reflexes force a Stance (CM-1400), that force MUST be read as setting effective Stance only, per TM-760 and TM-770. Neither document may make a Reflex alter initiative or reaction capacity.

TM-2680 14-victory.md MUST evaluate at Reckoning step 8 and MUST NOT evaluate at any other point (TM-1950). It MUST own the hostility relation where the ruleset offers teams (TM-1570 clause 1).

TM-2690 03-architecture.md MUST provide: the Int arithmetic discipline and overflow behaviour (AR-080) used by TM-910; the canonical hash primitive (AR-130) used by TM-2370; the order log and its sequencing (AR-260) used by §3; incremental visibility with a proof of equivalence (AR-480) used by TM-2140; deterministic pathfinding and tile-index tie-breaks (AR-750) used by TM-1480; and the determinism lint and CI corpus (AR-085, AR-955, AR-960) that enforce §16.1.

TM-2700 05-multiplayer.md MUST provide: transport of order records and observation streams; the presence channel of TM-440 as ephemeral non-authoritative data; the deadline and reserve-bank clocks as host-side state that reaches the core only as TurnTimeout and CloseOrders (TM-550); the activation-order hash exchange of TM-2380; and the single-payload transmission of TM-2170.

TM-2710 06-ai.md MUST provide seats that submit order records within the same Orders phase as human seats, with no extra time, information, or order kinds (TM-410), and substitutes that satisfy TM-590.

TM-2720 04-ui-ux.md MUST provide the presentation of: the live initiative readout and its term breakdown (TM-1090, TM-1080); the own-units relative order (TM-380); the coarse enemy band (TM-1100); the Stance control and its derived-value display (TM-730); playback, clustering, skipping and step-through (§15); and the fallback-count report of TM-2320.

20. Worked example, normative as a test vector

Three positions — Meridian, Karsk, Ostry — on turn 41. A river runs north–south; the only crossing is Kelsey Ford at (15,9). All state below is as of the close of the Orders phase.

TM-2730 A conforming implementation MUST reproduce both activation orders below exactly, from the stated inputs.

20.1 The board

20.2 Tier 1 (the shipped default): class base, Stance, Forming Up

TM-2740 At Initiative Tier 1 the scores MUST be:

and the frozen order, descending initiative with ties on ascending sequence, MUST be:

0231 (O) → 0601 (M) → 0402 (M) → 0488 (K) → 0644 (O) → 0117 (K) → 0104 (M) → 0670 (M) → 0455 (K)

Owner pattern O M M K O K M M K: three positions thoroughly interleaved, from one integer sort of three terms.

20.3 Tier 3: all seven terms

TM-2750 At Initiative Tier 3, with 0402 at veterancy 2, 0104 at veterancy 1, 0488 disrupted, nobody out of supply and nobody attached to a Formation, the scores MUST be 0231 68, 0601 68, 0402 44, 0644 38, 0117 34, 0488 32, 0104 30, 0670 28, 0455 24, and the frozen order MUST be:

0231 (O) → 0601 (M) → 0402 (M) → 0644 (O) → 0117 (K) → 0488 (K) → 0104 (M) → 0670 (M) → 0455 (K)

Rationale: the two orders differ in exactly one place and it is the interesting place. At Tier 1, Karsk's 0488 acts fifth, at full priority, as though the beating it took last turn had not happened. At Tier 3 the disruption penalty drops it behind Ostry's 0644 and Karsk's own picket. That single swap is the whole argument for the tier system: the extra terms buy consequence, and a player who has not yet met the systems that produce them loses nothing but that consequence.

20.4 The Cascade, and what falls out of it

Non-normative narration of the Tier 3 order, included because the interactions it produces are the ones an implementation must get right.

1 · 0231 (Ostry, 68). Rides toward (15,11). Entering (17,10) puts it at Chebyshev 1 of Karsk's 0117, which is in Hold with capacity 1 and observes the tile. The eligible set is non-empty, so a reaction fires (TM-1730): the horse halts at (17,10), forfeits its remaining points (TM-1640), and takes whatever 11-combat.md's reaction does. The seventh-highest unit on the board stopped the highest — but only because Karsk chose Hold, paid −6 for it, and gave up 0117's movement.

2 · 0601 (Meridian, 68). Four points, in March, so five (TM-660). Its condition — if enemy-held, halt at (14,9) — is evaluated on arrival against Meridian's knowledge view at that instant (TM-1260): the ford is empty, because almost nothing has moved. Meridian takes Kelsey Ford, and pays for it: in March it has no reaction (TM-1700) and the weakest defensive treatment in the game.

3 · 0402 (Meridian, 44). Two points to the ford. Its condition — entrench in place if the ford is not friendly-held — evaluates false, because 0601 holds it. It completes the move and stacks.

4 · 0644 (Ostry, 38). Ordered to assault the ford. When Ostry wrote that order the ford was empty. It is now held by two units, one of them a veteran, across a river. The order says assault, so it assaults, and it dies. Ostry made two mistakes and both are learnable: the order carried no condition, so it could not notice the world had changed; and 0231's ride in step 1 revealed the Karsk column, but 0231 activated in the same Cascade, so that knowledge arrived too late to act on. "Assault the ford; if held by two or more, halt at (16,10) and entrench" would have left a live unit dug in on the approach. The conditional vocabulary is the skill ceiling.

5 · 0117 (Karsk, 34). Hold, no movement, reaction already spent. A no-op activation (TM-1230) by a unit that shaped the turn thirty seconds ago.

6 · 0488 (Karsk, 32). Two points to (16,9). Nobody can react: the Meridian units at the ford are in March and Advance, neither of which has capacity. Karsk is in contact.

7 · 0104 (Meridian, 30). Entrenched garrison. No-op.

8 · 0670 (Meridian, 28). Holding the Vell approach, reaction armed, nothing in range. No-op — but it is the reserve, it resolves last with the fullest picture of where Karsk went, and next turn its Forming Up penalty drops from −6 to −4. Exactly the unit a naive seniority rule would have written off.

9 · 0455 (Karsk, 24). One point, ordered to (17,10) to set up a bombardment. (17,10) is occupied — by Ostry's crippled light horse, stopped there in step 1 by Karsk's own overwatch. Move is not attack (TM-1380), so the gun halts at (18,10). Karsk's bombardment is spoiled by a third party's crippled scout, put there by Karsk's own shot. Nobody designed that; it fell out of the ordering.

Reckoning. Vell completes a line infantry: it draws the next sequence number, age = 0, and first activates in turn 42 near the bottom of the order. 0488's disruption flag clears at step 6 of the next Reckoning, so it is penalised in exactly one Cascade.

Open questions

1. Is +1 movement the right price for Stance March? TM-660 chose a flat integer over a percentage, deliberately favouring slow units, and the reasoning is sound on paper. What it has not been tested against is whether it makes infantry columns too fast relative to the roster 02-units-and-industry.md ends up with. The signal is the March usage rate of TM-1750: if March is above 40% of activations and the units taking it are predominantly slow, the +1 is the cause and it should become +1 only for units with an allowance of 3 or less.

2. Per-unit reaction capacity, or a shared alert pool? TM-1530 specifies per-unit because it is simple, legible on a unit panel, and needs no new resource. A per-player alert pool would make screening a resource-allocation decision, which is richer, and would let a player concentrate defensive attention where they expect an attack rather than spreading it evenly. The objection is that it needs a whole new number on the HUD and makes "will this picket fire?" unanswerable by looking at the picket. Worth revisiting once 11-combat.md has decided what a reaction actually does, because the answer changes how much a reaction is worth and therefore how much rationing it matters.

3. Should reaction reach above 1 exist at launch? TM-1580 provides the field and defaults it to 1, so the shipped game can have no unit with reach 2 or 3 and nothing changes. The question is whether artillery covering a ford at range is a behaviour worth the complexity of a reaction that fires from a tile the mover never approached — which is dramatic and is also the most confusing possible thing to see in playback.

4. Is the coarse initiative band the right disclosure? TM-1100's three bands were chosen so that Stance shows through and composition does not. The alternative positions are showing nothing at all (which makes planning against an opponent guesswork and quietly removes the reason to think about the order) and showing the exact number (which hands over veterancy, supply and disruption in one integer). Three bands is a middle that has not been playtested, and the band boundaries in particular are a guess calibrated on line infantry.

5. Does the establishing turn of Entrench need a consolation? TM-700 makes the first turn of Entrench strictly worse than Hold: the same reaction capacity and the same defensive treatment for twice the initiative cost. The argument is that it is a tempo price for a stronger position later, and it is honest. The counter-argument is that a strictly dominated option on turn one is a trap for a new player who has not yet understood that it pays off on turn two, and the cheapest fix — give the establishing turn 11-combat.md's Hold treatment plus a small bonus — costs one number.

6. Should the observation stream be padded? TM-2160 and TM-2170 close the gap and timing channels, but a payload's size still correlates with how much a player observed. That correlation is almost certainly harmless, because the player already knows how much they saw and cannot learn anything from their own payload — the leak would require an opponent to observe the payload, which the transport should already prevent. Recorded rather than fixed, because if 05-multiplayer.md ever relays streams through a peer, it stops being harmless.

7. Should the alternating-activation model ever ship as a variant? This document specifies exactly one turn model, and TM-1300 forbids adding simultaneous-conflict rules on the grounds that none are needed. Strict alternating activation on a creation-order queue is a genuinely good two-player game and board wargames have loved it for fifty years. The reason not to build it is not that it is bad, it is that a second turn model means every other subsystem in this specification must be correct under both, which roughly doubles the rules test matrix for a mode that would serve a small fraction of play. Deferred well past 1.0, and it would need a strong reason to pick up.

8. How much of the Reckoning ordering will survive contact with 12-economy.md? TM-1930 fixes nine steps and TM-1980 says this document's ordering governs a conflict. That is the right default and it is written by someone who does not yet know what the economy needs. If integration, upkeep, or manpower turns out to need a step before combat aftermath rather than after, the fix is to move the step here rather than to let either document write the same field twice — but it is a real possibility and it should be checked before either document is implemented.