12 — Economy: Works, Manpower, and the Cost of Holding Ground

This document specifies the economy of Every Last City: the two resources a player spends (Works, local to a city and non-transferable; Manpower, a single national stock priced once at commissioning and never charged again), what a city is worth and how that worth is composed, and the five interlocking systems — Integration, Unrest, the Administrative Cadre, Reach, and War Damage — that together price conquest without ever charging a player for growth behind their back. It owns the Levy formula, the Effective Works formula, Population, the garrison burden, supply states and attrition, razing, Loyalty memory and Naturalisation, and the Ledger phase in which all of the above resolves. Its central obligation is the one the direction document names in §6: a brake on growth that is drawn on the map, priced in integers the player can read, paid in units the player can see, and beatable by a player who plans better than their opponent. Everything here is integer arithmetic; no fixed-point value appears anywhere in the economy.

Status: Draft v0.2 · Owner: unassigned · Depends on: docs/design/00-direction.md, docs/design/01-decision-turn-model.md, docs/design/economy.md, 01-game-rules.md (map, terrain, terrain movement costs, zones of control, fog, setup), 02-units-and-industry.md (unit schema, the Industry ladder, unit costs, the production queue, class flags), 10-turn-model.md (turn structure, the Cascade, initiative, activation, Forming Up), 11-combat.md (combat resolution, strength, capture, defensive values), 13-command.md (Postures, Sanctions, Doctrines, Postings, Consignments, Requisitions, the Dispatch), 14-victory.md (Standing, the Seal, territorial and economic tracks), 03-architecture.md (determinism, integer arithmetic, canonical hashing, seeded PRNG), 04-ui-ux.md (client presentation)

Naming note, binding on this document only. The source proposal used Theatre for a named grouping of cities with a shared production ratio, a rally point and a priority. That object already exists as the Posting of 13-command.md (CM-1130), with its Doctrine (CM-770), its anchor, and its integer weight; this document uses Posting throughout and does not introduce a second grouping. The proposal's Order Board is likewise the Dispatch of 13-command.md (§11); this document specifies an Empire Ledger screen for economic state, and routes every by-exception economic item through the Dispatch rather than building a competing surface.

Naming note on supply state, binding on this document only. Earlier drafts called a unit's or city's position in the three-value supply vocabulary — Supplied, Extended, Isolated — its supply grade, and named the hashed field supplyGrade. This document uses supply state throughout and names the field supplyState (EC-160). The word grade is reserved for the veterancy grade of 11-combat.md, which is the only one of the three quantities that once shared the word that a player says aloud. Nothing about the mechanic changes: the three values, their derivation from the fill (EC-1680), and their effects (EC-1720) are exactly as they were. Documents citing the older name — 02-units-and-industry.md US-1970 and US-2130, 03-architecture.md, 04-ui-ux.md, and 11-combat.md CB-1630 and CB-2780 — are citing this concept under its former name, and are to be read as citing supplyState.

1. The brake must be visible, and this is the test

The direction document (§6) names opaque anti-snowball economics as a known weakness to fix, and is explicit that an invisible tax on growth is worse than the snowball it corrects. This section states that as an enforceable test rather than an aspiration, because a principle with no test attached is decoration and drifts on first contact with a tuning pass.

EC-010 The economy MUST NOT reduce a city's output, raise a unit's cost, slow a production queue, or degrade any unit's effectiveness as a function of the owning player's total city count, total unit count, total Works income, score, Standing, Tenure, or rank among players. No rule in any specification MAY introduce such a function into the economy.

Rationale: this is the single prohibition the whole document exists to enforce, and it is stated as a prohibition rather than as advice because the alternative is cheap, effective, and permanently tempting. Every brake below is a price on a thing the player chose to acquire — a city they took, a Cadre they bought, a distance they advanced — never a penalty for the aggregate they have become. The difference is not cosmetic: a price can be paid, budgeted for, and beaten by better play, and an aggregate penalty cannot be reasoned about at all.

EC-020 Every mechanism in this specification that slows a player's growth (each is a brake) MUST satisfy all four clauses of the Visibility Test:

EC-030 The brakes in this specification MUST be exactly the six below, and each MUST satisfy EC-020 as audited here. Adding a seventh brake is a rules change and MUST carry its own audit row.

EC-040 Every brake MUST be paid in an object the player owns and can point at — a Cadre unit, a garrison unit, a Depot, an Integration number, a War Damage number — and MUST NOT be expressed as an unattributed reduction of a rate. A client MUST be able to answer "why is this number what it is" for Effective Works, Levy, Integration delta, Unrest delta, garrison requirement and supply state by naming every contributing term and its integer value (§14).

EC-050 No economic quantity MAY be hidden from the player it belongs to. Every field this specification defines on a city, a unit, or a player pool MUST be readable by that player at all times, exactly, as an integer.

Rationale: rounding a displayed economic value, or showing it as a bar without a number, reintroduces the invisible tax through the interface rather than through the rules. A player who cannot read the exact integer cannot verify the forecast, and a forecast that cannot be verified will not be trusted or used.

EC-060 No economic quantity MAY be drawn from the seeded PRNG. The economy MUST be a total, deterministic function of committed state.

Rationale: a deterministic-core game whose growth brake is a die roll is a game where the leader loses to luck, which is a worse experience than losing to nothing at all. It also makes the forecast of EC-020 possible: a player can compute their own future exactly, and the client can show it to them.

EC-070 The economy MUST NOT charge any recurring per-turn cost against a unit for existing. There MUST be no upkeep, maintenance, supply consumption, wage, or attrition of any resource that scales with the size of a living army.

Rationale: upkeep punishes having an army, which is the exact behaviour this game is about, and it converts every unit into a bill the player resents. Pricing Manpower once at commissioning produces the opposite incentive and a better game: a large surviving army costs nothing per turn, and a large dying army costs enormously, because the dead do not come back. That rewards preserving formations, makes attrition warfare a strategic decision rather than a spreadsheet entry, and puts the whole cost of a war where the player can feel it — at the moment of replacement.

EC-080 The economy MUST NOT impose any cap, tax, or efficiency penalty that scales with the number of orders, Formations, Groups, Postings, or Requisitions a player commands. 13-command.md CM-1300 forbids placing a brake in command capacity and CM-2190 assigns the brake to this document; EC-030 discharges that obligation and this requirement closes the loop from the economy's side.

EC-090 Where a design decision in this document trades legibility against fidelity, legibility MUST win, and the trade MUST be recorded in the requirement's rationale.

2. Determinism and arithmetic

EC-100 Every quantity in this specification MUST be a signed 32-bit integer. No Q16.16 fixed-point value and no floating-point value MAY appear in economy state or in any economy computation.

Rationale: this is a real and deliberate saving. Because the economy is integer-only end to end, economy code needs no fixed-point review, no rounding-convention audit, and no determinism lint exemption; it is trivially reproducible and hashable. Every rate in this document was chosen so that this property holds without contortion, and a proposed rule that needs a fraction is a proposed rule that needs redesigning.

EC-110 All division MUST be floor division toward negative infinity, MUST be written explicitly as floor(...) at every occurrence in this document, and MUST be implemented as such. Where a value must round up, this document MUST write ceil(...) explicitly; ceil(a / b) for non-negative integers MUST be implemented as floor((a + b − 1) / b).

EC-120 Multipliers that are not whole numbers MUST be expressed as per-mille integers and applied as floor(value × permille / 1000). Percentages internal to a formula MUST be expressed as integer percent and applied as floor(value × percent / 100). Fixed fractional modifiers MUST be written as an explicit integer ratio applied by multiply-then-floor — floor(x × 3 / 4), never x × 0.75.

EC-130 Where two rates or ratios must be compared, the comparison MUST be performed by cross-multiplication rather than by division, so that no intermediate floor discards the distinction.

EC-140 Where a formula composes several operations, this document MUST state the order of operations explicitly and an implementation MUST follow it exactly. Applying the same modifiers in a different order is a rules change, because floor division does not commute with multiplication.

EC-150 Every economic iteration over a collection MUST be performed in a canonical order: players in ascending seat index; cities in ascending city index; units in ascending creation sequence number; tiles in ascending tile index. Every tie in every economic selection MUST terminate in one of those four keys.

EC-160 The following MUST be authoritative game state and MUST contribute to the canonical state hash: every city's integration, unrest, revoltCountdown, population, popProgress, warDamage, warDamageProgress, yard, unsettled, emergencyLevyCooldown, industryLevel, worksExpansionLevel, traits, owner, foundingOwner, homelandClaimants, and its per-player loyalty map; every player's manpower pool; every unit's worksPaid, manpowerPaid, supplyState and isolatedTurns; every Awaiting Levy hull and its skipCount; every Cadre's assignment; every Depot's emplacement state and anchor round.

EC-170 Supply overlays, forecasts, decomposition tooltips, Empire Ledger sort order, and every projection described in §14 MUST NOT contribute to the canonical state hash. They MUST be recomputable from hashed state alone.

Rationale: the split is the same one 13-command.md CM-180 draws and for the same reason — what the economy does is the game, and how it is explained is the interface. Forecasts must be free to improve across the product's life without invalidating a saved game.

3. The two resources

EC-180 The economy MUST have exactly two resources: Works and Manpower. No third resource — fuel, materiel, ammunition, food, money — MAY be introduced by this or any other specification.

Rationale, stated at length because the brief asks this to be argued rather than assumed.

Why not one. A single-resource economy cannot express the thing this game most needs to express: that conquering a city's industry is not the same as conquering its people. With one resource a captured city is simply a fraction of a producer and the only dial available is which fraction — which is the invisible tax of EC-010 wearing a hat. "Their factory works for me now" and "their sons do not" are statements about two different things moving at two different speeds, and two speeds need two quantities. Two resources also give every unit a two-dimensional price, which means the army a player can field is determined by the shape of their empire and not only its size. That is free strategic texture: see §16, where the fast conqueror is forced to mechanise because the people he conquered will not carry a rifle for him. Nobody designed that outcome; it falls out of the second axis.

Why not three. The obvious third axis is a consumable that must be moved to the front. It is rejected on redundancy, not on complexity: the job a fuel economy does is to make operating far from home expensive and to make cutting an enemy's rear decisive, and Reach (§13) already does that job with zero additional ledger entries — no per-unit stock, no convoy routing, no depot inventory. A third resource would buy a second, worse copy of an effect we already have, and would charge every player a per-unit bookkeeping tax for the privilege. A future proposal for a third axis must argue that it does something Reach and Manpower do not; that it is thematic is not an argument.

3.1 Works

EC-190 Works MUST be a per-city integer income, accrued into that city's Yard each Ledger phase, spendable only on that city's own production queue.

EC-200 Works MUST NOT be transferable between cities, between players, or between a city and any national pool, by any mechanism. Specifically, and exhaustively, the engine MUST NOT provide: a Works refund paid into a city other than the one that spent it; a Works transfer, gift, trade, loan or tribute; a Yard merge; a Yard transfer on capture; or any unit, structure, trait or order whose effect is to move Works from one city's Yard to another's.

Rationale: the enumeration is not pedantry. Every one of those is a plausible convenience feature, and any one of them turns Works into a national pool through the back door — at which point the local-versus-national distinction that makes conquest pay immediately and govern slowly collapses, and with it the whole shape of §16. The disband refund of EC-820 pays Manpower only for exactly this reason: refunding Works would let a player build in a rich city, walk the unit to a poor one, disband it, and have invented a Works teleporter.

EC-210 A city's Works income MUST transfer in full to a new owner on capture, subject only to Integration (§6), the loss of the Yard (EC-620), and the Unsettled turn (EC-630).

Rationale: conquest must pay, and it must pay visibly and soon. Works is the generous half of the two-resource model and it is deliberately generous — the 20% floor of EC-560 means a captured city is producing for its captor from the turn after it falls. Every brake in this document acts on the other half.

