14 — Victory

This document is the normative specification of how a game of Every Last City ends, and of the system that makes ending it a part of play rather than a terminating check bolted onto a simulation. It specifies the uniform Track abstraction under which every victory condition is one integer progress value, one integer threshold and one Vigil; the full Track catalogue with exact progress and threshold formulas; Standing and Tenure, the two integer scores that resolve every ambiguity in the design; the Ebb, the published schedule by which thresholds descend so that no game runs forever; the rules for combining Tracks, including per-player Charters and hidden Sealed Orders; the non-terminal objectives (Warrants, Tallies) that give the middle third of a long game a rhythm; the setup presentation and the in-game progress readout, including exactly how much of an opponent's progress is published and at what precision; and the four independent mechanisms that end a decided game early — Capitulation, mathematical elimination, the Verdict and Concession. It also owns the design's answer to a weakness no other document owns: a losing player must have a path back, and if they do not have one they quit, which in a multiplayer game destroys the game for everyone still in it. Dissolving the mop-up endgame is the reason this subsystem exists; it is a first-class system, not a settings checkbox.

Status: Draft v0.2 · Owner: unassigned · Depends on: docs/design/00-direction.md, docs/design/01-decision-turn-model.md, docs/design/victory.md, 10-turn-model.md (the Cascade, activation order, the per-turn barrier), 01-game-rules.md (map generation, cities, Regions, Landmarks, setup parameters, fog), 02-units-and-industry.md (unit Works cost, supply state, displacement bound), 11-combat.md (capture and city ownership change), 12-economy.md (Works, Manpower, Integration, effective output), 13-command.md (Attention Events and the Dispatch), 03-architecture.md (determinism, integer arithmetic, seeded PRNG, canonical hashing), 04-ui-ux.md (presentation surfaces), 05-multiplayer.md (correspondence play, absence, substitution), 06-ai.md (deterministic evaluation and vote policy)

0. Named objects

Every capitalised term below is defined normatively in the section named. They are listed here so the rest of the document can be terse, and so that no requirement has to reintroduce a name it uses.

1. Scope, and the four problems this system exists to solve

VC-010 This document MUST be the sole owner of: the definition of winning and losing; every victory condition and its parameters; the Standing and Tenure scores; the evaluation instant; Capitulation, Concession, mathematical elimination and the Verdict; the victory setup screen's content and lint rules; the content (not the pixels) of the victory readouts; and the comeback instruments of §15. No other specification MAY define a way to win, lose, or leave a game.

VC-020 Victory MUST be a configurable system selected at setup from the catalogue of §8, not a fixed rule. Total conquest MUST be exactly one option among many and MUST NOT be the default (docs/design/00-direction.md §5).

VC-030 Every enabled victory condition MUST be legible during play. Specifically, for every enabled Track and every player, the engine MUST be able to answer, at every Seal, in integers: what the progress is, what the threshold is, how far the player is from it, whether a Vigil is running, and how many Seals remain in it. A condition whose progress cannot be stated as an integer at every Seal MUST NOT be admitted to the catalogue.

Rationale: this is the enforceable form of "understandable at a glance." A condition that cannot be reduced to two integers and a countdown cannot be drawn on a forty-pixel strip, cannot be estimated by the setup screen, cannot be reasoned about by an AI evaluator, and cannot be argued about by two players after the game. Uniformity is not an aesthetic preference here; it is what makes every other requirement in this document implementable once instead of fourteen times.

VC-040 The system MUST address four distinct failures, and a requirement in this document MUST be traceable to at least one of them. They are not the same failure and a single turn limit fixes only the third:

VC-050 No requirement in this document MAY be justified by reference to any existing game. Every threshold, weight, cadence and default MUST carry a stated design reason, and where the reason is a guess awaiting self-play data the requirement MUST say so and MUST still state a concrete number.

VC-060 The victory system MUST produce observable events during play at a cadence measured in turns, not once at the end. Concretely: across a game of Horizon H ≥ 150 turns under any preset of §12.5 other than Every Last City, the engine MUST emit at least one Chronicle entry of a class other than EbbStep in every rolling window of 20 turns, or the preset MUST fail the setup linter's L4 check.

Rationale: F1 restated as something a build can check. A victory system that fires once is a terminating condition; a victory system that fires every fifteen turns is a part of the game. The exemption for Every Last City is deliberate — that preset exists precisely to be the thing this design otherwise refuses to be, and it is labelled as such on its card.

VC-070 The victory system MUST NOT confer any combat, movement, vision, production, or economic advantage except where this document explicitly grants one, and every such grant MUST be published to every player at the instant it takes effect. The complete list of such grants is exactly: the Alarm's Bellwether vision (§13.4), the Rally's Survey and Levy Call (§15.3), and the Warrant rewards enumerated in §11.4.

Rationale: 13-command.md CM-050 and CM-060 establish that a subsystem must not become mandatory by making its users stronger. The same discipline applies here and matters more, because a hidden victory-side advantage is indistinguishable from cheating. Enumerating the grants exhaustively means adding a new one requires editing this requirement, which is exactly the friction it should have.

VC-080 Losing MUST be a defined, dignified, recorded exit rather than an absence. A player who leaves the game by any route — Capitulation, Concession, elimination by conquest, or departure — MUST receive a final placing (§16) and MUST appear in the game record.

VC-090 The victory system MUST guarantee termination. For every legal setup, the engine MUST be able to prove at setup time that the game ends within a stated finite number of turns, and the Terms paragraph (§12.3) MUST state that number. A setup for which no such bound exists MUST be rejected by the setup linter as an error, not a warning (§12.4, L4).

2. Determinism and arithmetic discipline

VC-100 All victory computation MUST live in the simulation core, MUST be identical for every player, client and AI seat, and MUST be a total deterministic function of the sealed board state and the game's configuration. A client MUST NOT be able to compute a different result. Rationale: the same argument 13-command.md CM-100 makes for automation applies with more force to the thing that decides who won.

VC-110 All victory arithmetic MUST be integer. Q16.16 fixed-point MUST NOT appear anywhere in this document's computations, and floating-point MUST NOT appear anywhere in the engine's victory path. Rationale: nothing here needs sub-integer resolution. Per-mille is finer than any quantity being measured — one city on the largest supported map is more than one per-mille — so the fixed-point layer buys nothing and costs a class of rounding bugs in the one subsystem where a rounding bug decides the game.

VC-120 Every fractional quantity MUST be expressed in per-mille (parts per thousand) as an integer in [0, 1000] unless a requirement explicitly permits a larger value. Percentages MUST NOT appear in engine state; they MAY appear in presentation, computed from per-mille by integer division by 10.

VC-130 Every ratio comparison MUST be performed by cross-multiplication, never by division. Where this document writes a comparison such as a / b ≥ c / d, an implementation MUST evaluate a × d ≥ c × b.

VC-140 Every division that appears in a formula in this document MUST be integer division truncating toward zero on non-negative operands, written floor(...), and no formula in this document MAY produce a negative dividend. Where rounding up is intended the formula MUST write ceil(x / y) and an implementation MUST evaluate it as floor((x + y − 1) / y).

VC-150 The Ebb and every other scheduled drift MUST be computed as a closed form of the turn index, never accumulated from turn to turn. Rationale: an accumulated schedule is order-dependent, drifts under save/load, and cannot be evaluated for a future turn — which would break the single most valuable readout in the design, the one that lets a player count backwards to a date (§13.6).

VC-160 Victory computation MUST NOT draw from the seeded PRNG at any Seal. The PRNG MUST be consumed by this subsystem only at map generation, for exactly the schedules named in VC-170, and those draws MUST occur in the fixed order that VC-170 states.

VC-170 At map generation the victory subsystem MUST draw, from a dedicated PRNG stream named victory and in exactly this order: the Ascendancy rotation schedule (§8.6), the Warrant schedule (§11.2), each player's Sealed Orders where enabled (§10.2), and the Horizon jitter offset where enabled (§8.9). The resulting schedules MUST be stored as game configuration and MUST NOT be recomputed during play.

Rationale: fixing the draw order is the whole of the determinism argument for this subsystem. Everything else is a pure function of the board. Recomputation during play is forbidden because a schedule that is derived rather than stored will eventually be derived differently on two machines, and the failure will surface as a desync forty turns after the cause.

VC-180 Victory computation MUST NOT read wall-clock time, entity allocation order, hash-map iteration order, or object identity. Every set iterated during a Seal MUST be iterated in ascending entity sequence number, from the single monotonic counter 10-turn-model.md owns.

VC-190 Every distance this document names — in VC-950, VC-1070, VC-1310, VC-2530, VC-2660 and VC-2950, and in the Landmark and Region placement invariants of §8.4 and §8.5 — MUST be the wrapped Chebyshev distance 01-game-rules.md GR-170 defines, computed from the wrapped minimal displacements of GR-200 under the map's declared topology (GR-190). No requirement in this document MAY use a Euclidean, octile or unwrapped metric.

Rationale: stated once here rather than repeated at six sites, because the failure it prevents is silent. On a cylinder or torus map an unwrapped distance is wrong by up to half the map, and it is wrong in exactly the place where it decides a Bellwether, a Rally target or an elimination proof. GR-170 already claims the whole specification set; this requirement is the acknowledgement that makes the claim checkable here.

3. The Seal — when victory is evaluated

VC-200 Victory MUST be evaluated exactly once per turn, at a single instant called the Seal, and MUST NOT be evaluated at any other time. In particular, victory MUST NOT be evaluated during the Cascade, between two units' activations, or on any change of city ownership.

Rationale: this is the load-bearing requirement of the whole subsystem. 10-turn-model.md orders activation by an Initiative score with creation sequence as the tiebreak. If victory were tested mid-Cascade, a player could win because their unit sorted earlier — and a turn model chosen to reduce waiting would have silently become the turn model that decides games. Sealing once per turn makes victory turn-atomic and wholly independent of activation order. A city captured and recaptured within one turn nets out, which is also the only interpretation a player can hold in their head.

VC-210 The Seal MUST be the last step of a turn: after the Cascade has completed for every unit, and after all end-of-turn resolution — production, Works accrual, Integration, Unrest, supply, repair, upkeep and every other economic step 12-economy.md owns — has completed.

Rationale: the design proposal placed the Seal immediately after the activation queue and left the production step ambiguous. It is placed last here so that Standing is computed on a fully settled board: a city that finished integrating this turn contributes this turn, and "you won at the end of turn 180" means the board as it stood at the end of turn 180. The alternative — sealing before production — would make the score describe a state no player ever sees, which is a legibility failure in the readout that matters most.

VC-220 10-turn-model.md MUST provide the Seal as a single barrier point per turn at which no unit is mid-activation, no order is mid-resolution, and every player's turn has resolved. Where the turn model permits players to advance through the turn at different rates, all players MUST have reached the barrier before the Seal executes.

VC-230 The Seal MUST execute the following steps in exactly this order, and an implementation MUST NOT reorder them:

Rationale for the ordering, since every line of it is a decision. Standing before Tenure because Tenure integrates Standing. Progress before Vigils because a Vigil is a fact about progress. Completion (S8) before Capitulation (S13) so that a player who completes a Track on the same Seal on which an opponent capitulates wins by the Track, and the game does not have to adjudicate a cession that no longer matters. Elimination (S10) after Completion (S9) so an actual win always beats a proof about future wins. Publication last so that everything published describes the sealed state and nothing published is later revised.

VC-240 Every step of VC-230 MUST read only the S1 snapshot and the outputs of earlier steps. No step MAY read the live board.

VC-250 The Seal MUST produce a Seal record containing, for every live player: Standing, Tenure, Seatless state, Broken state, Reduced state, and for every enabled Track the raw progress, the threshold, the ratio (VC-490), the Vigil counter and the visibility band. The Seal record MUST be retained for the whole game and MUST be sufficient to redraw the Board (§13.6) for any past turn without recomputation.

VC-260 The Seal record MUST be included in the canonical state hash 03-architecture.md defines, so that a divergence in victory computation is caught at the turn it occurs rather than at the turn it changes the outcome.

VC-270 Turn numbering MUST begin at turn 1, and the first Seal MUST occur at the end of turn 1. Tenure MUST therefore have exactly t accruals at the Seal of turn t.

VC-280 A player who is not live at a Seal — capitulated, conceded, or eliminated by conquest — MUST be skipped by steps S2 through S12 and MUST retain the Standing, Tenure and placing frozen at the Seal on which they left.

VC-290 No player action taken during the Orders phase MAY be conditioned on the current turn's Seal, and no Seal output MAY be visible to any player before the Seal completes. Rationale: the Seal is the last thing in the turn; a player who could see part of it would be seeing the future of a turn they had already committed to.

VC-300 Victory MUST be able to be achieved on any Seal from turn 1 onward. No Track MAY carry a minimum turn before it can complete except where its own definition states one. Rationale: an artificial floor is a second, hidden clock. If a Track can be completed on turn 12 the answer is to configure a Track that cannot, not to forbid the outcome.

VC-310 The Seal MUST complete within 8 ms on the project's reference hardware for a game of 8 players, 256 cities and 3,200 units, excluding the reach-bound computation of VC-2270 which is separately bounded by VC-2880.

VC-320 All state this document defines MUST reach the simulation through the authoritative order log and MUST NOT enter by any other path. The player-issued orders this document defines are exactly: DesignateSeat, DesignateWorkSite, SelectCharter, CastVerdictVote, Concede, and ClaimWarrant where a Warrant requires an explicit claim. Rationale: 13-command.md CM-2040 states the same rule for the command layer, and for the same reason — a replay that does not contain the concession cannot reproduce the game.

VC-330 A game MUST be resumable from a save at any turn boundary with byte-identical subsequent victory behaviour, and the Seal records of past turns MUST survive save, load and replay unaltered.

4. The Track abstraction

Fourteen conditions, one shape. The uniformity is worth more than the expressive freedom it costs, because it buys one readout, one combination rule, one estimator, one linter and one AI evaluator.

4.1 The schema

VC-350 Every victory condition MUST be a Track, and a Track MUST be fully described by the following fields. No condition MAY be admitted to the catalogue that requires a field not in this list.

VC-360 A Track's kind MUST be exactly one of:

VC-370 Every Accumulative Track MUST declare an integer maxGainPerSeal that is a sound upper bound on the progress any player may gain at one Seal, and that bound MUST be computable at setup from the map and the configuration alone. Rationale: this bound is the entire basis of the provable early end in §14.3. A Track that cannot state it is not Accumulative, whatever its progress looks like.

VC-380 progress MUST be a pure function of the sealed board state, the player, and the turn index. It MUST NOT depend on any player's knowledge view, on the order in which cities changed hands, or on any prior Seal except through state the board itself carries.

VC-390 threshold MUST be a pure function of the turn index and the game configuration, and MUST be evaluable for any turn index in [1, H] at any time, including turns in the future. Rationale: the Board's descending-Ebb line and the "count backwards to a date" readout (§13.6) are the single most valuable legibility feature in the design and they require this. A threshold that can only be evaluated for the current turn cannot be drawn as a schedule.

VC-400 threshold(t) MUST be non-increasing in t for every Track. A threshold MUST NOT rise. Rationale: a rising bar is a game that gets harder to end the longer it runs, which is the stalemate failure F3 with extra steps.

4.2 Satisfaction and completion

VC-410 A Track is satisfied for player p at the Seal of turn t iff progress(p, t) ≥ threshold(t).

VC-420 A Track is completed by player p at the Seal of turn t iff it has been satisfied for p at each of the Seals t − vigil + 1 through t inclusive, and p was live at every one of them.

