Business Dealings

Deep dive on the financial and contractual machinery: how the company raises capital, how it owns and partners with other businesses, and how it earns the revenue that makes the network a going concern.

→ Parent: GDD.md

---

Sub-Systems

Business Dealings is several closely related sub-systems:

1. Bonds — debt issued by the company to finance projects and obligations.
2. Company Stock — the company's own publicly-traded equity: issuance, buybacks, dividends, and stock as compensation.
3. Equity — ownership stakes the company holds in other businesses on the map.
4. Contracts — revenue agreements with shippers, passengers, and the government.

A closely related sub-system, Procurement (sourcing of locomotives, rolling stock, materials, technology licenses, and skilled labor), is architecturally a specialized application of the contract framework but lives in its own deep dive — see Procurement.md.

Each is described below.

---

Bonds

Bonds are debt instruments. The company sells bonds to investors and receives cash; in exchange, the company commits to paying periodic coupons and repaying principal at maturity.

Why Issue Bonds

The default reason is to finance a specific project that exceeds available cash. A connection between two urban regions might cost more than the treasury holds; a bond issuance, sized to the project's projected cost (plus a margin), funds it. Bonds may also be used to refinance other bonds, ride out a cash crunch, or fund an equity acquisition.

Bond Properties

Each bond issue has:

• Principal — the amount raised at issuance.
• Coupon rate — the periodic interest paid.
• Maturity — when the principal must be repaid.
• Pricing — what the company actually receives per dollar of principal at issuance, which depends on the coupon and current market conditions.
• Linked purpose — what the bond is being raised for (project, refinancing, general).
• Type — simple, sinking-fund, callable, or convertible (see Bond Types below).
• Investor pool — who holds the bonds (see below).

Bond Types

Manifest Rail supports four bond types. The player picks which to issue based on the trade-offs each presents.

Type	Coupon vs. Simple	Cash-flow obligations	Special trait	When to use
Simple	Baseline	Interest only	None	Default; predictable
Sinking fund	Lower	Interest + scheduled sinking-fund deposits	Missing a deposit is a default-class event	Better terms when steady cash flow is reliable
Callable	Higher	Interest only	Issuer can retire early after the call date	Refinancing optionality; expected rate or cash changes
Convertible	Lower	Interest only (until conversion)	Bondholders can convert to company equity at a fixed ratio; conversions dilute existing equity	Equity issuance is gated; corporate-warfare lever

Notes on the non-simple types:

• Sinking fund. Lenders treat the discipline as added credit quality; the lower coupon is real, but each scheduled deposit is a hard cash obligation and missing one is treated as a default. Players who issue sinking-fund bonds during boom years can find themselves squeezed when a panic hits and the deposits keep coming due.
• Callable. The premium coupon is the cost of optionality. Useful late in long scenarios where interest rates move, or when the player expects a cash windfall (a major contract win, an equity sale, a successful project bringing fresh revenue) and wants to retire debt early.
• Convertible. The Erie War (1868) is the canonical use case — Gould and Fisk issued massive convertibles and converted them to flood the market and dilute Vanderbilt. Convertibles let the player work around a closed equity market and, in corporate-warfare scenarios, become a hostile-action lever in their own right.

Bearer vs. registered is not modeled as a mechanical distinction. The bond market is not something the player can invest in directly — capital that isn't financing operations should be doing something more interesting than buying back bonds — so the distinction is flavor only.

UX Requirement: Clear Implications at Issuance

The bond-issuance UI must display the chosen type's coupon rate, payment schedule, total expected cash outflow over the bond's life, and any extra obligations (sinking-fund deposits, conversion-dilution risk) before the player commits. The player should be able to compare types side-by-side without computing trade-offs mentally — particularly the difference between a simple bond and a sinking-fund bond, where the lower coupon hides an ongoing cash-flow commitment that becomes painful in a downturn.

Investor Pool: Who Holds the Bonds

Where the bonds are sold determines who bears the relationship consequences when things go right or wrong. The viable channels vary by era, by company size, and by deliberate choice:

• Local population — characteristic of early-era railroads. Company agents traveled town to town selling bonds directly to small-town residents. The investors are real, named people in specific regions, and they form a bondholder interest group within those regions' populations (see Populations.md). Goodwill consequences land on the regional Public, on both the company track and the player/executive track — bondholders feel personally betrayed when defaults happen, and the executive's name is on the certificate.
• Financial markets — characteristic of mature capital-market eras. Bonds are placed through underwriters and sold to banks, institutions, and wealthy investors at scale. Goodwill consequences are abstract and land on Financial Markets as a stakeholder.
• Mixed — many real issues used both channels. The split is part of issuance authoring.

The era's communication and finance infrastructure shapes which channel is realistic. An 1830s railroad has no choice but to sell locally; a 1900s railroad has full access to capital markets. Mid-era scenarios sit in the transition. (This is an example of where the hybrid Clout-shift authoring matters — early-era scenarios override the default "bond issuance shifts Financial Markets Clout" entry, because in that era the bond shifts regional Public Clout instead.)

What Affects Bond Terms

• Company goodwill — high goodwill lowers coupon rates and improves pricing; tarnished goodwill raises rates or makes issuance impossible. For local-population bonds, the relevant goodwill is with the regional Public; for market bonds, with Financial Markets.
• Existing debt load — overleveraged companies pay more for new debt.
• Macroeconomic conditions — scenario-driven interest rate environment.
• Linked project quality — bonds tied to a credible, well-scoped project price better than open-ended general obligations.

Servicing and Default

Coupons must be paid on schedule. Failure to pay is a default event with severe goodwill consequences. The shape of the consequences depends on the investor pool:

• Local-population defaults are devastating for regional sentiment in the towns where bonds were sold. The bondholder interest fraction in those regions becomes hostile — deep negative goodwill on both the company and player/executive tracks, typically a sticky modifier only clearable through full repayment, public restitution, or scenario-scripted resolution. Historical examples abound: small-town residents lost life savings when frontier railroads collapsed, and never forgave the executives whose names were on the bond certificates.
• Financial-market defaults are punishing in a different way: Financial Markets goodwill collapses (often a sticky/permanent modifier — see the Default of 1873 example in Goodwill), bond pricing for any future issuance becomes prohibitive or impossible, and the company may be forced into restructuring, asset sale, or scenario failure depending on scenario settings.

Either form of default may also trigger scripted events — lawsuits, political fallout, regulatory hearings.

---

Company Stock

The player's company is itself publicly traded. The stock market for the company's own shares is basic — modeled in the spirit of Railroad Tycoon 2 and Railroad Tycoon 3 rather than as a deep finance simulation. The player has four primary actions:

• Issue new shares (dilution) to raise cash.
• Buy back shares to reduce float and concentrate ownership.
• Set dividends per share, paid proportionally to all holders.
• Grant stock as compensation to named staff as part of hiring or retention.

Founding the Company

In scenarios that begin with the company being founded (rather than inheriting an established one), the player decides how to capitalize the new venture:

• Personal cash equity. The player character invests personal cash into the company in exchange for an equivalent founder's stake.
• Stock issuance via underwriter. An underwriter takes the rest of the funding need by selling stock to the public on the company's behalf. The underwriter provides a quote — what cash they will produce in exchange for what percentage of equity, at what fee.

Underwriters are financial-firm companies based in major urban regions. Like any other business entity in the game, each underwriter has its own reputation, which interacts with the player's reputation to shape the terms of the quote. The roster mixes:

• Historical underwriters — real firms active in the scenario's era and region (e.g., J.P. Morgan & Company, Kidder, Peabody & Co., Baring Brothers, Kuhn, Loeb & Co., August Belmont & Co., depending on date and setting).
• Generic underwriters — procedurally generated firms used as defaults where scenarios lack well-known historical names or to fill regional gaps.

The flow is modeled in the spirit of Railroad Tycoon 2's founding screen: the player picks the cash/equity mix, picks an underwriter (when more than one is on offer), and accepts the quote. The full quote model is pinned below.

Underwriter Quotes: Availability and Terms