3.2 Manpower

EC-220 Manpower MUST be a single integer national pool per player. There MUST be no per-city Manpower stock, no Manpower storage, no Manpower transport, and no Manpower routing.

EC-230 Manpower MUST have exactly three behaviours: it accrues each Ledger phase from the Levy (§7.1); it is spent in full at the moment a unit is commissioned (§7.3); and it is partially refunded when a unit is disbanded in a supplied friendly city (EC-820). No other rule MAY consume or produce Manpower except the Emergency Levy (§7.6) and the pool cap (EC-780).

EC-240 A living unit MUST NOT hold, drain, consume, or be charged Manpower for any reason after its commissioning. Restoring a unit's strength by repair (EC-1730) MUST NOT cost Manpower.

Rationale: Manpower is a stock, not an upkeep — this is the same commitment EC-070 makes, restated where a reader will look for it. A unit at 20% strength that repairs to full has not raised new men in the design's fiction; it has reconstituted around the cadre that survived. Charging for repair would smuggle the recurring bill back in through a side door and would make preserving a damaged formation worse than losing it and rebuilding, which is exactly backwards.

EC-250 A player's Manpower pool MUST NOT decay, and MUST be capped by EC-780 rather than by decay.

EC-260 Manpower MUST have exactly one failure mode: Awaiting Levy (§7.4), in which a unit's Works cost has been paid and there is nobody to crew it.

Rationale: a resource that can bind needs a named, visible, self-explaining state for the moment it binds. Awaiting Levy converts a shortage into a prioritisation decision the player has already expressed through their Posting weights, rather than into a silent slowdown that a player discovers by noticing their army is smaller than they expected.

EC-270 Manpower MUST remain national rather than per-region or per-Posting.

Rationale, because this was the source proposal's first open question and it is now decided. A national pool lets a besieged province draw men from across an ocean, which is thematically weak; a regional pool would be sharper but multiplies the ledger by the number of regions and forces a transfer mechanic, a shortage-in-one-place-surplus-in-another state, and a routing rule — three systems in exchange for one point of flavour. The sharpness is recovered without any of that by the payout order of EC-800: Awaiting Levy hulls are paid in Posting-weight order, so the player already says where their men go, using a dial 13-command.md made them set anyway. National accounting, regional expression, one number.

3.3 The price of a unit

EC-280 Every buildable item MUST carry a cost expressed as an ordered pair of integers (works, manpower), both non-negative. 02-units-and-industry.md owns the values for every unit class; this specification owns the values for the Administrative Cadre (§11), the Depot (§13.3), Reconstruction (EC-1520) and Works Expansion (EC-2140).

EC-290 The roster MUST preserve the following Works-to-Manpower ratio bands, measured as works : manpower for each class. At least one buildable land class MUST fall below the empire supply band and at least one above it.

The empire supply band — the ratio at which an empire's own income arrives — runs from 1.67 : 1 for a fully integrated Metropolis to 3.00 : 1 for a Town, clustering near 2.2 : 1 for a mixed holding (§4.3, §16). Infantry at 1.67 : 1 sits below that band, so infantry masses are manpower-bound. Armour at 7.5 : 1 sits far above it, so mechanised forces are works-bound. Which army a player can field is therefore dictated by the shape of the empire they hold, and that relationship is the entire justification for the second resource. A roster that placed every class inside the empire band would leave Manpower doing nothing but occasionally saying no.

4. Cities, Population, and Base Works

4.1 Cities are a fixed map resource

EC-300 Cities MUST be a fixed, finite resource placed at map generation. No player action MAY create a city. A city MAY be permanently removed from the map only by razing (§12.4).

Rationale: the title of the game is the scarcity. If cities can be founded, the contested-object count grows with a player's economy, every brake in §1 is diluted by a builder's curve, and the genre quietly changes. The itch to build something that is not an army is served instead by Depots (§13.3), Reconstruction (EC-1520), and the Industry ladder that 02-units-and-industry.md owns — three sinks that develop what a player already holds rather than manufacturing more of what everyone is fighting over.

EC-310 Every city MUST belong to exactly one class: Town, City, or Metropolis. There MUST be exactly three classes.

Rationale: a player must be able to read a city's rough worth from its map icon without opening a tooltip. Five classes look richer on a table and are indistinguishable at a glance on a map with four hundred of them.

EC-320 The class constants MUST be:

EC-330 Every city MUST record a foundingOwner: the player who held it at the first Seal of the game, or neutral where no player did. foundingOwner MUST be immutable for the life of the game.

EC-340 Every city MUST carry a unique, stable integer cityIndex, assigned at map generation in ascending tile index order, and MUST be identified by it in every canonical ordering in this document.

4.2 Population

EC-350 Every city MUST carry an integer population in [0, populationCap] and an integer popProgress in [0, 999]. population MUST begin at the class cap of EC-320, adjusted by traits (EC-490), and popProgress at 0.

EC-360 Population MUST NOT change on capture. A captured city MUST retain its population and popProgress exactly.

Rationale: this is the load-bearing asymmetry of the whole design and it deserves to be a requirement rather than an emergent consequence. The people are still there. They are simply not yours yet, and Integration (§8) is the only thing that makes them yours. You capture their factories immediately and their people never quite in time.

EC-370 Each Ledger phase, for every city with population < populationCap and unrest < 50, the engine MUST apply, in this order:

1. G = 50 + integration
2. If the city has the Farmland trait, G = floor(G × 3 / 2)
3. popProgress = popProgress + G
4. While popProgress ≥ 1000: popProgress = popProgress − 1000 and population = min(populationCap, population + 1)

EC-380 Where population ≥ populationCap or unrest ≥ 50, popProgress MUST NOT change and MUST NOT be reset.

Rationale for the shape of EC-370: cities begin at their cap, so growth is not an expansion curve — it is a recovery curve, and the only things that push a city below its cap are the Emergency Levy (§7.6) and razing. At Integration 100 a city recovers one Population every ceil(1000 / 150) = 7 turns, so the ten Population an Emergency Levy costs take about 67 turns to regrow. That is the correct sting: inside a 200-turn game the choice is felt for a third of it and is not permanent. At Integration 50 recovery takes ten turns per point, which is another quiet reason to govern what you hold.

4.3 Base Works

EC-390 A city's Base Works MUST be computed by the following steps, in exactly this order. Every step floors.

EC-400 industryMultiplier MUST be the per-mille multiplier that 02-units-and-industry.md assigns to the city's Industry level. Until that specification states otherwise, the values below MUST be used, and a conforming implementation MUST read them from ruleset data rather than hard-coding them.

Rationale: the Industry ladder is the growth curve available to a player who is not conquering, and it is the deliberate counterweight to §16's blitzer. Vela's five cities can climb from 56 Works to 84 by reaching Industry 2 everywhere — a 50% raise bought with production rather than with an army, on ground she already supplies, with no Cadre, no garrison and no Unrest. It is also worth noting what the ladder does not do: it multiplies Works and leaves Population alone, so a tall player's Works-to-Manpower ratio climbs exactly as a wide player's does, and both are pushed toward mechanisation by the same arithmetic from opposite directions. That symmetry was not designed; it is what happens when the two resources are genuinely independent.

EC-410 Base Works MUST NEVER fall below 1 for a city that exists.

EC-420 A city MUST NOT carry both the Farmland and Quarry traits. Map generation and scenario validation MUST reject such a city with a named error.

EC-430 Base Works MUST be visible to the city's owner, decomposed into every step of EC-390 with each intermediate integer named (§14.1), and MUST be visible in undecomposed form to any player with current vision of the city.

Rationale: enemy industry is public information the moment you can see it. The fog in this game is over positions, not over rules, and scouting an enemy's industrial geography must be a real objective rather than a guess.

5. Traits

EC-440 Every city MUST carry between 0 and 3 traits, within the per-class range of EC-320, assigned at map generation and immutable for the life of the game.

EC-450 Traits MUST be visible on the map to any player who has ever observed the city, and MUST persist in that player's knowledge view after the city leaves vision.

Rationale: traits are the reason a specific city is worth a campaign rather than a generic +12. Making them sticky in the knowledge view is what lets a player plan an operation against a city they scouted forty turns ago, which is the behaviour the whole feature exists to produce.

EC-460 The trait vocabulary MUST be exactly the nine entries below. Adding a tenth is a rules change.

EC-470 The Academy aura MUST be evaluated against the Academy city's current owner at the moment the Integration step runs (EC-1990 step 7), and MUST apply to every city that owner holds within Chebyshev 12 of the Academy, including the Academy itself.

Rationale: the Academy is the standout and it is deliberately the most contested object the map can carry. Its aura makes capturing the enemy's Academy slow their digestion of everything they hold and speed yours — an objective whose value is far larger than its Works line and which a fixed-value city list simply cannot produce. Keying the aura to current ownership rather than to the aura target's ownership history is what makes it flip in a single turn, which is what makes it worth a campaign.

EC-480 Multiple Academies MUST NOT stack. A city within range of two or more of its owner's Academies MUST receive +1, not +2.

EC-490 Trait effects on the population cap (Quarry) MUST be applied at map generation, before EC-350 sets the starting Population, and MUST NOT be recomputed thereafter.

EC-500 Cost-reducing traits (Foundry, Aerodrome, Academy) MUST apply to the Works figure only, except the Academy, which reduces both Works and Manpower for a Cadre as EC-460 states. Cost reductions MUST be applied after the Cadre escalation of EC-1250 and MUST NOT stack multiplicatively with each other; where two apply, only the largest reduction MUST be taken, ties broken by lowest trait id.

EC-510 The Shipworks restriction MUST be enforced at queue submission, with a named reason, and MUST NOT silently drop an item from a queue.

EC-520 A trait MUST NOT confer any effect not listed in EC-460. In particular no trait MAY affect Levy, Unrest, supply state, or combat except as EC-460 states.

EC-530 Map generation MUST guarantee that the number of Academy cities on a map is at least max(1, floor(playerCount / 2)) and at most playerCount + 2.

Rationale: too few Academies and the trait is a lottery ticket one player holds; too many and its aura stops being scarce enough to fight over. Half the player count at the low end guarantees the object exists as a contested prize even in a large game; the upper bound keeps digestion rates from becoming uniformly fast, which would flatten §16's whole argument.

6. Effective Works, the Yard, and the production interface

6.1 Effective Works

EC-540 A city's Effective Works — the integer it actually accrues in a Ledger phase — MUST be:

integrationPercent = 20 + floor(4 × integration / 5)
effectiveWorks     = max(1, floor(baseWorks × integrationPercent / 100))

where 20 is the un-integrated Works floor (settable at setup by EC-2120) and baseWorks is the value computed by EC-390.

EC-550 The integrationPercent term MUST take exactly the values below at the stated Integration levels, and an implementation MUST reproduce this table exactly.

EC-560 The un-integrated Works floor MUST be 20 percent.

Rationale: the floor is the reason conquest feels like it paid. A captured Metropolis yields 4 Works the turn after it falls, without a single administrative decision having been made — the factories are running and their output is now yours. The other 80% is the prize you have to earn by governing, and the gap between those two numbers is where the entire mid-game lives. Twenty is chosen against a specific target: a captured City must repay its full capture-and-integration cost within 25–35 turns of a 200-turn game and be strongly profitable after (EC-570). Below 15 the floor stops being felt and conquest reads as unrewarded; above 30 the digestion process stops mattering and §16's Consolidator loses to the Blitzer on raw count.

EC-570 The economy MUST be tuned to the payback target: a captured City held continuously, garrisoned to requirement and digested by one Cadre MUST repay the Works and Manpower spent on taking and integrating it within 25 to 35 turns, and MUST be strongly profitable thereafter. Any change to the floor of EC-560, the Cadre price of EC-1280, or the garrison table of EC-1170 MUST be re-measured against this target.