VC-430 Completion MUST be tested at step S8 of the Seal (VC-230) and nowhere else.

VC-440 A player who is Seatless (§8.14) MAY satisfy and complete Tracks normally. Rationale: Seatless already costs half of Tenure accrual, which is a severe and sufficient penalty. Forbidding victory outright would make one lucky raid on a capital a game-ending move, which is the opposite of the counterplay the Vigil exists to create.

4.3 Enabling, disabling and parameters

VC-450 Every Track except Last Standing (T3) MUST be individually enableable and disableable at setup. Last Standing MUST always be enabled and MUST NOT be disableable. Rationale: if one player remains, they have won. A configuration in which the last surviving player has not won is not a game, it is a bug with a settings screen.

VC-460 Enabling a Track MUST NOT change the parameters of any other Track. The only cross-Track effects permitted are the setup linter's advisory messages (§12.4) and the forced settings a Track's own catalogue entry names.

VC-470 Every Track parameter MUST have a stated default, a stated legal range, and a stated effect on estimated game length. A parameter MUST NOT be settable outside its legal range by any UI, save file or scenario definition; a value outside the range MUST be rejected at load with a named error.

4.4 Progress in natural units, ratio for the readout

VC-480 A Track's progress and threshold MUST be expressed in the same natural unit — cities, per-mille of cities, Landmarks, Regions, points, or accumulated Works — and completion MUST be tested in that unit. Ratios MUST NOT be used to test completion. Rationale: testing in natural units means the test is exact and the boundary is where a player expects it. Testing in a derived ratio would put the boundary at a rounding artefact.

VC-490 The ratio of a Track for player p at turn t MUST be ratio(p, t) = floor(1000 × progress(p, t) / threshold(t)), computed without clamping. The ratio MUST be used for the readout, the visibility bands (§13.2) and the Watch bar, and MUST NOT be used for any completion test.

Rationale: one number in one unit across fourteen conditions with utterly different natural units is what makes a single forty-pixel strip legible. A player who has learned to read the Dominion bar has learned to read every bar in the game, including ones they have never enabled. The ratio is deliberately unclamped so that a player who is well past a threshold and holding a Vigil reads as such rather than as pinned at 1000.

5. Standing and Tenure

Two integers. Standing is power now; Tenure is power integrated. Every ambiguity in this document resolves to Tenure, which is one rule instead of a precedence table and means the same thing every time: the player who has been ahead the longest.

5.1 What Standing counts

VC-500 Standing MUST be an integer computed for every live player at step S2 of every Seal, from exactly the five components in VC-510 and no others.

VC-510 The Standing components MUST be exactly:

VC-520 citiesHeld(p) MUST be the number of cities whose owner at the Seal snapshot is p. A besieged, blockaded, contested or Unsettled city MUST count as held by its owner. Neutral and Free Cities MUST count as held by nobody and MUST remain in the map's city total.

VC-530 output(p) MUST be the integer sum, over cities held by p, of each city's effective Works per turn as 12-economy.md defines it — that is, after the Integration scaling and any city-trait modifiers, and zero for an Unsettled city.

Rationale: using effective rather than base Works is what makes Standing describe an empire that has been governed rather than one that has merely been overrun. A player who has taken forty cities in fifteen turns and integrated none of them scores their cities but not their industry, which is precisely the true picture.

VC-540 The military component MUST be min( floor(Σ worksCost(u) / 4 over units u of p that are in supply), floor(civil × 250 / 1000) ), where civil is the sum of the first four components of VC-510.

VC-550 A unit not in supply, as 12-economy.md defines supply, MUST contribute zero to the military component. Units under construction MUST contribute zero.

VC-560 Standing MUST be civil + military and MUST be ≥ 0 for every live player.

Rationale for the whole table, since these five numbers set the meaning of every tiebreak in the document. The ratios matter more than the absolutes: a Landmark is worth two and a half ordinary cities, a Seat is worth three, and an empire producing 20 Works a turn is worth one extra city on the board. Those are the trades this design wants players to make. The military divisor of 4 and the 250‰ cap are the two least defensible numbers here and are named as open question 2 below; the cap exists so that the largest army a player can field adds at most a quarter to their score, which keeps Standing a statement about territory with an army term rather than the reverse.

5.2 Worked Standing, normative as a test vector

VC-570 A conforming implementation MUST reproduce the following computation exactly. Red at the Seal of turn 178 on the reference map holds 27 cities of which 2 are Landmarks, holds his own Seat and a captured rival's Seat, produces 132 effective Works per turn, and has 38 units in supply with a total Works cost of 1,180.

cities        27 × 100                                    =  2700
Landmarks      2 × 150                                    =  + 300
Seats          2 × 200                                    =  + 400
output       132 ×   5                                    =  + 660
                                            civil subtotal =  4060
military     floor(1180 / 4)              = 295
             cap = floor(4060 × 250 / 1000) = 1015
             min(295, 1015)                                =  + 295
                                                  Standing =  4355
                          Tenure accrual = floor(4355/100) =    43

5.3 The reference map

VC-580 This document's worked examples and test vectors MUST use the reference map: 48 cities, 5 Landmarks, 8 Regions, 4 players, Horizon 200, maximum map potential Works output 240. Any requirement stating a number "on the reference map" MUST be reproducible from these values. The Landmark and Region counts MUST be reproducible from the generation formulas rather than merely asserted: MAP_CITIES = 48 places the map in class Medium (VC-2040), giving L = 5 by VC-1081, and, with M0 = floor(51 / 6) = 8, M = min( floor(48 / 2), max( max(3, 4), min(24, 8) ) ) = min(24, 8) = 8 by VC-1031.

VC-590 The map's maximum possible Standing Smax MUST be computed once at setup as:

civilMax = 100 × MAP_CITIES + 150 × MAP_LANDMARKS + 200 × PLAYERS + 5 × MAP_POTENTIAL_OUTPUT
Smax     = civilMax + floor(civilMax × 250 / 1000)

On the reference map: civilMax = 4800 + 750 + 800 + 1200 = 7550; Smax = 7550 + 1887 = 9437.

VC-600 MAP_POTENTIAL_OUTPUT MUST be the sum over every city on the map of that city's effective Works at Integration 100 with its traits applied, and MUST be supplied by 12-economy.md as an integer constant of the generated map.

5.4 Tenure

VC-610 Tenure MUST accrue at step S3 of every Seal. For a live player who is not Seatless, the accrual MUST be floor(Standing / 100). For a live player who is Seatless (§8.14), the accrual MUST be floor(Standing / 200).

VC-620 Tenure MUST be the running sum of accruals and MUST NOT decrease for any reason. Tenure MUST NOT be reset, spent, transferred or reduced by any mechanism in this or any other document.

Rationale: monotonicity is not a stylistic choice, it is what makes §14.3's early end a proof rather than a heuristic. Because Tenure only rises and the per-Seal gain is bounded above by floor(Smax / 100), the engine can compute exactly whether a trailing player is still able to reach the leader. Give Tenure a single decreasing case and the elimination arithmetic becomes unsound, and the most valuable mechanism in the endgame becomes a guess.

VC-630 maxTenurePerSeal MUST be floor(Smax / 100) and MUST be computed once at setup. On the reference map it is 94.

VC-640 Tenure MUST integrate current state, never peak state. A player MUST NOT be able to bank a strong turn 40 and coast on it.

VC-650 Tenure MUST freeze at the Seal on which a player capitulates or concedes, and MUST NOT accrue thereafter. A seat taken over by an AI substitute (VC-3060) MUST continue to accrue Tenure normally.

Rationale: this pair is the anti-quit rule and it is provable, not exhortative. Accrual is floor(Standing/100) ≥ 0 always, and ≥ 1 for any player holding a single city. Therefore a player's final Tenure — and so their final placing (§16) — is non-decreasing in the number of Seals they survive, and quitting can never improve it. The design does not ask a losing player to stay for the good of the table; it makes staying weakly dominant on the only scoreboard the game keeps.

6. The Vigil

A Track does not win the instant you cross it. It wins when you have held it across V consecutive Seals, in public, while everyone knows exactly what you are holding and why.

VC-670 Every Track MUST carry an integer vigil in [1, 12]. A Track with vigil = 1 MUST win on the Seal at which it is first satisfied.

VC-680 A player's Vigil counter for a Track MUST be incremented by 1 at step S5 of a Seal at which the Track is satisfied for that player, and MUST be set to zero at any Seal at which it is not.

VC-690 Vigil failure MUST reset the counter to zero and MUST NOT decrement it, under the default setting Vigil Failure: Reset.

Rationale, and this is the design's chosen answer to a question the proposal left open. Reset creates a deliberate and necessary asymmetry: the leader must be airtight for V consecutive turns while the challenger needs exactly one successful attack. That asymmetry is the visible, attackable anti-snowball brake the direction document asks for in place of an invisible production tax, and it is the primary comeback instrument in §15. Decay to V−1 softens the leader's risk and therefore softens the only thing that makes a challenger's raid worth mounting; it converts the endgame from "can you break them once" into "can you break them every turn", which favours the stronger player. Reset is chosen for that reason and not because it is more dramatic.

VC-700 The setting Vigil Failure MUST offer exactly Reset (default) and Decay, where Decay decrements the counter by 1 to a floor of zero instead of resetting it. The setting MUST be a single game-configuration integer so that the two variants can be compared by replaying an identical seed under each.

VC-710 Vigils MUST be independent and concurrent. Two or more players MAY hold non-zero Vigil counters on the same Track at the same Seal, and one player MAY hold non-zero counters on several Tracks at once.

VC-720 A Vigil counter MUST be reset to zero if the Track is disabled mid-game by a scenario event, if the player capitulates or concedes, or if the player becomes not-live for any reason.

VC-730 Every Track whose kind is Threshold MUST have vigil ≥ 2, and MUST publish a non-empty sites set whenever any player's Vigil counter for it is non-zero.

Rationale: a Threshold Track with vigil = 1 is a win that arrives without warning at an address nobody can find, which is failure F4 in its purest form. Requiring both the countdown and the address is what turns crossing a threshold into an announcement of a battle.

VC-740 A Track with vigil = 1 MUST publish its progress at full precision, unbanded, to every player from the Seal at which any player's ratio for it first reaches 500.

Rationale: the four Tracks that legitimately want vigil = 1 — Every Last City, Last Standing, Ascendancy and the Great Work — each have their own long, visible build-up in place of a countdown. This requirement makes that build-up a rule rather than an accident of their design, so that no vigil = 1 Track can ever be a surprise.

VC-750 The engine MUST expose, for every player and every enabled Track, the integer pair (vigilCounter, vigil), and MUST publish it to every player whenever vigilCounter ≥ 1 (§13.2, Alarm band).

VC-760 A completed Vigil MUST resolve at the Seal on which the counter reaches vigil and MUST NOT be deferred, extended or re-tested. Rationale: "you won, but hold it one more turn to be sure" is a rule nobody can plan around.

7. The Ebb

The published schedule by which threshold Tracks descend toward their uniqueness floor. It guarantees termination, it breaks stalemates, and — the part that matters most — because it is published from turn 1, a player can count backwards from their current holdings to a date.

VC-780 Every Threshold Track MUST declare a uniqueness floor: the least threshold value at which at most one player can be satisfied simultaneously. A Track's threshold MUST NOT descend below its floor.

VC-790 The uniqueness floors MUST be:

Rationale: 501 and not 500. At exactly 500‰ two players can tie, and they will tie precisely at the moment the game is trying to end, which is where a tie is most expensive. One per-mille of headroom removes an entire class of edge case at the point where it is most likely to occur, and costs nothing anyone will ever notice.

VC-800 Where a Track's ebb schedule is enabled, threshold(t) MUST be:

threshold(t) = start                                                        for t < Ds
threshold(t) = max( floor_, start − floor( (start − floor_) × (t − Ds) / (H − Ds) ) )   for t ≥ Ds

where start is the Track's configured starting threshold, floor_ its uniqueness floor, Ds the configured Ebb start turn, and H the Horizon.

VC-810 Ds MUST default to floor(6 × H / 10) and MUST be settable in [1, H − 1]. On the reference map the default is turn 120.

VC-820 The Ebb MUST reach the floor exactly at t = H, and MUST hold at the floor for t > H where the Horizon has been disabled.

VC-830 The complete Ebb schedule MUST be published to every player from turn 1 as an evaluable function, and the Board (§13.6) MUST draw it as a descending line over the whole game.

VC-840 For each player, the Board MUST publish the earliest future turn at which that player's current progress would satisfy each enabled Ebbing Track, or state that no such turn exists before the Horizon. This value MUST be computed by evaluating threshold(t) forward from the current turn, and MUST be recomputed at every Seal.

Rationale: this is the "count backwards to a date" readout and it is the single most valuable object the Ebb produces. It converts a fog-of-war conquest game — which normally cannot tell you when anything will happen — into a game with a scheduled endgame on a known day. "I hold 26 cities; the bar reaches me on turn 178; I need to survive twelve more turns" is a sentence a player can build a plan around, and it is available to their opponents at the same precision, which is what makes it a plan rather than a secret.

VC-850 The Ebb schedule MUST be identical for every player. There MUST NOT be a per-player threshold under any setting other than Charters (§10), where the Track itself is per-player.

VC-860 A Chronicle entry of class EbbStep MUST be emitted at every Seal at which any enabled Track's threshold differs from its value at the previous Seal, naming the Track, the new threshold, and the equivalent in natural units.

VC-870 Worked Ebb, normative as a test vector. On the reference map with start = 625, floor_ = 501, Ds = 120, H = 200, a conforming implementation MUST produce:

"Cities of 48" is ceil(D(t) × 48 / 1000), the least integer city count that satisfies the threshold.

8. The Track catalogue

VC-880 The catalogue MUST consist of exactly the fourteen Tracks below and no others. A Track not in this table MUST NOT be selectable at setup. Adding a Track to the catalogue MUST require adding a row here, a progress function, a threshold function, and a calibration cell (§12.3).

VC-890 "Est. turns" in VC-880 MUST be the shipped fallback estimate used by the setup screen when the calibration table (§12.3) has no cell for the current map class and player count. It MUST NOT be used when a calibration cell exists.

8.1 T1 — Dominion

Hold more than half the world, plus a share.

VC-900 Dominion's progress MUST be floor(1000 × citiesHeld(p) / MAP_CITIES), its natural unit per-mille of map cities, and its denominator MUST be MAP_CITIES.

VC-910 Dominion's starting threshold MUST be D_start = 500 + floor(500 / P), where P is the number of player seats at setup, including AI seats. It MUST be overridable at setup in [501, 1000].

Rationale: the formula is chosen because a player can say it out loud — half the world, plus a share — and because scaling with player count is necessary. A flat 60 percent is trivial in a duel and near-impossible at eight players, so a fixed number would mean the same setting produced two different games. Deriving the bar from the seat count keeps the phrase "more than everyone else could plausibly split" true at every table size.

VC-920 MAP_CITIES MUST be published to every player from turn 1, including cities whose locations are unknown and cities that are neutral.

Rationale: you always know the size of the pie and never where the slices are. Without a public denominator the progress bar is not merely imprecise, it is meaningless — a player cannot tell whether 22 cities is a third of the map or nine tenths of it. Hiding a single map-level scalar buys no fog of any value; hiding the locations, which the design does, buys all of it.

VC-930 Dominion MUST Ebb per §7 with floor_ = 501 and Ds per VC-810.

VC-940 Dominion's vigil MUST default to 3 and be settable in [1, 12].