The founding capital target K is scenario-authored (the company's needed founding capital). The player chooses a personal-cash contribution C ∈ [0, min(personal cash, K)]; the underwriter covers the remainder need = K − C by selling stock to the public. If need ≤ 0 the venture is fully self-funded — no underwriter, the player owns 100%.

Availability — keyed to the player's regional standing, one quote per home firm. Reputation here is the player character's personal standing (per-region, player track) in each major urban region (a region carrying the majorUrban profile flag — see Region Scope). A region qualifies when the player's standing there ≥ quoteEligibilityThreshold (default 60 — the Respected floor). Each qualifying region then yields one quote per active underwriter homed there:

• No qualifying region → no quote; founding is personal-cash-only (the player owns 100% of whatever C capitalizes).
• One qualifying region with one home firm → one quote (that underwriter). The common case for a small financial center.
• Several home firms across qualifying regions → one quote each, sorted by player standing first, then firm reputation, capped at maxQuotesShown (default 3) — the player shops competing quotes. A strong financial center (e.g. Detroit, with several rostered houses) can fill the whole slate on its own; this is what makes a tiered roster meaningful.

Each quote comes from a roster firm homed in the qualifying region (a named entity per Pillar 3), filtered to firms active on the founding date (activeFrom/activeUntil). A qualifying region with no active rostered firm gets a generated generic firm (neutral dispositions, reputation derived from region size — same historical-vs-procedural pattern as named individuals).

Sequencing note (game-dev). Player per-region personal standing is the player-character entity's data (delivered in M14_C C-6). For founding at scenario start, this standing is scenario-seeded (playerFoundingStandingByRegion below — a known industrialist starts Respected in Detroit, an unknown starts Neutral), so C-2's founding flow does not block on C-6. For post-start foundings, it reads the live player-character standing. See open question at the end of this doc.

Terms — three numbers per quote: cashToCompany, equityDemanded, feePct. Better combined reputation bends every term toward the player (less equity surrendered, lower fee, more cash), per Pillar 2.

Let:

• equityFair = need / (need + C) — the public's cash-proportional ownership (the fair, no-premium baseline).
• T = (w_player · S_player + w_firm · S_firm) / 100 — the terms score in [0,1], blending the player's standing in the firm's region (S_player) and the firm's reputation (S_firm); weights w_player (default 0.6) + w_firm (default 0.4) = 1.
• feeDisposition, equityDisposition — per-firm multipliers from the roster (1.0 = neutral; >1 greedier, <1 more generous), each clamped to [0.5, 1.5].

Then:

equityDemanded = equityFair · (1 + premiumMax · (1 − T) · equityDisposition)
                 clamped to [equityFair, equityCap]          (equityCap default 0.90)

feePct        = feeBase + feeSpread · (1 − T) · feeDisposition
                 clamped to [feeMin, feeMax]                  (defaults 0.03, 0.07, 0.02, 0.12)

feeCash       = feePct · need
cashToCompany = need − feeCash

On acceptance: the treasury receives C + cashToCompany; the public float gains equityDemanded (distributed across the firm's affinity regions); the player's founder stake = 1 − equityDemanded; feeCash leaves the system as the underwriting spread (cost of capital). A sterling player + prestigious firm (T → 1) pays no equity premium and the floor fee, retaining their full cash-proportional share; a barely-eligible player + middling firm pays the largest premium and spread. Volume/leverage does not enter founding — the company does not yet exist, so reputation alone bends the terms (the leverage model applies only to a going concern's counterparties).

Worked examples (K = $10,000; defaults above):

	A — strong / prestigious	B — threshold / middling	C-Detroit	C-Grand Rapids
S_player	85	60	85	70
S_firm	80	45	80	55
equityDisposition	1.0	1.0	1.0	1.0
feeDisposition	1.2	1.0	1.2	0.9
C	$2,000	$1,000	$3,000	$3,000
need	$8,000	$9,000	$7,000	$7,000
equityFair	0.800	0.900	0.700	0.700
T	0.83	0.54	0.83	0.64
equityDemanded	0.868	0.90 (clamped)	0.760	0.826
feePct	4.4%	6.2%	4.4%	5.3%
cashToCompany	$7,646	$8,440	$6,690	$6,631
founder stake	13.2%	10.0%	24.0%	17.4%

Example C is one player holding two quotes: the Detroit house (player Revered there, prestigious firm) beats the Grand Rapids house on every term despite GR's more generous fee disposition — the standing term dominates. The player shops and takes Detroit. Example B shows the equity clamp biting: a barely-eligible player putting in little cash is held at the 90% float floor and pays the steepest spread.

What lives in JSON — scenario economy.json → founding block (tunable coefficients/bounds, never hardcoded in C#):

"founding": {
  "targetCapitalization": 10000,
  "quoteEligibilityThreshold": 60,
  "maxQuotesShown": 3,
  "standingWeights": { "player": 0.6, "firm": 0.4 },
  "equity": { "premiumMax": 0.5, "cap": 0.90 },
  "fee": { "base": 0.03, "spread": 0.07, "min": 0.02, "max": 0.12 },
  "genericFirm": { "reputation": 50, "feeDisposition": 1.0, "equityDisposition": 1.0 },
  "playerFoundingStandingByRegion": { "detroit": 70 }
}

(majorUrban is a flag on the region profile, not here; playerFoundingStandingByRegion seeds the scenario-start founding moment only.)

What lives in the underwriter roster — a separate underwriters.json authored by the railroad-historian for Michigan-1920s firms + regional generics. The game-designer specifies only the schema; the historian fills it:

{
  "underwriters": [
    {
      "id": "firm_id",
      "name": "Display Name",
      "homeRegion": "<major urban region id>",
      "regionalAffinity": ["<region id>", "..."],
      "reputation": 70,
      "feeDisposition": 1.1,
      "equityDisposition": 1.0,
      "isHistorical": true,
      "activeFrom": "1900-01-01",
      "activeUntil": null
    }
  ]
}

Per-firm: reputation is the firm's prestige (S_firm); regionalAffinity lists the regions where it can place stock (primary = homeRegion); the two disposition knobs let the historian characterize a firm independently (a prestigious-but-greedy house = high reputation, high feeDisposition); activeFrom / activeUntil window the firm to its real operating years. Historical exemplars are East-Coast (J.P. Morgan & Company, Kidder, Peabody & Co.) — the historian supplies the period-and-region-accurate Michigan roster.

The player character may hold and lead more than one company at a time — see Multiple Companies: Authority and Engagement. Founding is one way a company enters the player's portfolio; buying in, taking board seats, and winning takeovers are others.

The player's company is a fresh startup, not a historical road. The founded company is a new named entity the player names (free text in Free Scenario; scenario-authored in Campaign/Standalone) — never a real historical incumbent, which are reserved as rivals. In scenario data the player's company therefore carries a reserved, non-historical id (recommended player_railroad) distinct from every rival id, with a scenario-default display name the founding setup replaces; this keeps every real road — including the Detroit & Mackinac Railway — free to seed as a named rival (Pillar 3). (Resolves the michigan_1920s detroit_mackinac id collision: free that id for the real rival, and give the player's primary company the reserved id. The specific reserved-id string and the default fictional name are content/implementation details — recommended id player_railroad.)

Capital Structure

The company has an outstanding share count. Ownership is tracked at two levels:

• Named-entity ownership — tracked individually for entities that matter strategically: the player character, player-company executives (named staff who hold shares from compensation, founding stakes, or open-market purchases), competing companies (when a competitor owns shares in the player's company directly), and competing-company executives.
• Public float — everything else, broken down per region. Regions where the company operates accumulate public shareholders (locals who use the railroad and invest in what they know); regions where the company has no presence hold few or no public shares. The geographic distribution of the float is itself an asset to the player — public shares in regions where the company is well-liked tend to vote with the incumbent in any takeover contest (see Market Dynamics below).

The cap-table panel reads as a list with each named holder's name and percentage; the public float is shown broken down by region. The total always sums to 100% of outstanding shares.

Issuance and Buyback

• Issue shares. The company creates new shares and sells them on the market for cash. New shares enter the public float, distributed across regions roughly in proportion to where the company has presence and reputation; existing percentage stakes are diluted accordingly. Issuance is gated by Financial Markets goodwill — a tarnished company finds the market unwilling to absorb new issuance, or only at a deep discount.
• Buy back. The company uses treasury cash to repurchase shares, reducing the public float and raising existing percentage stakes. Useful to defend against hostile accumulation, signal confidence, or return cash to shareholders without committing to ongoing dividends.

Dividends

The player sets a per-share dividend, declared quarterly. When paid, every share receives the payment — the player character's, the executives', the competitors', and the public's — and the cash leaves the treasury. Dividends are the main mechanism by which the player character realizes personal income from the company's success, and a stable or rising dividend is a signal that tends to support the share price.

Stock as Compensation

Stock grants are an alternative or supplement to cash salary when hiring or retaining named staff. A talented Chief Engineer might accept a lower cash salary in exchange for a stock package, especially during the company's growth years when the upside is real. The grant becomes part of that named individual's tracked holdings and persists with them on departure (they keep the shares). Stock compensation is also a strong tool against poaching: a long-tenured executive with a meaningful stake has real reason to fight for the company and is harder to lure away.

Magnitudes reflect historical norms. Stock comp scale is anchored to the era's actual practice rather than modern equity-heavy norms. By 19th- and early-20th-century railroad standards:

• Founder's stakes, granted at incorporation to the people who put the company together, can be substantial — historically often 5–25% of the company for top founders, with a long tail of smaller stakes for other founding participants.
• Hire-on packages for senior executives at an established company are typically modest — usually fractions of a percent rather than double-digit grants.
• Mid-level and junior staff receive token grants or none. Stock comp is reserved for genuine retention pressure on staff who could realistically be poached.

Modern-era scenarios (post-1950s) loosen these norms somewhat, tracking the real-world shift toward larger equity-heavy compensation. Specific magnitudes are scenario-tunable; the design intent is that the player feels they are operating in their era's actual labor market — not in a modern one.

Market Dynamics

• Share price is driven by the simulation: company profitability, dividend history, Financial Markets goodwill, outstanding debt load, recent issuance/buyback activity, and scenario-driven market events (panics, booms, regulatory shocks). The specific formula is scenario-tunable; what matters at the design level is that price moves with the underlying state in a way the player can read.
• Control and takeover. Hostile takeover follows shareholder voting mechanics, not pure direct ownership. The threshold for control is 51% of votes cast. Votes break as follows:
• Named-entity holders vote their actual shares — the player character votes their stake, executives typically vote with the company, and a hostile competitor votes their accumulated stake against the incumbent.
• Public float votes by region, and each region's votes break based on the company's reputation in that region. Regions where the company is well-liked vote with the incumbent; regions where it is reviled vote with the challenger; neutral regions split or abstain.

The result: a hostile takeover requires both a large direct stake and an unfavorable reputation environment for the incumbent. A player at 30% direct ownership can defend successfully if the public regions vote heavily with them; a player at 40% direct ownership can be ousted if their reputation has collapsed across operating regions. Convertible bonds (see Bond Types) are a common counter-lever — a wave of conversions floods the float and dilutes the hostile accumulator's percentage.

Consequences of being ousted. By default, losing a hostile takeover is not game over — the player character simply no longer owns or controls that company. They retain their personal assets, reputation, and any remaining stock holdings (now in a company they no longer run); losing the leadership of one company leaves the rest of their portfolio intact — they may still lead or sit on the boards of others, and may start or buy into new ventures. Scenarios can override this default to script their own outcomes — a "save the railroad" scenario might end on takeover; a managed-decline scenario might keep the player on as a subordinate executive; a corporate-warfare scenario might transition the player into the role of the new acquirer's antagonist.

---

Multiple Companies: Authority and Engagement

The player character is not limited to a single company. They can lead one railroad, sit on the board of another, and hold a passive stake in a third at the same time. Two independent questions govern how the player interacts with any company in their portfolio: how much authority they hold there, and how much they choose to engage.

Authority — What the Player May Do

Authority is earned through the ownership and shareholder-voting mechanics described above (Capital Structure, Market Dynamics): buy shares, accumulate enough to win board seats, and — with control of the vote — install yourself or your choice of leader. Three levels:

Leader — full management surface

The person in executive control. The player gets the complete management surface — identical to the company they started the scenario with: commissioning projects, signing and negotiating contracts, issuing bonds, setting dividends, hiring staff, the works.

The leader's title is scenario-authored to fit the company's country, era, and form. Mechanically they are all "the leader"; the label grounds the period.

Setting	Typical leader title
1920s United States, chartered corporation	President — often under a Chairman of the Board who holds controlling ownership
1830s–1850s early American line	Superintendent, or President
Victorian / Edwardian Britain	Chairman (the controlling figure) or Managing Director, with a General Manager as operating chief
Continental European state railway	Director-General
Mid-20th century onward	Chief Executive (CEO)

Where ownership and executive control are split — a Chairman-of-the-Board owner above a President, common in the period — the scenario names which role the player occupies. The player can hold the controlling-owner role while a hired executive runs the company day to day; that is simply delegation (below).

The same per-setting authoring that picks the leader's title also picks the region term the map is partitioned by (county, département, uyezd, …) — see Region Scope Across Settings.

Board member — the board lever set

A Director (era- and country-appropriate term). The player gets exactly the levers an AI board member has — the set is identical for player and AI, so a board seat means the same thing whoever holds it:

• Vote on board matters — leadership appointments, dividends and buybacks, major financing, merger and acquisition proposals, and any hostile bid for the company.
• Privileged information — the company's internal books and reports, beyond what a passive holder or the public can see.
• Propose strategic direction — table proposals (expand into a region, cut a dividend, pursue a target) that the board then votes on.
• Influence executive hiring and payouts — nominate or oppose a leader, push on compensation.

A board member does not directly commission projects, sign contracts, or allocate fleet — those are the leader's surface. Board influence is exercised through votes and proposals, and its weight depends on how many seats the player and their allies control.

Passive holder

Holdings, dividends, and whatever information the stake entitles the player to (subject to information lag). No operational levers — the value is financial (price appreciation, dividends) and optional (a foothold to accumulate toward a board seat or a takeover).

Engagement — How Much the Player Does

Authority sets the ceiling; engagement is the player's choice within it. For any company where the player has a management surface, they pick between two modes — independently per company, changeable at any time:

• Hands-on — the player operates the surface directly.
• Delegated — the company runs on its hired staff, who make decisions according to their own competence, traits, and priorities (per ProjectManagement — Staff and Labor). A delegated company needs a capable head (a hired leader / general manager) plus the staff to execute; delegation quality is hiring quality. A cost-cutting head runs the company differently than a growth-chaser, and the player feels the difference in the results.

Delegation is never a black box: the staff's decisions are reported back (in the inbox and the company's records) and trace to the responsible staffer's traits, so the player can audit why a delegated company did what it did — and decide whether to step back in or replace the staffer (per Pillar 6 — The Player Sets Their Own Depth).

The player's primary company is simply the one they keep hands-on. There is no hard cap on how many companies the player can hold or lead — the only real limit is attention, which is exactly what delegation is for. The intended arc mirrors Out of the Park's "run the big club hands-on, let the farm system run itself": lead one railroad closely, delegate the others, and step into a delegated company only when its inbox surfaces something worth your time.

Private Capital vs. Company Capital

Two distinct pools of money fund portfolio play, and the design keeps them separate:

• Personal (private) capital — the player character's own cash and stock holdings (per GDD — The Player Character). This is what the player spends to buy into companies personally — building a private stake, funding a personal run at a board seat or a takeover. Dividends from companies the player holds flow into this pool.
• Company capital — a company's own treasury. A company can itself hold equity in other businesses (captive shippers, suppliers, even other railroads) as a corporate strategy. That is the company acting, not the player personally.

The distinction drives both control and consequence: a stake bought with the player's private capital is the player's, and survives the loss of any one company; a stake held by Company A is Company A's, and changes hands if the player loses Company A. Hostile-takeover and corporate-warfare play turns on which pool is doing the buying.

Rivals as Full Companies

AI competitors are not a thin layer bolted onto the player's company — each rival is a full Company runtime with its own company-scoped service graph (treasury, rail, contracts, goodwill, bonds, fleet, projects, equity), ticking off the shared world clock exactly like a player-held company (Pillar 3; the GDD already frames competitors as "dynamic actors with their own networks, goodwill, finances, projects, and contracts"). There is one kind of company in the world; "rival" vs. "player-led" is not a different runtime but a position on the authority × engagement axes above:

• Rival — a company the player holds low or no authority over, delegated to an AI head.
• Player-led — a company where the player holds Leader authority and engages hands-on (or keeps it delegated by choice).

Buying into a rival therefore does not convert one runtime into another — it slides the same company along the authority axis (buy-in below).

The rival AI is a delegated head

The rival AI reuses the delegation engine (the C-4 DelegatedManager / DelegationCompetence machinery) rather than running a separate rival-strategy AI. A rival is, in design terms, a company fully delegated to an AI-controlled head — which is exactly what the delegation engine already is: the company runs on its staff, who decide by their own competence and traits, with every call audited back to the responsible staffer (Engagement, Pillar 6). A parallel rival AI would fork the "AI operates a company" path, violate the same constraint the board loop holds (the AI drives the identical surface; only the input source differs), and make rival conduct a black box — which Pillar 6 explicitly forbids.

What the rival head decides each tick is the Leader management surface: commission feasibility studies and activate projects; accept and triage contracts; issue bonds, set dividends, issue/buy back stock; procure and allocate fleet; pursue equity and trackage rights; and vote / table proposals on any board it sits on.

The one piece the delegation engine does not already carry is strategic disposition — a rival's posture and scenario focus (an aggressive consolidator vs. a conservative dividend-payer; "pursue UP iron expansion"). That is not a second decision system: it is the head's traits + mandate, an input that weights the delegation engine's priorities, exactly as a cost-cutter vs. growth-chaser head already runs a delegated company differently (Engagement). It keys off the existing rivals.json aggression / baseStanding knobs (already cited for AI director disposition) plus a scenario-authored focus — the GDD's "scenarios script a competitor's high-level focus, dynamic within it" is precisely this layering.

RivalService accordingly becomes an orchestrator/registry, not the rival simulation: it holds each rival's archetype / disposition + scenario focus and steps every AI-headed company's delegated tick against that company's own service graph. It is not absorbed, but its old thin-AI shared-contract-pool logic is replaced by the full delegation-driven runtime. Rival companies live in the same company registry the Portfolio reads; a rival the player holds no stake in is simply a company absent from the portfolio.

Starting networks, capital, and competitive balance

Planning ruling for C-1_A_3_B (rival-network seeding). The scale, capital, and aggression magnitudes below are RECOMMENDED pending user sign-off — they are the opening-difficulty lever and the user wants eyes on them before authoring. The structural calls (spine-not-full-network, expand-via-delegation, capital-as-character, aggression-untouched) are designer calls, grounded as noted.

Rivals seed with real, recognizable networks — they are the established incumbents the player's founded startup competes against. The intended fantasy is the scrappy upstart among incumbents: the player founds a company with a modest capitalization and a tiny seed network (Player Setup at Start — "enough to begin a small network … not lavish enough to skip the early-game decisions"). The player out-relationships the field, not out-muscles it: contract acquisition is relationship-weighted and the leverage model lets a high-goodwill small operator win business a giant reviled one cannot (Pillar 2). Scale ≠ unwinnable.

Scale — spine, not full density (designer call). Authoring each road's full historical mileage (Pere Marquette ~1700 route-mi, Michigan Central ~1000+) at full branch density would (a) make the player a flea past the point of the intended fantasy and (b) flood contested settlements past their growth envelopes (Populations — contested-settlement growth). Instead author the real spine — each road's trunk corridor(s), division mainline(s), and key junctions, at correct line tier — and cap feeder/branch density to a representative subset. The road stays recognizably itself (Pillar 3) and shapes its corridor (Pillar 7) without an unbounded authoring or balance surface.

RECOMMENDED tier → budget (player seed for reference: 5 stations / 4 segments):

Tier	Stations	Segments	Composition
LARGE	8–14	8–16	real trunk + 1–2 division mainlines + key junctions; mostly standard/trunk; ≤3 stub branches
MEDIUM	5–8	5–8	one real spine; branch tier on feeders, standard on the core
SMALL	2–4	2–3	minimal stub on real anchor node(s)

Place each road at the top or bottom of its band by real footprint: Pere Marquette (largest in-state) tops LARGE; Grand Trunk Western and Michigan Central fill LARGE; Ann Arbor and Detroit & Mackinac sit MEDIUM; Detroit, Toledo & Ironton sits SMALL (see thin-coverage roads).

Capital — fuel, and character (designer call; magnitudes RECOMMENDED). Each rival seeds a treasury that funds operating costs and expansion. Treasury is tier-scaled and footprint-weighted, and is also a characterization lever (Pillar 3) — a small road with a deep-pocketed backer carries an above-tier war chest (see Detroit, Toledo & Ironton under thin-coverage roads). Tier → base-treasury defaults live in economy.json (tunable); per-rival overrides in rivals.json (startingTreasury) — never hardcoded (CLAUDE.md). RECOMMENDED bands, anchored to the player's ~$10k founding target: LARGE ≈ $40–80k, MEDIUM ≈ $15–30k, SMALL ≈ $5–12k. Incumbents hold war chests but not infinite ones — operating costs bleed an idle treasury, so the field still feels finance pressure.

Expansion — on, via delegation (designer call). Rivals are not static. Each rival's day already runs on the delegation engine, whose Leader surface includes commissioning feasibility studies and activating projects — so rivals expand their networks through the same gated, capital-funded path the player uses, governed by their treasury + their disposition (aggression + scenario focus weight the delegation priorities). There is no separate expansion AI and no artificial network cap beyond what capital and the feasibility gate impose — a parallel rival-build system would make rival conduct a black box, which Pillar 6 forbids. Sequencing note (game-dev): shipping starting networks first and enabling rival-commissioned expansion in a follow-up wave is a fine implementation order — but the design intent is that rivals expand; static-forever is not the target.

Aggression / field feel — untouched (designer call). The existing aggression (30–70) is a disposition knob (how readily the delegated head accepts contracts / pursues expansion), not a scale knob; real networks + capital now carry the new contention, so aggression does not need retuning for scale. Keep the historian's per-road spread — it expresses character (Pere Marquette the aggressive "everywhere" road at 70; Detroit & Mackinac the declining isolate at 30–35). Intended opening difficulty: a moderately competitive field of established incumbents the player out-relationships, not out-builds (Pillar 2). If playtest finds the field too punishing, the first lever to pull is rival scale/capital (the balance axis), not aggression (the character axis).

Red flag: rivals authored at full historical density (breaches growth envelopes, crushes the upstart fantasy); a rival treasury so large operating costs never bite; a separate rival-expansion AI that bypasses the delegation engine (black-box conduct — Pillar 6).

Thin-coverage and gap roads

Three seed-geography calls fall out of the historian's topology research:

• Detroit, Toledo & Ironton — keep active, small network, deep treasury (designer call). ~85% of DT&I's mileage is off-map in Ohio; on the Michigan seed it is a Detroit-south stub. Cutting its active slot would delete a real named entity (Pillar 3) and lose the Henry Ford ownership (1920–29) — exactly the texture the design wants. Instead seed it SMALL (2–4 stations) but give it an above-tier, Ford-money treasury (MEDIUM band) — a thin-mileage road that contends on its backer's capital, not its track. Recommended it reach at least one contested county seat (Monroe) so it is a real Detroit-area competitor for auto/coal traffic rather than a stub through non-seat hamlets. Exact anchor-node selection within the SMALL budget = railroad-historian geography call.
• Grand Rapids & Indiana corridor — add a 7th LP rival (USER call). The PRR-controlled GR&I "Fishing Line" (Kalamazoo–Grand Rapids–Cadillac–Petoskey–Mackinaw City) is a LARGE, settlement-rich N–S west-Michigan corridor owned by no authored rival — a constellation gap (Pillar 3) and an unshaped corridor (Pillar 7). Folding it into Michigan Central or Pere Marquette is historically wrong (PRR ≠ NYC ≠ PM) and blurs the named-entity texture; leaving it as ownerless "neutral track" contradicts the seed's company-owned-lines model. Recommended: author a 7th active LP rival, grand_rapids_indiana (PRR-controlled), LARGE, owning the corridor — it gives Pere Marquette a real west-Michigan competitor. Flagged a USER call because it expands the active rival roster and the authoring/balance surface.
• Character (designer call): baseStanding 55, aggression 50. Standing 55 seats it with its LARGE peers (Pere Marquette 55, Grand Trunk Western 55) and just under the NYC-system trunk Michigan Central (60) — a respectable established PRR lessee whose resort/passenger orientation carries real public goodwill, but not the premier trunk. Aggression 50 reads as a steady corridor road on its established resort + lumber/agriculture niche — a conservative PRR lessee, clearly below the aggressive trunk consolidators (PM 70 / GTW 65 / MC 60) yet above the small/declining roads (Ann Arbor 45, Detroit & Mackinac 35). Distinct named-entity character, not a roster duplicate (Pillar 3); standing as a live lever (Pillar 2). Per user decision D this authors only the new rival; existing rivals' character knobs are untouched.
• NYC "Old Road" (ex-Lake Shore & Michigan Southern, southern tier) → fold into Michigan Central (designer call). Both were NYC-controlled; one coherent named NYC road (Chicago–Detroit trunk + southern-tier main) reads better than two fragments (Pillar 3). Affirms the historian's recommendation; exact node assignment is the historian's geography call.

Buy-in: the authority slide

A rival is a first-class Company the Portfolio can hold a stake in. Buying in moves the company up the authority ladder without re-instantiating it:

• Passive holding — a portfolio entry; dividends + entitled info (subject to lag). The AI head keeps driving the company unchanged.
• Board (Director) — the board lever set: vote, privileged books, propose, influence hiring. The AI head still runs day-to-day, but the player can now table proposals and vote — including Appoint / replace leader (supermajority) to install themselves or a chosen head.
• Leader — won via the shareholder vote (51% / CapTable) or a board appointment. The player now picks engagement: take the company hands-on, or keep it delegated to a head of their choosing (possibly the incumbent). The company is now "player-led," but it is the same runtime throughout — only authority and who-supplies-input changed.

This is the authority × engagement model doing exactly what it was built for: authority is the ceiling, engagement the choice within it, and a rival is just a company whose ceiling the player has not yet raised.

Board Governance: The Proposal Loop

The board lever set (vote / privileged information / propose strategic direction / influence executive hiring) is exercised through an ongoing governance loop — proposals are tabled, the board votes, and carried resolutions apply to the company. This is the real mechanism, not a set of one-shot modals, and it runs for every company that has a board, whether the player Leads it, sits on it as a Director, or merely watches an AI-led one they hold.

Two voting systems, kept distinct

Manifest Rail has two votes, and they must not be conflated:

1. Shareholder voting — who controls the company. Share-weighted: 51% of votes cast, named holders voting their shares and public float voting by regional reputation. This is the already-shipped CapTable engine (TakeoverSucceeds); hostile takeovers, change of control, and electing the controlling owner resolve here. No parallel takeover engine is built — the board loop reuses this, it does not reimplement it.
2. Board governance voting — how the company is run between control contests. Seat-weighted: the company's Directors vote on proposals, one vote per seat (a chairman or dominant holder may hold several seats). Routine strategic decisions resolve here.

The relationship is explicit: shares elect the board; the board governs by seat-vote. A hostile bid is a shareholder contest (CapTable); when one is live, the board separately votes a Respond-to-hostile-bid proposal (seat-vote) authorizing defensive measures (buyback, convertible flood — see Bond Types, Issuance and Buyback), whose effects feed back into the CapTable state that decides the outcome. The board votes the response; CapTable decides the control outcome. After any change of control the board is reconstituted (re-apportioned, below).

Board composition

Each company has an authored seatCount (default 7, scenario-tunable). Seats are apportioned from the cap table:

• A named holder with fraction ≥ seatThreshold (default 1/seatCount) receives round(fraction · seatCount) seats.
• Remaining seats are independent directors, who vote each proposal by the company's regional reputation — the same reputation predicate the CapTable takeover uses, reused at seat granularity, not duplicated. Independents back incumbent leadership when reputation is strong and side against it when it has collapsed.

Board control therefore tracks ownership and reputation, mirroring the takeover model one level down. The player's seat count follows their (and allies') share fraction; a Director with one seat on a seven-seat board has real but bounded weight, exactly as the board lever set describes.

The loop (state machine)

Tabled ──▶ Open ──▶ ┬─ Carried ──▶ Applied ──▶ Closed (recorded)
                    ├─ Failed ────────────────▶ Closed (recorded)
                    └─ Lapsed (no quorum) ────▶ Closed (recorded)
(Tabled / Open) ──▶ Withdrawn (proposer pulls) ▶ Closed (recorded)

1. Tabled. A proposal is raised. Sources: the player (when Director or Leader — the propose strategic direction lever); an AI director (via event); or an auto-trigger (a live hostile bid auto-tables Respond-to-bid; the periodic board meeting auto-tables standing items).
2. Open. Directors cast For / Against / Abstain within a deadline (option decay applies — per Pillar 4). The player votes their seats manually; AI and independent directors vote by disposition + company reputation.
3. Resolve. Tally seat-votes. Quorum (default ≥ half the seats vote) is required or the proposal Lapses. Carried needs a simple majority (>50% of seats voting) for routine items, a supermajority (≥ 2/3) for leadership change, merger, and sale.
4. Apply. A Carried proposal dispatches its effect to the owning service (table below). Failed / Lapsed / Withdrawn just record.
5. Closed (recorded). The outcome is written to the persisted board history and surfaced in the inbox.

Cadence is hybrid: most proposals are event-driven (a bid, a player proposal, an AI proposal arrive as inbox events with deadlines); a periodic board meeting (default annual, scenario-tunable) batch-tables standing items (leader confirmation, dividend ratification). Consistent with Pillar 5, the loop is menu-and-inbox driven — never a real-time clock.

What can be proposed, and what each resolution does

The propose strategic direction lever is this table. Carried effects route to existing services — the board loop is an authorization layer, not new economic machinery:

Proposal	Carried effect	Vote rule
Expand into region	Commissions a feasibility study for the named expansion	majority
Set / cut dividend	Changes the per-share dividend	majority
Authorize financing	Approves a bond issue or share issuance above the board-approval threshold	majority
Pursue acquisition	Authorizes pursuit of an equity stake / takeover of a named target	majority
Appoint / replace leader	Nominates or removes the company's leader (the influence executive hiring lever; drives delegation)	supermajority
Respond to hostile bid	Authorizes defensive measures feeding the CapTable contest	majority
Merger / sale	Approves merging or selling the company	supermajority

Leader vs. Director under the loop. A Leader acts directly on the operational surface (commission / sign / allocate) and may table proposals — but under the LOW ratification band (the canonical stance; see resolved α), the governance teeth bite from day one: every boardroom proposal type — not just leader replacement, merger, and sale, but also routine dividend and financing moves — tables to the board and requires ratification, even from the Leader. There is no "discretionary band" of routine acts a Leader applies unilaterally; the band is set effectively at zero (leaderRatificationRequired lists all proposal types in economy.json governance). The Leader is not powerless over routine items — a controlling Leader carries them with their own seats and allied independents — but the act tables first, so multi-company politics is felt from the very first tick rather than only when ownership or reputation slips. Leadership change, merger, and sale stay supermajority regardless of band. A Director has no direct-action surface: propose + vote + privileged info + influence hiring, identical to an AI director's levers (hard constraint).

AI-director disposition → vote

AI directors propose and vote by leaning on the same C-4 delegation disposition a rival head already carries — the aggression / baseStanding knobs in rivals.json consumed by DelegatedManager / Economy.Delegation. This is a thin lean-function over that disposition, not a second AI (Pillar 6 — a vote must be explainable from disposition, never random; same drift guard as rivals-as-companies).

Two disposition axes, both reusing existing knobs.

• Risk axis = aggression measured against the same pivot the delegation triage uses, delegation.neutralAggression (default 60). A director is expansionist when aggression ≥ neutralAggression + dispositionLeanMargin, conservative when aggression ≤ neutralAggression − dispositionLeanMargin, and neutral (→ Abstain on risk items) in the band between.
• Stability axis = baseStanding against neutralStanding (default 50). Stability-minded when baseStanding ≥ neutralStanding + dispositionLeanMargin; opportunist when ≤ neutralStanding − dispositionLeanMargin.

Three director kinds (the seat classes apportioned above):

1. Incumbent-aligned named director — a holder who votes with the company's current leadership (the Leader's own seats, allied executives, friendly holders). Alignment dominates: casts For whatever the incumbent leadership supports and Against anything that unseats or sells it, regardless of disposition. Disposition only sets the lean when this director is the one tabling a proposal (what an aligned director chooses to put forward).
2. Rival-aligned named director — a competitor holding seats; carries that rival's aggression / baseStanding from rivals.json. Votes by the lean table below, and alignment flips the control-item rows (a rival wants the incumbent weakened).
3. Reputation-driven independent — a non-named seat; votes by the company-reputation predicate reused from the CapTable (Board composition) against the two cutoffs below. This replaces the placeholder independentBacksProposal = (_,_) => true with the reputation-driven predicate in the feel safeguard below.

Lean table (rival-aligned named directors; also governs what an AI director chooses to table). rep = the company's regional-reputation score from the reused CapTable predicate:

Proposal	For	Against	Else
expandRegion	expansionist	conservative	Abstain
authorizeFinancing	expansionist and rep ≥ independentBackingThreshold	conservative, or rep < independentBackingThreshold (won't lever a failing road)	Abstain
pursueAcquisition	expansionist	conservative	Abstain
setDividend	stability-minded (a return / continuity signal)	expansionist (prefers reinvesting the cash)	Abstain
appointLeader — confirm incumbent	incumbent-aligned, or stability-minded with rep ≥ independentOustThreshold	rival-aligned, or rep < independentOustThreshold	Abstain
appointLeader — install challenger	rival-aligned to the challenger, or rep < independentOustThreshold	incumbent-aligned, or rep ≥ independentOustThreshold	Abstain
respondHostileBid — defend	incumbent-aligned, or stability-minded with rep ≥ independentOustThreshold	rival-aligned (the bidder is always Against), or rep < independentOustThreshold	Abstain
mergerSale	opportunist, or aligned to the acquirer	stability-minded (preserve the going concern)	Abstain

Precedence per vote: (1) control-item alignment override → (2) reputation gate (independentBackingThreshold / independentOustThreshold) → (3) disposition lean → (4) Abstain. Abstentions count toward quorum but not toward the carry tally. Incumbent-aligned directors and backing independents cast For (not Abstain) on routine items the incumbent supports, so the incumbent coalition reads as solid votes rather than a thin plurality of a few For against many Abstains.

Independent-backing predicate (the feel safeguard from C-5_2). An independent backs the incumbent's position — casting For the incumbent's proposal — when company reputation ≥ independentBackingThreshold (default 50, the Neutral floor) on the routine items (expandRegion, setDividend, authorizeFinancing, pursueAcquisition). Independents swing only as reputation slips:

• Below independentBackingThreshold (50) — independents stop rubber-stamping new routine spending: they Abstain on routine items (and vote Against authorizeFinancing, per the table — they won't lever a sliding road).
• Below independentOustThreshold (40) — sliding toward Reviled, independents turn on the seat itself: on control items (appointLeader-to-replace, respondHostileBid, mergerSale) they cast For the challenger / Against the defense.
• Between 40 and 50 — independents defend the Leader's seat (continuity) but no longer fund new ventures.

A declining reputation bites exactly when the score crosses these snapshot cutoffs — there is no separate trend input, so the predicate stays the reused CapTable snapshot, not a new signal.

Board-meeting cadence under the LOW band. The annual periodic meeting (intervalDays, default 365) auto-tables exactly two standing items: dividend ratification (a setDividend at the current standing per-share rate) and leader confirmation (an appointLeader confirming the incumbent — supermajority). It does not auto-table expandRegion / authorizeFinancing / pursueAcquisition / mergerSale / respondHostileBid — those stay event-driven (an actual action, deal, or live bid tables them). Under the LOW band the meeting is the periodic confidence backstop: even in a year the Leader tabled nothing, the dividend must be re-blessed and the Leader re-confirmed. While reputation sits at or above the cutoffs a controlling Leader carries both; the meeting is where a Leader whose standing collapsed during the year faces an orderly dividend cut (routine majority) or removal (supermajority) — the non-hostile counterpart to a CapTable bid.

JSON — game-dev authors these into economy.json → governance (this pass keeps that file single-writer; the keys + defaults are pinned here only). Defaults are balance-reasonable; period archetypes are deferred to the railroad-historian:

Key	Default	Meaning
dispositionLeanMargin	5	Half-width of the Abstain band around each pivot; outside it a named director leans For/Against. (Compressing the 35–70 aggression spread; a margin of 5 keeps the trunks For and the small/declining roads Against rather than collapsing everyone to Abstain.)
neutralStanding	50	Pivot for the baseStanding stability axis.
independentBackingThreshold	50	Company-reputation score at/above which independents back the incumbent on routine items.
independentOustThreshold	40	Company-reputation score below which independents swing to a challenger on control items.

The risk-axis pivot is deliberately not duplicated here — it reuses delegation.neutralAggression (already 60), the same constant the C-4 contract triage pivots on, so a director's vote lean and a head's contract-accept lean can never drift apart (drift guard).

Named directors live (C-5_3_B)

The disposition→vote lean table is shipped and unit-tested but never fires in a live game: rivals are built with an empty cap table, so every rival board apportions to one all-independent bloc and no named director exists to lean. C-5_3_B is the producer that puts named directors with dispositions onto rival boards so the lean goes live — and so dispositionLeanMargin (5) is finally exercised against the real 35–70 aggression spread.

Pinned mechanism — per-company named directors (rivals only this pass). Each rival seats its own named directors on its own cap table (Pillar 3 — the controlling figures are first-class named entities, not an opaque "the board"; Pillar 6 — a director's vote is explainable from its disposition, never random). This reuses every existing seam: ApportionSeats reads the cap table's named holders; IssueToHolder / IssueToFloat seed them (CapTable); the lean table and the injected dispositionOf delegate resolve the vote. The player-led board already works (the founder seat votes manually, public float votes as independents) — no AI named directors are added to it this pass. Cross-holdings — a financier or rival leader holding seats across several boards — is a richer, later deepening and is explicitly out of scope (see verdict below).

JSON shape (game-dev authors; designer specifies). A directors array under each rival in rivals.json, colocated with the company that elects them:

{
  "id": "detroit_mackinac", "name": "Detroit & Mackinac Railway",
  "baseStanding": 30, "aggression": 35,
  "directors": [
    { "id": "detroit_mackinac", "name": "<head>", "role": "President",
      "isHead": true, "ownershipFraction": 0.65 },
    { "id": "dm_outside_director", "name": "<figure>", "role": "Director",
      "ownershipFraction": 0.15, "aggression": 45, "baseStanding": 55 }
  ]
}

• id — the director id (also the holder id on the cap table). The head's id is the company id (detroit_mackinac above) — this makes incumbentOf(companyId) == head.id resolve true so the head is correctly incumbent-aligned on control items, and lets the head's disposition resolve through the existing rival-by-id dispositionOf path with no code change.
• isHead — exactly one director per rival; the controlling President/Chairman.
• ownershipFraction — the director's stake (0–1). Drives seats: round(fraction · seatCount); a director clears seatThreshold (0.1429) to get any seat. Directors' fractions sum to < 1; the remainder is public float, distributed across the rival's served regions (the existing DistributeFloat home-weighted pattern) so the rest of the board is reputation-driven independents.
• aggression / baseStanding — the director's own disposition (0–100). Optional; default to the owning company's values. This is the lever that makes a non-head director's lean diverge from the company's reputation (a conservative director on a high-reputation road) — without divergence the lean and the independents are correlated and rarely change an outcome (see live-red).

Game-dev seeds these in AddRival: Stock.IssueToHolder(director.id, round(fraction · TotalShareBasis)) per director, remainder to float, against the canonical 1000-share basis for determinism. No governance-block change is needed — the director data lives in rivals.json, and dispositionLeanMargin / neutralStanding / independentBackingThreshold / independentOustThreshold and the risk pivot (delegation.neutralAggression) all stand.

dispositionOf resolution (the one thin wiring change). Today dispositionOf(companyId, directorId) resolves only directors whose id is a rival company id — so a non-head director (dm_outside_director) returns null and is treated as absent. The fix is a thin lookup, not a second AI: build a director registry from the directors arrays, and resolve in order — (1) registry hit → the director's own aggression/baseStanding, each field falling back to the owning company's value when unset; (2) else the existing Rivals by-id lookup (the head-as-company-id path, unchanged); (3) else null (the player / unknown seat). The head needs no registry change; only non-head directors do.

Seat apportionment. Unchanged. With shares now present, ApportionSeats produces named seats for every director at/above seatThreshold plus reputation-driven independent seats from the float — exactly the Board composition model, now fed real data.

Live-red criterion (game-dev proves with a failing test first).

• Primary — validates the dispositionLeanMargin gate. On Michigan Central (company reputation = baseStanding 60, so the all-independent baseline backs routine spending), seat a non-head director with own aggression 45 holding a 2-seat block; the head (aggression 60) holds 3; 2 seats independent. Resolve an expandRegion proposal. Baseline (all-independent, today's live behaviour): rep 60 ≥ independentBackingThreshold 50 → all 7 independents For → Carried. With the director: the head Abstains (60 sits in the 60 ± 5 neutral band), the director votes Against (45 ≤ 60 − 5), independents For (2) → For 2 not > half of the 4 decisive seats → Failed. The flip is gated entirely by dispositionLeanMargin = 5: an author who set the director to aggression 56 would land it in the neutral band (Abstain) and the proposal would carry — so the failing test pins that the margin fires and changes the outcome.
• Secondary — alignment flip, head-only, needs no dispositionOf change. On Detroit & Mackinac (rep 30), the controlling head (ownershipFraction ≈ 0.65 → 5 of 7 seats, incumbent-aligned) votes For on the annual meeting's auto-tabled appointLeader-confirm item; 2 independents vote Against (rep 30 < independentOustThreshold 40). Supermajority 5 ≥ ⅔·7 → Carried. Baseline: 7 independents at rep 30 → all Against → Failed. The entrenched President survives a board that public sentiment has turned against — a live outcome change reachable with only the cap-table seed.

Code gaps to flag for game-dev (not blocking the live-reds). (a) The lean table specifies that an incumbent-aligned named director casts For routine items the incumbent supports (alignment dominates), but the shipped NamedAiVote applies the incumbent-aligned override only on control items — on routine items even the head votes by raw disposition lean. Reconcile when non-head loyal directors must vote routine items as a bloc. (b) For non-head directors to participate correctly on control items, alignment must generalize from "id == incumbent" to a per-director alignment flag — needed only once cross-holdings or loyal-bloc control votes ship; the primary live-red (a routine expandRegion) does not depend on it.

Railroad-historian research ask. For each of the 7 active LP rivals, supply the early-1920s controlling/notable board figures: name, period title/role (President, Chairman, receiver, controlling owner), which is the head (controlling owner/President — gets the company id and the large block), and a character read mapping to aggression / baseStanding or "inherit the company." Ground disposition divergence in real character only where it existed (a conservative chairman over an aggressive road); default to inherit otherwise. Notables already surfaced: Henry Ford at Detroit, Toledo & Ironton (owner 1920–29 — the marquee aggressive-industrialist head); Pere Marquette's early-1920s receivership / Van Sweringen orbit; NYC's nominee at Michigan Central; the Canadian National president at Grand Trunk Western; the PRR nominee at Grand Rapids & Indiana; the entrenched controlling owner at Detroit & Mackinac (the declining-isolate character, and the secondary live-red's protagonist). This extends the existing open-question historian dependency (rival strategy archetypes) to named board figures.

Verdict — BOUNDED SEEDING. Author director data + a thin dispositionOf registry lookup + cap-table seeding in AddRival, all over existing seams (ApportionSeats, NamedAiVote, CapTable.IssueToHolder/IssueToFloat, the existing dispositionOf delegate). No new world-scope entity model, no second voting axis, no apportionment restructuring. The large fork is cross-holdings — a financier / rival leader holding seats across multiple boards — which would require a world-scope named-entity model (entities not tied to one cap table), dispositionOf resolving cross-board entities, and the per-director alignment generalization for the rival-aligned control-item rows. Desirable (Pillar 3) but not needed to take the lean table live; deferred to its own pass.

AI-leader discretionary tabling (C-5_3_C)

The disposition→vote lean table and the named directors make AI directors vote by disposition. The other half of the loop — an AI Leader tabling a discretionary proposal — is dormant in live play: over a 5-year run rival boards table 0 discretionary items (expandRegion / authorizeFinancing / pursueAcquisition / mergerSale), only the two annual standing items the board-meeting cadence auto-tables. The governance engine is correct; the rival delegation engine simply never routes a discretionary act through LeaderAct. This section pins the cadence + thresholds that wake it — a thin lean over the existing C-4 disposition, not a rival strategic planner.

The bound (the whole mechanism in one line). On a periodic discretionary review cadence, a rival's incumbent Leader reads its existing disposition (the same aggression / baseStanding NamedAiVote already reads) and its existing company state (treasury, leverage, open-proposal count), and tables 0 or 1 discretionary item of the type its disposition leans toward — subject to guardrails. No multi-turn plan, no look-ahead, no new decision subsystem; everything reduces to one disposition read against current state per cadence tick. The act flows through the same LeaderAct → proposal-loop teeth a player Leader's act does — the AI does not get a privileged direct-apply path (player/AI-identical surface).

Q1 — Cadence. A separate discretionary-review cadence, not the annual board meeting. Rationale (Pillar 4 — the loop has texture; Pillar 5 — legible, not spam): the annual meeting is the confidence backstop (re-bless the dividend, re-confirm the Leader); a strategic move (expand, finance, acquire) should be able to arise between meetings, when treasury and opportunity allow, so the board reads as a living body rather than a once-a-year ritual. But the review must be infrequent and staggered, or seven rivals each rolling daily floods the inbox.

• Cadence period = discretionaryReviewIntervalDays (default 90 — a quarterly review). On each rival's review day the Leader rolls one consideration; the next review is scheduled + interval.
• Stagger the first review per company by companyId hash modulo the interval, so the seven rivals' reviews don't land on the same day (the same determinism discipline the board meeting and apportionment already use — ordered, hashed, reproducible).
• Per-review table probability = discretionaryTableChance (default 0.5) gates whether a leaning Leader actually tables this quarter (a conservative/neutral Leader tables nothing regardless — see Q2). This keeps even an expansionist road from tabling every single quarter like clockwork.

Target rate (the "alive but not chaotic" sizing). Quarterly review × ~0.5 table-chance × the disposition gate yields, for an expansionist rival, ≈ 1–2 discretionary items/year; for a neutral rival ≈ 0 (it abstains-to-table — see Q2); for a conservative rival 0 (consistent with the delegated head that "never expands" at aggression 0). Across a 7-rival field that reads as a handful of strategic board moves per year, concentrated in the aggressive roads — the constellation feels alive, the inbox isn't spammed, and the per-rival rate maps legibly onto each road's authored character (Pillar 3). If playtest reads as too quiet, raise discretionaryTableChance before shortening the interval (keep the cadence legible); too noisy, lengthen the interval first.

Q2 — Which item, by disposition (reuse the exact NamedAiVote lean bands). The Leader tables the type its own disposition would vote For — read with the same bands NamedAiVote uses (expansionist = aggression ≥ neutralAggression + dispositionLeanMargin; conservative = ≤ neutralAggression − dispositionLeanMargin; stabilityMinded / opportunist on baseStanding ± dispositionLeanMargin). No new pivot, no new margin — the tabling read and the voting read share the constants, the drift guard applied to the propose side. The mapping is a subset of the existing lean table restricted to the four discretionary types, in priority order (a Leader tables the first type that clears its disposition gate and its guardrails — at most one per review):

Disposition read	Tables (priority order)	Gate	Rationale
expansionist (high aggression)	1. expandRegion → 2. authorizeFinancing → 3. pursueAcquisition	the For rows of the lean table for these types	a growth road grows network-first; finances/acquires only when expansion is blocked, futile, or capital is needed for it
opportunist and rep < independentOustThreshold (low standing, sliding)	mergerSale	the mergerSale For row (opportunist takes the exit)	a failing low-standing road seeks the sale/merger exit before the board forces it (the orderly counterpart to a hostile bid)
conservative or neutral (in the Abstain band)	nothing	—	a passive/conservative Leader tables few or none — exactly the aggression-0 head that never expands; a neutral Leader has no For lean to act on, so it tables nothing this review

authorizeFinancing and pursueAcquisition sit below expandRegion for an expansionist so a healthy expansionist road defaults to the feasibility-gated expansion path it already uses, reaching for debt or an acquisition only when expansion is gated out or futile. Two distinct fall-through conditions, both meaning "expandRegion yields nothing this review":

• Gated out (treasury). Treasury below the expansion floor but above the financing floor → the expansion guardrail skips expandRegion, and the Leader tables authorizeFinancing to fund the next push.
• Futile (no feasible target). The feasible frontier pool is empty — every reachable candidate fails feasibility (goodwill-blocked, terrain, or treasury), so a cash-rich builder cannot extend track no matter its war chest. This is the Bug-A / GTW-Adrian case: the expansionist has cash (clears the expansion floor) but no buildable target. expandRegion produces nothing, so the priority order must fall through to pursueAcquisition — the expansionist consolidates by acquiring a spine-adjacent road instead of laying track it cannot lay. This is the design-correct expansionist behavior and the seam that lets D-3 friendly/hostile acquisition fire on a seed with one builder: without the futile fall-through, a cash-rich expansionist never reaches pursueAcquisition and D-3 never tables (Ruling-D's "movement among the standers" would never start). pursueAcquisition is an expansionist verb (the buyer side) — the mergerSale row is the separate opportunist/seller side; a distressed road selling and an expansionist road acquiring are two ends of the same deal, not alternatives to each other.

The acquisition-target gate still applies: pursueAcquisition tables only if a valid acquirable target (satisfying the friendly OR hostile gate) is spine-adjacent; absent one, the expansionist tables nothing this review — restraint, not a forced bad move. This keeps the four types from being equiprobable noise and makes each rival's sequence of moves legible from its character.

Q3 — Anti-runaway guardrails (the M10-runaway analogue). Each is a config-driven condition the Leader checks BEFORE tabling; a type that fails its guardrail is skipped and the next priority type is considered (so a guardrail never forces a bad table, it just removes an option). These bound the high-aggression rival without a planner — the loop's teeth plus these floors are the only brakes, exactly as the contract-triage margin gate bounds the contract side:

• Concurrent-proposal cap. Do not table if the board already has ≥ discretionaryConcurrentCap (default 1) open discretionary proposals. One strategic question before the board at a time — the loop resolves it before the next is raised. (Standing items don't count against the cap; they're the backstop.) This is the primary anti-spam and anti-runaway bound: a road can't stack three expansions while none have resolved.
• Treasury floor for expansion. Do not table expandRegion unless treasury ≥ discretionaryExpansionTreasuryFloor (default scenario-tunable; recommended a multiple of the tier's typical feasibility-study + activation cost). A road can't commission expansion it provably can't fund — the unaffordable-commit ruling applies the same logic to the player's discretionary commits.
• Leverage ceiling for financing. Do not table authorizeFinancing if the company is already at/above discretionaryLeverageCeiling (default debt-to-treasury or debt-to-equity ratio, scenario-tunable — recommend reusing whatever ratio the bond-servicing / leverage model already exposes rather than inventing a second ratio). This is the direct M10-runaway guard: a high-aggression road cannot lever itself into the collapse the M10 treasury-runaway signal warned of, because the financing option is removed once it's over-levered. (It may still expand from cash if the treasury floor is met — financing is the leveraged path, and that's the one the ceiling gates.)
• Acquisition target gate. Do not table pursueAcquisition unless a valid named target exists (a rival the company can plausibly pursue) — no abstract "acquire something." Reuse the existing target enumeration the acquisition path already needs; absent a target, the type is simply unavailable and the Leader falls through to nothing.

A Leader that clears its disposition gate but fails every guardrail for its leaning types tables nothing this review — the guardrails turn a runaway into restraint, not into a forced sub-optimal move.

Q4 — Named-director personality. Yes — and it requires no new knob, because the Leader is a named director. The tabling read pivots on the incumbent head's own disposition, resolved through the existing dispositionOf(companyId, head.id) seam — the head-as-company-id path that already resolves the head's aggression / baseStanding. So personality is already felt: an aggressive head (Pere Marquette, aggression 70) tables expansion roughly twice as often as it reaches the table at all, while a declining-isolate head (Detroit & Mackinac, aggression 35, baseStanding 30) tables nothing strategic and, once rep slides under the oust threshold, leans only toward mergerSale — its character read straight off rivals.json. Only the head tables this pass: a non-head named director (C-5_3_B) votes its own disposition but does not drive tabling — tabling is a Leader act (LeaderAct), and the head is the incumbent Leader. (A non-head director tabling its own counter-proposal — a dissident board faction — is the cross-holdings deepening fork, explicitly deferred; it needs the per-director proposer path that pass introduces, not this thin Leader-only cadence.) This keeps the personality entirely on the existing disposition seam — no per-director tabling knob invented.

Q5 — Config keys (authored into economy.json → governance; game-dev single-writes the file). All new; defaults balance-reasonable for the Michigan seed, all scenario-tunable:

Key	Default	Meaning
discretionaryReviewIntervalDays	90	Days between a rival Leader's discretionary-review rolls (quarterly). First review per company staggered by companyId-hash mod interval.
discretionaryTableChance	0.5	Probability a leaning Leader actually tables on a given review (a non-leaning Leader tables nothing regardless). The legibility dial — raise before shortening the interval.
discretionaryConcurrentCap	1	Max open discretionary proposals on a board before the Leader stops tabling new ones (standing items exempt). Primary anti-spam + anti-stack bound.
discretionaryExpansionTreasuryFloor	(tier-scaled; recommend ≈ one feasibility-study + activation cost for the road's tier)	Treasury below which the Leader will not table expandRegion.
discretionaryLeverageCeiling	(reuse the existing leverage ratio; recommend the bond-servicing debt ratio)	Leverage at/above which the Leader will not table authorizeFinancing — the M10-runaway guard.

The risk/stability pivots and margins are deliberately NOT re-declared here — the tabling read reuses delegation.neutralAggression, dispositionLeanMargin, neutralStanding, independentBackingThreshold, and independentOustThreshold exactly as NamedAiVote does, so the propose-side and vote-side reads can never drift (drift guard).

Verdict — BOUNDED LEAN, no new subsystem. This is a cadence wrapper over LeaderAct driven by the same disposition read NamedAiVote already performs, gated by config-driven state checks. No strategic planner, no multi-turn plan, no look-ahead, no second decision model. It reuses: LeaderAct (the tabling teeth), the dispositionOf head path (personality), the NamedAiVote lean bands + shared pivots (which type), and the existing treasury/leverage/target state the company already exposes (guardrails). The only net-new artifacts are the five config keys above and the per-rival review-cadence bookkeeping (a next-review-day map, mirroring the existing _nextMeetingDay). Game-dev implements against this in C-5_3_C (the propose-side counterpart to C-5_3_B's vote-side seeding).

Rival target-selection heuristic

The C-5_3_C tabling decides whether and which type a rival Leader tables. This section pins what it picks — the target a Carried expandRegion builds toward and the target a Carried pursueAcquisition pursues. Like tabling, it is a bounded lean over the existing disposition, not a planner: a single ranked greedy pick over candidates incident to the rival's own spine, scored by observable signals, re-evaluated once per discretionary review against current state, then feasibility- and treasury-gated. The intelligence is in the legibility and the disposition coupling, not in search depth.

expandRegion — spine-adjacency-first ranked score. Candidates are the rival's expansion frontier — connection-only in v1: candidates are connections to existing settlements the rival can reach from its current network, not open-country plants (open-country planting stays a player-only world-shaping verb in v1; the rival planting branch is behind a config flag for a later follow-up). Each candidate is scored:

Signal	What it measures	Effect on score
1 — Spine adjacency (dominant)	graph-hops from the candidate to the rival's nearest owned node	fewer hops → higher score. The rival extends its own corridor rather than leaping across the map. Dominant by weight.
2 — Settlement value	the candidate settlement's pop × station-tier demand	richer settlement → higher score.
3 — Disposition contest multiplier	whether the candidate is already served by a competitor	a multiplier read from the rival's disposition: an aggressive rival leans toward contesting a competitor-served candidate; a conservative-expansionist leans away. Read via the same (aggression, baseStanding) disposition + lean bands the tabling read and NamedAiVote use — no new pivot, no new margin (the drift guard).

Feasibility gates candidacy, THEN pick the single top-scoring candidate. The order is: (1) compute the frontier candidate set (multi-hop per the reach fix); (2) filter that set to the feasible candidates — those with a positive feasibility-study verdict and clearing the C-5_3_C treasury floor; (3) take the single greedy top of the feasible set. An infeasible candidate was never a valid candidate — feasibility is a property of the candidate pool, not a post-pick veto on a pick already made. If the top-scored raw candidate (e.g. a hop-1 town whose geographic-goodwill verdict sits below the threshold) is infeasible, it is simply not in the pool and the pick falls to the top feasible candidate behind it — the rival keeps building toward the targets it can reach.

This is one greedy pick, not a fallback search — the three red-flag NOTs hold. The forbidden "fallback search down the ranked list" is iterative descent: pick #1, if it fails try #2, if that fails try #3 — a mini-search that smuggles in lookahead. Feasibility-first filtering is not that: the pool is pre-filtered once, then a single top-of-pool pick is made — no descent, no re-try loop, still exactly one disposition read against current state per review (drift guard). The relationship-not-build invariant is preserved per target: the goodwill-blocked town (Adrian) stays unbuilt until the rival's geographic goodwill there recovers — the rival is relationship-blocked from that town, exactly as intended — but a single low-goodwill county does not strand the builder off the whole frontier when feasible targets exist behind it. A rival tables no build only when the feasible pool is empty (every reachable candidate is infeasible) — genuine relationship-or-treasury blockage, not a selector artifact.

Feasible-pool-empty is the signal the tabling priority falls through on. When the feasible pool is empty, expandRegion produces nothing this review, and the expansionist Leader's priority order falls through to authorizeFinancing / pursueAcquisition — expansion being futile (no feasible target) is one of the "expansion blocked" conditions the priority order is built to fall through on (see tabling priority order).

Affordability is part of the candidacy filter, not a separate gate (Bug C ruling — D-4b). The candidate pool at step (2) filters on feasibility and affordability together: a candidate whose estimated build cost exceeds the rival's treasury is not a selectable candidate, exactly as an infeasibility-blocked candidate is not. This is a clarification of the existing feasibility-first frame, not a new surface — the frame already reads "clearing the C-5_3_C treasury floor" as a candidacy condition (step 2 above); Bug C only makes that treasury condition per-candidate (this candidate's estimated cost vs. this treasury) rather than the coarse flat tier floor (discretionaryExpansionTreasuryFloor, a can-I-afford-a-build check) it collapsed to. Both floors hold: the flat floor gates whether the road tables expandRegion at all; the per-candidate affordability filter removes the specific towns it can't fund from the pool. The design-correct reading is "affordability is a property of the selectable pool, exactly like feasibility" — the same clarification already ruled for feasibility, applied to the treasury axis feasibility itself already names.

• Why not "affordability lives only at the build edge." The build-edge restraint re-check (the C-1 unaffordable-commit ruling) is the last line, not the only line. Left as the only line it produces the observed pathology: the greedy top pick (high-pop hop-1 Detroit) is permanently unaffordable at authored capital, so the build edge silently declines it every review, the study re-commissions every review, the road builds nothing — and worst, the always-non-empty feasible pool keeps hasFeasibleExpansionTarget true, so the futile fall-through never fires and zero acquisitions ever table. Reading the Detroit-churn as "legible frustrated ambition" is rejected: it is not saving toward Detroit (there is no rival-saves-toward-a-target mechanic — see below), it is thrashing — recommissioning an identical study it will decline again, an illegible no-op the player can't even see. That reads as a broken road, not an ambitious one (Pillar 6 — a delegated head's conduct must be legible and trace to its traits; an infinite decline-loop traces to nothing).

• The cost-estimate SIGNAL stays inside the three NOTs — it is a GATE input, not a SCORING pivot. The selector runs before the study, so it lacks the study's real LandCost / PermitCost; affordability-at-selection needs a pre-study cost estimate (candidate hops × line-tier cost + a population-scaled land estimate — the same inputs the study itself uses, read coarsely). This estimate is a binary selectability gate, not a fourth scoring signal: it does not re-rank the affordable candidates (their Signal-1/2/3 order is untouched) — it only removes the unaffordable ones from the pool, exactly as the feasibility verdict removes goodwill-blocked ones. It therefore introduces no new pivot or margin (NOT #3 holds — no neutralAggression-style constant is added; affordability is treasury-vs-estimate, a state comparison, not a disposition read), no lookahead (NOT #1 — it is one comparison against current treasury, no "build A to afford B later"), and no global optimization (NOT #2 — still the rival's own frontier, still one greedy top-of-pool pick). A cost estimate that fed the score (e.g. "cheaper towns rank higher") would be a new scoring pivot and would cross the line — that is explicitly not what is ruled; the estimate gates candidacy only.

• Futile fall-through confirmed — an all-unaffordable pool reads futile, and B2 fires. With affordability in the filter, a pool where every feasible candidate is unaffordable is an empty feasible+affordable pool — which is exactly the feasible-pool-empty signal the tabling priority falls through on. So a cash-constrained expansionist that cannot afford to build falls through to pursueAcquisition and acquires a cheaper spine-adjacent road instead — the pursueAcquisition smallest-target pick (out-relationship, don't over-reach). This is the design-correct expansionist behavior and is fully consistent with the B2 futile-acquire ruling: "can't lay track it cannot lay → consolidate by acquiring." The two D-4a fixes stop being mutually defeating — the unaffordable-but-feasible Detroit no longer props the pool non-empty, so the futile read finally reaches the acquire path.

• What is NOT opened (the scope line held). This ruling does not introduce a "rivals save cash toward big targets" mechanic — there is no accumulate-toward-Detroit behavior, and none is wanted; a rival that can't afford its top target this review simply picks the best target it can afford, or falls through to acquire. Nor does it introduce a real cost-model: the pre-study estimate is a coarse gate input reusing the study's own cost inputs read cheaply, not a second economic model the designer must author and balance. If a future pass wants rivals that visibly bank toward a marquee build, that is a new mechanic and a new scope decision — out of D-4b.

Feel call (Ruling-D / "established incumbent who consolidates") — Pillar 6 + Pillar 2 drive it. GTW visibly building a steady stream of affordable towns and acquiring when it can't build reads as a living, legible incumbent whose every move traces to its state and its head's character; GTW fixated on an unaffordable Detroit for half the game reads as a stuck road running an invisible decline-loop. The first honors Pillar 6 (delegated conduct is legible and auditable — the player sees builds it can afford and acquisitions when it can't, each traceable) and Pillar 2 (the D-3 leverage-weighted acquisition churn is the "out-relationship, not out-build" movement Ruling-D wants — GTW consolidating by acquiring a spine-adjacent road is that churn). "Frustrated ambition" would only read as character if it were visible and chosen; a silent per-review thrash is neither. Pillar 6 drove the call — the deciding factor is legibility of delegated conduct, not liveliness for its own sake.

pursueAcquisition — smallest acquirable target adjacent to the spine. The parallel pick: among acquirable targets adjacent to the acquirer's spine, take the smallest (cheapest to absorb, lowest-risk consolidation — out-relationship, don't over-reach). "Acquirable" = satisfies the friendly OR hostile gate from Friendly vs. Hostile Acquisition above: a sterling rival whose owner won't sell is not enumerable, so it is never picked. This is the same enumeration the discretionary acquisition gate already requires.

The three red-flag NOTs (the standing drift guard). Every rival decision still reduces to one disposition read against current state:

• NO lookahead — no multi-turn plan, no "build A now to enable B later." One pick per review.
• NO global optimization — no field-wide best-move search, no learned/search-based selection. A greedy pick over the rival's own frontier only.
• NO new pivots or margins — signal 3 reuses the existing delegation.neutralAggression / dispositionLeanMargin / neutralStanding bands. The selection read and the tabling / voting reads can never drift apart.

Config scalars (game-dev authors into economy.json; designer names them, does not edit the file). The heuristic weights live in an expansion block under governance (or a sibling expansion block — game-dev's file-layout call in D-2); the designer pins the scalars and their meaning:

Scalar	Meaning
spineHopWeight	weight on Signal 1 (graph-hops to nearest owned node). Dominant — set so spine adjacency outranks settlement value at any realistic pop.
settlementValueWeight	weight on Signal 2 (pop × station-tier demand).
contestMultiplierAggressive	Signal-3 multiplier (> 1) applied when an aggressive-leaning rival scores a competitor-served candidate (leans toward contesting).
contestMultiplierConservative	Signal-3 multiplier (< 1) applied when a conservative-expansionist-leaning rival scores a competitor-served candidate (leans away).

These are the only new scalars the heuristic needs; the disposition pivots/margins it reads are already declared (governance + delegation.neutralAggression) and are not re-declared. Magnitudes are balance-reasonable defaults, tuned via the D-4 playtest (the Ruling-D target: a handful of segments per aggressive road over 10y — out-relationship, don't out-build).

Appetite-spread calibration (D-4)

Two M14_C/E playtest signals — "one builder, six standers" and "finishes year 3" — sit against the Ruling-D target ("the player out-relationships the field, not out-muscles it … out-relationship, not out-build; the tuning lever is scale/capital, never aggression"). This pins how to spread build appetite across the field without touching aggression as a scale knob, and pins the target: how many roads should build, and how much.

The gate is the HEAD's disposition, not the company's. The tabling read and NamedAiVote pivot on the incumbent head's own aggression, resolved through dispositionOf(companyId, head.id) — the head-as-company-id path (Q4). A rival's company-level aggression is not the appetite gate; the head director's aggression is. On the shipping seed, read against the expansionist band (neutralAggression 60 + dispositionLeanMargin 5 = ≥ 65), the seven active LP heads are:

Rival	Company agg	Head agg (the gate)	Expansionist (head ≥ 65)?
Grand Trunk Western	65	68 (Thornton)	✅ tables + builds
Pere Marquette	70	58 (Alfred)	❌ (head sits in neutral band)
Michigan Central	60	60 (inherit)	❌
Grand Rapids & Indiana	60	55	❌
Detroit, Toledo & Ironton	55	60 (Ford)	❌
Ann Arbor	55	55 (inherit)	❌
Detroit & Mackinac	50	50 (inherit)	❌

Only Grand Trunk Western's head (Sir Henry Thornton, 68) clears 65 — "one builder." The often-cited "PM 70 / GTW 65 clear the band" reads the company number; the engine reads the head.

Historian verdict (grounded, timeline-anchored) — the one-builder read is HONEST, not a gap. An earlier draft of this section ruled the one-builder signal a head-authoring gap and prescribed lever (b): bump PM's and Ford's heads to ≥ 65. The railroad-historian returned a fidelity verdict that kills (b):

• Pere Marquette head (Frank H. Alfred, 58) — NO. Alfred was a conservative rehabilitation president (1917 reorg → 1933). The PM's expansion/consolidation energy was (a) a controlling-financier phenomenon (the Van Sweringens), not the operating president, and (b) a ~1924+ phenomenon — arguably anachronistic to read as expansionist at a 1920–1923 start. It already lives correctly on the Van Sweringen director seat (aggr 70) and the company number (70). Bumping Alfred's head misrepresents the man and the road's survival posture.
• Detroit, Toledo & Ironton head (Henry Ford, 60) — NO (wrong axis). Ford was maximally aggressive on capital / operations / efficiency but did not extend the route network — "improve-and-operate the existing line fanatically," not "grow the map." That is the wrong axis for a network-growth aggression scalar; head at 60 is already correctly calibrated as "active operator." A ≥ 65 network-growth bump misrepresents the road.
• Constructive note. GTW's Thornton (68) is the one genuinely network-growth-expansionist head on the seed, and being "one primary builder" is historically honest for this seed/period. Two standing time-sensitivity flags: the PM consolidation posture is ~1924+ (reading company-aggr 70 as expansionist at a 1920–1923 start is arguably anachronistic), and the aggression scalar conflates capital-aggression with route-aggression — a known modeling seam to revisit in a later authoring pass.

Target — how many builders, how much (the Ruling-D ceiling), revised. The prior draft targeted 3–4 builders; the historian's verdict resets the honest expectation to 1–2 genuine network builders for this seed/period (Thornton's GTW, plus at most one road the historian reads as expansive on re-authoring). The other 5–6 stand or contract — declining isolates and conservative rehabilitation/lessee roads should be quiet; that is character (Pillar 3), not a bug. The builder(s) table ≈ 1–2 discretionary items/year (the C-5_3_C target rate), of which only feasibility- and treasury-passing ones become real builds — netting a handful (roughly 3–8) of completed segments per builder over 10y. 12-of-12 building is carpeting and remains the red flag; so is any road building itself into insolvency now that build costs real cash (the discretionaryLeverageCeiling / discretionaryExpansionTreasuryFloor guards hold that line). The "living map" no longer depends on more track-layers — it depends on the reach fix keeping the one builder busy plus the D-3 acquisition churn moving ownership among the standers (below).

The three candidate levers, and why only (c) survives. Two were considered and are now foreclosed; a third ships and needs no escalation:

• (a) — widen the band (neutralAggression / dispositionLeanMargin). FORBIDDEN by the drift guard. Widening the band (or dropping the pivot) to pull more roads into "expansionist" is a disguised aggression tune: it re-labels the same dispositions as more aggressive without re-authoring character, and it moves the shared risk pivot the contract triage, the vote lean, the tabling read, and the target-selection contest multiplier all read — the drift guard forbids a new pivot/margin, and this is exactly that. Band stays 60 / 5. (Unchanged from the prior ruling — this was never the lever.)
• (b) — re-author PM's and Ford's HEAD dispositions to ≥ 65. FORBIDDEN by fidelity (historian verdict above). Both bumps misrepresent the roads: Alfred was a caretaker and the PM's expansion was a financier/1924+ phenomenon already seated on the director + company knobs; Ford's aggression was on the wrong axis (capital/operations, not route). Lever (b) is killed.
• (c) — the multi-hop frontier reach fix. SHIPS, no escalation. A head that clears the gate still stops building once its 1-hop frontier is exhausted (the expansion frontier is v1 connection-only, one edge out) — "finishes year 3." Letting the frontier reach multi-hop as the network grows (game-dev's D-side graph fix) is what lets the one cleared head (GTW) keep finding sane targets across a 10-year run, so it accumulates a handful of segments rather than 2–3 and then idling. Adequate war-chest (tier-scaled treasuries, $55–75k for the LARGE roads) already funds it; the treasury floor is not the binding constraint for the LARGE builder. (c) is a game-dev reach/graph fix, not a designer scalar — it changes the candidate set the target-selection heuristic ranks, not any weight; spineHopWeight stays dominant so a nearer hop still always outranks a farther one (multi-hop only adds farther candidates for when the near ones are taken — it does not let a road leap the map).

Why "company-aggression as the appetite gate" is NOT a fourth lever. A tempting reading of the historian's "the system is expansionist even if the president is a caretaker" (PM company 70) is to drive the expansion gate off the company number rather than the head. Rejected on two independent grounds:

• It forks the disposition read (breaks the drift guard). The seam resolves through dispositionOf(companyId, head.id) where the head's id IS the company id (Named directors live) — the head's set aggression wins, inheriting the company value only when unset. To let expansion read the company number while contract-triage and the vote read the head number, the seam must run two disposition reads — exactly what the drift guard's "every rival decision reduces to one disposition read against current state" forbids. The propose-side and the vote-side would drift apart by construction.
• It breaks the delegated-head model (Pillar 6). The rival AI is a delegated head: the head is who ACTS, and every call must trace to the acting staffer's traits. A conservative President who declines to table expansions is the delegated head expressing character, not a fault to route around. Building past the head's disposition is precisely the black box Pillar 6 forbids — the build would not trace to any acting staffer's traits.

Where the real system-vs-head expansion energy DOES live (and why it's deferred). The historian is right that PM's expansion was a controlling-financier act — and the design already has the correct home for it: the Van Sweringen director seat (aggr 70) on PM's board is a first-class named director, and a Director can table expandRegion through the board proposal loop without the President tabling it. That is the honest, non-drift, non-black-box path for "the financier drives expansion over a caretaker president" — it traces to a named entity's disposition and runs through the shipped governance loop. But it is NOT a D-4 lever: it is ~1924+ (period-gated, arguably anachronistic at a 1920–1923 start), it depends on director-tabling (C-5_3_C tables off the head's discretionary review today; director-initiated expandRegion is a governance-loop deepening, not the current tabling path), and it is a roster/period-authoring call the railroad-historian + user own. It is recorded here as the deferred path, not adopted now.

FINAL RULING — CUT appetite-spread beyond the one honest builder; ship (c) + rely on D-3. "One builder" (GTW/Thornton, 68) is historically honest for this seed and period. The living competitive map is delivered without pretending conservative roads are expansionist:

1. (c) multi-hop frontier reach keeps the one builder finding sane targets across the full 10y (no "finishes year 3" idle).
2. D-3 friendly/hostile acquisitions create movement among the non-builders — opportunist/distressed roads get absorbed and ownership changes hands even where no new track is laid; a leverage-weighted acquisition churn is exactly the "out-relationship, not out-build" field Ruling-D wants.

Broader appetite-spread (a genuinely expansionist second/third road) is deferred to a future roster/period-authoring milestone, where three things get authored together with the historian in the loop: the Van Sweringen director-tabling path (period-gated ~1924+), any year-gated posture shifts (PM's company posture arguably should become expansionist only from ~1924), and the capital-vs-route aggression split the historian flagged (so a Ford-style operator can be "aggressive on its own corridor" — contract/rate/operations churn — without registering as a network builder). None of those are D-4 scalars; all are character/period authoring.

Ruling-D + drift-guard + pillar justification. CUT sits strictly inside Ruling-D ("out-relationship, not out-build; the tuning lever is scale/capital, never aggression") — it pulls no appetite lever at all, honoring the ceiling rather than pushing against it. It is drift-guard-clean by construction: no pivot, no margin, no second disposition read (band stays 60 / 5; the one read stays on the head). It honors three pillars at once: Pillar 3 (each road keeps its real character — a caretaker stays a caretaker, a financier's energy lives on the financier's seat), Pillar 6 (builds trace to the acting head's traits; no black-box company-over-head override), and Pillar 2 (the living map comes from leverage-weighted acquisition churn, not carpeted track). Where a call could have gone either way — accept honest-one-builder vs. gamify a second builder at a fidelity cost — Pillar 3 drove it: fidelity to the named roads' real character outranks a livelier-looking but false field.

Concrete calibration handed to game-dev:

• Band knobs — UNCHANGED, do not edit: delegation.neutralAggression = 60, governance.dispositionLeanMargin = 5 (expansionist cutoff stays head aggression ≥ 65). Drift-guard constraint: the selection read, the tabling read, and the vote read keep reading the same disposition bands off the same pivot/margin — no new pivot, no new margin, no per-read override, no second (company-vs-head) read.
• Head dispositions — UNCHANGED: do not bump PM's or Ford's heads (historian fidelity verdict). All seven heads stand as seeded. GTW/Thornton (68) is the one builder, by design.
• Frontier reach — game-dev graph fix (no designer scalar), SHIPS: widen the expansion frontier from one-edge-out to multi-hop as the network grows; it changes the candidate set the target-selection heuristic ranks, not any weight. spineHopWeight stays dominant.
• D-3 acquisitions — as already signed off (below); this is the movement engine for the non-building roads. No change.

Deferred past D-4 (NOT a D-4 scalar), now pinned for M14_C (m14c-multicompany) in Rival-Dynamism Deferrals, Pinned below: the Van Sweringen director-tabling expandRegion path (period-gated ~1924+) → 4a; and the capital-vs-route aggression split (so an operations-aggressive road like DT&I can churn its own corridor without reading as a network builder) → 4b. Still deferred (railroad-historian + user own): year-gated company-posture shifts (PM's company posture arguably becoming expansionist only from ~1924 — a mutating disposition, distinct from 4a's static-seat-that-becomes-able-to-table). Record the still-deferred item against the open questions / the D-0-deferred board-figures research; the date + which seat + the DT&I character reads are railroad-historian grounding done in parallel with the 4a/4b pins.

Rival-Dynamism Deferrals, Pinned (m14c)

The three D-4-deferred rival-dynamism features, pinned for game-dev to TDD on m14c-multicompany (M14_C). Each is judged BOUNDED (reuses existing seams) or STOP / fork (a milestone-sized new subsystem). All three honor the drift guard — no second disposition read, no new pivot/margin — and the player/AI-identical surface.

4a — Van Sweringen director-seat tabling (~1924+) — BOUNDED

The mechanic in one line. From a scenario-authored activation date, a non-head named director with an expansionist disposition (the Van Sweringen seat on Pere Marquette's board, aggression 70) becomes eligible to table expandRegion / pursueAcquisition through the existing proposal loop — the consolidation energy the historian grounds as a controlling-financier phenomenon, correctly seated on the financier's named-director seat rather than misattributed to the caretaker President (D-4 fidelity verdict).

What tables what. It tables the existing expandRegion and pursueAcquisition discretionary types — no new proposal type. "System/consolidation" is expressed as these two existing verbs driven by a director whose disposition leans expansionist, exactly as the C-5_3_C tabling read already maps an expansionist disposition to that priority order. A carried expandRegion commissions a feasibility study; a carried pursueAcquisition runs the friendly-first / hostile-fallback resolution — both already dispatch.

Where the tabling comes from — the one net-new seam (the bound's edge). C-5_3_C's DiscretionaryReview tables only off the head (_incumbentOf(companyId)). The Van Sweringen seat is a non-head director, so this is the director-initiated tabling path the C-5_3_B verdict and Q4 explicitly named as "the cross-holdings deepening … it needs the per-director proposer path that pass introduces." That path is the scope decision here: a non-head director rolling its own discretionary review and tabling through LeaderAct (or a DirectorAct sibling with the same teeth). It is BOUNDED because it reuses the whole disposition→lean→table pipeline unchanged — same DiscretionaryTableType read against the director's disposition (resolved through the existing DirectorRegistry.DispositionOf, which already resolves a non-head director's own aggression), same guardrails, same review cadence bookkeeping, same LeaderAct teeth. The net-new artifact is a per-director review loop mirroring the head's, and an eligibility flag narrowing which directors may table (below). No new proposal type, no new decision model, no new pivot.

Time-gate — keys off sim date via a scenario-authored per-director field (not a hardcoded year, not a scripted event). The gate is a tablesFrom date on the director in rivals.json (author the Van Sweringen seat "tablesFrom": "1924-01-01"; absent ⇒ eligible from scenario start, the default for all existing directors). The director's discretionary review is a no-op before _clock.Today reaches tablesFrom; on/after it, the seat rolls exactly as the head's review does. This keys off the sim date (Pillar 4 — time has texture) through authored data, not a hardcoded constant (CLAUDE.md — no baked numbers), and needs no Events.md scripted trigger. The historian grounds the exact date + which seat in parallel; the designer pins that the gate is a per-director authored date read against the clock.

Where the disposition shift lives. Nowhere new — the Van Sweringen seat is already a first-class named director with its own authored aggression (70, expansionist). There is no runtime disposition mutation and no director "trait" system invented: the seat is expansionist from birth; the tablesFrom gate is what withholds its tabling ability until the period date, not a disposition that changes. This is deliberately the cheaper model — a static-disposition seat that becomes able to act on a date, not a director whose character mutates mid-game. (A genuinely mutating posture — PM's company becoming expansionist ~1924 — is the separate year-gated posture-shift deferral, not this.)

Which directors may table (the eligibility narrowing — keeps 4a from becoming the full cross-holdings fork). Only a director with an explicit canTable: true flag rolls a discretionary review this pass — authored on the Van Sweringen seat only. Every other non-head director keeps its C-5_3_B behavior (votes its disposition, does not table). This bounds the pass to the one intended financier seat; it does not open a general dissident-board-faction system (every non-head director tabling counter-proposals), which stays the deferred cross-holdings deepening. Without the flag, seeding director-tabling on all seven rivals' full director rosters would flood the inbox and is the fork.

Verdict — BOUNDED (director-initiated tabling, one gated seat). Net-new: a per-director review loop mirroring the head's, a tablesFrom date field, a canTable flag, all in rivals.json + DiscretionaryReview. Reuses: DiscretionaryTableType, DirectorRegistry.DispositionOf (non-head path, already shipped), the guardrails, LeaderAct, the expandRegion / pursueAcquisition dispatch. STOP-adjacent line: if game-dev finds the per-director proposer path forces the per-director alignment generalization (C-5_3_B code-gap (b)) or a world-scope named-entity model (a financier holding seats across boards), that is the cross-holdings fork — surface it; the single gated seat on PM's own cap table does not need either.

4b — split the aggression capital-vs-route axis — BOUNDED

The conflation. Today one aggression int feeds two consumers with different meanings — the D-4 historian verdict flagged it as "a known modeling seam to revisit":

• Capital-aggression — how readily the delegated head accepts thinner contract margins (DelegatedManager.AcceptThreshold / WouldAccept, the contract-accept gate).
• Route-expansionism — how readily the head pursues network expansion (ExpansionTargetScorer contest-multiplier + BoardService.AggressionLeanFor tabling/vote lean).

A capital-aggressive-but-compact road — Ford's DT&I, financially muscular but deliberately not a system-builder — cannot be expressed: one number cannot be high for contract-accept and low for expansion at once. The D-4 verdict already forced this ("Ford's aggression was on the wrong axis — capital/operations, not route") and seated Ford's head at 60 as a compromise that misreads him on both axes.

The split — a second axis, routeAggression. Keep aggression as the capital-aggression axis (its contract-accept meaning is the dominant historical use and the AcceptThreshold consumer is unchanged). Add routeAggression (0–100) as the route-expansionism axis. Consumer split:

Consumer	Reads	Meaning
DelegatedManager.AcceptThreshold / WouldAccept	aggression (unchanged)	accept thinner contract margins
BoardService.AggressionLeanFor → LeanOf (tabling + vote lean, expandRegion / pursueAcquisition rows)	routeAggression	pursue network expansion / consolidation
ExpansionTargetScorer contest multiplier (Signal 3)	routeAggression	lean toward/away from contesting a rival-served candidate

The setDividend / authorizeFinancing vote rows and the mergerSale / control-item rows keep reading baseStanding (stability axis) exactly as today — 4b touches only the expansion-lean rows, moving them from aggression to routeAggression.

Range / default / back-compat — the drift guard is preserved by construction. routeAggression is 0–100, defaults to aggression's value when the key is absent. Every existing rivals.json seed (and every director) is therefore byte-for-byte unchanged in behavior — with no authored routeAggression, the two axes are identical and every consumer reads the same number it reads today. The drift guard is not broken because the pivot and margin do not move: routeAggression is classified through the same LeanOf band (_neutralAggression 60 ± dispositionLeanMargin 5) that aggression is — the tabling read, the vote lean, and the ExpansionTargetScorer contest sign all continue to route through the one shared classifier (AggressionLeanFor), now fed the route axis. The guard forbids a second pivot/margin, not a second input field read through the same pivot: the expansion consumers still make one disposition read against current state, off the same band — they just read the route-axis field. The contract-accept consumer keeps making its own read off aggression. These were already two separate reads of the same field; 4b gives them two fields, same bands.

DT&I expressible after the split. Ford's DT&I authors aggression high (capital-muscular — accepts thin margins, operates hard) and routeAggression low (compact — does not lay track). It reads correctly on both axes for the first time: capital-aggressive on the contract gate, non-expansionist on the board/expansion lean — exactly the "aggressive on its own corridor without registering as a network builder" the D-4 verdict deferred. The historian characterizes DT&I's two numbers in parallel; the designer pins the axis semantics.

Director-level split. The Director model's optional aggression? gains an optional routeAggression? with the same inherit-from-company fallback — so the Van Sweringen seat (4a) can be authored route-expansionist (routeAggression 70) while the PM company/head stay caretaker on the route axis, which is the honest expression of "the financier drives expansion over the President."

Verdict — BOUNDED (one additive field + a two-line consumer re-point). Net-new: a routeAggression int on Rival + Director (nullable, inherit-from-aggression default), and re-pointing the three expansion-lean reads (AggressionLeanFor's expansion classification, ExpansionTargetScorer's contest sign, the tabling read that already calls AggressionLeanFor) from aggression to routeAggression. DirectorRegistry.DispositionOf's return tuple gains the route field. No new pivot, no new margin, no new decision model, no scenario-seed behavior change. Watch item for game-dev: the drift-guard tests that assert the tabling read and the ExpansionTargetScorer contest sign classify off the same band must be updated to assert they read the same route-axis input through that same band — the invariant is "one band," and it holds; the test's input field changes, not the band.

4c — mergerSale seller-side exit dispatch — BOUNDED, with one enumeration seam to confirm

Framing confirmed against the docs — mergerSale is strictly the FRIENDLY seller-consent exit. It is the opportunist/seller verb: a failing, low-standing road whose own board authorizes selling the going concern before the board is forced to (the orderly counterpart to a hostile bid). It is tabled only when DiscretionaryTableType reads opportunist && repSliding (baseStanding ≤ 45 and rep < independentOustThreshold 40). The hostile case is a separate engine: it is the RespondHostileBid → CapTable.TakeoverSucceeds path, tabled on the target's board by an acquirer's accumulation, resolved by the shipped shareholder vote. mergerSale never covers the hostile case — a road does not table its own hostile takeover. This mirrors the two acquirer-side gates: mergerSale is the seller-consent side of the friendly deal, the exact complement of the acquirer-side friendly pursueAcquisition.

What a Carried mergerSale must DO — reuse the D-3 CapTable transfer, seller-initiated. On Applied, the exiting company's controlling block transfers to an acquirer via the same MoveControllingBlock seam pursueAcquisition already uses (buy back the head's block, issue it to the acquirer, ApportionSeats, reassign the Leader holding if player-held). The company does not dissolve and the field does not lose an entity — it changes hands: the road survives as an owned subsidiary/absorbed line under the acquirer, its cap table reflecting the new controller. This is the D-4 "movement among the standers" — ownership moves even where no track is laid (Pillar 3 — the named entity persists, it is not deleted). No dissolution path, no new economic machinery — it is the acquirer-side transfer run from the seller's authorization.

The counterparty — the one seam to confirm (potential fork, judged NOT a fork). pursueAcquisition carries its target in the proposal payload (the acquirer names who it buys). mergerSale today carries an empty payload (DiscretionaryPayload returns "" for it) — the seller authorizes selling but names no buyer. So dispatch needs who buys the exiting road. This is NOT a new buyer-matching subsystem — it reuses the existing acquisition enumeration in reverse: the buyer is the spine-adjacent rival for whom this seller is a valid acquirable target (the seller satisfies that acquirer's friendly gate — consents(sellerHead) is already true by construction, since the seller tabled mergerSale, i.e. is opportunist-and-sliding). Concretely: enumerate the companies whose spine is adjacent to the seller and who can afford the friendly price; the buyer is the nearest/most-able among them (mirror of the acquirer-side "smallest acquirable target adjacent to the spine" pick — here the seller picks the most-able adjacent acquirer). If no willing, able, spine-adjacent acquirer exists, the Carried mergerSale records the authorization but transfers nothing this resolution (the exit is authorized; the market has no buyer yet) — a legible "for sale, no buyer" state, not a crash and not a forced bad transfer. This is the same "restraint when no valid counterparty" pattern the acquisition-target gate already uses.

Why the counterparty seam is BOUNDED, not a fork. A general buyer-matching market (auctions, competing bids, price discovery across the whole field) would be a milestone-sized subsystem — and is not built here. The pin deliberately reuses the one-directional, spine-adjacent, disposition-gated enumeration D-3 already ships, run from the seller's side: it is one greedy pick over the seller's own spine-adjacency, same as every other rival decision, honoring the three NOTs (no lookahead, no global optimization, no new pivot). The HasAppliedMergerSale guard already prevents re-tabling, so an authorized-but-unsold road does not spam the exit.

Verdict — BOUNDED (reuse MoveControllingBlock + reverse the D-3 enumeration). Net-new: a case ProposalType.MergerSale: in DispatchBoardEffect (today it falls to the record-only default:) that resolves the buyer via the reversed enumeration and calls MoveControllingBlock(buyerId, sellerId); the seller-side counterpart populates DiscretionaryPayload for mergerSale (or the dispatcher enumerates the buyer at Apply time). Reuses: MoveControllingBlock, ApportionSeats, the D-3 spine-adjacency + affordability + consents enumeration, the HasAppliedMergerSale guard. STOP-adjacent line: if a scenario needs the seller to dissolve (leave the field entirely, contracts/debt wound down) rather than transfer to an acquirer, that is the "full-sale/merge semantics — what happens to the seller's board, contracts, debt, and network" seam the D-4 open question flagged; the transfer-to-acquirer path pinned here does not need it (the absorbed road keeps its books under the new owner, exactly as a D-3 friendly acquisition leaves them).

Note for ui-designer — player/AI-identical surface

The board surface renders exactly the four levers and nothing else: an open-proposals list to vote on, a propose action (any allowed type), the privileged-info books, and influence-hiring (a proposal subtype). The AI drives the identical proposal/vote API; the only player/AI difference is who supplies the input. Bind the surface to the AuthorityCapabilities.Can() Director caps — do not invent a separate board lever inventory.

Persistence shape (flag for C-1 forward-compatibility)

C-1 should reserve a boards section in the v2 schema (keyed by companyId) so C-5 adds fields without a migration fork:

• Board composition — seatCount; seats as { holderId, seatWeight, isIndependent }.
• Proposal records — { proposalId, companyId, type, proposerId, payload, dateTabled, deadline, state }.
• Vote tallies — per proposal, { directorId, vote, seatWeight }, plus computed for / against / abstain.
• Resolution history — closed proposals with outcome, appliedEffectRef, date.
• Cadence state — nextBoardMeetingDate.

C-1 need not implement the logic — only leave an (optional / empty) boards node so the shape is forward-compatible.

Service surface (game-dev, C-5)

A BoardService (or governance extension), pure-C# over the VirtualClock like the rest of the service layer:

• RaiseProposal(companyId, type, proposerId, payload, deadline) → record (Tabled → Open).
• CastVote(proposalId, directorId, vote) → updates tally.
• ResolveProposal(proposalId) → seat-tally (player manual + AI / independent auto by reputation + disposition); sets Carried / Failed / Lapsed against quorum + majority rule.
• ApplyResolution(proposalId) → dispatch the Carried effect to the owning service (CapTable / ProjectManagement / equity / leader-assignment).
• ApportionSeats(companyId) → recompute composition from CapTable fractions + reputation; called on any change of control. Reuses the CapTable reputation predicate — does not fork a second voting model.

JSON — a governance block in economy.json: seatCount default, seatThreshold, majorityFraction, supermajorityFraction, quorumFraction, board-meeting intervalDays, leaderRatificationRequired (which proposal types require ratification even from a Leader — all seven under the LOW band) and supermajorityProposalTypes, plus the disposition→vote scalars dispositionLeanMargin, neutralStanding, independentBackingThreshold, independentOustThreshold. AI director dispositions key off the existing rival aggression / baseStanding (rivals.json); the risk-axis pivot reuses delegation.neutralAggression rather than duplicating it. The ResolveProposal AI / independent tally follows the disposition→vote rules.

---

Equity

Equity here refers to the company acquiring ownership stakes in other businesses on the map. (For the player's own company's outstanding shares, see Company Stock above.) The shape of an equity transaction depends on the size and type of the target.

Types of Equity

• Full ownership / outright purchase — typical for small businesses such as rural farms, small ranches, small mills. The company buys the business outright and runs it as a wholly-owned subsidiary.
• Partial stake — typical for larger businesses such as major factories, refineries, mines. The company acquires some percentage of the equity, sufficient (or insufficient) to influence the business's behavior.
• Founding ownership — when a project under Construction commissions a new business (e.g., the company builds a new refinery as a subsidiary), the company owns it from inception.

Why Hold Equity

• Captive shippers (vertical integration downstream). A producer the company owns or co-owns will preferentially route through the company's network, locking in freight contract revenue.
• Captive suppliers (vertical integration upstream). A stake in a supplier — a locomotive manufacturer, a steel mill, a rolling-stock builder, a construction firm — turns it into a captive vendor for the company's procurement, including the construction labor pool that builds and maintains the network (see Construction — Staff and Labor). The strategic mirror of captive shippers: where captive shippers secure the revenue end of the chain, captive suppliers secure the cost end.
• Profit upside. Owned businesses contribute earnings (or losses) to the company.
• Strategic control. Equity in a refinery prevents a competing line from poaching its freight business; equity in a competing railroad's feeder business drains revenue from the rival.
• Project co-financing. Equity partners may co-fund projects that benefit them.

Friendly vs. Hostile Acquisition

A company can take control of another company by two distinct paths. They are complementary, not redundant — gated by opposite reputation conditions, paying different costs, and reaching targets the other cannot. The same end-state (control of the target) reached by either path produces very different goodwill outcomes on both player and company tracks. Both move control of a company — a rival railroad or other company-class entity; the small-business stakes in Types of Equity above (farms, mills, refineries) are the AcquisitionService industry-fraction buyout, a separate seam.

Note — what "acquisition" means here. This section is company-control acquisition: accumulating or buying a controlling equity block on the target's CapTable and winning the board through normal seat apportionment. It is not Portfolio.BuyStake — that is a personal-capital display field for a passive holding and does not sync the cap table, so it cannot transfer control. Both paths below transfer control by moving the block on the CapTable.

Hostile — control against the incumbent

Mechanism. Accumulate shares against the incumbent's will and win a reputation-gated ≥51% shareholder vote, exactly the Market Dynamics takeover model: named holders vote their shares, the public float votes by regional reputation, and the independents on the board turn on the seat once standing slides under independentOustThreshold (the respondHostileBid / appointLeader-install-challenger rows of the lean table). This is the already-shipped hostile engine — CapTable.TakeoverSucceeds and the ApplyHostileTakeover control-flip-and-reapportion path. No new hostile engine is designed or built; this path is that engine.

Success condition. Succeeds only when the target's reputation has collapsed — the float and independents must turn on the incumbent seat for a challenger to clear 51% of votes cast. A well-reputed target's float votes with its incumbent, so the hostile bid cannot clear the threshold. The hostile path is therefore the lever for distressed / reviled targets.

What transfers / what it costs. The accumulated block moves on the target's CapTable; winning the vote flips control and re-apportions the board. Pays a goodwill hit on both the player and company tracks (a hostile take is read as predation) — and can trigger scripted fallout (lawsuits, political reaction), the same as any Market Dynamics contest.

Friendly — control with the incumbent's consent

Mechanism. Negotiate a controlling equity block at a premium price purchased with the incumbent's consent. The premium bends on the two-factor leverage model (goodwill + counterparty leverage substituting into an effective standing): a well-liked acquirer with leverage pays a smaller premium; a reviled or weak acquirer pays a fat one. No share war, no vote against the incumbent.

Success condition. Succeeds when price + relationship clear AND the target's controlling holders consent — consent resolved by the target head's disposition (the mergerSale lean: an opportunist-and-sliding head takes the exit; a healthy stability-minded head refuses to sell the going concern at any reasonable price). Because consent is gated by a willing holder, the friendly path works on healthy, well-reputed targets the hostile path cannot touch — a respected road with an opportunist or distressed owner is friendly-acquirable though no hostile bid could ever clear its float.

What transfers / what it costs. Pays cash (book/market value + the leverage-bent control premium) out of the acquirer's treasury; the controlling equity block moves on the target's CapTable — an ApplyHostileTakeover analogue without the hostile vote, yielding control through the same normal seat apportionment. Avoids the hostile goodwill hit (a consensual deal is not predation). The transfer is on the CapTable, not Portfolio.BuyStake — the personal-capital display field does not sync cap-table shares and cannot carry control.

One mechanism for partial and control stakes. The same negotiated-price mechanism serves a partial friendly stake: a partial stake is simply a smaller block at a smaller premium, with no control transfer (it may earn a board seat if it clears seatThreshold, but does not flip control). There is no second partial-stake system — magnitude is the only difference.

The two paths are complementary (the invariant)

• Opposite reputation gates. Hostile needs the target's reputation collapsed; friendly needs a willing (opportunist / distressed) holder. They cover disjoint-but-adjacent target populations.
• A board-carried pursueAcquisition authorizes the pursuit and resolves friendly-first, hostile-fallback: the actor attempts the consensual block purchase; the hostile path fires only when friendly is refused AND the target's reputation has collapsed enough to clear the CapTable vote. A pursueAcquisition is the authorization, not the method — the method is selected by which gate the target satisfies.
• A sterling rival whose owner won't sell is acquirable by neither path — its reputation is too high for hostile and its holder too stability-minded to consent. This is correct, intended behavior, not a gap: a well-run, well-liked road should be unassailable until its owner's disposition or its standing changes. (It is exactly the "valid acquirable target" definition the discretionary-tabling acquisition gate and the target-selection heuristic below depend on: a valid acquirable target = one that satisfies the friendly OR the hostile gate. A target satisfying neither is not enumerable, so a pursueAcquisition against it never tables.)

D-3 implementable sign-off (friendly acquisition)

The D-0 pins above define the friendly path in design terms; this section confirms the code-level specifics game-dev needs for D-3, reusing the named seams and inventing no parallel machinery. All of it sits under the complementary-paths invariant.

Control-premium math (the "leverage-bent premium"). The friendly price is target valuation + a control premium that shrinks with the acquirer's effective standing toward the target — a well-liked acquirer with leverage pays a small premium, a reviled/weak one pays a fat one (Pillar 2). Concrete formula shape:

value      = target book/market value of the controlling block being bought
E          = effectiveStanding(acquirer → target) ∈ [0,100]         // the (goodwill + volume)/2 score, below
premiumPct = acqPremiumMin + (acqPremiumMax − acqPremiumMin) · (1 − E/100)
                 clamped to [acqPremiumMin, acqPremiumMax]
price      = value · (1 + premiumPct)

• E is NOT a new score — it is the existing effective-standing (goodwill_score + volume_score) / 2, the same two-factor leverage model sweetheart contracts and procurement already read. "Leverage-bent" = the volume_score half; "reputation-bent" = the goodwill_score half. A sterling acquirer with a dominant existing relationship (E → 100) pays acqPremiumMin; a reviled unknown (E → 0) pays acqPremiumMax. This reuses the leverage seam wholesale — do not author a second premium curve.
• Config scalars — new, into economy.json, mirroring the founding equity block shape (premiumMax / cap already live there for underwriting, so the pattern exists): an acquisition block with premiumMin (default 0.10 — the floor a sterling acquirer still pays for control) and premiumMax (default 0.50 — the ceiling; reuses the same 0.5 magnitude the founding equity.premiumMax uses, so the two premium curves stay legibly parallel). value is read from the target company's book/market valuation the share-price / market-dynamics model already computes — not a new valuation model.
• UNDER-SPECIFIED-FOR-CODE FLAG. effectiveStanding(acquirer → target) between two companies is not yet a shipped seam — the leverage model is authored for a player-vs-counterparty contract/procurement relationship (per-counterparty volume share), and the leverage-curve coefficients are still in Open Questions as "scenario-tunable, will need playtesting." For D-3, E must resolve for a company→company pair: goodwill_score = the acquirer's standing with the target (or the target's controlling regions); volume_score = the acquirer's existing volume/interchange share with the target, or Negligible if none. Game-dev should reuse the existing EffectiveStanding helper if one exists and extend its inputs to a company→company pair; if it does not exist at company granularity, that is a genuine seam gap to surface back — do not invent a bespoke acquisition-only standing score. Flagged for the caller as the one place the D-0 pin needs an implementation-level resolution before D-3 codes the premium.

Consent predicate (does the target head sell?). Restated as a crisp predicate over the target head's disposition, reusing the exact mergerSale For row of the lean table — no new condition:

consents(targetHead) ==
    opportunist(targetHead)  AND  rep(target) < independentOustThreshold

where opportunist = baseStanding ≤ neutralStanding − dispositionLeanMargin (the existing stability-axis band, 50 − 5 = ≤ 45), rep(target) = the target company's regional-reputation score from the reused CapTable predicate, and independentOustThreshold = 40 (existing governance key). A stability-minded head (baseStanding ≥ 55) refuses at any reasonable price — it will not sell the going concern. This is the same mergerSale-lean the C-5_3_C tabling already uses for a road seeking its own exit, read here from the acquirer's side against the target's head — one predicate, both directions. No new pivot, no new margin, no new threshold: neutralStanding 50, dispositionLeanMargin 5, independentOustThreshold 40 all already declared.

Enumeration — "smallest acquirable target adjacent to the spine." Confirmed as pinned in the target-selection heuristic: among the acquirer's spine-adjacent targets (a company stationing a settlement on or incident to the acquirer's own expansion frontier), filter to acquirable, then take the smallest by target valuation (cheapest to absorb — out-relationship, don't over-reach). acquirable = consents(head) (friendly gate) OR TakeoverSucceeds would clear at the current standing (hostile gate) — the disjunction from the complementary invariant. A target satisfying neither gate is not enumerable and a pursueAcquisition against it never tables (the acquisition-target gate drops the option). Reuse the same enumeration the discretionary acquisition gate already needs — one target list, shared by the gate and the pick.

Complementary-paths invariant test cases (game-dev must pin these). These prove the two gates stay disjoint-but-adjacent, not redundant:

1. Well-reputed CONSENTING target → friendly-acquirable, NOT hostile-takeable. Target rep ≥ 50 (float votes with its incumbent) and head opportunist with rep < 40… — note the tension: consent requires rep < independentOustThreshold, so a healthy-reputation target does not satisfy the consent predicate as written. The intended "well-reputed consenting" case is a target whose reputation is high enough that the hostile float won't turn (so TakeoverSucceeds = false) but whose head is opportunist and its standing has slipped just under the oust line (so consents = true). Test: rep in the narrow window just below 40 with an opportunist head → friendly-acquirable, hostile-fails (float hasn't collapsed enough for a challenger to clear 51%, but the head takes the exit). This pins that consent, not raw reputation, is what the friendly gate turns on.
2. Reputation-collapsed target → hostile-fallback-takeable. Target rep well below 40 with a non-consenting (stability-minded, or opportunist-but-refusing-terms) head → friendly refused, hostile TakeoverSucceeds = true (collapsed float + independents turn on the seat). Pins the friendly-first / hostile-fallback resolution: the pursuit tries consensual first, fires hostile only when friendly is refused and reputation has collapsed enough to clear the CapTable vote.
3. Sterling non-consenting target → acquirable by NEITHER. Target rep ≥ 50 (hostile can't clear) and stability-minded head (won't consent) → not enumerable, pursueAcquisition never tables against it. Pins the intended "unassailable well-run road" — correct behavior, not a gap.

Hostile-fallback threshold — reuse, don't invent. "Reputation collapsed enough" for the hostile fallback is not a new scalar: it is precisely the condition CapTable.TakeoverSucceeds already evaluates — the accumulated block + the reputation-weighted float + the independents turning on the seat below independentOustThreshold (40). The hostile path is that shipped engine (D-0 pin); the fallback fires exactly when TakeoverSucceeds returns true. No separate "collapse threshold" is authored — reuse TakeoverSucceeds and the existing independentOustThreshold.

mergerSale Carried-effect dispatch — a real gap, but NOT this fix pass's scope (scope ruling, D-4 playtest). D-4 found a Carried mergerSale hits ApplyResolution's record-only default: (no dispatch case) — the board approves the sale, nothing transfers. Measured against the pinned ApplyResolution contract ("dispatch the Carried effect to the owning service") and the Merger/sale Carried effect ("Approves merging or selling the company"), that is a genuine wiring gap — not a designed no-op. But it is not on D-3's critical path and not what unblocks the milestone:

• pursueAcquisition (the acquirer/buyer verb) is D-3's seam — the friendly-first / hostile-fallback resolution, whose CapTable transfer is wired (the ApplyHostileTakeover-analogue). mergerSale (the target/seller verb — a road approving its own sale) is a different resolution with a different owning-service dispatch, and it is not the path an expansionist rival's futile fall-through tables (that tables pursueAcquisition). So D-3 fires on this seed without MergerSale dispatch being wired.
• Therefore: close the two Bug-A / Bug-B2 seams first (they are what make the milestone deliver on this seed); wire mergerSale dispatch as a separate, tracked follow-up (an open question below), scoped with the opportunist-seller path, not folded into the D-3 acquirer fix. Reason to keep it separate: MergerSale's Carried effect (merge two companies / sell the whole company) is a broader control-and-consolidation transfer than a pursueAcquisition block-purchase, and rushing it into a bug-fix pass risks an under-specified merge semantics. Pinning it deserves its own seam review (what happens to the seller's board, contracts, debt, and network on a full sale/merge — the acquirer-absorbs-target bookkeeping).

Verdict — BOUNDED, over existing seams. Friendly acquisition adds: the premium formula (two new economy.json scalars, mirroring the founding equity block), a consent predicate that is the existing mergerSale lean read from the acquirer's side, and the ApplyHostileTakeover-analogue-without-the-vote CapTable transfer the D-0 pin already named. Two flagged gaps: (1) effectiveStanding at company→company granularity — extend the existing leverage seam, do not fork a bespoke score; (2) mergerSale Carried-effect dispatch — a real wiring gap, deferred to its own seam-review follow-up (above), out of this fix pass's scope.

Selling Equity

Equity stakes are not permanent. The company can divest stakes for cash, often at a premium or discount versus book value depending on conditions, and may be forced to divest under regulatory pressure or financial stress.

---

Contracts

Contracts are the revenue engine. The rail network does not earn money simply by existing; it earns money by fulfilling contracted shipments and services. The contracts that emerge are driven by the underlying regional economy — price differentials between regions, industries needing specific inputs, populations needing staples, and so on.

Revenue Accrual

Revenue is accrued per period, not per shipment. The simulation floor is daily — the engine processes contract performance, revenue accrual, maintenance costs, and similar at most once per day, which is fine-grained enough to align with the information-lag system without flooding the inbox with micro-revenue events.

The player's financial UI reads in summary cadences — typically weekly and monthly aggregates — with daily detail available on drilldown. Day-by-day numbers are jittery; weekly and monthly are the natural reporting cadences for a railroad business.

Settlement cadences for the various financial flows:

• Contract revenue — accrued daily; summarized weekly/monthly in the UI.
• Dividends — declared and paid quarterly (see Dividends).
• Bond coupons — typically semi-annual or annual depending on issue; the daily floor supports any cadence ≥ 1 day.
• Maintenance costs — ongoing, accrued daily (see Operations.md).

What a Contract Defines

A contract is an agreement between the company and a counterparty (a shipper, a passenger entity, a government body) covering some combination of:

• Origin and destination — a region at each end. Both regions must have rail infrastructure of at least the contract's required tier (see Capacity Gating below).
• Cargo or service type — specific commodity, passenger class, mail.
• Volume — quantity per period, or guaranteed minimum.
• Rate — payment per ton-mile, per passenger, per piece of mail, or a flat fee.
• Service level — frequency, on-time requirements, capacity guarantees.
• Term — duration, renewal terms, exit penalties.
• Breach penalties — what the company owes if it fails to perform. Ranges from informal (the counterparty stops sending business; goodwill hit) to formal financial penalties, fines, court costs, and regulatory consequences for high-leverage counterparties.

Capacity Gating

Each contract carries two required capacity tiers: a station tier (at both endpoint regions) and a line tier (on the track between them). Both must be met for the contract to be offered.

Station tier — the throughput ceiling at the customer's region. Reflects platforms, freight handling, yard capacity:

• Halt suffices for low-volume rural shippers — small farms, individual mines, single-shipper-per-period producers.
• Depot is the floor for ordinary inter-regional contracts — town-to-city freight, mid-size industrial customers, regular passenger service.
• Terminal is required for the largest customers — urban market leaders, mainline government contracts, premium passenger service, daily-volume manufacturers.

Line tier — the throughput ceiling of the track between origin and destination. Reflects gauge, single vs double track, weight rating, signalling:

• Branch track is enough for low-volume rural-to-regional traffic.
• Standard track handles ordinary inter-regional contracts.
• Trunk track is required for premium passenger express, mainline freight, and any contract whose volume or service level demands sustained high throughput.

A contract is not even offered to the player if either of: the origin's station tier, the destination's station tier, or the line tier between them falls below the contract's requirements. This is the primary mechanism by which infrastructure investment unlocks higher-tier business. A player who wants Ford's mainline freight contract has to upgrade Detroit's infrastructure to Terminal and the Detroit-area trunk to Trunk — there's no rate negotiation that can substitute for physical capacity. See Station Capacity Tiers and Line Capacity Tiers.

Contract Acquisition (Competing Networks)

When the player's company is one of multiple networks vying for a customer's business, contract acquisition is relationship-weighted — pure rate-bidding is not the model. Goodwill (with the customer, the relevant industry stakeholder, and possibly the regional Public or Government) modifies bids, so a trusted operator can charge somewhat above market and still win, while a reviled operator must underbid steeply or lose. The mechanic is deliberate: relationship-weighted acquisition rewards reputation maintenance, which is the loop the design wants to encourage. Pure rate-bidding would reduce the game to a margin contest.

Competing networks and CORRIDOR contest are distinct axes. Relationship-weighted acquisition above is competition for a customer's business. Separately, when multiple roads run parallel trunk routes into the same gateway — the contested-corridor case the successor canonical seed authors — the contest is over scarce throughput/car-supply to the gateway, not over any single shipper. There, holding a low-margin contract on a saturated corridor carries a real opportunity cost when a dearer offer arrives later, and the player's lever is drop-to-upgrade. "Contest" in that sense is demand-over-capacity on a company-owned segment, not player-vs-rival shared-track ownership.

Contract Tiers

The contract a counterparty offers depends on who they are and how much leverage they have, and the breach penalties and exclusivity rules scale up the same way.

Standard Contracts (Rural / Small Producers)

A small farm in a rural region uses whatever infrastructure the region has — Halt is sufficient — and ships at the network's standard rate for that cargo type. There is no negotiation — the rate sheet applies. These contracts are individually small but collectively important; a dense rural feeder network of Halt-tier regions produces revenue from a long tail of standard contracts.

Exclusivity: non-exclusive. The customer simply uses whichever network's rates and reputation suit them in the moment, and may use multiple networks across different shipments.

Breach penalty: informal. The producer stops shipping with the company and word may spread (goodwill hit with the local public and similar producers). No formal legal exposure.

Sweetheart Contracts (Large Industrial Customers)

A large factory, mine, or refinery has options. They may have a competing rail network nearby, or they may be able to threaten to relocate or self-build. To win or retain their business, the company offers a sweetheart contract: below-standard rates, prioritized service, capacity guarantees. They suppress per-ton-mile revenue but can lock in enormous volumes the company would otherwise lose to a rival.

These contracts require Depot or Terminal tier infrastructure at the customer's region — the volume guarantee and service-level commitments aren't physically possible at Halt. Customers know this and won't approach a player whose infrastructure can't handle their throughput.

Sweetheart deals are negotiated individually. Two factors determine whether the customer is willing to deal:

• Goodwill with the customer's owner — high goodwill lowers the bar.
• Counterparty leverage — what the company brings to the table. A large operator with substantial volume, presence across multiple urban regions, or unique route advantages has leverage even at low goodwill.

The two factors are substitutes. A well-liked operator can extract sweetheart deals at modest scale because they are trusted; a reviled but dominant operator still gets sweetheart deals because no one else can move the goods at scale. The formal substitutability is described in The Leverage Model below.

Exclusivity: sweetheart contracts may include exclusivity clauses as a negotiated term — the customer commits to using only the player's network for the contract's duration in exchange for the rate concessions and service guarantees. Exclusivity is the customer's leverage point: when they grant it, they expect more from the player in return.

Breach penalty: formal. Sweetheart contracts are negotiated deals with teeth — non-performance typically triggers contractual financial penalties (baked into the agreement), exclusivity clawbacks, and potential litigation. The customer who got a sweetheart rate is exactly the customer with the leverage to enforce it.

Government Contracts

Governments are the most lucrative class of customer despite often paying the lowest rates. A government contract typically guarantees a base minimum volume (or a flat-fee guarantee) for freight or mail. Historically, government mail and freight contracts kept early railroads solvent by providing reliable revenue that paid for ongoing maintenance even on lightly-trafficked lines. Government contracts:

• Pay low rates per unit.
• Guarantee high volume.
• Have stringent service requirements (mail in particular).
• Require company goodwill above a threshold to qualify, and active player goodwill with the relevant government body to win.
• May come with political strings — operating restrictions, route obligations, rate regulation on other contracts.

Exclusivity: always exclusive. When the player wins a government mail or freight contract, no competitor can serve that government's same need for the contract's duration. Exclusivity is the government's expected term — they are committing to one operator and want the corresponding commitment back.

Breach penalty: highest legal exposure. Non-performance can trigger fines, court costs, regulatory penalties (rate hearings, route obligations), and in extreme cases revocation of operating privileges. Combined with the goodwill consequences, these are the most punishing contracts to default on.

The Leverage Model

Sweetheart contracts (and procurement terms) are governed by a shared two-factor model where goodwill and counterparty leverage substitute for each other. The substitutability is formalized as an effective-standing score that combines them additively; the relevant gradation outcomes (pricing premium, delivery delay, tier restriction, refusal, preferred customer) read off the combined score rather than off goodwill alone.

Volume leverage is measured per counterparty — the player's share of that counterparty's business. A supplier whose biggest customer is the player carries high player-leverage; a supplier the player is 1% of a customer for carries near-zero. Underlying values are continuous and scaled quadratically in raw share. The continuous score maps to a 5-tier ladder parallel to the goodwill tier ladder:

• Negligible — barely a blip on the counterparty's radar.
• Modest — present but small.
• Substantial — meaningful customer/supplier.
• Major — one of the counterparty's most important relationships.
• Dominant — the counterparty depends on this relationship.

Effective standing is the simple average of goodwill score and volume score:

effective = (goodwill_score + volume_score) / 2, clamped to 0–100.

Worked examples:

• A Reviled operator (goodwill 15) at Dominant volume (90) reads effective 52 — Neutral.
• A Reviled operator at Negligible volume reads effective ≈17 — still Reviled.
• A Revered operator at Negligible volume reads effective 90+ — Revered; sterling reputation carries them despite small scale.
• A Respected operator at Major volume reads effective ≈75 — Respected or above.

Gradation thresholds key off effective standing, not raw goodwill. The pricing-premium / delivery-delay / tier-restriction / refusal / preferred-customer outcomes described elsewhere apply against the combined score.

Why additive rather than max. Additive smoothing means volume never fully erases bad reputation — a Dominant + Reviled operator reads Neutral, not Revered. That's intentional: the design wants reputation to always matter at the margin. A pure max-based combination would let giant reviled operators feel commercially invincible, which would flatten the goodwill mechanic.

Dynamic Demand and Contract Lifecycle

Contracts are not static. They are issued, fulfilled, breached, renegotiated, expired, and renewed. New contracts emerge in response to scenario events, economic shifts, and the appearance of new businesses. Existing contracts can be lost to competitors, terminated for poor service, or restructured under duress.

Temporal Demand Rotation, Pinned (2026-07-08) — a deterministic seasonal/secular envelope with seeded-stochastic bookings inside it; envelope dominant

The G-0 design pin for M14_G — Demand Rotation. At the G-0 baseline the shipped generator implemented only the spatial half of this section (M14_G has since shipped the temporal half described below): ContractGenerator.GenerateAvailable was a pure function of world state (commodity × producer × consumer × path, no time input), and ContractService.Refresh() regenerated the whole Available pool only on rail mutation, never on a day-tick — so on a static network the pool was fixed across the horizon. That static pool is what left M14_F's churn gradient LATENT at flat 0.00/d: a saturated corridor never later surfaces a dearer offer, so drop-to-upgrade has nothing to reach for. M14_G adds the temporal half. This subsection pins the cadence, the reproducibility mechanism, the exact rotation property the churn engine consumes, and the economy-revalidation STOP. Resolves the plan's Forks 1–3. Grounds on the railroad-historian's 1920s Michigan freight-cadence consult (persisted agent-memory).

Fork 1 — cadence: HYBRID, envelope-dominant. A deterministic seasonal/secular ENVELOPE, with seeded-stochastic bookings inside it. The historian's bottom line is that 1920s Michigan freight was a predictable calendar, and the design follows it: the arrival process is a deterministic envelope that a seeded-stochastic booking process rides inside, with the envelope dominant — the envelope sets each corridor-commodity's expected offer intensity and margin band day-by-day; the stochastic layer only jitters which eligible offers materialize and their exact timing within the band, never invents demand the envelope doesn't call for. The envelope has two authored components, both period-grounded:

• Seasonal (intra-year, calendar-locked). The sharpest scheduled spike is the sugar-beet campaign — harvest late Sept–Oct, factory slice-campaign ~Oct→Jan, then 8–9 idle months (MC + PM branches to Bay City / Saginaw / Alma / Caro / Sebewaing / Mt Pleasant). The Great Lakes freeze is a strong calendar-locked binary switch (navigation ~Apr open → Nov close; hard layup Dec–Mar) — autumn pre-close ore rush to the docks, winter all-rail coal diversion inland. Fruit-belt perishable pulses (cherries ~July, apples ~Sept–Oct) and fall-weighted storable grain/beans/potatoes fill in the rest. These are the Pillar 4 "time has texture" surface the player reads as period-authentic harvest/freeze rhythm.
• Secular (multi-year trend). The Detroit auto corridor ramps across the horizon (US production 2.3M → 5M+ cars/decade, ~+8–10%/yr) — this is the single biggest source of a new, dearer offer arriving later on an already-busy corridor, and it is precisely the temporal texture drop-to-upgrade needs. Layered on it: model-year summer retooling shutdowns, and Q5 late-dearer-offer drivers (new plant/mine openings — River Rouge, Dow Midland, Alpena cement, Rogers City limestone).

The stochastic layer is deliberately minor: within an envelope band, offer arrival is a seeded draw (which of the eligible commodity × producer × consumer × path triples surface as live bookings on a given day, and their exact stagger inside the season). It exists to keep two adjacent playthroughs from feeling like a fixed timetable read aloud, not to make demand unpredictable — the player who learns the beet campaign or the auto ramp is rewarded, exactly as a 1920s operator planning car supply around a known calendar would be. If a scenario authors the stochastic amplitude to zero, the mechanic degrades cleanly to a pure scheduled calendar (Fork 2b) with no code change.

Regulatory framing — re-pricing is SHIPPER competition for scarce car supply, never a carrier hiking its published rate. Post-Transportation Act 1920, ICC-regulated tariffs meant a carrier could not freely re-price. So the "dearer offer" the player chases is not the railroad raising a rate — it is a shipper bidding up against scarce car supply when peaks collide (car shortages were real, especially Q4 when the beet campaign, the pre-freeze ore rush, and the fall harvest all landed at once). The margin an offer carries still tracks the live per-region price differential the generator already computes; the envelope modulates how many offers a corridor sees and how contested its car supply is, which is what makes a corridor's best-available margin move over time. This keeps the whole mechanic inside the 1920s frame (Pillar 3, a world of named shippers, not an opaque "the market").

Amplitude figures are TUNABLE calibration, not frozen. The historian's multipliers (~3–5× beet, ~1.5–2× grain, the auto ramp slope) are period-informed inference, not measured citations — they are starting points authored into scenario JSON, tuned at the G-3 gradient/viability gate, never hardcoded in a service (the data-in-JSON rule).

Fork 2 — reproducibility: LOAD-BEARING, and preserved by construction. The determinism the whole test discipline rests on (the byte-identical guards, the Viability Invariant probes, the M14_E convergence measures) is non-negotiable and survives rotation as follows:

• The envelope is a pure day-tick function — given the scenario's authored seasonal/secular calendar and the sim day, the envelope's value for every corridor-commodity is deterministic with no random input. Trivially reproducible.
• The stochastic booking layer, if a scenario enables it, MUST draw from a seeded PRNG threaded through the sim's existing deterministic clock/RNG discipline — never wall-clock, never DateTime.Now, never iteration order over an unordered collection (Dictionary/HashSet) as an implicit entropy source. The PRNG is seeded per-scenario (or per-scenario-plus-run-seed) and advanced only on the ordered day-tick, so the same seed replays the same booking sequence byte-for-byte.
• The determinism invariant, stated so the harness/PM can assert it: a run under a fixed scenario seed produces a byte-identical offer-arrival/expiry sequence and byte-identical realized income across the full horizon, on repeat. This is the same class of guard M14_E/M14_F depend on; it does not go away under rotation — it moves from "byte-identical to the static pool" to "byte-identical to this seed's rotation trajectory." Any nondeterminism here fails the invariant and blocks the milestone.

The engine-consumed rotation property — pinned PRECISELY (heed the M14_F proxy lesson). M14_F's fixture failed because it pinned a plausible proxy ("contested corridor = blocked positive-margin offers") when the churn engine actually consumes the strictly stronger single-drop-seatable dearer offer. Do not repeat that. Rotation must produce, and G-3 must measure through the churn engine, exactly this:

On a saturated corridor, a NEW offer LATER arrives that is (a) dearer than a currently-held contract on that corridor AND (b) single-drop-seatable — dropping exactly one held contract frees precisely the throughput headroom needed to accept it, net of the dropped contract's breach penalty and re-acquisition friction clearing the competence-scaled swap bar. Call this the dearer-single-drop-seatable-offer property.

This is the exact thing the churn engine queries — not "the corridor is contested," not "a dearer offer exists somewhere," but "a single drop seats a dearer offer." G-3 measures the gradient through the engine (does an active same-tick drop-to-upgrade beat the lag-bounded delegate?), not through a proxy on the pool. If rotation surfaces dearer offers that are not single-drop-seatable (they need two drops, or the breach penalty eats the upgrade), the gradient stays flat and the property is not met — that is the measurement that matters.

The contested-corridor successor seed (M14_H) is what supplies this property on the canonical network the player plays — a saturated Detroit–Chicago trunk belt where the optimal book fills a binding segment and a dearer offer can arrive blocked behind a held cheaper one. Rotation is the temporal half (a dearer offer arriving later); corridor contest is the spatial half (a full corridor for it to arrive on). The M14_G G-0 probe proved michigan_1920s structurally lacks the spatial half — rotation alone cannot produce the single-drop-seatable property on a network that never saturates a corridor. On the static-first M14_H seed the belt is contested year-round without rotation; rotation is layered on later only if the static seed de-contests (M14_H Fork (c)).

Two Starvation Triggers: Fleet vs Throughput

A contract that's been signed but can't be physically served enters starvation — a state where it accumulates goodwill damage daily and auto-breaches after 30 days of continuous starvation. Two independent triggers can put a contract into starvation:

• Fleet shortage — insufficient locomotives or rolling stock allocated to the route (see Procurement — Triage When Fleet Falls Short).
• Segment saturation — at least one segment on the contract's route is over its per-segment throughput capacity (see Operations — Throughput and Saturation). Saturation can arise from the player's own contracts piling up on a corridor or from rival contracts running under trackage rights consuming capacity.

Either trigger alone is sufficient to starve a contract; they don't compound (a contract is "starving" or "running" — not "starving by fleet" vs "starving by throughput"). When a segment saturates and the system must shed load, the triage order is:

1. Rival contracts before player contracts (the player has absolute priority on player-owned segments — see Trackage Rights → Mechanics).
2. Within each owner group, lower-priority before higher-priority — Standard < Government < Sweetheart.
3. Within the same priority, oldest acceptance date first (FIFO tiebreaker — newer contracts are more replaceable because the railroad hasn't built goodwill around them yet).

The player has a manual re-route action on player contracts: at any time the player can ask the routing engine to find an alternate path through the current network state, avoiding saturated segments where possible. Free in cash, with a 30-day cooldown per contract to prevent the player from arbitrarily dodging saturation by spamming re-route — the player must commit to a routing choice and live with it for a month.

---

Interchange and Trackage Rights

When competing networks operate in the same region or share access points, the player has two main negotiated arrangements available for moving cargo across network boundaries: interchange and trackage rights. Both are alternatives to building a parallel route the player owns end-to-end.

Interchange

An interchange arrangement is a cargo hand-off. Network A carries cargo to a shared point; Network B picks it up there and carries it onward. Each carrier gets paid for the miles it actually hauled — the shipping payment is split between the two networks based on the haul each performed.

• The arrangement is negotiated. Each network can refuse to interchange, demand favorable splits, or charge premium handoff fees.
• Goodwill and counterparty leverage shape the terms — a competitor with high goodwill toward the player and meaningful volume to gain can negotiate cleanly; a hostile rival with little to gain may simply refuse.
• Refusal forces the player to choose: build their own competing route to bypass, or accept that some cargo cannot reach its destination through this corridor.

Trackage Rights

A trackage rights arrangement is more intimate. The player's company runs its own trains on the competitor's track — the player provides the fleet (locomotives, rolling stock, crews), the competitor provides track access. Shipping proceeds are split between the two: one party paid for the carry, the other for the access.

• Like interchange, trackage rights are negotiated and subject to refusal.
• The trade-off versus interchange: trackage rights require the player to operate fleet over more territory (more procurement need, higher fleet capacity demand), but the player retains end-to-end operational control of the shipment rather than handing it off.
• Useful for expanding into a new region without the capital outlay of building parallel track.

Mechanics

Trackage rights are granted per segment (settlement-pair), not per individual physical-line entity — with multiple lines potentially sharing a corridor (see Per-Segment Composition), a right covers the whole corridor rather than a specific track. A right carries:

• A grantee — the rival the right is issued to.
• A per-day fee — the access fee the grantee owes daily, debited from the grantee's treasury and credited to the grantor's.
• An expiry date — the right ends at midnight on this day unless renewed.

Loading and arbitration. A grantee's contracts that route over the granted segment contribute to that segment's throughput load (see Operations — Throughput and Saturation). When a shared segment saturates, the grantor's contracts have absolute priority: rival contracts starve first, regardless of contract priority tier. Within the grantor's own contracts, normal triage priority applies (Sweetheart > Government > Standard).

This encodes the realistic "whose track is it?" dynamic. A premium trackage-rights tier that grants the rival priority parity (for a much higher fee) is a plausible future deepening; the baseline grant is unequal.

Mid-run expiry. If a rival contract is in flight when its trackage right expires (or is revoked by the grantor), the contract auto-breaches at the next segment crossing. The rival pays the standard breach penalty to its shipper and takes the goodwill hit. The grantor collects accumulated fees through expiry and incurs no penalty for the contract's failure — though revoking aggressively damages the grantor's goodwill with the rival and any third parties watching the dispute.

Implementation state. The data model + service (TrackageRightsService) shipped in M13 Phase 9 — grants are stored per region-pair, daily fees credit the grantor's treasury, expiry detection works, the Network panel surfaces active grants. The negotiation flow — rival-initiated request events with player accept/counter/deny choices, plus the rival-side fee debit (rivals don't yet have treasuries in v1) — is the deferred Phase 10 work. Until that ships, rivals can't request grants through normal play; the service is invoked only directly (e.g. by test harnesses or scenario events).

The Player's Decision

For any cargo route that crosses competitor territory, the player chooses among three options:

1. Interchange — let the competitor carry the foreign-territory leg. Lower fleet demand on the player; competitor takes their cut for the miles they hauled.
2. Trackage rights — keep end-to-end operational control with the player's fleet on the competitor's track. Higher fleet demand on the player; player keeps more revenue but pays the access split.
3. Build a competing route — a Construction project. Highest capital outlay; eliminates dependency on competitor cooperation entirely.

Historical norm was mostly interchange, with trackage rights granted selectively and parallel-track building reserved for major strategic competition. Hostile periods (Vanderbilt's New York Central famously refused interchange with rivals) push players toward more parallel-build, while regulated late-era environments push toward open interchange.

---

Procurement

Procurement — sourcing locomotives, rolling stock, materials, technology licenses, and skilled labor — is architecturally a specialized application of the contract framework described above, but it has grown into its own deep dive.

→ Full detail: Procurement.md

---

How Business Dealings Interlocks With the Other Systems

• With Goodwill. Bond pricing, contract terms, procurement terms, and acquisition outcomes all key off goodwill — modulated by counterparty leverage (volume can substitute for personal favor). Conversely, business conduct (defaults, hostile takes, contract breaches) moves goodwill.
• With Construction. Bonds typically fund projects. Equity partners may co-fund projects. New construction creates new nodes that enable new contracts. New contracts justify new construction, and they also create the fleet demand that drives procurement. Owned businesses (including owned manufacturers) are built as projects.

The systems form a cycle: the company raises money (bonds), spends it on network (projects) and equipment (procurement), uses the network and fleet to win revenue (contracts) and to acquire businesses (equity), and earns or burns goodwill at every step — which feeds back into the terms it gets on the next iteration. Procurement and contracts are tightly linked: contracts demand fleet capacity, fleet capacity comes from procurement, and a procurement bottleneck forces contract triage.

---

Open Questions

Major Business Dealings design questions are resolved, including the underwriter quote model and the board governance loop (pinned for M14_C). Specific tunable values — bond coupon ranges, dividend defaults, share-price formula, founding quote coefficients, board seat-count / majority thresholds, vote weights for the takeover model, leverage-curve coefficients — are scenario-tunable and will need playtesting.

Rivals as Full Companies is resolved (rival = full Company runtime driven by the delegation engine; buy-in is the authority slide). Its one content dependency: the rival strategy archetypes / scenario focus (how 1920s Michigan roads actually behaved — consolidators, granger feeders, interurban competitors, auto-era traffic chasers) need railroad-historian grounding before rivals.json disposition + focus authoring, so the archetypes reflect real period behavior rather than generic tycoon-AI.

Board governance open question α (ratification band feel) is resolved (user, 2026-06-25) to the LOW band — "governed from day one." Two prongs:

• Uniform governance — YES. The board loop runs on every company, including the player-led one: its board can table and ratify the player-Leader's dividend/financing and can move to replace them (the 1920s norm of a President under a Chairman/board, and the user's "real ongoing loop" ruling). The loop does not govern only the companies where the player is a Director.
• LOW ratification band. The controlling Leader does NOT auto-pass routine items. Even routine dividend / financing moves table to the board and require ratification before they apply — the discretionary band below which a Leader acts unilaterally is set effectively at zero (leaderRatificationRequired lists all proposal types). A controlling Leader still carries routine items with their own seats; they just table first, so the multi-company politics is felt from the very start, not only when ownership or reputation slips. Leadership change / merger / sale remain supermajority regardless. (This supersedes the earlier "a player-Leader who controls enough seats passes routine items by default" recommendation — the LOW band is the deliberate opposite.)

The Leader vs. Director under the loop paragraph and the governance block in economy.json carry this stance; the band is scenario-tunable (raise it later for MEDIUM/HIGH feels by dropping routine types from the ratification set).

mergerSale Carried-effect dispatch — PINNED for M14_C (4c). A Carried mergerSale currently hits DispatchBoardEffect's record-only default: — approved, nothing transfers. It is a real wiring gap against the ApplyResolution contract, deliberately kept out of the D-4 Bug-A/Bug-B2 fix pass (see the D-3 scope ruling). It is the opportunist/seller exit (the orderly counterpart to a hostile bid), the target-side complement to the acquirer-side pursueAcquisition. 4c above pins it BOUNDED: reuse the D-3 MoveControllingBlock transfer (seller-initiated) with the buyer resolved by the reversed spine-adjacent acquisition enumeration. The seller-dissolves variant (leave the field, wind down contracts/debt/network) — the broader full-sale/merge semantics — stays deferred; the transfer-to-acquirer path 4c pins does not need it.