EC-580 The max(1, ...) in EC-540 MUST apply to every existing city. A city MUST NEVER accrue negative Works, and a city that exists and is neither Sabotaged (EC-1080) nor Unsettled (EC-630) MUST accrue at least 1.

Rationale: the floor of 1 exists only to close an edge case — a city ground to Base Works 1 by War Damage and then freshly captured would otherwise be permanently worth nothing at all, which is a dead object on the map that still demands a garrison. One Work per turn is not a reward; it is the difference between a city and a ruin, and ruins have their own representation (§12.4).

6.2 The Yard

EC-590 Every city MUST carry an integer yard, its accumulated unspent Works. Each Ledger phase the city MUST add its Effective Works to yard (EC-1990 step 10).

EC-600 When yard is greater than or equal to the Works cost of the item at the head of the city's production queue, that item MUST complete in that Ledger phase and yard MUST be reduced by that cost. After a completion, yard MUST be clamped to at most one turn's Effective Works: yard = min(yard, effectiveWorks).

Rationale: the carry-over cap stops a completion from cascading — a city cannot finish four items in one phase off a hoard — while leaving ordinary accumulation toward an expensive head item untouched. Accumulating 600 Works toward a carrier over thirty turns is intended play; converting a hoard into a fleet in a single phase is not.

EC-610 Where a city's production queue is empty, yard MUST continue to accrue up to a cap of 2 × effectiveWorks, above which further accrual MUST be discarded and a ProductionIdle Attention Event (13-command.md CM-1720) MUST be raised each Ledger phase until the queue is non-empty.

Rationale: a small buffer means a player who edits a queue does not lose a turn's production for the privilege. A large one would be a stockpile, and a stockpile is a Works bank, which EC-200 forbids in every other form and should not permit here by omission. The event exists because Works quietly evaporating is precisely the invisible loss EC-010 is written against.

EC-620 On capture, a city's yard MUST be set to 0 and every in-progress item in its production queue MUST be discarded. Neither MUST transfer to the capturing player.

EC-630 On capture, a city MUST be marked Unsettled for exactly one Ledger phase: at the first Ledger phase after the capture it MUST accrue 0 Works, MUST complete no production item, and MUST gain no Integration. Unrest and Population MUST resolve normally during the Unsettled phase.

Rationale: one phase, not three. The obligation to make conquest pay immediately (EC-210) and the fiction of a city whose lights are out for a day are both served by a single turn; more would be a second brake wearing Integration's clothes, and §1 permits exactly six. It also gives 14-victory.md the "Unsettled" city marking it asks for, at a duration short enough that it cannot be farmed as a denial tactic.

EC-640 A city's Effective Works, its yard, its queue and its Unsettled state MUST be visible to its owner at all times, and the number of turns until the head item completes at the current rate MUST be displayed as an integer.

6.3 The production interface

EC-650 The production queue's structure, ordering, editing, Templates and Requisition-driven selection are owned by 02-units-and-industry.md and 13-command.md. This specification owns only: what a queue item costs (EC-280), when the Works are paid (EC-600), when the Manpower is paid (EC-760), and what happens when it cannot be (§7.4).

EC-660 A production item that has begun MUST NOT be cancelled, retargeted, or re-costed by the economy for any reason, in accordance with the obligation 13-command.md CM-1270 places on this specification.

EC-670 A player MAY cancel a queued item explicitly. Cancelling MUST refund nothing. Cancellation MUST be possible only before completion; after completion the item is either commissioned (EC-760) or an Awaiting Levy hull (EC-790), and an Awaiting Levy hull is disposed of by EC-830.

EC-680 A newly captured city's Consignment MUST default to Auto, per 13-command.md CM-1160, and the economy MUST NOT require any player input to make a captured city produce.

Rationale: capturing a city must not generate clerical work. The command layer already answers the question a player would answer identically every time; the economy's job is to not ask it.

7. Manpower: the Levy, the pool, and Awaiting Levy

7.1 The Levy

EC-690 Each city's Levy — the Manpower it contributes to its owner's national pool each Ledger phase — MUST be:

levy = floor(population × integration / 1000)

EC-700 The Levy MUST use floor division, and the consequence MUST be treated as a designed feature rather than as a rounding artefact: a city below its class's levy threshold contributes exactly zero Manpower.

Rationale: the floor is doing real work and it is the sharpest edge in the document, so it is stated as its own requirement rather than buried in a formula. A conqueror who has taken thirteen Cities and left them at Integration 20 collects thirteen Manpower per turn from a population of 650 people. A Town at Integration 40 collects nothing at all — not a little, nothing — which is what makes the difference between owning ground and governing it a thing a player feels rather than reads about. It also produces the visible, plannable moment EC-020 demands: the city panel can say "this Town begins yielding men at Integration 50, eleven turns from now", and that sentence is a plan.

EC-710 A player's levy rate MUST be the sum of levy over every city they hold at the moment the Levy step runs, and MUST be displayed on the Empire Ledger together with a per-city breakdown and an explicit list of the cities contributing zero.

Rationale: the list of zeroes is not a courtesy. It is the anti-snowball brake's own receipt, and a player who cannot see it will experience Manpower scarcity as an unexplained ceiling — which is the failure mode EC-010 exists to prevent.

7.2 The pool

EC-720 Every player MUST have exactly one integer manpower pool, beginning at the scenario's stated value and defaulting to 40.

Rationale: forty is roughly one line infantry plus one armour, or four militia — enough that a player's first two builds are not gated on a resource they have not been taught yet, and little enough that Manpower begins to bite around turn 15, which is where the progressive-disclosure plan wants it.

EC-730 The pool MUST NOT go negative. Any operation that would take it negative MUST instead not occur, and MUST produce an Awaiting Levy hull (EC-790) where the operation was a commissioning.

EC-740 The pool, its cap, the current levy rate, and the total Manpower committed to Awaiting Levy hulls MUST be displayed together at all times in the Empire Ledger and in the production interface of every city.

7.3 Commissioning

EC-750 A unit MUST be commissioned — created, placed, and given its creation sequence number — only when both its Works cost and its Manpower cost have been paid in full. Partial payment MUST NOT occur.

EC-760 At the Ledger phase step at which a production item completes (EC-1990 step 11), the engine MUST attempt to pay the item's Manpower cost from the owner's pool. Where the pool holds at least that amount, the payment MUST be made and the unit MUST be commissioned at EC-1990 step 17. Where it does not, an Awaiting Levy hull MUST be created instead.

EC-770 Every commissioned unit MUST record worksPaid and manpowerPaid: the actual integers paid for it after all trait and escalation modifiers. These fields MUST be used for every refund computation and MUST NOT be recomputed from the class's list price.

EC-780 At the end of every Ledger phase, a player's Manpower pool MUST be clamped:

manpowerCap = max(50, 10 × levyRate)
manpower    = min(manpower, manpowerCap)

Manpower discarded by this clamp MUST be reported to the player as returned to the fields, with the exact integer discarded.

Rationale: the cap stops a turtle banking five hundred Manpower for a turn-200 army the map cannot see coming, which would convert Manpower from a pacing device into a hidden stockpile. Ten turns of income is generous enough that a player saving toward a carrier is never punished for it. The floor of 50 answers the opposite failure: a player who has just lost their integrated core has a levy rate near zero, and a cap of ten times zero would confiscate their remaining men at exactly the moment they most need them — a death spiral, and precisely the sort of quiet compounding punishment §1 forbids.

7.4 Awaiting Levy

EC-790 An Awaiting Levy hull MUST record: the producing city index, the item's class, worksPaid, the Manpower still owed, a player-settable levyPriority boolean defaulting to false, an integer skipCount beginning at 0, and a creation order integer. A hull MUST NOT occupy the producing city's queue: the queue MUST advance to its next item.

Rationale: blocking the queue would idle the city silently, which is the invisible slowdown of EC-010. Letting the queue advance converts the shortage into exactly what the design wants — a visible pile of hulls and a prioritisation decision — while the Works keep flowing into things the player can still afford.

EC-800 At EC-1990 step 13 the engine MUST pay out Manpower to Awaiting Levy hulls, per player in seat order, walking that player's hulls in this total order:

1. levyPriority = true before levyPriority = false
2. descending skipCount
3. descending Posting weight of the producing city's Consignment, per 13-command.md CM-1130 and CM-1160; a city consigned Manual or none MUST be treated as weight 0
4. ascending Posting id
5. ascending cityIndex
6. ascending hull creation order

For each hull in that order: where the pool holds the Manpower owed, pay it, remove the hull, and mark the unit for commissioning; otherwise increment skipCount and continue to the next hull.

EC-810 A hull MUST NOT be paid partially. skipCount MUST reset to 0 when the hull is paid.

Rationale for the aging term: walking in priority order and stopping at the first unaffordable hull starves everything behind an expensive one forever; skipping without aging starves the expensive one forever instead. Promoting a hull by its skip count gives cheap units the tempo they should have and guarantees the carrier eventually gets its crew, in a rule that is one integer wide and completely predictable. A player who wants a specific hull first says so with levyPriority, which is a real decision and therefore theirs.

EC-820 A unit disbanded on a tile containing a friendly city whose supply state is Supplied MUST refund floor(manpowerPaid × 60 / 100) Manpower to its owner's pool and MUST refund zero Works.

Rationale: sixty per cent makes disbanding an obsolete formation a real recovery rather than a punishment, and the forty per cent lost is the men who do not come back to the depot. Works refund zero because a Works refund paid into any city creates the transfer EC-200 forbids — build in the Metropolis, walk the unit to the Town, disband, and Works have moved. There is no version of a Works refund that does not open that door.

EC-830 A player MAY scrap an Awaiting Levy hull. Scrapping MUST refund floor(worksPaid × 50 / 100) into the producing city's yard and MUST remove the hull. Scrapping MUST be available only in the city that produced the hull, and only while that player still holds it.

EC-840 A city MUST hold at most 4 Awaiting Levy hulls. When a fifth would be created, the city's production queue MUST pause instead, and a ProductionIdle Attention Event MUST be raised naming the Manpower shortfall.

Rationale: an unbounded pile of hulls would let a manpower-starved player convert their entire Works income into inventory they can never crew, which looks like production and is not. Four is enough headroom that a temporary shortage never pauses a city, and small enough that a structural one is impossible to ignore.

EC-850 Awaiting Levy hulls belonging to a city MUST be destroyed, with no refund, when that city is captured, revolts, or is razed.

7.5 Refunds and the dead

EC-860 A unit destroyed in combat, lost to attrition (EC-1740), surrendered (EC-1750), or captured MUST refund no Works and no Manpower.

Rationale: this is the whole shape of the resource. A large surviving army is free; a large dying army is ruinous, because every replacement is priced at full Manpower against a levy rate that grows only as fast as you can govern. That is what makes an attritional exchange a strategic decision rather than a bookkeeping entry, and it is why §16's Blitzer — who has enormous Works and a starved levy — cannot afford to trade infantry with anybody.

7.6 The Emergency Levy

EC-870 A player MAY order an Emergency Levy in a city they hold, where all of the following hold both when the order is issued and when it resolves: integration at least 50; population at least 20; emergencyLevyCooldown equal to 0.

EC-880 An Emergency Levy resolving at EC-1990 step 12 MUST: reduce population by exactly 10; add exactly 20 to the owner's Manpower pool; add +25 to the city's unrest for that phase; and set emergencyLevyCooldown = 30. The cooldown MUST decrement by 1 each Ledger phase to a floor of 0, MUST persist through capture, and MUST NOT reset on a change of owner.

EC-890 Manpower gained from an Emergency Levy MUST be subject to the pool cap of EC-780 in the same phase.