VC-950 Dominion's sites MUST be its Bellwether set: let need = ceil(threshold(t) × MAP_CITIES / 1000) and margin = citiesHeld(p) − need. The Bellwether set MUST be the min(8, margin + 1) cities held by p with the smallest Chebyshev distance to the nearest city not held by p, ties broken by ascending city sequence number.

Rationale: the Alarm must hand every player the address of the fight (§13.4), but publishing the garrisons of all twenty-seven of a leader's cities is not an address, it is the leader's whole order of battle. The Bellwether rule publishes exactly as many sites as an attacker must take to break the Vigil, plus one, capped at eight — enough to plan an operation, not enough to plan a campaign. Selecting by frontier distance rather than by garrison weakness is deliberate: the frontier is where a counterattack would go anyway, whereas "your softest city" would make the Alarm a targeting service rather than a warning.

VC-960 Dominion MUST raise setup linter check L3 (§12.4) when MAP_CITIES < 24 and vigil ≥ 3. Rationale: on an 18-city map one city is 56‰, so a single capture moves the bar by more than a fifth of the Ebb's entire travel and Vigils thrash. The Track is not wrong; the map is too small for it.

8.2 T2 — Every Last City

VC-970 Every Last City's progress MUST be citiesHeld(p), its threshold MAP_CITIES, its vigil 1, and it MUST NOT Ebb.

VC-980 Enabling Every Last City MUST force Capitulation: Aggressive (§14.2) and MUST display a plain warning on its setup card stating the expected length and that the mercy rule is being forced on.

VC-990 Every Last City MUST be exempt from VC-060's event-cadence requirement.

Rationale: this Track is the thing the rest of the design spends its effort refusing to make you do, and it stays in the catalogue because some players want it and are entitled to it. Being honest about its cost on the card is better than pretending it does not exist, and forcing Aggressive Capitulation is the least that can be done to keep the ending finite.

8.3 T3 — Last Standing

VC-1000 Last Standing's progress MUST be 1 for player p at a Seal iff no other player is live at that Seal, and 0 otherwise. Its threshold MUST be 1 and its vigil MUST be 1.

VC-1010 Last Standing MUST always be enabled and MUST NOT be disableable (VC-450).

VC-1020 Where all live players would simultaneously become not-live at the same Seal, the winner MUST be resolved by the tie chain of VC-1520 among the players who were live at the previous Seal. Rationale: mutual annihilation is unlikely but must not produce a game with no winner and no record.

8.4 T4 — Hegemony, and Regions

VC-1030 01-game-rules.md MUST partition the map into M named, disjoint Regions at generation, MUST assign every city on the map to exactly one of them, and MUST designate one city of each Region as that Region's regional capital. Region membership, the set of Regions, and the regional capital designation MUST be fixed at generation and MUST NOT change for the life of the game by any mechanism, including capture, neutralisation (01-game-rules.md GR-960), abandonment (GR-970), cession as a Free City (VC-2560), or the Unsettled state (VC-2550).

Rationale: immutability is not tidiness, it is the precondition for Hegemony being a Track at all. VC-380 requires progress to be independent of the order in which cities changed hands and VC-390 requires threshold to be a pure function of the turn index; both fail the moment the partition can move. A regional capital that migrated to "the largest city the Region's dominant player still holds" — the obvious thing to reach for — would make the Region hold Warrant of VC-1810, the Bellwether set of VC-1070 and the ordering of VC-1033 all history-dependent, and the Board of VC-2400 could no longer be redrawn for a past turn from a Seal record. The Region is scaffolding: it is generated once, published once, and never argued with again.

VC-1031 M MUST be computed at generation as:

M0 = floor( (MAP_CITIES + 3) / 6 )
M  = min( floor(MAP_CITIES / 2), max( max(3, P), min(24, M0) ) )

where P is the number of player seats including AI seats. M MUST be overridable by a scenario in [3, 32] subject to VC-1032. On the reference map (48 cities, 4 players) M is 8.

Rationale for roughly six cities to a Region: M does not change how much of the map Hegemony asks for — that is K_start / M, near five eighths at every scale — it changes the granularity of the ask. Very few, very large Regions make progress an all-or-nothing lump nobody can move; very many, very small ones make Hegemony converge on Dominion and forfeit the reason both are in the catalogue. A Region of about six cities is a campaign season's work: large enough that clearing one is an operation, small enough that losing one city visibly costs a whole Region. The max(3, P) floor exists so that every seat can plausibly own a Region on a crowded map, and the floor(MAP_CITIES / 2) cap is what keeps VC-1032's two-city minimum satisfiable.

VC-1032 Every generated map MUST satisfy all of the following, as generator invariants in the sense of 01-game-rules.md GR-1560 — retried against the next PRNG state and then failed loudly, never emitted in violation:

Rationale for R6 and the obvious construction that satisfies most of these at once: choose M well-separated seed cities that are not start cities, preferring Landmarks where R8 requires it, make each the capital of its Region, assign every tile to the Region of the nearest seed under VC-190 with ties by ascending capital sequence number, and assign each city to the Region of its tile. That is a Voronoi partition; it is connected by construction, it covers the map by construction, and its boundaries follow distance rather than terrain, which is what makes R6 free. R2 and R3 are the two it does not give away, and they are what the retry budget is for. This document does not mandate the construction — 01-game-rules.md owns the algorithm — it states the eight properties the Track reads and notes that one cheap construction delivers six of them.

VC-1033 Every Region MUST carry a Region index in [0, M − 1], assigned as the ascending rank of its regional capital's city sequence number (01-game-rules.md GR-050). Every ordering in this document that says "ascending Region index" — VC-1070, VC-2310, and the Board's Region readout — MUST use it, and it MUST be stable across save, load and replay.

VC-1034 Publication of Regions MUST be exactly the following, from turn 1, to every player, independent of fog:

Publishing a Region, a boundary or a regional capital MUST NOT mark any tile Explored in the sense of 01-game-rules.md GR-070, MUST NOT write to any player's Terrain Record (GR-1140), and MUST NOT cause a city ownership announcement under GR-1430. A player learns who holds a Region's cities only by observation, by GR-1430 where they have explored the tile, or through a grant this document enumerates in VC-070.

Rationale: this is VC-920's bargain applied one level down — you always know the size of the pie and the names of the plates, never where the slices are. The per-Region city count is the part that makes Hegemony legible without a fog concession: a player who holds four cities of Vantar and knows Vantar has six knows exactly what the Track is asking of them and roughly where the other two must be, which is a plan. Publishing which cities those are would hand every player a free map of a third of the world. The distinction is worth the extra table row because the tempting implementation — "mark the published tiles as explored, it's simpler" — silently deletes the exploration game.

VC-1035 A change of a city's owner MUST NOT change its Region, its Region's city count, its Region's capital designation, or M. Capturing a regional capital MUST NOT by itself confer Hegemony progress, MUST NOT confer Standing beyond the ordinary city term of VC-510, and MUST NOT alter any threshold. Because 01-game-rules.md GR-830 and GR-960 forbid destroying a city, M and every Region's city count MUST be constants of the game, and no requirement in this document MAY provide for their revision.

VC-1040 Hegemony's progress MUST be the number of Regions in which player p holds every city, and its denominator MUST be M. A Region containing any city not owned by p at the Seal snapshot MUST NOT count, and that includes neutral cities, Free Cities created by VC-2560, and Unsettled cities held by another player. A city held by p and Unsettled under VC-2550 MUST count as held (VC-520).

Rationale: neutral cities counting against the holder is deliberate and it is what stops Hegemony being an accident. A Region is not "the part of the map nobody contests you in", it is a Region you have actually taken, neutral garrisons included. It also keeps the Track honest against VC-520, which already fixes that a neutral city is held by nobody, so no separate reading of "fully held" is possible.

VC-1050 Hegemony's starting threshold MUST be K_start = ceil(5 × M / 8), settable in [floor(M/2) + 1, M]. Its uniqueness floor MUST be floor(M / 2) + 1. Where K_start equals the floor, Hegemony MUST NOT Ebb, and the Terms paragraph MUST omit its Ebb clause (VC-1960, clause 2).

Note, stated so that no reader is surprised by it: at the default K_start the two coincide for every M ≤ 8, so on Skirmish and Medium maps Hegemony does not Ebb and its termination is carried by the Horizon (VC-1320), the Verdict (§14.5) and the reach bound (VC-2670). VC-880 lists Hegemony's Ebb as "yes" because it Ebbs at every M ≥ 9. This is a calibration question rather than a defect and it is open question 13.

VC-1060 Hegemony's vigil MUST default to 4.

VC-1070 Hegemony's sites MUST be built by walking the Regions p fully holds in ascending Region index (VC-1033) and emitting, for each, first that Region's regional capital and then that Region's frontier city — the city of the Region with the smallest distance (VC-190) to the nearest city not held by p, ties broken by ascending city sequence number — omitting the frontier city where it is the capital, and stopping at 8 sites in total.

Rationale for publishing the capital first: it is the one city of the Region every player has known by name since turn 1, so it is the address a challenger can act on without first having to be told which of six anonymous towns matters. The frontier city is the address a challenger should act on, because it is where a counterattack would arrive anyway. Publishing both, capital first, means the Alarm is legible at a glance and useful on inspection, which is the same division of labour the Watch and the Board have.

Rationale for the Track's existence: Hegemony is a genuinely different strategic shape from Dominion and that is the only reason both are in the catalogue. A player holding 55 percent of the cities scattered opportunistically across every border has zero Regions. Dominion rewards breadth; Hegemony rewards clean borders and consolidation. A setup enabling both asks the player to choose a doctrine, which is what a victory system should be doing. Its legibility is also unusually good: the map paints each Region by completeness, so a Region at seven of eight is visibly, achingly close to everyone at once.

8.5 T5 — The Keys, and Landmarks

VC-1080 01-game-rules.md MUST seed L Landmarks at generation. A Landmark MUST be a city — it MUST NOT be an open-terrain site, an Installation, a tile marker, or any object other than one of the cities 01-game-rules.md GR-820 defines — and it MUST carry a Landmark marker on that city. Its name MUST be the city's own name under GR-840; a Landmark MUST NOT carry a second name.

Rationale for insisting rather than permitting: three separate requirements in this document read a Landmark as a city and break outright if it is anything else. VC-510 pays +150 Standing for "each held city that is a Landmark" and has no term for holding a tile; VC-1100 counts "Landmarks held by p", which requires an owner, which only a city has; and VC-1210 requires the Great Work's Work Site to be a Landmark held by that player, which requires it to be capturable, garrisonable and productive. A Landmark on open ground would be a victory object carrying its own ownership, capture and garrison rules, and GR-010 forbids a sixth kind of thing occupying space on the map.

VC-1081 L MUST be computed at generation as the default for the map's class under VC-2040, reduced where necessary by the availability cap, and MUST always be odd:

The availability cap MUST be the greatest odd integer not exceeding floor( (MAP_CITIES − startCities × P) / 2 ), where startCities and P are 01-game-rules.md's setup parameters (GR-1480, GR-1500). Where the cap is lower than the class default, L MUST be the cap. Where the cap is below 3, L MUST be 0, the map MUST carry no Landmarks, and enabling any Landmark Track on it MUST raise linter check L8 as an Error (§12.4). L MUST be overridable by a scenario to any odd value in [3, 11] not exceeding the cap. On the reference map L is 5.

Rationale: L is set from the map's city count and not from the seat count because a Landmark is a property of the world, not of the table — the same map should present the same Landmarks to two players or to eight, and it is the Keys threshold (L+1)/2 that already scales the ask. L is odd for the reason VC-1110 gives: an odd L makes (L+1)/2 a strict majority and therefore a uniqueness floor with no Ebb and no tie. The availability cap exists because a map on which most cities are Landmarks is a map on which the Landmark bonus of VC-510 has replaced the city term, and because the cities L draws from must not include the start cities that VC-1082 K1 protects.

VC-1082 Every generated map MUST satisfy all of the following, as generator invariants in the sense of 01-game-rules.md GR-1560. Let S = floor(minStartSeparation / 2), where minStartSeparation is the parameter of GR-1480 and GR-1580.

Rationale: these five are the difference between the Keys being a race and the Keys being an allocation. They are stated here rather than left to 01-game-rules.md's judgement because they are not general map-fairness properties — GR-1610 already balances cities and land within a radius and would pass every map these five reject. They are properties that only a document that knows what the Keys asks for could think to require.

VC-1083 At turn 1 every Landmark MUST be unowned, and MUST carry whatever neutral garrison the neutralDefence parameter of 01-game-rules.md GR-990 specifies, exactly as any other neutral city does. A Landmark MUST NOT receive a garrison, a defensive term, a production bonus or a vision radius that an otherwise identical non-Landmark city would not receive.

Rationale, and this corrects an overreach in this document's earlier text, which spoke of "the defensive terrain advantage the map generator assigns it". VC-070 forbids the victory system from conferring any combat, movement, vision, production or economic advantage outside its enumerated list, and a Landmark marker that made a city harder to take would be exactly such a grant, conferred permanently, on the one city everyone must attack. The generator MAY prefer defensible ground when choosing which cities to mark — GR-850 already restricts cities to terrain that is not Mountains, Marsh or Icefield, and GR-380 already values the rest — but the advantage must come from the terrain, which every player can read, and not from the marker, which is a victory object.

VC-1084 Every Landmark MUST carry a Landmark index in [0, L − 1], assigned as the ascending rank of its city's sequence number (01-game-rules.md GR-050). It MUST be the index the Ascendancy rotation schedule of VC-1180 draws, and it MUST be stable across save, load and replay. A Landmark's marker and index MUST NOT move, MUST NOT be conferred on another city, and MUST NOT be removed, for the life of the game. Because 01-game-rules.md GR-830 and GR-960 forbid destroying a city, L MUST be a constant of the game. A Landmark that becomes neutral by GR-960 or GR-970, or a Free City by VC-2560, MUST remain a Landmark and MUST count for no player (VC-520).

VC-1085 A Landmark MAY be designated a Seat under VC-1450 or re-Seated to under VC-1470 once its designating player holds it and it satisfies those requirements. Where a player holds a Landmark that is also their Seat, the Standing terms of VC-510 MUST both apply, for 100 + 150 + 200 = 450.

Rationale: permitted explicitly so that nobody implements it as an error. It is a real and interesting choice with its own price — the Seat is the one city whose loss makes a player Seatless under VC-1460, and putting it on the map's most publicly contested tile is a wager, not an exploit. The Standing terms stack because they are counting three different true things about the same city.

VC-1090 Every Landmark's name and tile MUST be public to every player from turn 1, independent of fog. Its owner, garrison, Integration, production, surrounding cities and surrounding terrain MUST NOT be published by this rule. Publishing a Landmark MUST NOT mark its tile Explored in the sense of 01-game-rules.md GR-070, MUST NOT write to any player's Terrain Record (GR-1140), and MUST NOT cause a city ownership announcement under GR-1430. A player learns who holds a Landmark only by observation, by GR-1430 where they have explored its tile, or through a grant this document enumerates in VC-070 — the Alarm's Bellwether vision (VC-2290) or the Rally's Survey (VC-2950).

Rationale, and this is a deliberate departure from fog purity that the design defends directly: fog exists to hide what your opponent is doing, not what the world is. A general knows there is a mountain pass called the Iron Gate; he does not know who is marching to it. Publishing the Landmarks is what lets the game have known battlefields, and known battlefields are the most effective anti-tedium device available — the war has an address before the war starts, and every player can plan toward it from turn 1. It is also what makes the setup screen's estimated lengths mean anything, because the map's contested points are known quantities rather than emergent accidents. The exploration clause is the boundary of the concession and it is the part most likely to be implemented wrongly: marking the tile Explored would be simpler and would hand every player the terrain around every Landmark on turn 1, which is a different and much larger decision than the one made here.