Rationale: the Emergency Levy is deliberately a loser's button, and every term is chosen so that a winning player has no reason to press it. For a Metropolis it trades 1 Levy per turn forever for 20 Manpower now — a twenty-turn payback, correctly priced as a bad deal — plus 25 Unrest at the moment you can least afford a garrison. A player who is ahead is already at their Manpower cap and gains nothing from it at all, by EC-890, which is the cleanest possible expression of "not for you". A player about to lose their capital has every reason to press it twice. Giving the underdog a burst lever the leader will not touch is worth more to the health of the game than its complexity costs, and the cooldown surviving capture stops a city being farmed by successive owners.

8. Integration

This and the Cadre are the anti-snowball engine. Everything else in the document supports them.

EC-900 Every city MUST carry an integer integration in [0, 100].

EC-910 On capture, integration MUST be set by the Loyalty rules of §12.1 and MUST NOT be set to a fixed constant.

EC-920 Integration MUST resolve once per Ledger phase, at EC-1990 step 7, by computing a signed delta and applying it:

integration = clamp(integration + delta, 0, 100)

EC-930 The delta MUST be computed in exactly this order:

1.  if unsettled            -> delta = 0, stop                        (EC-630)
2.  if garrisonMet == false -> delta = 0, stop                        (EC-1180)
3.  if unrest >= 50         -> delta = 0, stop
4.  base = cadrePresent ? cadreRate(class) : (unrest < 30 ? 1 : 0)
5.  if base == 0            -> delta = 0, stop
6.  mods = (cadrePresent && supplyState == Supplied ? +2 : 0)
           + (academyAura ? +1 : 0)
           + (hostileWithin3 ? -3 : 0)
7.  gain  = max(0, base + mods)
8.  decay = (unrest > 40 || supplyState == Isolated) ? 1 : 0
9.  delta = gain - decay

EC-940 cadreRate(class) MUST be: Town +10, City +6, Metropolis +2. The academyAura term MUST be the +1 of EC-460 trait 7 and MUST apply with or without a Cadre present, as an exception to step 6's dependence on step 4 — that is, a city with no Cadre and unrest < 30 within an Academy's range gains 2 per turn rather than 1.

EC-950 hostileWithin3 MUST be true when any unit hostile to the city's owner stands within Chebyshev distance 3 of the city tile, evaluated on true world state rather than on the owner's knowledge view.

Rationale: Integration is a fact about the world, not a belief about it. An enemy raiding column disrupts the administration of a city whether or not its owner has seen the column, and computing it from the knowledge view would make a player's own economy depend on their own ignorance — which is both incoherent and exploitable. The player learns about the disruption from the Integration delta itself, which is exactly the kind of indirect intelligence a fog game should reward reading.

EC-960 The resulting integration rates MUST be exactly:

Rationale: the headline is the first row and it is the number the whole design is calibrated around — nine turns for a Town, thirteen for a City, twenty-five for a Metropolis, with an administrator standing in the street and a supply line running to it. Taking an enemy capital is a project, and that is the intent. Note that the ordinary case is the supplied one, because the numbers a spec quotes should describe the situation a player will usually be in; the out-of-supply row is 10 / 17 / 50 and is the price of a deep raid that outran its logistics, which is a second, quieter reason to advance at the pace your Depots can follow. Note also what row five says: without a Cadre a Metropolis takes a hundred turns, which on any real timescale means it does not integrate at all. That is the mechanism. Everything else is its price.

EC-970 Integration MUST NOT decay merely because a Cadre departs. Withdrawing a Cadre MUST freeze Integration at its current value, subject only to the decay term of EC-930 step 8.

Rationale: redeployment must be a real option rather than a punishment. A player who pulls a Cadre off a half-digested Town to save it from a raid should lose the progress they have not yet made, not the progress they have. Freezing rather than reversing is also what makes the Cadre's route a genuine planning problem — you are allocating a scarce administrator's turns, not defending a decaying investment.

EC-980 Where delta is negative, integration MUST decrease by exactly 1 per Ledger phase and no more. There MUST be no accelerated decay under any condition.

EC-990 Each Ledger phase, after applying the delta, the engine MUST update the city's Loyalty high-water mark for its current owner per EC-1420.

EC-1000 A city's Integration, its per-turn delta, every term of EC-930 that contributed to that delta with its integer value, and the projected turn at which the city will reach Integration 100 at the current rate MUST be displayed on the city panel.

EC-1010 Where the current delta is 0 or negative, the panel MUST state which numbered step of EC-930 stopped it, in plain language — for example "no Integration: Unrest is 61, and Unrest of 50 or more halts integration".

Rationale: this is EC-020's Forecastable and Counterable clauses discharged in one line of interface. A player who sees "no Integration" and is not told why has been handed the invisible tax after all, in a nicer font. A player who is told the clause and the number knows the counterplay before anyone explains it to them.

9. Unrest, Sabotage, and Revolt

9.1 Unrest

EC-1020 Every city MUST carry an integer unrest in [0, 100]. On capture, unrest MUST be set to the class value of EC-320 — Town 30, City 50, Metropolis 70 — plus 20 where the city has the Citadel trait, except where the capturing player is a Homeland claimant, in which case EC-1440 sets it to 0.

EC-1030 Unrest MUST resolve once per Ledger phase, at EC-1990 step 5, as the sum of every applicable term below, clamped to [0, 100]:

Rationale for the pairing of −4 and +6: a garrisoned city recovers from a Metropolis capture (Unrest 70) to the integration-permitting threshold in six turns and to the growth-permitting threshold in eleven, which sets the felt pace of digesting a big city. An ungarrisoned one climbs at +6 and reaches revolt from a Town capture in ten turns — long enough that the two-turn countdown is never the first warning, short enough that leaving a city empty is a decision with a deadline. The asymmetry (6 up, 4 down) is deliberate: neglect should outrun repair, because otherwise a player can garrison intermittently and pay nothing for it.

EC-1040 The garrison terms MUST be mutually exclusive; exactly one of −4 and +6 MUST apply every phase.

EC-1050 Unrest MUST NOT be affected by the owner's city count, unit count, or any aggregate, per EC-010.

EC-1060 A city's Unrest, its per-turn delta with every contributing term named and valued, and the projected turn at which it will reach 90 at the current rate — or the word stable where the delta is zero or negative — MUST be displayed on the city panel.

EC-1070 Unrest MUST be visible to any player with current vision of the city, to two significant terms: the exact value and whether it is rising or falling.

Rationale: an enemy city visibly seething is a legitimate operational intelligence product and a legitimate target. It tells a raider where a threatened counterattack will do the most damage, and it gives the losing player's Cadre-hunting raids an objective they can see. Hiding it would make the most interesting consequence of the occupation system invisible to the person best placed to exploit it.

9.2 Sabotage

EC-1080 A city MUST be Sabotaged in a Ledger phase where both hold at EC-1990 step 6: unrest ≥ 70, and the garrison requirement of EC-1170 is not met. A Sabotaged city MUST accrue 0 Works that phase (EC-1990 step 10) and MUST take the +4 Unrest term of EC-1030 in the following phase.

EC-1090 Sabotage MUST NOT destroy the city's yard, MUST NOT damage its Base Works, and MUST NOT affect Integration or Population beyond the Unrest term it adds.

EC-1100 The engine MUST NOT create partisan units, insurgent units, or any other unit a player did not build, except the single neutral defender created by a revolt (EC-1130).

Rationale: the source proposal reached for partisans winning engagements. Sabotage replaces them and is a better fit for three reasons. It is deterministic, so it does not put the anti-snowball brake behind a die roll that EC-060 forbids. It costs nothing to compute and nothing to look at — no unit to path, no combat to resolve, no icon to manage. And its effect lands exactly where the design wants pressure: on the Works of a city the occupier is refusing to garrison, which is precisely the behaviour being priced. A player who leaves a Metropolis at Unrest 70 with two militia in it is not fighting partisans, they are watching their new factory produce nothing, which is both clearer and more annoying in the right way.

9.3 Revolt

EC-1110 Every city MUST carry an integer revoltCountdown beginning at 0. At EC-1990 step 8 the engine MUST increment it by 1 where unrest ≥ 90, and MUST reset it to 0 otherwise.

EC-1120 A city whose revoltCountdown reaches 2 MUST revolt in that same step.

EC-1130 A revolt MUST resolve as follows, in order:

1. Where any Homeland claimant of the city (EC-1430) has a unit within Chebyshev 6 of the city tile, ownership MUST transfer to the qualifying claimant with the lowest seat index; integration MUST be set to that player's Loyalty in the city; unrest MUST be set to 0; and no defender MUST be created.
2. Otherwise ownership MUST become neutral; unrest MUST be set to 50; and exactly one neutral defender of the map's designated garrison class MUST be created on the city tile, with a garrisonRating sum equal to the city's garrison requirement at Integration 0 — 1 unit for a Town, 2 for a City, 3 for a Metropolis.
3. In both cases: the former owner's yard and Awaiting Levy hulls MUST be destroyed (EC-620, EC-850); warDamage MUST increase by 1 (EC-1470); every Cadre of the former owner on the city tile MUST be dispersed (EC-1340); and every other unit of the former owner on the city tile MUST be displaced to the cheapest legally-enterable adjacent tile, ties broken by lowest tile index, or destroyed where no such tile exists.
4. Loyalty high-water marks MUST be preserved for every player, including the former owner.

EC-1140 A revolt MUST NOT occur without the countdown having been visible for at least one full Orders phase. The client MUST display the countdown on the map, on the city panel, and as a RevoltImminent Attention Event (EC-1900) from the phase the countdown reaches 1.

Rationale: the two-phase countdown is the entire difference between a mechanic that teaches and one that feels cheated. A player who loses a city to revolt must have watched the number climb, been told the exact turn, been offered the counterplay, and declined it. That is a loss they own. Combined with the Unrest forecast of EC-1060 — which fires many turns earlier — a revolt should never be the first thing a player hears about the problem.

EC-1150 A city that has revolted to neutral MUST be capturable normally by any player, and MUST NOT retain any memory of the revolt beyond its Loyalty marks and its War Damage.

EC-1160 The rate of cities lost to revolt MUST be instrumented as a share of cities captured, with a design target of under 5% across a benchmark corpus of AI self-play games. A measured rate materially above that MUST be treated as evidence the Unrest curve of EC-1030 is too steep rather than as intended difficulty.

Rationale: above about one revolt in twenty captures, players stop reading the countdown as a warning and start reading the whole occupation system as a punishment, at which point they raze or stop expanding — both of which break the game the design is trying to produce. The target is a tuning contract, not a hope, and it is measurable from the first self-play run.

10. The garrison burden

EC-1170 Every city a player holds MUST have an integer garrison requirement in garrison points, determined by its class and its current Integration:

Rationale: the burden is front-loaded and falls away in visible steps, which does three things at once. It makes the cost of occupation largest exactly when the city is producing least, so a raw conquest is expensive at both ends. It gives the city panel something concrete to forecast — "this drops from 4 points to 2 at Integration 34, nine turns away" — which is EC-020's forecast clause discharged with no new machinery. And it makes a fully digested city genuinely free to hold, so consolidation pays a dividend a player can feel rather than merely compute.

EC-1180 Where a city has the Citadel trait, its garrison requirement MUST be ceil(req / 2).

Rationale: ceiling rather than floor, so a Citadel never reduces a nonzero requirement to zero. Walls reduce the number of men a place needs; they do not make it hold itself.

EC-1190 A unit MUST contribute its class's integer garrisonRating to the requirement of a city if and only if it stands on that city's tile at EC-1990 step 4. 02-units-and-industry.md owns garrisonRating per class; until it states otherwise the defaults MUST be: the dedicated garrison class 2; any other class able to occupy a city 1; every other class 0.

EC-1200 The garrison requirement MUST be met when the sum of garrisonRating over units of the city's owner standing on its tile is greater than or equal to the requirement. Units of any other player MUST NOT contribute.

EC-1210 An unmet garrison requirement MUST have exactly two consequences and no others: Integration gain is 0 (EC-930 step 2), and Unrest rises by 6 rather than falling by 4 (EC-1030). It MUST NOT reduce Works, MUST NOT reduce Levy, and MUST NOT affect combat.

Rationale: one cause, two effects, both of them in the occupation system where the player is already looking. Spraying the consequence across Works and combat as well would make an unmet garrison feel like a general malaise rather than a specific, fixable omission, and would put a growth penalty somewhere EC-030 has not audited.

EC-1220 The economy MUST NOT raise garrison units automatically. A city whose garrison requirement is unmet MUST instead insert a shortfall entry for one garrison-capable unit into the Requisition of the Posting it is consigned to, per the mechanism 13-command.md CM-1240 and CM-1250 define, and MUST raise a GarrisonShort Attention Event (EC-1900).

Rationale, because this was the source proposal's second open question and it is now decided. Automatic raising would remove the clicks and, with them, the feeling of paying for occupation — which is half of what the mechanism is for. Routing the shortfall into the Requisition removes the clicks and keeps the payment visible: the Works and Manpower still come out of the player's production, the militia still appear in their unit list, and the Requisition panel still shows the shortfall as an integer. The player is charged and shown the bill; they are simply not asked to type it.

EC-1230 The garrison requirement, the points currently present, the per-unit contributions, and the Integration at which the requirement next drops MUST be displayed on the city panel.

EC-1240 The share of a player's total builds that are dedicated garrison units MUST be instrumented, with a design target of under 25% across a benchmark corpus. A measured share materially above that MUST be treated as evidence that occupation is consuming the game rather than pricing it.

11. The Administrative Cadre

The Cadre is the mechanism this document is most confident about, because it converts an abstract digestion rate into a slow, visible, killable convoy of bureaucrats crawling along behind the armies. Nothing about the brake is hidden: it walks.

11.1 The unit

EC-1250 The Administrative Cadre MUST be a unit. It MUST be built in a production queue, occupy a tile, move under the movement rules, appear in the unit list, and be destroyable.

Rationale: this is the whole design in one decision. An integration rate expressed as a number on a settings page is a tax; the same rate expressed as a unit you paid for, chose a destination for, escorted, and can lose is a decision. The mechanism does not become fair by being cheap — it becomes fair by being an object.

EC-1260 02-units-and-industry.md MUST define the Cadre class with: movement allowance 1, no attack of any kind, no defence, and the flags nonCombat, noZoc, and cityBuildable. This specification owns the Cadre's cost, its integration effect, its dispersal rules, and its assignment behaviour.

EC-1270 A Cadre MUST be buildable only in a city of class City or Metropolis whose integration is 100.

Rationale: administrators are trained where administration already works. The requirement also does useful pacing work — a player's Cadre capacity is bounded by the fully-governed part of their empire, so the very first conquest is necessarily digested by a Cadre built at home, and a player whose core has been overrun cannot simply buy their way back into governing what they still hold.

11.2 The price

EC-1280 The cost of a Cadre MUST be:

N = the number of Cadre the player currently owns, alive or in production
works    = floor(150 × (S + N) / S)
manpower = floor( 20 × (S + N) / S)

where S is the escalation slope, an integer defaulting to 2 and settable at setup by EC-2130.

EC-1290 At the default slope the price schedule and its cumulative Works MUST be exactly:

Cumulative Works for N Cadre MUST equal 75 × N × (N + 3) / 2.

EC-1300 N MUST count Cadre the player currently owns, not the greatest number they have ever owned. Losing a Cadre MUST reduce N and therefore MUST reduce the price of the replacement to the rung the player is actually standing on.

Rationale, because this was the source proposal's third open question and it is the humane half of the answer. A ratcheting price would mean that losing a Cadre to a lucky raider after twenty turns of escort duty costs you the unit, the twenty turns, and a permanently higher price for every administrator you build afterwards — three punishments for one mistake, the last of them invisible until you open the queue. Pricing on the current count keeps the escalation curve intact for a growing empire (you still pay rung N to go from N−1 to N, and the cumulative figure is unchanged) while making a loss a loss rather than a scar. It also makes raiding Cadre worth doing for the right reason: you cost the enemy twenty turns of walking, not a permanent surcharge.

EC-1310 The Academy trait MUST reduce a Cadre's cost to floor(works × 3 / 4) and floor(manpower × 3 / 4), applied after the escalation of EC-1280.

EC-1320 The price of the player's next Cadre MUST be displayed permanently in every eligible city's production interface and in the Empire Ledger, together with the prices of the two Cadre after it.

Rationale: this single interface requirement is what converts the anti-snowball curve from a hidden multiplier into a decision. Every time the player opens a queue, the game asks them: this administrator, or four tanks? They answer it consciously, with both numbers in front of them, and whatever they choose they cannot claim they were not told. Showing the next three prices rather than one turns a decision into a plan.

EC-1330 The mathematical shape of the escalation MUST be preserved by any retuning. Cumulative Works to reach N Cadre grows as approximately 37.5 N², so N ≈ sqrt(spend / 37.5). Where a player devotes a constant fraction of Works to administration and Works grows with empire size S, the Cadre count grows as sqrt(S × T) while the demand for integration grows as S, so digestion capacity per city declines sublinearly as an empire grows.

Rationale: this is the honest version of the thing the classic anti-snowball tax was trying to do. Same curve shape, entirely different experience, because every term in it is a number the player chose and can see. The brake tightens the faster you expand — and it does so through a price on a screen, in a currency you spend, on an object that walks across the map.

11.3 Effect and assignment

EC-1340 A Cadre MUST be stationed in a city when it stands on that city's tile, the city is held by the Cadre's owner, and the Cadre did not move during the preceding Cascade. Only a stationed Cadre MUST satisfy cadrePresent in EC-930.

EC-1350 At most one Cadre MUST count as stationed in a city. Additional Cadre on the same tile MUST have no effect and MUST raise a CadreUnassigned Attention Event.

EC-1360 A Cadre MUST NOT voluntarily move to a tile within Chebyshev 1 of a unit hostile to its owner that is present in its owner's knowledge view, unless it ends that movement stacked with at least one combat unit of its owner.

EC-1370 Where a unit hostile to the Cadre's owner enters the Cadre's tile, the Cadre MUST be dispersed: removed from play with no refund, N reduced by 1 (EC-1300), and a CadreLost Attention Event raised. Where the tile also contains a combat unit of the Cadre's owner, combat MUST resolve first and the Cadre MUST be dispersed only if no such unit survives on the tile.

EC-1380 A Cadre in a city that is captured or revolts MUST be dispersed by EC-1370 and MUST NOT transfer to the capturing player.

Rationale: a captured administrator working for the invader is a good story and a bad rule — it would make conquest of a well-governed empire accelerate rather than slow, which inverts the entire brake. Dispersal keeps the price of governing on the person doing the governing.

EC-1390 Every Cadre MUST carry an assignment: a city id or none. A Cadre with an assignment MUST take Posture March to that city with a follow-on of Garrison on it, expressed as an ordinary order in the vocabulary of 13-command.md, and MUST require no further player input to reach and begin work.

EC-1400 A Cadre with assignment none MUST be assigned automatically at the Ledger phase, from the set of cities its owner holds where integration < 100, no Cadre is already stationed or assigned, and the garrison requirement is met. The selection MUST be:

value(city) = baseWorks × cadreRate(class)
eta(city)   = ceil(routeCost / moveAllowance), routed per 13-command.md CM-140

City A MUST be preferred to city B when value(A) × (1 + eta(B)) > value(B) × (1 + eta(A)), compared by cross-multiplication per EC-130. Ties MUST break by lowest eta, then by lowest cityIndex.

Rationale: baseWorks × cadreRate is the marginal Works per turn the Cadre buys by standing there, because Effective Works rises by 4 × baseWorks / 500 per point of Integration — so value is proportional to Base Works times the rate at which the Cadre delivers points. At Industry 1 that ranks a City at 72, a Town at 60 and a Metropolis at 40, which means the greedy default digests Cities first, then Towns, and leaves the Metropolis for last. That is a defensible myopic answer and a frequently wrong strategic one — the Metropolis is worth more in the end — which is exactly the right property for an automatic assignment under 13-command.md CM-010: good enough that a player who never touches it is not punished, wrong often enough that a player who does touch it is rewarded. Dividing by travel time stops the default from dispatching an administrator across a continent for a marginally better target, which is the classic failure of greedy assignment.

12. Loyalty, Naturalisation, War Damage, and razing

12.1 Loyalty memory

EC-1410 Every city MUST record a per-player integer loyalty[p] in [0, 100]: the highest Integration player p has ever achieved in that city. It MUST begin at 100 for the foundingOwner and 0 for every other player.

EC-1420 At EC-1990 step 7, after the Integration delta is applied, the city MUST set loyalty[owner] = max(loyalty[owner], integration).

EC-1430 Loyalty MUST NEVER decay, and MUST persist through capture, revolt, and neutrality.

EC-1440 On capture by player p, Integration and Unrest MUST be set as follows:

Rationale: the second row is what makes a second capture cheaper than a first — ping-ponging a city is not maximally punishing, and a player retaking ground they briefly held resumes from half of where they got to. The first row is the release valve the whole design leans on, and it is deliberately very strong. An invader spends twenty-five Cadre-turns making an enemy Metropolis productive; the Homeland claimant walks back in and has it at full value, with zero Unrest, the same turn. Deep conquest is structurally fragile and homeland defence is structurally cheap. That is the pressure release that keeps a losing player's counterattack meaningful into turn 150, and nobody needs the rule explained twice.

12.2 Naturalisation

EC-1450 Every city MUST record a set of Homeland claimants. The foundingOwner, where one exists, MUST be a claimant from the first Seal. A player MUST additionally naturalise — becoming a permanent claimant — after holding the city continuously at integration = 100 for 20 consecutive Ledger phases. The counter MUST be recorded per player per city, MUST reset to 0 on any loss of ownership or any fall below Integration 100, and claimant status once earned MUST be permanent.

Rationale: this is an addition to the source proposal and it answers a real hole in it. As proposed, a conqueror's cities are permanently more fragile than a defender's, forever, which means that fifty turns after a war of conquest ends the map still treats the winner as an occupier of ground they have governed longer than the original owner ever did. Naturalisation fixes that without weakening the release valve: twenty turns at full Integration is a long, expensive, visible commitment, reachable only after the nine-to-twenty-five turns of digestion that came before it. A city can have several claimants; a border city fought over for a century belongs to everyone who has truly held it, which is both correct and thematically the best thing in the document.

EC-1460 The Naturalisation counter and the current claimant list MUST be displayed on the city panel to its owner, and the claimant list MUST be visible to any player with current vision of the city.

12.3 War Damage

EC-1470 Every city MUST carry an integer warDamage beginning at 0 and an integer warDamageProgress beginning at 0. warDamage MUST be subtracted from Base Works at EC-390 step 5 and MUST be capped at floor(w / 2), where w is the value of Base Works after EC-390 step 4.

EC-1480 warDamage MUST increase by 1 on every change of a city's owner, including a revolt, a capture from neutral, and a recapture by a Homeland claimant. It MUST increase by any further amount that 11-combat.md assigns for effects that damage a city's industry, subject to the same cap.

EC-1490 warDamageProgress MUST increase by 1 at each Ledger phase in which the city's owner is unchanged since the previous phase and integration ≥ 50. At 10 it MUST reset to 0 and reduce warDamage by 1. Any change of owner MUST reset warDamageProgress to 0.

EC-1500 War Damage MUST reduce Base Works only. It MUST NOT reduce Population, Levy, Reach, or the population cap.