VC-1100 The Keys' progress MUST be the number of Landmarks held by p, its denominator L, its threshold K = (L + 1) / 2, settable in [(L+1)/2, L].

VC-1110 The Keys MUST NOT Ebb, because (L+1)/2 is already the uniqueness floor for an odd L.

VC-1120 The Keys' vigil MUST default to 6, settable in [1, 12]. Rationale: Keys should be fought over for a while, not sniped. Six turns is long enough that a player who takes the third Landmark must then hold three separate publicly known places against everyone for most of a campaign season, which is the intended shape of the fight.

VC-1130 The Keys' sites MUST be exactly the Landmarks held by p, in ascending city sequence number.

8.6 T6 — Ascendancy

VC-1140 At any turn exactly A of the L Landmarks MUST be Lit, where A defaults to 3 and is settable in [1, L − 1].

VC-1150 The Lit set MUST rotate every RotP turns, where RotP defaults to 12 and is settable in [4, 40]. Rotation r (for r = 1, 2, 3, …) MUST cover turns (r − 1) × RotP + 1 through r × RotP inclusive.

VC-1160 A Tally MUST occur at step S6 of the Seal of turn r × RotP for every r ≥ 1 with r × RotP ≤ H. At each Tally, every live player MUST gain 1 Ascendancy point per Lit Landmark they hold at that Seal.

VC-1170 Ascendancy's progress MUST be the player's accumulated Ascendancy points, its threshold 7 (settable in [3, 40]), its vigil 1, and its maxGainPerSeal A.

VC-1180 The full rotation schedule MUST be drawn at map generation per VC-170 and stored. For each rotation, A distinct Landmark indices MUST be drawn from the range 0 to L − 1. A Landmark MUST NOT be Lit in more than 2 consecutive rotations; a draw violating this MUST be resampled, with at most 16 resample attempts, after which the constraint MUST be relaxed for that rotation only and the relaxation recorded in the stored schedule.

Rationale: the consecutive-rotation cap is what stops Ascendancy from degenerating into fortress-squatting on one lucky Landmark. The bounded resample with a recorded relaxation is there because an unbounded rejection loop is a determinism hazard and a hang risk on a pathological A/L pair; recording the relaxation means the schedule is reproducible from the stored data rather than from the algorithm.

VC-1190 The rotation schedule MUST be published to every player two rotations ahead — that is, at any turn during rotation r, the Lit sets for rotations r, r + 1 and r + 2 MUST be public. Rotations beyond that MUST NOT be published.

Rationale: this is the design's metronome and the reason this Track earns its place. Sixteen Tallies in a 200-turn game, each one a known place on a known date, twenty-four turns of warning. It manufactures scheduled crises without a random event system, it rewards operational mobility over fortification, and it makes turtling actively lose. Two rotations rather than the whole schedule because a player should be able to plan a campaign, not the whole war, from the calendar.

VC-1200 The Board MUST present the published rotations as a Tally calendar naming each Landmark, the turns it is Lit, and its current owner where known to the viewing player.

8.7 T7 — The Great Work

VC-1210 A player MAY designate one Work Site by the DesignateWorkSite order. The Work Site MUST be a Landmark held by that player at the Seal on which the order takes effect. A designation naming any other city MUST be rejected.

Rationale: the constraint is what saves this Track from being the worst failure mode in the catalogue. Allowed anywhere, a player builds it in a far corner of a large map, nobody can reach it, and the game becomes an unreachable inevitability — exactly the thing this document exists to eliminate. On a Landmark it is public, central, and defensible but attackable.

VC-1220 Great Work progress MUST be the accumulated integer Works contributed to the Work Site. Its threshold MUST be 900, settable in [200, 4000], its vigil 1.

VC-1230 Contribution MUST be capped at WorkRate = 30 Works per turn in total, settable in [5, 200], so that the Track has a hard minimum length of ceil(threshold / WorkRate) turns — 30 turns at the defaults. The Great Work's maxGainPerSeal MUST be WorkRate.

VC-1240 Great Work progress MUST be visible to any player who has observed the Work Site, and MUST become public to every player at the first Seal at which progress reaches floor(threshold / 2).

VC-1250 If the Work Site changes owner, then at the following Seal: the captor MUST gain nothing; the builder's stored progress MUST be set to floor(stored / 2); the builder MUST be forbidden from designating a new Work Site for 5 turns; and a Chronicle entry MUST record the capture and the new stored value.

Rationale: total loss of a thirty-turn investment is too swingy and will make nobody build one; zero loss makes capturing the site pointless. Half is the compromise and there is no principled defence of the exact fraction — it is named in the open questions as a calibration target.

VC-1260 The Great Work MUST be classified Accumulative for elimination purposes (§14.3). Its progress MAY decrease by VC-1250 only, and such a decrease MUST NOT invalidate the elimination bound, which uses current progress plus remainingTurns × WorkRate.

VC-1270 The Great Work's sites MUST be exactly the Work Site.

Rationale for the Track: it inverts the endgame. Instead of hunting for a hidden loser across a large map, every player converges on a known place on a known schedule. The last twenty turns of a Great Work game are a siege everyone chose to attend.

8.8 T8 — Prosperity

VC-1280 Prosperity's progress MUST be floor(1000 × output(p) / MAP_POTENTIAL_OUTPUT), where output(p) is the Standing output term of VC-530 and MAP_POTENTIAL_OUTPUT is the constant of VC-600. Its denominator MUST be MAP_POTENTIAL_OUTPUT.

VC-1290 Prosperity's threshold MUST default to 450‰, settable in [300, 900], and its vigil to 8.

VC-1300 Prosperity MUST NOT Ebb. Where its threshold is below 501‰, two or more players MAY satisfy it simultaneously and MUST be resolved by §9.

VC-1310 Prosperity's sites MUST be the eight cities held by p with the highest effective Works — or all of them where p holds fewer than eight — ties broken by ascending city sequence number.

Rationale, and this is a redefinition of what the design proposal left as a possible shadow of Dominion. Measuring realised output against the map's potential output makes Prosperity a statement about governing rather than about grabbing: under 12-economy.md a sprawling, freshly conquered, poorly integrated empire holding 60 percent of the cities may realise well under 40 percent of their potential, while a compact, fully integrated, Academy-anchored empire holding a third of the cities may realise more. If those two empires score the same on Prosperity the Track is decoration and linter rule L9 should say so; the redefinition is what gives it a chance of being a distinct strategic shape.

8.9 T9 — The Horizon

VC-1320 The Horizon MUST resolve at the Seal of turn H. The live player with the highest Tenure at that Seal MUST win.

Rationale: resolving on Tenure rather than Standing is the point of the Track. Tenure cannot be sniped on the last turn — you cannot buy the game on turn 199 with a desperate offensive, because the score being judged accumulated across 199 turns of actually holding things. It makes the last twenty turns about defending a record, which is a real strategic problem, instead of about a scoring spree, which is not.

VC-1330 H MUST default to 200 and be settable in [20, 2000].

VC-1340 The Horizon MUST be enabled by default in every preset. Disabling it MUST raise linter check L4 (§12.4).

VC-1350 Ties at the Horizon MUST be resolved by the tie chain of VC-1520.

VC-1360 Horizon Jitter J MUST be settable in [0, 40], default 0. Where J > 0, the true Horizon MUST be drawn once at generation per VC-170 as H_true = H + draw(0 … J), MUST NOT appear in any client-visible state, and MUST be published to every player at the start of turn H_true − 10. The window from H to H + J MUST be published from turn 1.

Rationale, and this settles a question the proposal left open. The Horizon is public by default because legibility is half the brief and a hidden clock silently removes the count-backwards-to-a-date readout that the Ebb exists to provide. But a fully public Horizon does invite last-turn optimisation, so the jitter option exists for tables that want the war to end "somewhere in the low two-hundreds" — with a guaranteed ten turns of notice, which is enough to fight the last battle and not enough to plan a scoring spree around it.

VC-1370 The Horizon's kind MUST be Scheduled and it MUST NOT carry a Vigil, an Ebb, or a sites set. Its ratio for the readout MUST be floor(1000 × t / H), and it MUST enter the Alarm band from turn H − 10.

VC-1380 From the Seal at which mathematical elimination (§14.3) leaves exactly one player able to lead Tenure at H, the Board MUST mark the Horizon Track DECIDED and name that player. The game MUST NOT end for this reason alone; other enabled Tracks remain live.

8.10 T10 — Endurance

VC-1390 Endurance's progress MUST be 1 for player p at the Seal of turn t iff t ≥ T and citiesHeld(p) ≥ N, and 0 otherwise. Its threshold MUST be 1 and its vigil 1.

VC-1400 T MUST default to floor(3 × H / 4) and N to ceil(MAP_CITIES / 8), both settable. Endurance MUST be disabled by default.

VC-1410 Where several players satisfy Endurance at the same Seal, the winner MUST be resolved by §9. Rationale: Endurance is a scenario Track, and a scenario in which several defenders all survive is a legitimate outcome that needs a defined ranking rather than a prohibition.

8.11–8.13 Charters, Sealed Orders, Warrants

VC-1420 T11 Charters and T12 Sealed Orders MUST be specified by §10 and MUST obey every requirement of §4 as ordinary Tracks except where §10 states otherwise.

VC-1430 T13 Warrants MUST be specified by §11, MUST NOT be a terminal Track, and MUST NOT be able to win a game by itself under any configuration.

8.14 T14 — Throne, and the Seat

VC-1440 Every player MUST have exactly one Seat or be Seatless. The Seat MUST be a city the player holds.

VC-1450 At setup each player's Seat MUST be their starting city with the highest base Works, ties broken by ascending city sequence number. A player MAY re-designate their Seat to any city they hold by the DesignateSeat order during turns 1 to 5 inclusive, once.

VC-1460 When a player's Seat changes owner, that player MUST become Seatless at the following Seal, and the city MUST remain marked as that player's Seat — and therefore MUST continue to count for the Standing Seat term (VC-510) and for Throne — until the player re-Seats or leaves the game.

VC-1470 A Seatless player MUST accrue Tenure at half rate (VC-610) and MUST NOT re-Seat for 6 turns after becoming Seatless. From the seventh turn onward they MUST re-Seat at the next Seal at which they hold a city with Integration ≥ 50, choosing by DesignateSeat order or, absent an order, the eligible city with the highest effective Works, ties broken by ascending city sequence number. On re-Seating, the former Seat city MUST cease to be a Seat.

Rationale: losing a capital must be severe but never fatal, and the penalty must live in a currency this document owns rather than reaching into another subsystem's mechanics. Halving Tenure accrual is exactly the right severity and exactly the right meaning — your government is in exile and the world does not count those years — and it costs a Seatless player their placing and their Horizon prospects without costing them a single soldier. The Integration-50 requirement is what stops a collapsing player from re-Seating in a city they captured last week, and it ties the recovery to the economy subsystem's own pacing rather than to an arbitrary timer alone.

VC-1480 Throne's progress MUST be the number of live rival players r for which either p holds r's Seat, or r is Seatless. Its threshold MUST be the number of live rival players, its denominator that same count, and its vigil 3.

Rationale: counting a Seatless rival as satisfied is what makes Throne terminate. Without it, a rival with no eligible city to re-Seat in would make the Track permanently unsatisfiable, and the fastest Track in the catalogue would become the one that never fires. It also reads correctly: you have already thrown down their throne, and you do not additionally have to garrison the rubble.

VC-1490 Throne's sites MUST be the rival Seat cities held by p, in ascending city sequence number, together with the Seat cities of rivals p does not hold, marked as objectives rather than as holdings.

Rationale for the Track: very few, very high-value, publicly known targets, which is what makes it the fastest condition in the catalogue and the backbone of the short presets. It is also the Track most vulnerable to a re-Seat undoing a Vigil, which is intended — a Throne war should be a campaign against a government, not a race to one building.

9. Combination and resolution

Conditions are a set, they all run at once, and the first Track to complete wins. That is the whole of it, and the uniformity of §4 is what lets it be.

VC-1500 Every enabled Track MUST be live simultaneously and MUST apply to every player, except Charters and Sealed Orders, which are per-player by construction (§10).

VC-1510 The first Track completed MUST win the game. Where exactly one player completes exactly one Track at a Seal, that player MUST win with no further test.

VC-1520 The tie chain MUST be, in order, and MUST be applied only where the preceding criterion is equal:

Rationale: one chain, used for every ambiguity in this document, and it means something defensible at every step. Tenure first because it is the player who has been ahead the longest, which is the only tiebreak that describes the whole game rather than one instant. Standing second because it describes the present. Cities third because the game is about cities. Fewest units lost fourth because between two otherwise identical empires, the one that got there more cheaply played better. Seat index last because it is arbitrary and must therefore be unreachable except in a genuinely symmetric position, where any answer is arbitrary and the only requirement is that it be deterministic.

VC-1530 Where two or more players complete different Tracks at the same Seal, the winner MUST be the one highest on the tie chain of VC-1520. There MUST NOT be a precedence order among Tracks.

Rationale: a precedence table is fourteen more numbers to justify, fourteen more things to memorise, and it would silently make one Track better than another for reasons unrelated to how hard it is. Resolving to Tenure gives the same answer every time and is explicable in one sentence.

VC-1540 Where two or more players complete the same Track at the same Seal, the winner MUST be the one with the higher raw progress for that Track; if still equal, by the tie chain of VC-1520.

VC-1550 A player MUST be able to hold non-zero Vigil counters on several Tracks at once, and completing any one of them MUST win.

VC-1560 A Track MUST NOT be disabled, re-parameterised or added mid-game except by an explicit scenario event recorded in the order log. Where one occurs, every Vigil counter for the affected Track MUST reset to zero and a Chronicle entry MUST record the change.

VC-1570 Teams. Where teams are enabled, a team MUST be treated as a single player for every purpose in this document: cities, Landmarks, Seats, output and in-supply units MUST be aggregated over the team's members before Standing is computed, Tenure MUST accrue once for the team, Tracks MUST be evaluated on the aggregate, and the team MUST win or lose as a unit.

Rationale, settling a question the proposal left open. Aggregating holdings rather than summing members' individual Standings is chosen because it makes every intra-team transfer of a city or a unit score-neutral: a team is never rewarded or punished for internal bookkeeping, and a sacrificial member is worth exactly what they were holding. Summing member Standings would make the military cap of VC-540 apply per member, so a team could score more military by splitting an army across seats, which is a bookkeeping exploit and not a strategy.

VC-1580 A team member who capitulates or concedes MUST leave the team; the team MUST continue with its remaining members and its Tenure MUST NOT be reduced. A team all of whose members have left MUST be treated as a single not-live player.

VC-1590 Where a game ends by any route, the engine MUST emit a result record naming the winner, the Track and turn by which they won or the route by which the game ended, every player's final Standing, Tenure and placing, and the complete Chronicle.

10. Per-player objectives: Charters and Sealed Orders

Two asymmetric modes, both off by default. Charters are public and their value is information; Sealed Orders are hidden and their value is the moment they stop being hidden.

10.1 Charters

VC-1600 Where Charters is enabled, every player MUST carry exactly one Charter: an instance of a catalogue Track (§8) with its own parameters, evaluated only for that player.

VC-1610 Every Charter MUST be visible to every player from turn 1, including its Track, its parameters, its Vigil and its Weight.

Rationale: the value of this mode is information, not variety. Knowing that Green must go for Landmarks tells you where Green will be for the entire game, and that is enormously richer than "everyone wants everything." A three-player game with public Charters has the texture of strategy; the same game with hidden ones has the texture of a guessing contest.

VC-1620 Charter Mode MUST offer exactly two values:

VC-1630 The Charter pool MUST be exactly the following, and a Charter MUST be assigned to each player at setup either by explicit selection in seat order or, absent selection, by drawing without replacement from the pool per VC-170.

VC-1640 A Charter's Weight MUST be an integer in [1, 5] estimating its difficulty, where 5 is hardest.

VC-1650 A player holding a Charter of Weight w MUST receive a setup handicap of exactly: (w − 1) × 40 Works placed in their Seat's Yard at the start of turn 1, and, where w ≥ 4, one additional starting city adjacent to their starting position.

VC-1660 The Weights in VC-1630 and the handicap formula in VC-1650 MUST be treated as provisional and MUST be regenerated from self-play calibration per VC-3210. The setup screen MUST label them as provisional until a calibration table has been generated for the current map class and player count.

Rationale, stated plainly because the alternative is to pretend: these nine weights are invention. There is no defensible number here before self-play data exists, and the honest move is to ship concrete values, label them, and make the recalibration a CI obligation rather than an intention. The acceptance target is in §18.

VC-1670 Where Charter Mode is Exclusive with three or more players and the spread of assigned Weights exceeds 2, the setup linter MUST raise check L7 (§12.4).

10.2 Sealed Orders and Ambition

VC-1680 A Sealed Order MUST be a Track-shaped hidden objective carried by one player: a progress function, a threshold, and a difficulty class of Minor, Major or Grand.

VC-1690 A Sealed Order MUST NOT win a game under any configuration. Completing one MUST grant Ambition points only: Minor 1, Major 2, Grand 3.

VC-1700 Ambition MUST be a Track (T12) with progress equal to the player's accumulated Ambition points, threshold 5 settable in [3, 12], vigil 1, kind Accumulative, and maxGainPerSeal 4.

VC-1710 Ambition MUST also be obtainable publicly, through Warrants (§11.4), in every configuration in which Sealed Orders are enabled. The Ambition Track MUST NOT be purely hidden.

Rationale: secret victory conditions are usually a mistake, because being surprised by a loss is the worst experience a strategy game can deliver. Three rules make them safe, and this is the first: the hidden thing feeds a public meter that anyone can also fill in the open, so the meter is always legible even when its inputs are not.

VC-1720 A Sealed Order MUST auto-reveal — its full text and its holder published to every player — at the first Seal at which its own ratio (VC-490) reaches 600, and MUST remain public thereafter.

Rationale: this is the second safety rule, and the reveal is the mechanic rather than a concession to it. It is the moment the table finds out what Green has been doing on that worthless island for thirty turns. Nobody is ever surprised by a win; they are surprised by an explanation.

VC-1730 The number and difficulty class of every player's Sealed Orders MUST be public from turn 1, without their content. Rationale: the third safety rule. "Green holds two Sealed Orders, one Major" tells you the shape of the threat without its content, which is exactly enough to plan against and not enough to make the reveal worthless.

VC-1740 Each player MUST receive SO Sealed Orders where SO defaults to 1 and is settable in [0, 2]. Sealed Orders MUST be disabled by default in the Tournament preset.

VC-1750 The Sealed Order pool MUST be exactly the following, and each player's Orders MUST be drawn without replacement per VC-170. An Order whose subject does not exist on the generated map, or whose subject exists but makes the Order unsatisfiable by construction, MUST be discarded and redrawn, up to 16 attempts, after which the player MUST receive one Order fewer and the shortfall MUST be recorded in the stored schedule. Unsatisfiable by construction MUST include at least: an Order naming a Region with fewer cities than the Order requires held (VC-1032 R2 permits a Region of two); an Order requiring a coastal city in a Region containing no Port (01-game-rules.md GR-890); and an Order naming a rival seat that is not occupied at setup.

Rationale: the redraw rule already existed for a subject that does not exist; the failure it missed is a subject that exists and cannot be satisfied, which is worse, because it is invisible. A hidden objective a player cannot complete is not a hidden objective, it is a hidden penalty, and under VC-1730 the table has been told that player holds a Major without being told it is dead. Bounding the redraw and recording the shortfall follows VC-1180's precedent for the same determinism hazard.

Rationale for the pool's shape: every Order is expressible as two integers, which is VC-030 applied to hidden objectives, and it is what makes the 600‰ auto-reveal computable at all. Note that most Orders are measured in consecutive Seals rather than in a state — a hidden objective that can be satisfied for one turn by accident is not an objective, and the consecutive-Seal form also gives the reveal a meaning: when Green's Order surfaces at 600‰, the table learns not only what Green wants but that Green has been holding it for a while.

11. Warrants and Tallies — objectives that are not endings

A victory system should produce events every fifteen turns, not one event at the end. Warrants are the direct answer, and they are the reason this is a system rather than a terminating check.

VC-1760 A Warrant MUST be a scheduled, publicly announced objective with a stated reward that MUST NOT be victory. Claiming a Warrant MUST NOT complete any Track directly; it MAY grant Tenure or Ambition, which feed Tracks that are themselves public.

VC-1770 The mechanisms this document provides that fire during play without ending anything MUST be exactly:

Rationale: the stretch from roughly turn 60 to turn 130 is the part of every long strategy game that sags, and it is the part this table is aimed at. On the reference map that stretch contains about five Warrant windows and six Tallies, which is a scheduled reason to leave your fortress roughly every seven turns.

11.1 Cadence and announcement

VC-1780 Every WarPeriod turns, where WarPeriod defaults to 15 and is settable in [5, 60], the game MUST open between 1 and 3 Warrants, the count and content drawn at generation per VC-170.

VC-1790 Each Warrant MUST be announced 5 turns before it opens, MUST remain open for a deadline of WarPeriod turns, and MUST expire unclaimed at the Seal of its deadline turn.

VC-1800 An announced Warrant's full text, subject, deadline and reward MUST be public to every player from the announcement.

11.2 The Warrant catalogue

VC-1810 A Warrant MUST be an instance of exactly one of the following forms, with its subject drawn from the generated map:

VC-1815 A Warrant's subject MUST be one every player can act on and some player can reach. Concretely:

• A Capital hold, Region hold or Scout Warrant naming a Region or a regional capital MUST name it by the public identifiers of VC-1034, so that the objective is actionable from the announcement without exploration.
• A Hold or Scout Warrant MAY name a city whose location is not public; where it does, the announcement MUST publish that city's name and tile for the life of the Warrant, under the same restriction VC-1090 places on Landmarks — no Explored mark, no Terrain Record write, no ownership announcement.
• A Region hold Warrant MUST NOT be opened on a Region in which no live player already holds at least half the cities, rounded up, at the Seal at which it is announced.

Rationale for the last clause, and for adding the Capital hold form beside it: "hold every city of a six-city Region within fifteen turns" is, from a standing start, not an objective, it is a decoration on the Warrant board, and VC-1770 claims Warrants are the mechanism that gives the middle third of the game a rhythm. The regional capital is the fix. It is one publicly named city that every Region has, that every player has known since turn 1, and that is reachable in a Warrant's window — which gives the regional capital a job in play rather than leaving it a label on a boundary, and gives every map, however few Landmarks it carries, M permanent publicly known contested points.

VC-1820 A Warrant MUST be claimable by at most one player unless its text states otherwise. Where two or more players satisfy it at the same Seal, the claimant MUST be resolved by the tie chain of VC-1520.

VC-1830 A Warrant MUST be claimed automatically at the Seal at which its test is satisfied. No ClaimWarrant order MUST be required for any form in VC-1810. Rationale: a reward that a player can lose by forgetting to press a button is a trap, and 13-command.md CM-050 forbids exactly that shape of thing.

11.3 Contested Warrants

VC-1840 Warrant Mode MUST offer exactly Open, Contested and Mixed.

VC-1850 A Contested Warrant MUST publish that it is Contested, and MUST name the player currently excluded, from the moment it is announced.

Rationale, and the honest cost. Contested Warrants are rubber-banding, and the in-world reading — the leader's rivals coordinating against them — is at least an honest fiction rather than an invisible hand. But this audience tends to resent being nannied, and a system that quietly helps whoever is behind is exactly the invisible tax the direction document forbids in the economy. The compromise is that it is a visible, named, announced exclusion that the leader can see coming, that it is a single setting, and that Tournament runs Open. It is named in the open questions as the setting most likely to be wrong.

11.4 Rewards, exhaustively

VC-1860 A Warrant's reward MUST be exactly one entry from the following table and no other. This list, together with the Alarm's Bellwether vision and the Rally's grants, is the complete set of advantages the victory system may confer (VC-070).

VC-1870 The total Tenure a single player MAY receive from Warrants across one game MUST NOT exceed 30 × maxTenurePerSeal. A claim that would exceed the cap MUST pay the remaining balance and MUST record the truncation in the Chronicle.

Rationale: Warrants must be able to change a placing and must never be able to buy a game. Thirty turns' worth of maximum accrual, on the reference map about 2,800 Tenure against a typical winning total near 15,000, is enough to move second place to first in a close game and nowhere near enough to overturn a decided one.

VC-1880 A Warrant MUST NOT grant units, combat strength, movement, production capacity beyond the Works grant of VC-1860, or any modification to a Track's threshold or Vigil.

VC-1890 Every Warrant opening, claim, expiry and truncation MUST emit a Chronicle entry, and the Board MUST present a Warrant board listing open, upcoming, expired and claimed Warrants with their claimants.

VC-1900 Warrants MUST be disableable at setup. Where they are disabled and no other mechanism of VC-1770 is enabled, the setup linter MUST raise check L10 (§12.4).

12. Legibility, part one — the Terms

Fourteen conditions with parameters is its own failure mode. A wall of settings is not a broad option space, it is a wall. The setup screen is designed around three ideas: cards rather than checkboxes, a generated paragraph that says in prose what you just built, and an estimated length that is measured rather than asserted.

12.1 Cards

VC-1910 The victory setup screen — the Terms — MUST present each Track as a card. A card MUST carry exactly: the Track's name; one plain-language sentence of at most 140 characters; at most three parameters with their current values; and three integer ratings, Length, Aggression and Complexity, each in [1, 5].

VC-1920 A Track MUST NOT expose more than three parameters on its card. Any further parameter MUST live behind an advanced disclosure and MUST have a default that a player never needs to change.

Rationale: the constraint is the design. A condition that needs four dials to express is a condition nobody will read, and the cap is what forces each Track to have one idea. It is also what makes the Terms paragraph generatable — a clause template with three slots can be written; one with seven cannot.

VC-1930 The Length rating MUST be computed from the Track's estimated median completion turn m against the Horizon H: 1 where 5m ≤ H, 2 where 5m ≤ 2H, 3 where 5m ≤ 3H, 4 where 5m ≤ 4H, else 5.

VC-1940 The Aggression and Complexity ratings MUST be the fixed per-Track constants below. Aggression MUST measure how much the Track requires taking things from other players; Complexity MUST measure how many concepts beyond cities and turns a player must hold to use it.

VC-1950 Enabling, disabling or re-parameterising any Track MUST immediately regenerate the Terms paragraph (§12.2), the estimate (§12.3) and the linter results (§12.4), without a confirmation step and without navigating away from the cards.

12.2 The generated Terms paragraph

VC-1960 Below the cards the Terms MUST generate a prose paragraph stating, in plain language, exactly what the assembled configuration does. The paragraph MUST be composed of the following clauses, in exactly this order, omitting any clause whose subject is not enabled:

VC-1970 The terminal-Track clauses MUST be exactly:

VC-1980 Every quantity in the paragraph MUST be stated in natural units, never in per-mille. The paragraph MUST say "30 of the map's 48 cities", never "625 per mille".

Rationale: this paragraph is the single most valuable object on the setup screen. If a player reads nothing else, they know what they signed up for. Per-mille is the engine's unit and it is the right one there; it is not a unit anyone plans in.

VC-1990 The paragraph MUST state every rule that can end the game and MUST NOT state anything that cannot.

VC-2000 The generated paragraph MUST be stored verbatim in the save file and in the game record, and MUST be presented unchanged in the end-of-game summary.

Rationale: an argument about what the rules were is the worst way for a multiplayer game to end. Storing the paragraph means the answer is the text every player agreed to before turn 1.

VC-2010 A worked paragraph, normative as a test vector. For the reference map under the Standard War preset the generator MUST produce:

This game ends when a player holds 30 of the map's 48 cities for 3 turns; or holds 3 of the 5 Landmarks for 6 turns; or is the last player left. From turn 120 the Dominion requirement falls, reaching 25 of 48 cities at turn 200. At turn 200, the player with the highest Tenure wins. Broken players surrender automatically after 3 turns. A decided game may be ended early by a vote of the trailing players. A player far behind receives public Rally objectives, and taking a city from the leader is worth extra Tenure. Estimated length: 90–160 turns.

12.3 Estimated length

VC-2020 The setup screen MUST present an estimated length as an integer range and MUST NOT present a qualitative label in its place.

VC-2030 The estimate MUST come from a shipped calibration table estimate[track][mapClass][players] holding the median, 20th and 80th percentile completion turns, generated at build time from at least 2,000 headless self-play games per cell. At runtime it MUST be an integer lookup and MUST NOT be simulated.

VC-2040 mapClass MUST be determined by MAP_CITIES alone:

VC-2050 For a configuration with several enabled terminal Tracks, the presented estimate MUST be p20 = min over enabled terminal Tracks of that Track's p20 and p80 = min(H, min over enabled terminal Tracks of that Track's p80).

Rationale: the game ends when the first Track completes, so the length of a multi-Track game is governed by the fastest, and the Horizon caps everything by construction. Taking the minimum of the percentiles rather than modelling the joint distribution is an approximation and a deliberate one: it is conservative in the direction that matters — it never promises a shorter game than the configuration can deliver — and it is computable from a table that already has to exist.

VC-2060 Where the calibration table has no cell for the current (track, mapClass, players), the fallback range of VC-880 MUST be used and the estimate MUST be visibly labelled as an estimate without calibration data.

VC-2070 The calibration table MUST record the rulesetVersion against which it was generated. Where that version differs from the build's, the estimate MUST be labelled stale on the setup screen and the build MUST fail the CI check of VC-3290.

Rationale: the estimate is the most useful number on the screen and the one most likely to become a lie. Any balance change to the economy, the roster or combat invalidates it silently, and an estimate that is quietly wrong is worse than none — a player plans a two-hour evening around it. Making staleness both visible to the player and fatal to CI is the only way this stays honest.

12.4 The setup linter

VC-2080 The Terms MUST lint the assembled configuration and MUST present every finding with a concrete, numeric message naming the setting that would resolve it.

VC-2090 Findings MUST carry a severity of Error or Warning. An Error MUST prevent the game from starting. A Warning MUST be dismissible and MUST be recorded, dismissed, in the game record.

VC-2100 The lint checks MUST be exactly the following:

VC-2110 L9 MUST be computed from the calibration corpus only, MUST be suppressed entirely where no calibration data exists for the current cell, and MUST be presented as advice rather than as a defect.

Rationale: L9 is the check most worth having and the one least certain to be computable honestly. Detecting that two Tracks are redundant requires a correlation measure across map classes that may simply be too noisy to threshold. Suppressing it without data, rather than falling back to a guess, is the difference between a lint and a superstition; if the measure proves unreliable it should become advisory prose on the cards and this row should be deleted.