Rationale, because this is the document's answer to a problem the source proposal flagged and could not solve: loyalty ping-pong. With Loyalty memory as designed, a contested border city can change hands twenty times with each side restoring it instantly and neither ever profiting — thematically perfect and, over twenty turns of play, tedious. War Damage dissolves it by making the prize itself decay: after three flips a Town is at half Works, after six a City is, after ten a Metropolis is, and at that point neither side wants the fight any more because there is materially less there to want. It is in-world (a city fought through repeatedly stops working), it is one visible integer, it is symmetric, it recovers if someone holds the ground, and it gives Reconstruction (EC-1520) something to do. Restricting it to Works rather than also to Population is a legibility choice under EC-090: one number, one effect, one recovery rule, and the Levy stays a pure function of Population and Integration.

EC-1510 War Damage, its cap, its recovery progress, and the turn at which the next point recovers MUST be displayed on the city panel, and War Damage MUST be visible to any player with current vision of the city.

EC-1520 A city MAY queue Reconstruction: cost 60 Works, 0 Manpower, completing per EC-600, reducing warDamage by 1 and leaving warDamageProgress unchanged. Reconstruction MUST be queueable only where warDamage > 0, and a queued Reconstruction MUST be cancelled without refund if warDamage reaches 0 before it completes.

Rationale: 60 Works buys back 1 Works per turn permanently — a sixty-turn payback, correctly priced as a repair rather than an investment. It is the sink that lets a player who has just won a long fight over a border city do something about the state of it, and it is the only "build something that is not an army" option this document adds by default, which is deliberate.

12.4 Razing

EC-1530 A player MAY order a unit standing on a city tile of a city they hold to raze it. The order MUST occupy the unit's entire activation, MUST place a visible Razing marker on the city for every player with vision of it, and MUST resolve at the following Ledger phase (EC-1990 step 9).

Rationale for the one-turn delay: razing is the most irreversible act in the game and it should be interruptible. A marker visible for one full Orders phase gives the city's Homeland claimant a turn to do something about it, which turns razing from a unilateral erasure into a race — and races are better than fiats.

EC-1540 Razing MUST: remove the city from the map permanently, replacing it with a Ruin map feature that has no owner, no Works, no Population, no Reach, no traits, cannot be captured, and counts for nothing in any victory condition; destroy every Awaiting Levy hull and the yard; disperse any Cadre on the tile; and add +30 Unrest to every city the razing player holds within Chebyshev 10 (EC-1030).

EC-1550 Razing MUST NOT reduce the map's total economic potential as read by 14-victory.md, which MUST be fixed at the first Seal.

Rationale for both: razing must stay a niche answer rather than a dominant one, and the structural reason it does is that an un-integrated city is already a tribute state — it yields 20% of Base Works for the price of a garrison, forever. Razing trades that small permanent income for nothing at all, plus 30 Unrest across your own nearby holdings. It remains correct in exactly one situation: an indefensible city you cannot garrison and do not want the enemy to reclaim. Freezing the map's economic potential is what stops razing from becoming a way to win an economic victory track by shrinking the denominator, which would be a degenerate strategy invented entirely by accident. Cities razed per game MUST be instrumented with a design target of under 2; a spike is evidence integration is priced too high.

13. Reach: supply as drawn geography

Supply is the brake that makes distance cost something. It must be visible as a map overlay before it is anything else: if a player is ever surprised by their supply state, the overlay has failed and the mechanic is a tax.

13.1 The model

EC-1560 Supply MUST be modelled as a cost-limited flood fill from sources, producing one integer supply cost per tile per player, from which a supply state is derived for every unit and city. There MUST be no per-unit supply stock, no consumption, no convoy, no depot inventory, and no routing decision.

Rationale: this is the design's argument against a third resource made structural. Reach delivers the entire strategic effect of a logistics economy — distance from home is expensive, cutting a rear is decisive, an encirclement kills — for the cost of one integer per tile and zero per-unit bookkeeping. Any proposal to add stock or consumption on top must first say what it buys that this does not.

EC-1570 The fill MUST be computed on true world state, not on any player's knowledge view, and MUST be computed independently per player.

EC-1580 The fill MUST use the terrain movement-cost table that 01-game-rules.md owns, evaluated for a single canonical foot movement class, so that one supply network exists per player rather than one per movement class.

Rationale: a per-class network would be more faithful and would produce four overlays a player must cross-reference, four dirty-flag sets to maintain, and a supply state that differs between two units standing on the same tile. One network is a legibility choice under EC-090, and the fidelity it costs is small: the question supply answers is "is there a road home", and roads are roads.

13.2 Sources

EC-1590 A city MUST be a supply source for its owner if and only if integration ≥ 50. Its Reach MUST be the class value of EC-320 — Town 8, City 12, Metropolis 18 — plus 8 where it has the Railhead trait.

Rationale: the Integration 50 threshold is the single most important line in this section, because it is what ties offensive tempo to governing tempo. A freshly captured city does not supply your army. You cannot leapfrog: taking the next city forward does not extend your network until you have spent thirteen turns and an administrator making it yours. Supply alone would throttle the front while leaving the leader's economy untouched, and Integration alone would slow digestion while leaving the front free to run; the threshold is what makes them one system instead of two.

EC-1600 An emplaced Depot MUST be a supply source with Reach 10, subject to the anchoring rule of EC-1660.

EC-1610 No other object MAY be a supply source. Units, formations, Postings, and un-integrated cities MUST NOT project supply.

13.3 Depots

EC-1620 A Depot MUST be a buildable item costing 60 Works and 4 Manpower, or 30 Works and 4 Manpower where built in a Railhead city. It MUST enter play as a unit with movement allowance 1 and the flags nonCombat, noZoc.

EC-1630 A Depot MUST emplace by spending one entire activation stationary on a tile whose supply state for its owner is Supplied. An emplaced Depot MUST be immobile and MUST project Reach 10 from the following Ledger phase. A Depot MAY strike — become mobile again — by spending one entire activation, and MUST cease to be a source immediately.

EC-1640 A Depot MUST be destroyed with no refund where a unit hostile to its owner enters its tile.

EC-1650 Depots MUST be cheap enough to use freely and fragile enough to be worth raiding. A player MUST be able to queue a Depot in any city they hold, without an Integration requirement.

Rationale: the Depot is the player's lever for pushing an offensive beyond their integrated territory, and it must be usable the moment they need it or the whole Reach system reads as a wall rather than a problem. Sixty Works is one and a half infantry — cheap enough that a player pushes three of them forward without agonising, expensive enough that losing a chain to a raid is a real loss.

EC-1660 Depot anchoring MUST be resolved by iterated rounds, per player, at EC-1990 step 1:

1. Round 0: perform the flood fill from every eligible city source. Every Depot whose tile is Supplied after round 0 becomes anchored at round 1.
2. Round k: repeat the fill including every Depot anchored at round k or lower. Every not-yet-anchored Depot whose tile is now Supplied becomes anchored at round k + 1.
3. Iterate to a fixed point, or to a maximum of 8 rounds, whichever comes first. A Depot not anchored by round 8 MUST NOT be a source.

EC-1670 A Depot chain MUST therefore be exactly as strong as its weakest link: destroying, striking, or cutting the supply to any Depot MUST remove every Depot anchored only through it from the network in the same Ledger phase.

Rationale: this is the property that makes a rear worth raiding and an offensive worth escorting. It is also why the round limit is 8 rather than unbounded: eight Depots at Reach 10 is eighty tiles of chain past the last integrated city, which is far beyond any axis a player should be operating on, and bounding the iteration bounds the cost of the fill.

13.4 Propagation

EC-1680 The fill MUST be a Dijkstra expansion from all of a player's sources simultaneously, where each source seeds its own tile at cost 0 and expands to a budget equal to floor(3 × reach / 2). A tile's supply cost MUST be the minimum over all sources. Ties MUST break by lowest tile index. The tile's supply state MUST be:

EC-1690 Propagation MUST be blocked as follows. A tile MUST NOT propagate supply outward, and MUST NOT itself receive supply, where it is occupied by a unit hostile to the player, or where it lies within Chebyshev 1 of a unit hostile to the player that carries the zoc flag — unless that tile is occupied by a unit of the player or contains a city the player holds.

EC-1700 Water tiles MUST cost max(1, ceil(terrainCost / 2)) in the propagation of a coastal source, max(1, ceil(terrainCost / 4)) in the propagation of a Free Port source, and MUST be impassable to the propagation of a non-coastal source.

Rationale: halving the cost of water is how "coastal cities project double Reach over water" is expressed inside a single fill, with no second budget and no second network. Free Port quartering it is what makes an island empire genuinely viable rather than merely possible, and it gives the trait an effect worth a campaign on an archipelago map.

EC-1710 Air units MUST NOT take their supply state from the fill. An air unit MUST be Supplied where it ends the Ledger phase on a friendly city, carrier, or air base whose own supply state is Supplied, and Isolated otherwise. There MUST be no Extended supply state for air units.

Rationale, because this was the source proposal's eighth open question and it is now decided. Air logistics is basing, not a road network: an aircraft is either operating from somewhere that can service it or it is not, and the distance it can operate over is already priced by its own range, which the roster owns. Giving air units a flood-fill supply state would double-charge that distance and would produce the absurdity of an aircraft being "extended" over ocean it crossed in one turn. Naval units need no special case at all: the fill already covers water, and a naval unit reads the supply state of its tile like everyone else.

13.5 Supply states and their effects

EC-1720 The supply state MUST have exactly these effects and no others:

The movement penalty is stated here as this specification's required value and is a contract on 01-game-rules.md; the combat multiplier is likewise a contract on 11-combat.md. Both MUST be applied by multiply-then-floor to an integer strength, which is exact.

EC-1730 Repair MUST be applied at EC-1990 step 3 to a unit that ends the Cascade on a tile containing a friendly city, whose supply state is Supplied, and that did not initiate an attack that turn. Repair MUST cost no Works and no Manpower (EC-240). An Aerodrome MUST restore air units to full strength in one phase, and a Free Port MUST restore naval units to full strength in one phase.

EC-1740 Attrition MUST be applied at EC-1990 step 2. Every unit whose supply state is Isolated MUST increment isolatedTurns and lose ceil(maxStrength × pct / 100) strength, where pct is min(25, 5 × isolatedTurns). isolatedTurns MUST reset to 0 at any phase in which the unit's supply state is Supplied or Extended.

EC-1750 A unit reduced to strength 0 by attrition MUST surrender: it MUST be removed from play, MUST NOT be credited as a combat kill to any player, MUST NOT confer veterancy, MUST refund nothing (EC-860), and MUST be reported to its owner as surrendered rather than destroyed.

Rationale for the escalating schedule: a fixed rate either kills a pocket too fast to be relieved or too slowly to matter. Escalating from 5% to 25% means an encircled formation dies in six to eight turns — long enough that a breakout or a relief attempt is a real operation with a real deadline, short enough that an encirclement is a genuine victory rather than a nuisance. Surrender rather than death is a tone decision and a mechanical one: units that starve should not feed the killer's veterancy, or cutting a supply line becomes a way to farm experience.

EC-1760 A city MUST take its own supply state from the fill, and MUST NOT suffer any Works, Levy or Population penalty from being Extended or Isolated. The only economic effect of a city's supply state MUST be the Integration terms of EC-930 steps 6 and 8.

Rationale: Works is local by construction (EC-190) and a cut-off city's factories do not stop turning. Charging its output for being isolated would be a second, undeclared brake, and §1 permits six.

EC-1770 The unit whose supply state determines an effect MUST be the unit standing on the tile at the moment the effect is evaluated. A unit MUST NOT carry a supply state from a previous phase.

EC-1780 The share of unit-turns ending Isolated without a player order that intended it MUST be instrumented, with a design target of under 3%. A materially higher figure MUST be treated as evidence the overlay of EC-1880 is not readable rather than as evidence players are careless.

14. What the player sees

Section 1 makes visibility a requirement rather than a courtesy. This section says concretely what must be on screen, because a brake that satisfies EC-020 on paper and not in the client has failed the direction document's test just as completely as an invisible multiplier would.

14.1 The city panel