12.5 Presets

VC-2120 The Terms MUST offer exactly the following presets, and each MUST be expressible entirely as values of the settings this document defines.

VC-2130 A player who never opens the Terms MUST receive Standard War. Rationale: the default configuration is the one most people will play, and it must be a good game rather than a neutral one. Standard War is a good game.

VC-2140 Every preset except Every Last City and Tournament MUST run the Verdict and the Ebb.

VC-2150 Selecting a preset and then changing any setting MUST leave the preset name shown as modified, and the Terms paragraph MUST regenerate.

13. Legibility, part two — the Watch, the Board, the Alarm

There is a real conflict here and it must be resolved rather than split. Publish everyone's exact progress and the scoreboard becomes a free intelligence oracle: "Red went 458 to 479 this turn, that is one city, so their army is in the north." Publish nothing and a player genuinely does not know they are losing until it is over, which is not tension, it is ignorance. The answer is quantisation that tightens as the stakes rise.

13.1 Principles

VC-2160 For every live player and every enabled Track, the engine MUST compute at every Seal a published value whose precision depends on that player's ratio for that Track, per §13.2, and MUST publish it to every other player.

VC-2170 A player MUST always see their own Track values at full precision, unbanded, including their own Vigil counters and their own sites.

VC-2180 The published value MUST be derived only from the Seal record. It MUST NOT reveal city locations, unit positions, unit strengths, orders, or any per-turn delta finer than the band permits.

VC-2190 Progress Visibility MUST offer exactly Banded (default), Public (every value at full precision to everyone) and Own Only (no opponent values published at any band, except the Alarm, which MUST remain in force under every setting).

Rationale: Own Only exists because some players will feel the mystery deflate and they are entitled to that game. The Alarm is exempt from it because the failure the Alarm prevents — the leader is about to win, I want to stop them, and I cannot find the thing to attack — is not a matter of taste, it is the failure this whole document exists to eliminate. A setting may make the game more mysterious; it may not make the endgame a search.

13.2 The three bands

VC-2200 A player's band for a Track MUST be determined by their ratio (VC-490) and their Vigil counter:

VC-2210 The Rumour vocabulary MUST be exactly:

VC-2220 Band transitions MUST use hysteresis on the way down and MUST NOT on the way up. A player MUST enter Alarm at ratio ≥ 900 or vigilCounter ≥ 1 and MUST leave it only when ratio < 850 and vigilCounter = 0. A player MUST enter Report at ratio ≥ 500 and leave it only at ratio < 475.

Rationale: without hysteresis a leader sitting on the boundary flickers the Alarm banner on and off every turn, which trains every player to ignore it. The asymmetry — instant on the way up, sticky on the way down — is deliberate: a warning must never be late, and a warning that lingers two turns too long costs nothing.

VC-2230 A player in the Alarm band MUST be told, at full precision, exactly what has been published about them and which of their sites have been revealed.

Rationale: the leader has to be able to plan around the disclosure. An Alarm that reveals three of their cities without telling them which three converts a fair fight into an ambush, and the whole justification for the Alarm is that a player who crosses 90 percent has accepted being fought at a known place.

13.3 The report quantum

VC-2240 For a Track whose threshold in natural units is at most 8, the Report band MUST publish the exact natural-unit count and threshold — "Keys 2 of 3" — rather than a quantised ratio.

Rationale: a Track counting to three is already coarse. Quantising it produces a number less informative than the count and no less revealing, because one Landmark is a third of the bar however it is displayed.

VC-2250 For every other Track, the Report band MUST publish floor(ratio / Q) × Q, where the report quantum Q is:

Q = max( 50, ceil( 2 × 1000000 / (denominator × threshold(t)) ) )

VC-2260 Q MUST be recomputed at every Seal, because threshold(t) may Ebb, and MUST be published so that a player can see the precision of what they are reading.

VC-2270 Worked quantum, normative as a test vector. On the reference map at turn 100, Dominion has denominator = 48 and threshold = 625, so Q = max(50, ceil(2000000 / 30000)) = max(50, 67) = 67. A player at ratio = 733 publishes as floor(733 / 67) × 67 = 10 × 67 = 670, presented as "Dominion 67 percent".

Rationale, and this is the requirement that makes banded visibility honest rather than decorative. A flat 5 percent quantum sounds coarse and is not: on the reference map 50 per mille of the Dominion ratio is 1.5 cities, so a player watching the published number across two turns can count captures. The 2 × 1000000 / (denominator × threshold) term is the ratio-space width of two units of the underlying countable, so the quantum is never finer than two cities, two Landmarks, or two units of output. The leak is therefore bounded at plus or minus one city per reading, which is imprecise enough that the scoreboard cannot be used to track an army and precise enough that a player can see a rival closing. The leak is real and is not eliminated; Own Only exists for players who want it gone.

13.4 The Alarm and the Bellwethers

VC-2280 When a player enters the Alarm band on any Track, the engine MUST, at that Seal: emit a Chronicle entry of class AlarmRaised; publish a banner to every player naming the player, the Track and the number of turns to completion; publish the Track's sites as Bellwethers, each named and locatable; and raise a non-adaptable Attention Event on every other player's Dispatch (13-command.md CM-1610, CM-1720, CM-1790).

VC-2290 Every player MUST be granted live vision of each Bellwether tile and of the units occupying it, refreshed at every Seal, for the duration of the Alarm and for 2 turns after it clears.

Rationale, and this is a large fog concession made deliberately. The failure being prevented is precise: the leader is about to win, I want to stop them, and I cannot find the thing I need to attack. A hidden win condition on a two-thousand-tile map is not tension, it is a formality with a countdown attached. The Alarm hands every player the address of the fight, which is what makes the last twenty turns a battle rather than a search. The in-world reading is not embarrassing either — the world notices when someone is about to win. The two-turn grace exists so that a counterattack already in motion does not go blind at the exact moment it arrives.

VC-2300 Bellwether vision MUST NOT reveal terrain the viewer has not explored, MUST NOT reveal any tile other than the Bellwether tiles themselves, and MUST NOT reveal past states. It MUST be exactly current occupancy of named sites.

VC-2310 The Bellwether set MUST be capped at 8 sites per player across all Tracks in Alarm simultaneously, selected by ascending Track index then by each Track's own sites ordering.

VC-2320 A Track with vigil = 1 MUST additionally obey VC-740, publishing full precision from ratio ≥ 500, because its Alarm and its completion coincide.

VC-2330 The engine MUST record, for every Alarm, the turn it was raised and the turn the game ended, so that acceptance metric M4 of VC-3300 can be computed from any replay.

13.5 The Watch

VC-2340 The client MUST present the Watch: a compact, always-visible strip, never dismissible, carrying exactly one row per player.

VC-2350 A Watch row MUST carry exactly six fields, and no more:

VC-2360 Tenure MUST be published at full precision to every player at all times and MUST NOT be banded.

Rationale: Tenure is an integral over the whole game, so its per-turn delta is a coarse aggregate that leaks nothing about position. It is also the tiebreaker for everything, the basis of the Horizon and the input to the Verdict, so a player who cannot see it cannot reason about any of those. Publishing it exactly costs no fog and buys the single most useful trend line in the game.

VC-2370 The Watch MUST additionally carry a one-line footer stating the current Ebb value with its next scheduled change, and the current turn against the Horizon.

VC-2380 The Watch MUST answer, without any click: who is closest to what, by how much, whether they are rising or falling, and how long the game has left.

13.6 The Board

VC-2390 The client MUST present the Board — the full victory panel — from a single keypress, and it MUST contain at least: the full matrix of players against Tracks showing published value, per-Seal delta and Vigil state; the Ebb schedule drawn as a descending line; the per-player "count backwards to a date" markers of VC-840; the Warrant board of VC-1890; the Ascendancy Tally calendar of VC-1200; each player's Charter and Sealed Order count; every player's Standing and Tenure history; and the Chronicle.

VC-2400 The Board MUST be redrawable for any past turn from the retained Seal records (VC-250), without recomputation.

VC-2410 The Board MUST mark every Track that has been proved DECIDED (VC-1380) and every player who is Out of Contention (§14.4), naming the turn on which each was established.

13.7 The Chronicle

VC-2420 The engine MUST emit a Chronicle entry for every victory-relevant event, permanently retained, one line per event, each carrying the turn number, a class from VC-2430, and a plain-language rendering.

VC-2430 The Chronicle classes MUST be exactly: TrackCrossed, VigilBegun, VigilHeld, VigilBroken, AlarmRaised, AlarmCleared, EbbStep, TallyResolved, WarrantAnnounced, WarrantOpened, WarrantClaimed, WarrantExpired, WarrantTruncated, SealedOrderRevealed, AmbitionGained, WorkSiteDesignated, WorkSiteCaptured, SeatLost, SeatRestored, Broken, Recovered, Capitulated, Conceded, Substituted, TrackDecided, OutOfContention, VerdictOffered, VerdictPassed, VerdictFailed, ReducedEntered, ReducedLeft, RallyIssued, RallyClaimed, DefianceScored, GameWon.

VC-2440 A Chronicle entry MUST be visible to a player only where the event it describes was published to that player under §13.2, except EbbStep, TallyResolved, WarrantAnnounced, WarrantOpened, WarrantExpired, Capitulated, Conceded, Substituted, ReducedEntered, ReducedLeft, OutOfContention and GameWon, which MUST be visible to everyone.

VC-2450 At the end of the game the complete Chronicle MUST be published to every player without redaction.

VC-2460 A worked Chronicle, normative as a test vector for the rendering of the classes it uses:

 t131  Red takes Kestrel Bay (Landmark).  Red — Keys 3/3.  VIGIL BEGINS (6).  ALARM.
 t134  Blue takes Kestrel Bay.            Red — Keys 2/3.  VIGIL BROKEN at 3/6.
 t141  Gold capitulates (Broken 3 turns). 3 cities ceded to Red — Unsettled 8 turns.
 t145  Ebb: Dominion 587 per mille (29 of 48 cities).
 t172  Horizon DECIDED for Red — Blue and Green can no longer reach 14,880.
 t178  Ebb: Dominion 536 per mille (26 of 48).  Red holds 27.  VIGIL BEGINS (3).  ALARM.
 t179  Blue takes Ashford.  Red — 26 cities, 541 ≥ 534.  Vigil holds 2/3.
 t180  Vigil 3/3.  RED WINS — Dominion.

Rationale: the whole endgame is reconstructable from eight lines, and that is the legibility target. If a reader cannot follow what happened from the Chronicle alone, the readouts above it are decoration.

14. The endgame

Four independent mechanisms, each aimed at a different sub-failure of VC-040. Capitulation deletes the mop-up. Mathematical elimination closes a decided game with a proof. The Verdict closes the cases arithmetic cannot reach, by consent. The Ebb and the Horizon guarantee termination. Dissolving the endgame is the reason this subsystem exists, and none of these four is a patch on the others.

14.1 The four mechanisms

VC-2470 The engine MUST implement all four mechanisms. A configuration MAY disable the Verdict and MAY set Capitulation to Never, but MUST NOT disable mathematical elimination or the Horizon-and-Ebb termination guarantee.

14.2 Broken, and Capitulation

VC-2480 A live player MUST be Broken at a Seal iff either:

• citiesHeld = 0, or
• citiesHeld ≤ max(1, floor(peakCities / 8)) and output × 1000 ≤ 200 × peakOutput.

VC-2490 peakCities and peakOutput MUST be the maxima of that player's citiesHeld and output across every Seal of the game so far, including the current one.

Rationale: the definition must catch a collapsed player and must not catch a player who started small. Measuring against their own peak rather than an absolute threshold is what does that — a player who never held more than four cities is not Broken at one city if they are still producing, while a player who held forty and is down to four with a fifth of their industry plainly is. Requiring both conditions together, rather than either, is deliberate: a player squeezed into two well-developed cities that still produce is playing a defensive game, not a lost one.

VC-2500 A player continuously Broken for C consecutive Seals MUST capitulate at that Seal.

VC-2510 A player with citiesHeld = 0 and no units MUST capitulate immediately at that Seal regardless of C. Rationale: there is nothing left to recover with, and making the table wait three more turns to confirm it is precisely the tedium this document exists to delete.

VC-2520 On capitulation, at step S13 of the Seal and in this order: the player's units MUST be disbanded without combat, movement or a chase; their Work Site progress MUST be discarded; their open Warrants MUST close unclaimed; their Sealed Orders MUST be revealed; their Seat MUST cease to be a Seat; their cities MUST be disposed of per VC-2540; their Tenure MUST freeze; and they MUST receive a final placing.

Rationale: units disbanding without a chase is the single most important line in this section. The mop-up is not the rule that a broken player must be finished off; it is the hour spent finding their last destroyer on a two-thousand-tile map so that a win condition can technically fire. Deleting the units deletes the hunt.

VC-2530 The Principal Aggressor of a capitulating player MUST be the live player who has captured the most cities from them across the whole game, ties broken by the shortest Chebyshev distance from any of their cities to the capitulating player's Seat, then by lowest seat index.

Rationale: whole-game captures rather than "who took the last city", because otherwise a third party can swoop on a final city and inherit a war they did not fight. The rule is not a reward for opportunism, it is a statement about who actually broke them.

VC-2540 Cession MUST offer Aggressor, Free and Auto (default). Under Auto, the capitulating player's remaining cities MUST cede to the Principal Aggressor where two or fewer other players remain live, and MUST become Free Cities where three or more do.

Rationale, settling a question the proposal left open. Ceding is clearly correct in a duel or near-duel: there is no third party to kingmake and the cities should go to whoever won them. Above that it is the largest single swing in the match and it hands it to whoever happened to be adjacent, which is exactly the kingmaking the design tries to avoid elsewhere. Making the rule depend on the live count rather than on the starting count matters, because a six-player game that has become a three-player game should behave like a three-player game.

VC-2550 Ceded cities MUST arrive Unsettled for 8 turns — producing no Works, accepting no production, contributing no output to Standing — and the Unsettled state MUST be visible to every player who can see the city.

Rationale: without it, a capitulation is an instant snowball handed to the player already winning. Eight turns is a guess and is named as such in the open questions; the requirement it is trying to satisfy is that the payout must be worth having and must not be worth engineering.

VC-2560 Free Cities created by this rule MUST become neutral, MUST retain their Integration and Works, MUST receive the neutral garrison 01-game-rules.md defines, and MUST remain in MAP_CITIES.

VC-2570 A capitulated player MUST NOT be able to return to the game, MUST NOT vote in a Verdict, MUST NOT accrue Tenure, and MUST retain their Standing, Tenure and placing exactly as frozen.

VC-2580 Every capitulation MUST be recorded with the Seal at which it occurred, the C in force, the player's peakCities and peakOutput, the disposition of their cities and the Principal Aggressor, so that false-positive metric M6 of VC-3300 can be computed by replay.

14.3 Mathematical elimination

VC-2590 The engine MUST close a decided game by proof only. Every elimination test in this section MUST be conservative — it MUST NOT declare a player eliminated in any circumstance in which that player could still complete the Track under any sequence of legal play. A heuristic MUST NOT be used, and a bound that is merely very likely MUST NOT be presented as an elimination.

Rationale: this is the requirement that separates this design from every "the AI has conceded because it evaluated its position as hopeless" system. A wrongly ended game is far worse than a slightly long one, and a player told they cannot win must be able to check the arithmetic. Everything that is not provable belongs to the Verdict, where it is settled by consent instead.

VC-2600 For every Accumulative Track, the engine MUST compute the remaining ceiling for player B at the Seal of turn t as ceiling(B) = (H_end − t) × maxGainPerSeal, where H_end is the Horizon, or H + J where jitter is enabled, or the configured hard bound of VC-090 where the Horizon is disabled.

VC-2610 Absolute elimination. B MUST be eliminated from an Accumulative Track X iff progress(B, t) + ceiling(B) < threshold(H_end).

VC-2620 Relative elimination. B MUST be eliminated from the Horizon iff Tenure(B) + (H_end − t) × maxTenurePerSeal < max over live players of Tenure.

Rationale: using the leader's current Tenure rather than a projection of it is what makes the test sound. Tenure is monotone (VC-620), so the leader's final Tenure is at least their current Tenure, and the bound assumes B takes the entire map next turn and holds it while the leader gains nothing further. That is impossible, which is the point — a bound nobody can beat is a bound nobody can dispute.

VC-2630 Worked elimination, normative as a test vector. On the reference map at the Seal of turn 172 with Smax = 9437 and maxTenurePerSeal = 94:

remaining turns R = 200 − 172              = 28
ceiling            = 28 × 94               = 2632
Tenure: Red 14,880 · Blue 11,410 · Green 6,020
Blue:  11,410 + 2,632 = 14,042 < 14,880    → eliminated from the Horizon
Green:  6,020 + 2,632 =  8,652 < 14,880    → eliminated from the Horizon

The Board MUST mark the Horizon DECIDED — Red at turn 172. The game MUST NOT end, because Dominion and the Keys remain live and Blue can still win either outright.

VC-2640 The engine MUST state, on the Board and in the Terms, that Threshold Tracks cannot be closed by the arithmetic of VC-2610 and VC-2620.

Rationale, stated because the honest limit is more useful than a fudged claim: there is no sound way to prove from a score that a player with three cities cannot take thirty more in the turns remaining. In principle they can. Any design claiming otherwise is smuggling in a heuristic and calling it a proof. Dominion, the Keys, Hegemony, Prosperity and Throne are therefore closed by the reach bound below, by the Ebb, or by the Verdict — and by nothing else.

VC-2650 The reach bound. 02-units-and-industry.md MUST publish an integer MAX_DISPLACEMENT: a sound upper bound on the map distance, in tiles, that any unit of any enabled class may be displaced in one turn, including every transport, carriage, road and rail effect and every chained transfer legal within one turn.

VC-2660 01-game-rules.md MUST publish an integer MAP_SPAN: the greatest distance, under VC-190, between any two tiles of the generated map — that is, the maximum of dist(A, B) over all tile pairs, evaluated under the map's declared topology (GR-190) using the wrapped displacements of GR-200. At a Seal of turn t with R = H_end − t, and only where R × MAX_DISPLACEMENT < MAP_SPAN, the engine MUST compute for each live player B the set Reach(B, R): every city whose distance to some tile occupied by a B unit, or to some city held by B, is at most R × MAX_DISPLACEMENT. maxHold(B) = citiesHeld(B) ∪ Reach(B, R).

Rationale for MAP_SPAN rather than "the map's diagonal", which is what this requirement said before and which is wrong on two of the three topologies GR-190 offers. On a torus no two tiles are more than max(floor(width/2), floor(height/2)) apart, which on a 240 × 168 map is 120 rather than the 240 a diagonal reading gives; on a cylinder only one axis wraps. Overstating the span makes the guard permissive, which is merely wasted work — but the same wrong metric used inside Reach would make the bound unsound in the other direction, computing a player as unable to reach cities they can walk to by going the short way round. One published constant, defined by the same metric the reach itself uses, removes both.

VC-2670 B MUST be eliminated from a Threshold Track by the reach bound exactly per the following tests, evaluated against the Track's threshold at H_end, which is its lowest value:

VC-2680 The reach bound MUST ignore enemy units, combat outcomes, supply, terrain movement costs, production, and every other obstacle. It MUST assume B captures every reachable city unopposed.

Rationale: this is what makes it a proof and not a projection, and it is the only extension of the elimination arithmetic beyond the accumulative case that can be made honestly. It is deliberately, almost absurdly generous — a player who could not physically get a unit to enough cities before the Horizon even if every one of them were undefended cannot win the Track, and no amount of skill changes that. It fires rarely and it fires late, which is correct: early in a game the bound is the whole map and the guard in VC-2660 skips the computation entirely, so the cost is paid only in the turns where it can produce an answer.

VC-2690 The reach bound MUST be recomputed at every Seal at which the guard permits, and its result MUST be published: a player eliminated from a Track MUST be told so, with the arithmetic.

14.4 Out of Contention and the early end

VC-2700 A live player MUST be marked Out of Contention at a Seal iff they are eliminated from every enabled terminal Track by VC-2610, VC-2620 or VC-2670. The status MUST be published to every player and MUST emit a Chronicle entry.

VC-2710 The Sole Contender rule. Where exactly one live player L is not Out of Contention, the game MUST end immediately at that Seal with L as the winner.

VC-2720 The all-eliminated rule. Where every live player is Out of Contention, the game MUST end immediately at that Seal and the winner MUST be resolved by the tie chain of VC-1520. Rationale: this cannot occur while the Horizon is enabled, because relative elimination always leaves a Tenure leader standing. It exists so that a configuration with the Horizon disabled still terminates, which VC-090 requires.

VC-2730 A player who is Out of Contention MUST remain live, MUST continue to accrue Tenure, MUST continue to hold cities and units, MUST retain every order and every capability, and MUST NOT be removed from the game. The only consequence of the status MUST be that they can no longer win.

Rationale: this is a comeback requirement as much as an endgame one. A player told "you cannot win" who is then also stripped of agency has been handed the exact experience that makes people quit. Left in the game with a live army, a Tenure score that is still rising, a placing to fight for, and the ability to decide who wins, they still have a game — and in a six-player match their choices matter enormously to five other people.

VC-2740 Out of Contention MUST be revocable. Where a later Seal's arithmetic no longer eliminates a player from some enabled Track — which the reach bound permits, since reach grows with a player's holdings and shrinks with remaining turns — the status MUST be cleared and a Chronicle entry MUST record it.

14.5 The Verdict

VC-2750 At a Seal, the engine MUST offer a Verdict iff all four of the following hold for the player L with the highest Standing:

1. Standing(L) ≥ 2 × Standing(second)
2. L also leads on Tenure
3. L has held the Standing lead continuously for at least 12 Seals
4. No live player other than L has a non-zero Vigil counter on any Track

VC-2760 The Verdict MUST be a vote of the surviving non-leaders, cast as CastVerdictVote orders. A majority of surviving non-leaders voting to end MUST end the game with L as the winner and the remaining placings by Tenure.

VC-2770 Abstention MUST count as "play on." A player who does not vote MUST be recorded as voting to continue.

Rationale: the default must always be to continue, because a wrongly ended game is far worse than a slightly long one, and because a vote that ends a game through inattention is not consent.

VC-2780 The vote MUST resolve at the Seal VerdictWindow turns after it is offered, where VerdictWindow defaults to 2 and is settable in [1, 6]. In correspondence play the offer MUST be raised as a non-adaptable Attention Event on every eligible voter's Dispatch and MUST persist until the window closes.

Rationale, settling a question the proposal left open. A single-turn window in a game whose turns are measured in days means most players never see the offer, and defaulting to "play on" then makes the Verdict useless in exactly the mode where long games hurt most. Two turns is the compromise: in live play it is a minute, in correspondence it is a few days, and in both it is long enough that a player who is paying any attention at all gets to answer.

VC-2790 A failed Verdict MUST impose a 20-turn cooldown before another may be offered.

VC-2800 In the Tournament preset the Verdict MUST require unanimity of surviving non-leaders.

VC-2810 AI seats MUST vote by a deterministic policy derived from their evaluation and the game seed, MUST vote identically on every machine, and MUST have their vote recorded in the order log like any other.

Rationale: in solo play this is where most of the Verdict's value lands. The single-player mop-up is the worst version of the problem, and a beaten AI that concedes when it should largely deletes it.

VC-2820 The Verdict trigger MUST key on Standing, and Tenure MUST serve only as the sanity check of condition 2.

Rationale: Standing is current power and predicts the future; Tenure integrates from turn 1 and moves far too slowly for a 2× gap to appear before the game is long over. Keying the trigger on Tenure would mean the Verdict never fires in time to be useful, and keying it on Standing alone would let one spectacular turn trigger it. Each does the job the other cannot.

VC-2830 Worked Verdict, normative as a test vector, and it correctly declines. On the reference map at the Seal of turn 160, Red's Standing is 4,180 and Blue's is 2,510. 4180 ≥ 2 × 2510 = 5020 is false — the ratio is 1.67×, short of 2×. No Verdict is offered, and rightly so: Blue still holds two Keys and is one capture from his own Vigil. The trigger is deliberately strict and must be visibly capable of declining.

14.6 Concession

VC-2840 A live player MUST be able to concede at any time, by an explicit Concede order requiring a confirmation. Concession MUST NOT be reversible.

VC-2850 Concession MUST have effects identical to capitulation (VC-2520), including the disposition of cities under VC-2540.

VC-2860 A conceding player MUST NOT choose the beneficiary of their cities. The Principal Aggressor rule and the Cession setting MUST apply unchanged.

Rationale: this does not eliminate kingmaking in a three-player game — nothing can — but it makes the beneficiary whoever actually fought them, which is the fairest available answer, and it removes the ability to concede at someone out of spite.

VC-2870 A conceding player MUST keep their frozen Tenure and MUST take a final placing computed from it.

Rationale: this is one half of the anti-quit rule of VC-650 and it must be stated from the conceder's side too. Conceding is a legitimate, recorded exit, not a punishment — but because Tenure freezes and would otherwise have kept rising, playing on hopelessly is never worse for a player's placing than quitting, and is usually better. The design does not moralise about quitting; it prices it.

15. The comeback path

The direction document names endgame tedium, micromanagement, opaque economics and flat combat. Underneath the first of those sits a failure it does not name and no other document owns: a player who cannot come back stops playing, and in a six-player game a player who stops playing takes the game away from the five who did not. This section owns that failure. Its instruments are goals and information, not handouts, because a handout that makes a losing player stronger is the invisible hand the direction document forbids in the economy and would be worse here.

15.1 The four instruments

VC-2880 The comeback design MUST rest on four instruments and MUST NOT introduce a fifth without amending this requirement:

VC-2890 The primary comeback instrument MUST be the Vigil, and every other instrument in this section MUST be secondary to it.

Rationale, and it is worth stating plainly because it is the design's best answer to a hard problem. The Vigil creates a deliberate asymmetry at the exact moment a game would otherwise be over: the leader must be airtight for V consecutive turns while a challenger needs exactly one success, and the Alarm hands every challenger the address. That is a comeback path made of the game's own mechanics — armies, terrain, timing — rather than of compensating arithmetic. It rewards the trailing player for playing well rather than for being behind, which is the only kind of catch-up that a strategy audience will accept and the only kind that produces a story worth telling afterwards.

15.2 Reduced status

VC-2900 A live player MUST become Reduced at a Seal iff all of: the turn is at least 20; they are not Broken; and Standing(p) × 1000 ≤ 400 × Standing(leader), where leader is the live player with the highest Standing.

VC-2910 A Reduced player MUST cease to be Reduced at the first Seal at which Standing(p) × 1000 > 550 × Standing(leader), or at which they become Broken, or at which they leave the game.

Rationale: the hysteresis band between 400 and 550 per mille exists so that a player hovering near the boundary does not flicker in and out of a public status every turn, and so that recovering out of Reduced requires genuine progress rather than one good roll.

VC-2920 Reduced status MUST be public to every player, including which player is the leader it is measured against.

Rationale: an assistance mechanism that operates in secret is indistinguishable from the game cheating on someone's behalf. Publishing it also converts it into information the leader can act on, which is the difference between rubber-banding and a coalition.

VC-2930 Reduced status MUST NOT confer any combat, movement, vision, production or Works advantage beyond the grants VC-2950 enumerates, and MUST NOT alter any threshold, Vigil, Ebb schedule or tie-break.

VC-2940 A player MUST NOT be able to profit by entering Reduced deliberately. The total Tenure paid by the Rally across one game MUST NOT exceed 20 × maxTenurePerSeal for any player, and the entry condition MUST require a Standing gap that costs more than the Rally can return.

15.3 The Rally

VC-2950 A Reduced player MUST receive exactly the following and nothing else:

VC-2960 Rally Warrants MUST be public, including their target and their holder, from the moment they are issued.

Rationale: the leader is told exactly which of their cities the game has asked someone to come and take. That is what makes this an announced coalition rather than a hidden thumb on the scale, and it gives the leader something to do about it, which a hidden bonus never would.

VC-2970 The Survey MUST reveal ownership only. It MUST NOT reveal unit positions, garrison strengths, production, Integration, or any terrain the player has not explored.

Rationale: this is exactly the information a comeback needs and exactly not the information that trivialises an attack. Knowing the political shape of the map tells a beaten player where the war is and which rival is actually winning; it does not tell them where the defences are thin. A beaten player's real problem is almost never that they lack an army, it is that under fog they cannot see which fight is worth having.

VC-2980 The Rally MUST be disableable by a single setting, Rally: On (default) or Off, and disabling it with a long Horizon MUST raise linter check L11.

15.4 Defiance

VC-2990 Where Defiance is on, a player who captures a city from the player currently leading on Tenure MUST receive +150 Tenure at the following Seal.

VC-3000 Defiance MUST be capped at 600 Tenure per player per rolling 10-turn window and 3,000 Tenure per player per game. A grant exceeding a cap MUST pay the balance and MUST record the truncation.

VC-3010 Defiance MUST be off in the Tournament preset and on in every other preset, and MUST be a single setting.

Rationale, with its cost stated. Defiance is rubber-banding and there is no honest way to call it anything else. What makes it defensible is that it must be earned by winning a battle against the strongest player in the game, that its magnitude is bounded at roughly a fifth of a typical winning Tenure total, and that it is visible in the Chronicle every time it fires. What makes it optional is that this audience tends to resent being helped, and Tournament play should be decided by nothing but play. It is named in the open questions as the setting most likely to be wrong, alongside Contested Warrants, which it resembles.

15.5 What this section deliberately does not do

VC-3020 The comeback instruments MUST NOT include: a production bonus scaled to being behind; a combat bonus scaled to being behind; a reduction of any Track threshold for a trailing player; an increase of any Vigil for a leading player; or any grant that is not published at the instant it takes effect.

Rationale for each refusal, because the rejected alternatives are the ones a reader will ask about. A scaled production or combat bonus is the invisible tax the direction document forbids, wearing the opposite hat, and it makes losing profitable. A reduced threshold for a trailing player breaks the single-readout property of §4 and makes the Watch a lie. Lengthening the leader's Vigil in proportion to their lead is the most tempting of these and it is the worst: it makes a decided game take longer, which is the exact failure this document exists to fix, and it punishes a player for playing well. The four instruments of VC-2880 all share one property that these do not — they give a trailing player a reason and an address to attack, and then require them to win the attack.

16. Placings, the record, and departure

VC-3030 At the end of a game every player MUST receive an integer placing from 1 to the number of seats. The winner MUST place 1. All other players MUST be ordered by the tie chain of VC-1520, applied to their state at the Seal at which each left the game or at the final Seal for those still live.

VC-3040 A player's placing MUST be non-decreasing in the number of Seals they survived, all else equal.