EC-1790 The city panel MUST decompose Effective Works into every step of EC-390 and EC-540, each named and each shown as an integer — class base, each trait modifier applied, the Industry multiplier and its result, Works Expansion where enabled, War Damage subtracted, Base Works, integrationPercent, and Effective Works.

EC-1800 The city panel MUST decompose Levy as population, integration, the product, and the floored result, and MUST state the Integration at which the city next yields one more Manpower, and the turn it will reach it at the current rate.

EC-1810 The city panel MUST show, for Integration: the current value, the current delta, every term of EC-930 that contributed with its integer value, the stopping clause where the delta is zero (EC-1010), and the projected turn of reaching 100.

EC-1820 The city panel MUST show, for Unrest: the current value, the current delta, every contributing term of EC-1030 with its value, and either the projected turn of reaching 90 or the word stable.

EC-1830 The city panel MUST show the garrison requirement, the points present, each contributing unit and its rating, and the Integration at which the requirement next drops (EC-1230).

EC-1840 The city panel MUST show War Damage, its cap, and the turn the next point recovers (EC-1510); the Naturalisation counter and claimant list (EC-1460); the yard, the head item, and the turns to completion (EC-640); and any Awaiting Levy hulls with the Manpower each owes.

14.2 The Cost of Conquest preview

EC-1850 For any enemy or neutral city in the player's knowledge view, the client MUST present a Cost of Conquest panel stating, from the terms the player can see:

EC-1860 The Cost of Conquest panel MUST use only the player's knowledge view, and MUST mark every line derived from a stale observation with its observation age.

Rationale: this panel is the single most important piece of interface in the document, because it is where "visible and plannable" stops being an adjective and becomes a screen. A player deciding whether to take the Metropolis on their flank should be able to read, before they commit a single unit, that it will pay them 4 Works next turn, demand six garrison points for twelve turns, need an administrator they do not yet own at a price of 600, take twenty-five turns to become worth 20 Works and 12 Manpower, and start at Unrest 70. That is the anti-snowball design presented as an offer rather than administered as a penalty, and a player who takes the city anyway has taken a mortgage with the terms in front of them.

14.3 The Empire Ledger

EC-1870 The client MUST provide an Empire Ledger screen showing: total Works accrued this phase with a per-city breakdown sortable by every column; the Manpower pool, cap, levy rate, and the Manpower committed to Awaiting Levy hulls; the per-city Levy breakdown with the zero-yield cities listed explicitly (EC-710); the Cadre count, their assignments, and the prices of the next three (EC-1320); every city's Integration and Unrest with its delta; and the total garrison points required and present across the empire.

EC-1880 The client MUST provide a supply overlay rendering the three supply states in three colours across the whole map, and a projected overlay showing the network as it would be if a named Depot were emplaced on a chosen tile, or if a named city crossed Integration 50.

Rationale: the projected overlay is the counterplay clause of EC-020 for Reach. Without it, "push a Depot forward" is a guess the player makes and discovers the result of two turns later; with it, it is a plan they can evaluate before spending 60 Works and three turns of walking.

EC-1890 The client MUST provide a Digestion Forecast: for the whole empire, the turn at which every currently-held city reaches Integration 100 under the current Cadre assignment, and the marginal effect of buying one more Cadre — which city it would take, how many turns it would save, and what it would cost.

Rationale: this is the Cadre price of EC-1320 turned into a decision with an answer attached. "600 Works, or four tanks" is a hard question; "600 Works buys the Metropolis at Ashfall eleven turns sooner, which is 88 Works and 66 Manpower of income you do not currently have" is a question a player can actually answer. It is also the clearest possible demonstration that the brake is a price rather than a punishment, because the player can see exactly what buying it off would cost.

14.4 Attention Events

EC-1900 The economy MUST emit the following Attention Events into the Dispatch of 13-command.md, deterministically and per player from that player's fog-filtered view, with the terms below assigned per CM-1740, CM-1750 and CM-1760. It MUST NOT provide a competing by-exception surface of its own.

EC-1910 RevoltImminent MUST be exempt from the adaptive player weight of 13-command.md CM-1780, on the same grounds CM-1790 exempts CityThreatened: the game must never learn to stop telling a player they are about to lose a city.

EC-1920 Every economic Attention Event MUST carry at least one one-action resolution, per CM-1650. GarrisonShort MUST offer raise the Requisition target; CadreUnassigned MUST offer assign to the auto-selected city naming it; AwaitingLevy MUST offer flag for priority levy and scrap the hull; SupplyCut MUST offer centre on the broken link.

EC-1930 Economic events MUST be deduplicated by cause key per CM-1700, with the cause entity being the city or Cadre concerned.

EC-1940 The number of economic Attention Events presented per turn MUST NOT grow with the player's city count, in accordance with the obligation CM-090 places on the whole system. Events that would grow with city count — GarrisonShort, AwaitingLevy, UnrestRising — MUST merge into one item per Posting where more than three of a class are live.

EC-1950 No economic Attention Event MAY reveal any entity, tile, or fact the receiving player could not otherwise observe, per CM-1850.

15. The Ledger phase

EC-1960 The economy MUST resolve entirely within a single Ledger phase, which MUST run after the Cascade of 10-turn-model.md has completed and before the Seal at which 14-victory.md evaluates victory. There MUST be no player input during the Ledger phase.

Rationale: the source proposal placed the economy at the top of the round, written before the turn model was settled. After the Cascade is strictly better under Orders and the Cascade, for one reason that matters: the player opens their Orders phase looking at the consequences of the turn that just resolved — this turn's Integration, this turn's Unrest, this turn's new units — rather than at figures a phase out of date. Planning against stale numbers is the thing the Orders phase exists to avoid.

EC-1970 The Ledger phase MUST be independent of activation order. No step MUST depend on which unit acted when during the Cascade, except by reading the world state the Cascade left behind.

EC-1980 Every per-player step MUST process players in ascending seat index, and every per-city step MUST process cities in ascending cityIndex, per EC-150.

EC-1990 The Ledger phase MUST execute exactly these steps, in exactly this order:

EC-2000 Step 12 MUST run after step 11 so that a hull created this phase can be paid by this phase's Levy, and step 14 MUST run after step 13 so that a player never loses to the cap Manpower they were about to spend.

EC-2010 Step 8 MUST run before step 10 so that a city that revolts this phase does not accrue Works for its former owner.

EC-2020 Step 5 MUST run before step 7 so that Integration reads this phase's Unrest. A city captured at the class Unrest of EC-1020 therefore has one Unrest tick applied before its first Integration test, which MUST be treated as intended.

Rationale for stating these three orderings as their own requirements: each of them is a place where a reasonable implementer would choose the other order and produce a subtly different game — a Metropolis captured at Unrest 70 is inert for five phases under this ordering and six under the reverse, and a hull can wait an extra full turn for men that were in the pool. Ordering is rules, and rules that live only in a numbered list get reordered by a refactor.

EC-2030 Newly commissioned units MUST enter the initiative order of 10-turn-model.md at the next Cascade, carrying the Forming Up penalty that specification defines. The economy MUST NOT assign initiative.

EC-2040 The Ledger phase MUST produce a per-player phase report enumerating every change it made to that player's economy, retained for at least the 20 most recent turns and for the whole game in a replay.

Rationale: the same argument 13-command.md CM-1940 makes for the CommandDecisionRecord. A player who cannot audit why their Works fell by six will conclude the game is taxing them, and they will be right to, because a change they cannot attribute is indistinguishable from one that was hidden.

EC-2050 The phase report MUST NOT contribute to the canonical state hash and MUST be reproducible from a replay.

16. Worked example: five cities against forty

Every figure below is computed with the formulas of this document and is normative as a test vector. A conforming implementation MUST reproduce every integer in these tables. All cities are at Industry 1, so industryMultiplier is 1000‰ and Base Works equals the class base of EC-320; no city carries a trait or War Damage. The reference units are the anchors of EC-290: line infantry at 40 Works / 24 Manpower, armour at 120 Works / 16 Manpower, dedicated garrison at 24 Works / 10 Manpower.

EC-2060 The three positions, all at turn 60.

Vela holds her five starting cities — 1 Metropolis, 2 Cities, 2 Towns — all at Integration 100, compact, entirely within her own supply.

Corvain the Blitzer started with the same five and has taken 35 more between turns 20 and 60. He bought 7 Cadre along the way. Those Cadre have fully digested 12 Towns and 1 City; the remaining 22 captures — 6 Metropolis, 13 Cities, 3 Towns — sit at Integration 20.

Corvain the Consolidator is the same player in a counterfactual where he took 15 cities instead of 35, with the same 7 Cadre: 3 Metropolis, 6 Cities, 6 Towns, all digested except one Metropolis at Integration 60.

EC-2070 The Works and Levy figures above MUST be reproducible term by term:

Note the three Towns at Integration 20 in the Blitzer's column. Sixty people, and floor(20 × 20 / 1000) = 0 — they contribute literally nothing to his levy. That single line is the anti-snowball design working, and it is one floor division.

EC-2080 The garrison burden MUST be reproducible from EC-1170: Blitzer, 6 Metropolis at Integration 20 requiring 6 points each (36), 13 Cities requiring 4 each (52), 3 Towns requiring 2 each (6) — 94 points, satisfied by 47 dedicated garrison units at rating 2, a sunk cost of 1,128 Works and 470 Manpower. Consolidator, one Metropolis at Integration 60 requiring 2 points — one unit, 24 Works and 10 Manpower. Vela, zero.

EC-2090 The army each position can field over 100 turns, using only the two reference land classes and exhausting both resources, MUST be:

Read the first two columns together and the design does its job in one line:

Eight times the cities buys 4.3 times the industry, 3.1 times the manpower, and 2.9 times the army.

An 8 : 1 territorial lead has been compressed to a 2.9 : 1 military one, and every step of that compression is something Corvain can point at. He chose to buy 7 Cadre rather than 12. He chose to take 35 cities rather than 20. He can see the 47 garrison units sitting in his cities and the 1,128 Works they cost. He can see the Integration bars creeping up and the three Towns yielding zero men. Nothing was taken from him quietly, and there is no term in any of it that reads his city count.

Now read the second and third columns together, which is the result the whole proposal exists to produce:

The Consolidator holds half as many cities as the Blitzer and fields 24% more units, with a garrison bill of one.

Twenty digested cities beat forty raw ones. The optimal strategy is therefore expand at the rate you can govern — arrived at through the player's own arithmetic rather than through a rule that punishes them for expanding, which is precisely the pacing that keeps a multiplayer game contestable.

And the fourth column, which is why blitzing remains a real option and not a trap:

Once digested, those 40 cities are worth 862 units per 100 turns — more than double the Consolidator.

Blitzing is a mortgage, not a mistake. You are worse off for forty turns and far better off after, and you have denied twenty cities to your rivals in the meantime, which matters under every territorial victory condition. Whether to take that mortgage, and whether you will survive the window in which you are paying it, is a genuine strategic decision with no dominant answer.

One more detail, and it is the best argument for the second resource. Look at the forced mix. Vela fields 7.6 infantry per tank. The Blitzer is forced down to 2.7 — he must mechanise, because his Works are enormous and his Manpower is starved by 22 cities full of people who do not yet answer his call. His army is expensive, materiel-heavy, and slow to replace when it dies, against an opponent whose infantry is cheap and whose ground restores itself. He conquered an industrial base and inherited a manpower crisis. Nobody designed that outcome directly; it fell out of two resources moving at two speeds.

What the two players actually experience. Vela sees a small, dense, fully green empire and a Dispatch that is almost always empty. She is manpower-bound, as everyone is on infantry, so her decisions are about what to build rather than whether; she can spend Works on the Industry ladder instead of on administrators, and taking her five cities to Industry 2 raises her to 84 Works per turn on ground she already supplies. Corvain sees a sprawl, amber and red at the edges, a queue that offers him a Cadre at 600 Works and asks every turn whether that administrator is worth four tanks, a slow line of bureaucrats walking east, and two cities with revolt countdowns on them. He is winning. He will win if nothing changes. And the game is asking him a real question every turn, which is exactly the window in which Vela has to make him answer one of them wrong.