Rationale: this is the anti-quit rule made checkable. Tenure accrual is floor(Standing / 100) ≥ 0 at every Seal and is at least 1 for any player holding a single city, so surviving one more Seal never lowers a player's final Tenure and usually raises it. Quitting can therefore never improve a placing. This is a property of the arithmetic rather than an exhortation, and it should be asserted in a test.

VC-3050 The end-of-game record MUST contain: the winner and the route by which they won; every player's placing, final Standing, final Tenure and the turn they left; the stored Terms paragraph (VC-2000); the complete Chronicle; every dismissed linter warning; and the victoryLogicVersion and rulesetVersion under which the game ran.

VC-3060 Where a player departs a live multiplayer game — disconnection beyond the tolerance 05-multiplayer.md defines, or an explicit away state — their seat MUST be substituted by an AI rather than removed, and the seat MUST continue to accrue Tenure normally.

VC-3070 A substituted seat's final placing MUST be recorded against the departed player, and substitution MUST NOT freeze Tenure.

Rationale: the design must not make leaving attractive. A departed seat that froze its Tenure would be identical to conceding, and a departed seat that vanished would hand its cities to whoever was adjacent and rewrite the game for everyone else. Substituting an AI keeps the board intact and keeps the departed player's placing tied to how their empire actually fares, which is very likely worse than if they had stayed — and that is the correct incentive.

VC-3080 Substitution MUST emit a Chronicle entry visible to every player, and the reclaiming player MUST resume the seat with its state unaltered.

VC-3090 A capitulated, conceded or eliminated player MUST retain full spectator access to their own past Seal records and to the public Chronicle, and MUST receive the complete Chronicle at the end of the game.

17. Contracts on other documents

These are obligations this specification places on subsystems it does not own. They are recorded here so that a change on either side is detectable, and so that no requirement above has had to paraphrase another document's rules.

VC-3100 10-turn-model.md MUST provide the Seal as a single barrier point per turn, occurring after the Cascade has completed for every unit and after all end-of-turn resolution, at which no unit is mid-activation and every player's turn has resolved (VC-200, VC-210, VC-220). It MUST guarantee that no victory-relevant state changes between the barrier and the completion of the Seal, and it MUST provide the single monotonic entity sequence counter from which every tie-break in this document draws (VC-180).

VC-3110 01-game-rules.md MUST provide the following. Each row is a separate obligation and each is checkable; the requirement in the right-hand column is the one that fails if the row is not delivered.

Note on what this document does not ask for, so that 01-game-rules.md does not build it. It does not ask for Regions or Landmarks to be discoverable, decaying or fidelity-bearing: they are public, static victory scaffolding and they are outside the Intelligence Picture entirely. It does not ask for a regional capital to move, to be re-designated, or to be worth anything by itself. It does not ask for a Landmark to be placeable anywhere but on a city. And it does not ask for M, L, a Region's membership or a Region's city count ever to change during a game — VC-1035 and VC-1084 forbid it, and the elimination arithmetic of VC-2670 and the redrawable Board of VC-2400 are unsound if any of them does.

VC-3120 12-economy.md MUST provide: each city's integer effective Works per turn after Integration and traits (VC-530); the constant MAP_POTENTIAL_OUTPUT (VC-600); each city's Integration value for the re-Seat test of VC-1470; each player's current levy rate for the Levy Call (VC-1860, VC-2950); a Works grant into a named city's Yard (VC-1860); a Manpower grant subject to that document's own cap; and an accumulating construction sink for the Great Work supporting a per-turn contribution cap, a halving, and relocation (VC-1220 through VC-1250).

VC-3130 02-units-and-industry.md MUST provide: an integer worksCost per unit (VC-510); an in-supply flag per unit (VC-550); mass disband of a player's units without combat (VC-2520); and the integer MAX_DISPLACEMENT of VC-2650, which MUST be a sound upper bound including every transport, road, rail and chained-transfer effect legal within one turn.

VC-3140 11-combat.md MUST guarantee that every change of city ownership caused by combat or capture is complete and settled before the Seal barrier, so that the Seal snapshot contains no city in an indeterminate state.

VC-3150 13-command.md MUST add two Attention Event classes to the catalogue of CM-1720, both marked non-adaptable under CM-1790:

Rationale: CM-1790 exempts from adaptive demotion the classes where being wrong is unrecoverable, and it gives the example that the game must never learn to stop telling you your capital is about to fall. A rival two turns from winning the game is the same case, and so is a vote that will end the game if you ignore it — VC-2770 makes abstention count as "play on", which is only safe if the offer is impossible to miss.

VC-3160 03-architecture.md MUST provide: a dedicated PRNG stream named victory (VC-170); inclusion of the Seal record in the canonical state hash (VC-260); and the integer and per-mille conventions this document's arithmetic assumes (VC-110, VC-120).

VC-3170 04-ui-ux.md MUST own the presentation of the Watch, the Board, the Alarm banner, the Chronicle and the Terms, implementing the content requirements of §12 and §13. It MUST NOT compute any value this document defines, and it MUST NOT present a victory value at a precision finer than the band published for it.

VC-3180 05-multiplayer.md MUST provide: AI substitution of a departed seat without freezing its Tenure (VC-3060); transport of CastVerdictVote and Concede as ordinary logged orders (VC-320); and, in correspondence play, delivery of a Verdict offer within the VerdictWindow of VC-2780.

VC-3190 06-ai.md MUST provide: a deterministic Verdict vote policy derived from evaluation and the game seed, identical on every machine (VC-2810); an evaluator aware of every enabled Track, of its own Charter and Sealed Orders, and of Reduced status; and an AI that plays on rather than idling when Out of Contention, since VC-2730 leaves it in the game.

VC-3200 07-modding-content.md MUST allow a scenario to set every parameter this document declares settable, within the ranges it declares, and MUST NOT allow a scenario to add a Track to the catalogue of VC-880, alter a Standing weight, or alter a tie chain. Rationale: parameters are content; the scoring model is rules. A mod that changes what Standing counts changes what every tie-break in the game means, and no readout, estimate or lint rule would still be true.

VC-3210 The build pipeline MUST run headless self-play batches of at least 2,000 games per calibration cell, regenerating the length-estimate table of VC-2030, the L2 and L9 lint thresholds, and the Charter Weights of VC-1630, gated in CI per VC-3290 so that a balance change cannot silently invalidate them.

18. Versioning, performance, calibration and acceptance

VC-3220 Victory logic MUST be versioned by an integer victoryLogicVersion recorded in the replay header and in every save.

VC-3230 Any change to a progress function, a threshold function, an Ebb schedule, a Vigil default, a Standing weight, the tie chain, the Broken definition, an elimination test, the Verdict trigger, a band boundary, the report quantum, or a Rally or Defiance magnitude MUST bump victoryLogicVersion.

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

VC-3250 Presentation of victory state MUST be versioned separately by a victoryPresentationVersion, and a change to it alone MUST NOT invalidate a replay. Rationale: the same split 13-command.md CM-2050 and CM-2080 make, for the same reason — rewording a Chronicle line must not break every stored game.

VC-3260 The Seal MUST meet the bound of VC-310. The reach-bound computation of VC-2660 MUST complete within 20 ms for 8 players on a map of 256 cities and 4,096 occupied tiles, MUST be skipped entirely when its guard does not permit it, and MUST be computed at most once per player per Seal.

VC-3270 Band computation, quantisation and Chronicle emission MUST be incremental: a Seal at which no player's band changes MUST perform no re-derivation of published values beyond the changed Tracks.

VC-3280 The engine MUST expose every quantity this document defines to the AI evaluator and to the headless self-play harness as integers, without presentation formatting, so that the metrics of VC-3300 can be computed from a replay alone.

VC-3290 CI MUST fail where the calibration table's recorded rulesetVersion differs from the build's, or where any enabled preset's measured median length falls outside the estimate the Terms would present for it by more than 25 percent.

Rationale: this is the requirement that keeps VC-2030 and VC-2070 honest, and it is the one most likely to be quietly disabled when it becomes inconvenient. The estimate on the setup screen is a promise about how a player will spend an evening. A promise that nothing checks is a promise that will be broken, and it will be broken silently, and the first anyone will know is a review complaining that the ninety-minute game took four hours.

VC-3300 The following acceptance metrics MUST be computed from headless self-play batches and MUST be reported per preset. A metric outside its target MUST block release of a balance change until it is either restored or the target is explicitly and publicly revised.

Rationale: M1 is the headline. It is the direct measurement of whether the whole thesis is right — whether these games are still decided long before they end — and if it exceeds 250‰ the Verdict trigger is too strict or the Ebb starts too late, and the fix belongs in this document rather than in the economy. M11 and M12 are this document's own: M11 asks whether the comeback path exists in fact rather than on paper, and its lower bound matters as much as its upper — under 150‰ the instruments are decoration, over 350‰ they are rubber-banding and the leader is being robbed. M13 is the only one that cannot be automated and it is the most important test in the table.

VC-3310 The following worked computations in this document MUST be reproduced exactly by a conforming implementation and MUST exist as test vectors: the Standing computation of VC-570; the Ebb schedule of VC-870; the elimination arithmetic of VC-2630; the report quantum of VC-2270; the declined Verdict of VC-2830; the Terms paragraph of VC-2010; and the Chronicle rendering of VC-2460.

VC-3320 A replay MUST reproduce every Seal record byte-identically, and a divergence MUST be reported at the Seal at which it occurs rather than at the Seal at which it changes the outcome (VC-260).

VC-3330 An implementation MUST provide a mechanically checkable assertion that Tenure never decreases for any player at any Seal, and a test that VC-3040 holds — that surviving one more Seal never lowers a player's final placing, all else equal.

Rationale: both are one-line properties and both are load-bearing. The first is the premise of the entire elimination proof; the second is the entire anti-quit design. Neither should be left to a reviewer's attention.

Open questions

1. Vigil reset or decay. VC-690 decides Reset and states the argument: Reset is what makes one successful raid matter, and Decay quietly favours the stronger player. But this is the mechanic most likely to be experienced as unfair rather than as tense — losing a five-turn investment to a single landing may read as arbitrary to a player who does not see the design intent. VC-700 makes the two a single configuration integer specifically so the question can be settled by replaying identical seeds under both, and M2 is the metric that would settle it. Until that data exists the choice rests on an argument, not evidence.

2. Should Standing count military at all, and is the cap right? VC-540 counts army at a quarter of Works cost, capped at 250‰ of the civil subtotal. Excluding military entirely would make an eve-of-Horizon suicide offensive free; including it uncapped rewards hoarding an army that never fights. The divisor and the cap are both guesses, and the cap in particular has no derivation — it was chosen so that the largest plausible army adds about a fifth to a score dominated by territory. If the economy's unit costs move, this needs recalibrating or Prosperity and Dominion begin to collapse into each other.

3. Is Prosperity a distinct strategic shape or a shadow of Dominion? VC-1280 redefines it against realised output over potential output precisely to make it distinct, and the argument depends entirely on how strongly 12-economy.md couples output to Integration and supply. If a sprawling sixty-percent empire can sit at forty percent of realised potential, the two Tracks are different games. If it cannot, Prosperity is decoration and should be cut rather than kept for the sake of a fourteenth card. L9 is meant to detect this and VC-2110 concedes that L9 may not be computable honestly.

4. Does the Alarm's vision grant hand a coalition a free strike? In a six-player game the leader entering Alarm may be jumped by five opponents holding perfect information about eight of their cities. That might be exactly right — winning should be hard, and VC-2290 argues that a leader who reaches ninety percent has accepted being fought at a known place. It might instead mean that nobody ever dares cross ninety percent, which would be a disaster and would show up as M4 collapsing toward zero and M1 rising.

5. Is Cession: Auto cut at the right place? VC-2540 cedes to the Principal Aggressor with two or fewer other players live and creates Free Cities above that. The boundary is a judgement about when a three-city gift stops being a reward and starts being a coronation, and there is no data behind the specific number.

6. Eight turns of Unsettled. VC-2550 is a guess. The requirement it must satisfy is stated — the payout must be worth having and must not be worth engineering — but the number that satisfies it depends on the economy's payback curve, and if that curve moves this must move with it.

7. Charter Weights and handicaps are invention. VC-1660 says so on the setup screen, which is the honest thing to do, but a mode whose balance is admittedly unknown is a mode that will produce complaints in its first month. M10 is the metric; it needs at least 18,000 self-play games to be meaningful.

8. Defiance and Contested Warrants are the same argument twice. Both are rubber-banding, both are visible and bounded, and both default on outside Tournament. This document defends them as the price of solving F4, but the core audience for a game of this shape tends to resent assistance more than it resents losing. If M11 lands inside its band with both disabled, both should be cut, and the Vigil and the Ledger are doing the work alone.

9. Is halving the Great Work on capture right? VC-1250 admits there is no principled defence of one half. Total loss makes nobody build one; zero loss makes nobody take one. Somewhere between a third and two thirds is defensible and the choice needs play, not argument.

10. Ambition's numbers are a sketch. First to 5 with Minor, Major and Grand worth 1, 2 and 3 is a shape rather than a design, and the interaction with Warrant-granted Ambition — which makes the Track reachable without a single Sealed Order — has not been played.

11. Does the reach bound ever actually fire? VC-2660's guard means it is computed only when the remaining turns times MAX_DISPLACEMENT is smaller than the map, which on a fast roster may mean the last five turns of a two-hundred-turn game. If it never closes a Track before the Ebb or the Verdict does, it is a correct proof that earns nothing, and the honest response would be to keep it for the Board's Out of Contention readout and stop claiming it as an endgame mechanism.

12. Should the Horizon be hidden by default? VC-1360 decides public with an optional jitter, on the grounds that legibility is half the brief. The opposing case is real: a public Horizon invites a final-turns optimisation game that Tenure is supposed to prevent and only mostly does. The jitter option exists because the argument could not be settled.

13. M is calibrated against a granularity argument, not against play, and it decides whether Hegemony Ebbs at all. VC-1031 targets about six cities to a Region, which VC-1050 then makes self-defeating on exactly the maps most people will play: at the default K_start = ceil(5M/8) the starting threshold equals the uniqueness floor for every M ≤ 8, so on Skirmish and Medium maps — the reference map included — Hegemony never Ebbs, and its termination falls entirely to the Horizon and the Verdict. Three fixes are available and none is obviously right: raise M so that Medium maps land at 9 or more Regions, which makes each Region small enough to blur into Dominion; lower the default K_start toward ceil(2M/3), which gives the Ebb somewhere to travel but changes the Long War preset's published "Hegemony 5 of 8"; or accept it and say plainly on the card that Hegemony does not Ebb below nine Regions. The measurement that settles it is M8 (Ebb arbitrariness) read together with M3 (Track share) across the Medium and Large classes.

14. Are VC-1082's five Landmark invariants jointly satisfiable inside GR-1560's 64-attempt retry budget? K2 spacing, K4 nearest-assignment equity and K5's fifty-per-cent distance tolerance are stated as hard invariants because a Landmark dealt unevenly decides the Keys before turn 1, and 01-game-rules.md's own fairness invariants do not measure Landmarks at all. But three simultaneous geometric constraints on L sites, over a map that already has to satisfy GR-1590, GR-1600, GR-1610 and GR-1620, may simply reject too often — most likely on the Islands and Archipelago land ratios, where the candidate cities are clustered by the coastline rather than by the generator. If the retry budget is exhausted in more than a per-mille or two of generations, the right response is to relax K5's tolerance rather than to demote any of the five to advisory, because the failure a demoted invariant produces is the one map in fifty that decides a tournament.