17. Setup options and scaling

EC-2100 The economy MUST expose exactly the setup options below. Each MUST be visible in the setup screen with its effect stated in one sentence, and each MUST be recorded in the replay header.

EC-2110 With manpower: off, every item's Manpower cost MUST be treated as 0, the Levy MUST NOT accrue, Awaiting Levy MUST NOT occur, and the Emergency Levy MUST be unavailable. Every other system MUST be unaffected.

Rationale: this is the simplified ruleset the progressive-disclosure plan needs. It removes one resource and one failure mode and leaves Integration, Unrest, Cadre and Reach intact — which is the right subset, because those four are drawn on the map and Manpower is the one that lives in a number. A first game teaches Works and Integration; the second adds the second resource.

EC-2120 integrationSpeed MUST be applied as floor(cadreRate × permille / 1000) with a floor of 1, and MUST NOT affect the passive rate, the modifiers, or the decay. unintegratedWorksFloor MUST replace the literal 20 in EC-540 and MUST NOT change the shape of the formula: the multiplier MUST remain floor + floor((100 − floor) × integration / 100) reduced to the integer form floor + floor(4 × integration / 5) only at the default value.

EC-2130 cadreSlope MUST be the S of EC-1280. S = 3 MUST produce a shallower escalation (the 7th Cadre at 450 rather than 600) and S = 1 a steeper one (the 7th at 1,050).

EC-2140 With worksExpansion: on, a city MAY queue up to 3 levels of Works Expansion, costing 150 / 250 / 400 Works and 0 Manpower, each adding +2 at EC-390 step 4.

Rationale, because this was the source proposal's seventh open question and the answer is a decision rather than a hedge. Works Expansion is off by default. At a 75-turn payback for the first level it is correct in a 300-turn game and wrong in a 150-turn one, which makes it an option that punishes a player for not knowing the scenario length before they have played it — the worst kind of option, because the mistake is invisible until it is unrecoverable. It also quietly erodes the fixed-city premise of EC-300 by letting a player manufacture industrial capacity rather than take it. It survives as a scenario switch because a designer authoring a 300-turn map knows their own length and should be allowed to offer the sink; it does not survive as a default because a player picking Standard does not.

EC-2150 With warDamage: off, EC-1470 through EC-1520 MUST have no effect and Reconstruction MUST be unavailable.

EC-2160 No setup option MAY introduce a term that reads a player's city count, unit count, score or rank, per EC-010.

EC-2170 Every option MUST be constant for the duration of a game. Changing one mid-game MUST be impossible, and a save whose recorded options differ from a build's defaults MUST be loaded under its recorded options.

18. Performance and scale bounds

EC-2180 The full Ledger phase MUST complete within 20 ms on the project's reference hardware for 8 players, 400 cities, 3,200 units and 200 Depots, excluding the supply fill.

EC-2190 The supply fill MUST be incremental. A full recompute MUST be performed only on load and on a desync check. A source MUST be dirty-flagged when its Integration crosses 50 in either direction, when a Depot emplaces, strikes, is destroyed or loses its anchor, when a city changes owner, or when a unit carrying the zoc flag enters or leaves a tile adjacent to the current network boundary.

EC-2200 A full supply recompute MUST complete within 200 ms for 400 cities and 200 Depots on a 2000 × 2000 map. An incremental update for a single dirty source MUST complete within 5 ms.

EC-2210 The fill MUST be bounded per source at O(reach²) tiles by the budget of EC-1680, and the anchoring iteration MUST be bounded at 8 rounds by EC-1660.

EC-2220 Every forecast of §14 MUST be computable in O(cities) per player per turn and MUST NOT require simulating future turns.

Rationale: the forecasts are the visibility mandate and they must therefore be cheap enough to recompute on every panel open, on every hover, and on every hypothetical the projected overlay is asked to draw. A forecast that needs a simulation is a forecast that will be cached, and a cached forecast will be stale exactly when it matters.

EC-2230 No economy computation MAY allocate per tile per turn. The supply cost array MUST be a preallocated integer buffer per player, reused across turns.

19. Contracts on other documents

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

EC-2240 02-units-and-industry.md MUST express every unit cost as an ordered (works, manpower) pair (EC-280) and MUST keep every class within the ratio bands of EC-290, with at least one land class below the empire supply band and one above it.

EC-2250 02-units-and-industry.md MUST NOT levy any recurring per-turn cost against a unit — no upkeep, maintenance, wage, or consumption of any resource. Where its unit schema carries an upkeep attribute, that attribute MUST be removed; EC-070 and EC-240 are the governing rules and this specification owns the resource model.

Rationale, stated as a contract because it is the one place two designs genuinely collide. The units proposal carries upkeep = ceil(cost / 20) charged per turn to the empire; this document's entire Manpower argument is that a living army costs nothing per turn and a dying one costs everything. Both cannot be true. The upkeep field loses, on the direction document's own grounds: a per-unit recurring bill is a penalty that scales with army size, which is the invisible anti-growth tax §6 of the direction names as a weakness to fix, wearing a different hat.

EC-2260 02-units-and-industry.md MUST express the Industry ladder's economic effect as a per-mille multiplier consumed by EC-390 step 3, MUST own the upgrade costs and per-level unlocks, and MUST own the rule that capture degrades a city's Industry level. This specification reads industryLevel and does not set it.

EC-2270 02-units-and-industry.md MUST provide, per class: garrisonRating (EC-1190); the zoc flag (EC-1690); the air, naval, heavyHull, nonCombat and cityBuildable flags; maximum strength; and the Administrative Cadre and Depot class records described in EC-1260 and EC-1620.

EC-2280 01-game-rules.md MUST provide the terrain movement-cost table used by EC-1580, the water-tile classification used by EC-1700, the coastal classification used by the Shipworks, Free Port and coastal-source rules, and MUST apply the movement penalties of EC-1720 to units by supply state.

EC-2290 11-combat.md MUST apply the combat multipliers of EC-1720 by supply state, by multiply-then-floor to an integer strength; MUST own the Citadel defensive bonus of EC-460; MUST own any effect that damages a city's industry, expressing it as an increment to warDamage subject to the cap of EC-1470; and MUST NOT credit a kill, veterancy, or any combat reward for a unit that surrenders under EC-1750.

EC-2300 10-turn-model.md MUST provide the Ledger phase the barrier described in EC-1960 — after the Cascade completes and before the Seal — and MUST assign initiative and Forming Up to units the economy commissions at EC-1990 step 17. The economy MUST NOT assign initiative.

EC-2310 13-command.md MUST extend the Attention Event catalogue of CM-1720 with the ten economic classes of EC-1900 and their terms, and MUST exempt RevoltImminent from the adaptive weight of CM-1780 as CM-1790 exempts CityThreatened. Until it does, the economy's obligations under EC-1900 are unmet and the visibility test of EC-020 is not satisfied for Unrest, Integration or Reach.

EC-2320 13-command.md MUST accept the garrison shortfall entry of EC-1220 into the Requisition mechanism of CM-1240 and CM-1250, and MUST route Cadre assignment (EC-1390) through ordinary Postures. The economy MUST NOT introduce an order type of its own.

EC-2330 14-victory.md MUST read a player's empire output as the sum of Works actually accrued at EC-1990 step 10, and the map's total economic potential as a value fixed at the first Seal and immune to razing (EC-1550).

EC-2340 14-victory.md MUST weight a held city for territorial purposes by its Holding Weight, which this specification defines as 500 + floor(5 × integration) per-mille — 500‰ at Integration 0, rising linearly to 1000‰ at Integration 100.

Rationale, because this was the source proposal's fourth open question and it needed settling with whoever owns victory. Half weight at zero prevents a land grab from instantly winning a territorial track while still rewarding the grab, and it makes the digestion clock a victory clock as well as an economic one — which is the interlock that makes blitzing a mortgage rather than a shortcut. Defining the function here rather than there means the victory document reads one integer per city and does not need to know what Integration is.

EC-2350 04-ui-ux.md MUST own the presentation of the city panel decomposition (§14.1), the Cost of Conquest panel (§14.2), the Empire Ledger, the supply and projected overlays, and the Digestion Forecast, implementing the content requirements this document states.

Open questions

1. Does the brake survive multipolarity? Every figure in §16 compares one leader against one small player. A leader facing four uncoordinated small players may roll them up one at a time regardless of digestion cost, because each individual fight is short enough to win before the mortgage comes due. This is the largest hole in the analysis and no arithmetic in this document closes it. It needs eight-player AI self-play with the Gini coefficient of city count tracked by turn, against a target that the leader's units-per-turn advantage stays under 4× a mid-pack player through turn 120.

2. Is the Consolidator too strong? §16 shows twenty digested cities beating forty raw ones by 24%. That is the intended result, but if it holds at every ratio then blitzing is never correct, the mid-game becomes mutual digestion, and the map stops moving. The dials are unintegratedWorksFloor (raising it to 30 makes fast expansion meaningfully better) and garrisonScale (halving the requirement removes most of the Blitzer's sunk cost). The measurement that settles it is the share of winning games in which the winner's peak un-integrated city count exceeded 8; near zero means blitzing is dead.

3. Does Naturalisation weaken the release valve too much? EC-1450 lets a conqueror earn permanent Homeland status after 20 phases at full Integration. That is deliberately long, but a player who wins a war and then holds quietly for forty turns ends up with an empire as resilient as a native one — which removes the counterattack pressure that keeps a losing player in the game at turn 150. Twenty may be too few. It cannot be settled without playing the late game.

4. Is War Damage the right fix for loyalty ping-pong, or does it merely relocate the tedium? EC-1470 makes a contested city decay, which stops the endless flip. It also means a border city both sides genuinely want becomes worthless to both, which may read as the map punishing them for fighting over the thing they were supposed to fight over. The alternative — decaying Loyalty instead — was rejected because it weakens homeland defence, which is the mechanism's whole value. Neither option is obviously right.

5. How exposed should a Cadre be? EC-1300 removes the permanent price scar from losing one and EC-1360 keeps it away from known enemies, which together are the humane half of the answer. Whether the remaining exposure is enough for Cadre-hunting to be a real strategy, or so much that escort duty dominates the mid-game, is a playtest question. The measurement is Cadre lost per game and the share of combat units assigned to escort.

6. Should the Metropolis rate be +2 or +3? EC-940 sets 25 turns to digest a Metropolis in supply. That is the number the whole design leans on and it was chosen for feel rather than derived. Twenty would make big cities meaningfully more attractive to take and would shorten the mortgage window in §16 by about a fifth.

7. Is the Cadre auto-assignment of EC-1400 good enough to leave on? It ranks Cities above Towns above Metropolises, which is right per-turn and often wrong strategically. That asymmetry is defended above as the correct property for an automatic default, but if playtest shows players overriding it every single time, the default is simply wrong and the value function should weight the terminal Works of the city rather than its marginal rate.

8. Should a besieged city keep producing? EC-1760 says a cut-off city's factories keep turning, on the grounds that Works is local by construction. That is defensible and it means an encircled city is a fortress that arms itself indefinitely, which may make sieges unwinnable without assault. A siege or investment rule would belong to 01-game-rules.md or 11-combat.md rather than here, and this document takes no position beyond declining to add a seventh brake.

9. Is manpower: off genuinely a good first game, or a different game? EC-2110 removes the resource cleanly, but §16's entire argument is that the second axis is what compresses an 8× lead. With Manpower off, the compression falls to Integration, garrison and Reach alone, and the ratio a first-time player experiences is not the ratio the design was tuned for. It may be better to ship the simplified ruleset with a higher unintegratedWorksFloor and a steeper cadreSlope to compensate, which is a tuning question nobody can answer before there are games to measure.