Populations and Interest Groups¶

Deep dive on regional populations and the interest groups that form within them. Population composition drives the local outcomes the player cares about: workforce availability, sabotage risk, public sentiment, and the texture of operating in any given region.

→ Parent: GDD.md

Concept¶

Population exists at two levels, matching the county / settlement world model:

Settlement population — the people of a specific town (city, village, fort, camp…). This is the base for that settlement's passenger demand, market demand, and local labor. A settlement the railroad creates from open country starts at population 0 and grows from there.
Regional (rural) population — the people of a county's countryside, around its settlements. This pool staffs frontier businesses (lumber camps, ranches, mines) and supplies labor for track-laying, maintenance, and station operations across the county.

The total size of each is driven dynamically by the regional economy and by rail access (below). This doc describes the composition of a population once it exists: how the people break down into interest groups. Composition applies to both levels; the gameplay effects below read against whichever level a given interaction touches (hiring station labor reads the settlement + surrounding county; a frontier lumber operation reads the rural pool).

Settlement Growth and Decline¶

A settlement's population moves every monthly tick under a baseline-plus-pull model: an organic trajectory set by the place's regional archetype, plus a bounded pull from the rail traffic and local jobs the player's network brings. Baseline is what the settlement would do left alone; pull is the railroad accelerating it (Pillar 7). The two layers are additive — rail accelerates growth and can seed a planted population-0 stop, but its absence never drags an authored city below its organic line.

The per-tick delta:

organic = population × ((1 + rate_annual)^(days/365) − 1)        // compounding; signed
pull    = ( railCoeff × √throughput × tierMult
          + jobsCoeff × √jobsWeight × jobsArchMult ) × (days / 30) // additive; ≥ 0; diminishing
seedAllow = seedFloor × max(0, 1 − population / seedFloorPopCap)    // tapers full→0 as pop rises
ceiling = population × ((1 + maxAnnualRate)^(days/365) − 1) + seedAllow × (days / 30)
delta   = round( min(organic + pull, ceiling) )                   // population floored at 0

Organic compounds the archetype's signed annual rate_annual over the tick window (days/365 of a year). Compounding, not linear, because the source rates are CAGRs ((pop₁₉₃₀ / pop₁₉₂₀)^(1/10) − 1); applying them geometrically reproduces the census trajectory. Positive archetypes grow at their rate indefinitely; negative archetypes (copper, cut-over) decay asymptotically toward zero. There is no population-proportional decay term — decline is a negative rate, not a drain.
Pull is a per-month flow (scaled linearly by days/30), always ≥ 0, with diminishing returns (√) so traffic and jobs accelerate a place without ever running it away. tierMult scales rail pull by station tier (Halt negligible, Depot modest, Terminal strong), consistent with Economy — Migration. jobsWeight is the county-aggregated, employment-weighted local-jobs figure (see Jobs Keying below). jobsArchMult is the declining-extraction jobs-pull multiplier keyed on the settlement's own archetype (default 1.0; 0.0 for contracting-extraction archetypes — see Declining-extraction suppression) — a shrinking mine does not pull workers in.
Ceiling caps the delta so no settlement grows faster than maxAnnualRate no matter how much traffic the player floods through it. seedFloor is a small absolute allowance (people/month) that lets a population-0 planted stop take root — a rate-based ceiling of 0 × anything = 0 would otherwise pin it (Pillar 7). This allowance is a take-root mechanism, not a permanent ceiling subsidy: its contribution to the ceiling is scoped to nascent stops and tapers linearly with population, full at pop 0 and zero at/above seedFloorPopCap. So an already-established town — including a small declining one (e.g. a cut-over lumber stop, pop ~471) — derives no allowance from it and remains held strictly to the maxAnnualRate ceiling. This is what keeps the rate ceiling binding for established declining towns, so rail throughput-pull can fight the tide (the intended lever — see contested-settlement growth) but stays bounded by the ceiling rather than riding an inflated one.

Why this avoids both failure modes¶

The previous model (pull − population × decayRate) created a throughput-set carrying capacity at population = pull / decayRate: idle authored cities bled toward it (Detroit ~994k → ~100k over 10y) and high-traffic small towns chased it upward without bound (Lansing ~57k → ~256k). Baseline-plus-pull removes the attractor:

No collapsing cities. No pop-proportional drain exists. An idle white-hot Detroit still grows at its organic +5%/yr; zero rail means zero pull, not decay.
No runaway towns. Pull has diminishing returns and a hard rate ceiling. A flooded midsize town can be accelerated from its +2% baseline toward the +8% cap — the player reshaping the world (Pillar 7) — but never to the old ~4.5× runaway.
No spurious fixed point. The only pop-proportional term is a rate, which has no non-zero equilibrium; pull is additive and bounded. Growth and decline are trajectories, not convergence to a traffic-set level.

Archetype → settlement assignment¶

Each settlement resolves one growth archetype carrying a signed annual rate, grounded in 1920→1930 Michigan census CAGRs (research: data/research/m14b-population-growth.json):

Archetype	rate_annual	Period anchor
`boom_industrial_whitehot`	+5.0%	Detroit, Flint, Pontiac (white-hot auto)
`boom_enclave_plateaued`	+1.4%	Hamtramck, Highland Park (built-out enclaves)
`midsize_established`	+2.0%	Grand Rapids, Lansing, Saginaw, Kalamazoo…
`rural_farm_lp`	−0.3%	LP agricultural counties (the default)
`iron_range`	−0.4%	Marquette / Dickinson / Gogebic
`cutover_lumber`	−2.0%	cut-over stump counties (N. LP & UP)
`copper_country_declining`	−3.2%	Houghton / Keweenaw

Assignment is an authored override on a county-derived default — the same "scripted specifics + templates" pattern used for initial composition:

A settlement may carry an explicit growthArchetype. This is required wherever the archetype can't be read from the county — most importantly Detroit (white-hot) vs Hamtramck / Highland Park (plateaued enclave), which share Wayne county and its tags but grew five-fold differently across the decade. Named first-class settlements (Pillar 3) carry their own trajectory.
Otherwise the archetype is derived from the county: Mining + UP + copper → copper; Mining + UP + iron → iron range; rural northern-LP/UP forest county → cut-over; rural LP → farm; IndustrialHub / large auto city → white-hot or midsize by size. The modal Michigan county falls to defaultArchetype (rural_farm_lp).
A planted open-country stop inherits its county's derived default at creation — plant in thriving country and the seeded town rides that trajectory; plant in declining copper country and it struggles even with traffic (Pillar 7 cuts both ways).

Jobs keying¶

Local-jobs pull is aggregated at county scope (the county is the labor shed) and weighted by employment, fixing the bug where the term was keyed to the settlement id and read zero for Detroit — whose authored industries sit at satellite settlement ids (wayne_highland_park, wayne_hamtramck), not at wayne_detroit:

Each industry carries an employment figure (authored; fallback defaultEmployment), counted once per county.
The county's total employment is allocated to its stationed settlements purely by population share: jobsWeight(s) = popShare(s) × countyEmp, where popShare(s) is settlement s's share of the county's stationed-settlement population. There is no direct-site credit — a plant's population pull accrues to where the county's people actually live (housing + rail access), not to the parcel the plant sits on. (If the county's stationed population sums to zero — e.g. a just-planted pop-0 stop — split countyEmp equally among the county's stationed settlements rather than divide by zero.) Allocation conserves the pool: Σ jobsWeight(s) = countyEmp.

This routes Wayne's ~67k auto employment to Detroit (which holds ~91% of Wayne's stationed-settlement population) — the term is live for the biggest city, fixing the dead-term bug — while crediting the built-out enclaves only their small resident share. That is both the historically correct mechanism and the fix for the enclave-inversion trap: Highland Park (~45k jobs) and Hamtramck (~22k jobs) carry the county's largest factory workforces but had near-flat 1920s population growth (no land to annex — boom_enclave_plateaued, ~+1.4%/yr). Crediting their direct site employment as pull would push them to the top of the growth ranking, exactly inverting the census, and the +8% ceiling sits far above their +1.4% baseline so it would not bound the error. Pure pop-share gives each enclave only its resident share, keeping it near its historical line, because their workers settled in Detroit and across the wider county, not the built-out enclave. A fresh player-built stop instead grows on its rail pull + seed floor — the primary world-shaping lever (Pillar 7) — and as that traffic raises the stop's population, its pop-share rises and it captures a growing share of the county's jobs pull over time.

Because the archetype baseline already encodes the historical job-driven demographics (the auto boom is the +5% white-hot rate), jobsCoeff is deliberately modest — a marginal accelerator, not a second copy of the boom (historian caveat: do not double-count the auto boom). Sanity check at jobsPullCoeff = 0.5: Detroit's allocated jobsWeight ≈ 0.913 × 67,000 ≈ 61,000, so the jobs term contributes 0.5 × √61,000 ≈ 124 people/month — ~3% of Detroit's ~4,000/mo organic term (993,678 × ((1.05)^{30/365} − 1)). It nudges, never drives, and over 10 years adds only ~15k to a city heading toward ~1.6M. No settlement reaches the rate ceiling from jobs alone (a plateaued enclave's jobs term is ~27/mo on a ~53/mo organic base — a fraction of a percent a year added, not a boom).

Declining-extraction jobs-pull suppression¶

A contracting extraction industry is not a migration magnet — it is the opposite. Calumet & Hecla shed shifts straight through the 1920s (depleted lodes, high-cost copper vs. western/foreign ore, the 1913–14 strike aftermath, the post-war price slump); the iron ranges softened; the cut-over lumber district was a post-boom remnant (historian: data/research/m14b-industry-employment.json, decline notes per entry; data/research/m14b-population-growth.json, copper_country_declining / iron_range / cutover_lumber). The mine's contraction is the story of those counties' population loss.

That contraction is already encoded in the negative organic archetype rate — copper's −3.2%/yr is the mine releasing workers and people leaving the Keweenaw. Letting the same shrinking mine also feed a positive jobs-pull double-counts it in the wrong direction: pure pop-share jobs-pull on Calumet & Hecla's payroll out-pulls the −3.2% organic decline and inverts the census (Calumet would grow). This is the exact mirror of the auto double-count the jobs-keying coefficient already guards against — there the white-hot +5% baseline already bakes in the auto boom, so jobs-pull must stay a modest nudge; here the negative extraction baseline already bakes in the mine's decline, so jobs-pull on a contracting mine must be suppressed entirely, not merely shrunk.

The mechanism is an archetype-keyed multiplier on the jobs term, jobsArchMult = jobsPullArchetypeMultiplier[settlement.archetype] (default 1.0; 0.0 for the three contracting-extraction archetypes copper_country_declining, iron_range, cutover_lumber). It is keyed on the settlement's own growth archetype, so a copper or iron town gets zero jobs-pull regardless of which industries sit in its county, while rail throughput pull is untouched — heavy ore traffic can still accelerate a range town (Pillar 7), but the mine's payroll no longer manufactures phantom in-migration. A planted open-country stop that inherits a declining-extraction county default is suppressed the same way: plant in dying copper country and the stop grows only on the rail pull and seed floor you bring, fighting the regional tide (Pillar 7 cuts both ways), consistent with the archetype-assignment note above.

Why this is the right layer (vs. decaying the employment figure). Decaying each mine's authored employment over time was the first-considered fix, but it is mechanically too weak to reliably flip the 10-year trajectory: the jobs term scales with √employment, so halving the term needs employment cut to a quarter, and the early years (highest population, employment still near its start value) dominate the decade CAGR — no plausible, historically-defensible annual decay rate flips the sign cleanly. The archetype multiplier removes the spurious pull immediately and completely, fixes copper and iron in one stroke, and touches nothing outside the three declining-extraction archetypes (so every growing/stable settlement — Detroit, the plateaued enclaves, the midsize cities, the planted prairie stop — is bit-for-bit unchanged). The authored per-industry employment figure stays available for traffic/output modeling; if a future milestone wants employment to also drive freight tonnage, a separate decay schedule can be authored there without re-litigating the population fix.

This adds no population-proportional drain — it only zeroes a positive accelerator for contracting-extraction settlements — so the model's no-collapse / no-spurious-fixed-point guarantees above are preserved: a copper town falls at most at its asymptotic −3.2% organic rate, never below 0.

Multi-company traffic aggregation¶

The world is a constellation of companies — N player-held plus M rival, each a full runtime (Rivals as Full Companies). A settlement grows on all rail through it, not just the active or owning company's (Pillar 7); rivals are first-class contributors (Pillar 3), counted identically to player companies. The two pull inputs aggregate as:

Throughput. throughput(s) = Σ over every company c, Σ over segments incident to s, SegmentLoad(c, segment). Load is keyed to the contract owner, so each shipment is counted exactly once even when it crosses another company's track: parallel lines on a shared corridor (Per-Segment Composition) carry distinct contract-loads (two real flows), and a rival running under trackage rights on the grantor's track contributes its own load while the grantor's contracts contribute theirs — additive, never double-counted. The diminishing-returns √ is applied once to the aggregate (√(Σ loads)), not per company. This is deliberate: √ models the place's absorptive capacity, not each carrier's; a per-company-then-sum (Σ √load_c) would let fragmenting the same traffic across more carriers manufacture growth (3·√(X/3) ≈ 1.73·√X > √X), a gameable artifact. tierMult reads the highest station tier present at the settlement across all companies — the town's best-equipped station defines its connectivity to the wider world regardless of who built it.
Jobs. jobsWeight stays the county-aggregated, employment-weighted figure and is owner-agnostic: county employment sums every industry in the county, counted once, whether player-held, rival-held, or unowned. A factory's workforce is the same town's jobs pull no matter who holds its equity — ownership drives company profit, not the town's growth. (The single-company jobsOf wiring is an implementation artifact of the pre-multi-company build; the jobs-keying design intent is and always was owner-agnostic — see game-dev note.)

Competition is purely additive at the growth layer. Two companies contesting a town both feed their throughput in; the town grows on the total — a well-served competitive junction booms (historically true). Competition resolves in the contract / goodwill / revenue layer (who wins the business, the split, the margin), never as a growth penalty. The √ and the maxAnnualRate ceiling already bound any runaway.

Playtest signal to watch: contested-junction settlements (served by ≥2 companies) breaching their archetype growth envelope in the 10-year harness — the growth coefficients were calibrated against census CAGRs under single-company traffic, so confirm √-on-aggregate keeps shared corridors bounded, and that rival-only-served towns (player absent) still grow, confirming rivals are real world-shapers.

Contested-settlement growth (design intent)¶

When C-1_A_3_B gives rivals real starting networks, contested settlements (served by ≥2 companies) legitimately grow faster than the single-company traffic the growth coefficients were first calibrated against. This is intended, not a regression — more carriers serving a junction is more service, and a well-served competitive junction historically boomed (Pillar 7; additive competition, aggregation rule above). Use the following to tell a legitimate re-baseline from a bug:

What SHOULD happen. A node served by 2+ companies grows faster than under single-carrier traffic — its expected growth moves up toward the maxAnnualGrowthRate ceiling (0.08). The gate's expected numbers for contested nodes should be re-baselined upward to this new truth, not held at the single-company figures.
Bounds that still hold — by design, not a bug to chase. The √-on-aggregate damping and the rate ceiling bound any pile-up: no node grows faster than maxAnnualGrowthRate no matter how many carriers contend. Do not add a competition-specific penalty or a per-junction carrier cap — that would contradict additive competition and Pillar 7; √+ceiling are the only intended bounds.
What IS a bug. (a) Any settlement exceeding maxAnnualGrowthRate. (b) An extraction-inversion: a declining copper / iron / cut-over town flipping to growth driven by jobs-pull — jobsArchMult = 0 must still zero jobs-pull on those archetypes regardless of carrier count (declining-extraction suppression); a reappearing jobs-pull inversion is the regression to catch. (Rail throughput-pull accelerating a declining town is not an inversion — it is the intended fight-the-tide lever, bounded by the ceiling. Note the active LP roads are not ore carriers, and the UP ore roads are inactive until UP opens, so heavy ore throughput onto declining range/copper towns does not occur on the michigan_1920s LP seed yet.)
Anchor checks that must still pass. Detroit's Y10 lock holds: Detroit is a white-hot organic city dominated by its +5%/yr baseline, with pull a ~3% nudge (jobs-keying sanity check); multi-carrier throughput should move its Y10 only marginally. A large Detroit Y10 swing signals over-weighted pull (a bug), not a legitimate re-baseline.

Game-dev (C-1_A_2). Replace the single-company throughputOf: SegmentLoad.AllLoads() / jobsOf: JobsWeightFor construction of SettlementService with the aggregate above: sum SegmentLoad across all company runtimes (player + rival) for throughput; sum all county industries' employment (owner-agnostic) for jobs. Order deterministically (by companyId, then segmentId) so the tick is reproducible.

Tunables (scenario JSON)¶

All coefficients live in economy.json under a settlementGrowth block — never hardcoded in C# (per CLAUDE.md). First-pass values:

"settlementGrowth": {
  "tickDays": 30,
  "archetypes": {
    "boom_industrial_whitehot": 0.050,
    "boom_enclave_plateaued":   0.014,
    "midsize_established":       0.020,
    "rural_farm_lp":           -0.003,
    "iron_range":              -0.004,
    "cutover_lumber":          -0.020,
    "copper_country_declining": -0.032
  },
  "defaultArchetype": "rural_farm_lp",
  "railPullCoeff": 3.0,
  "jobsPullCoeff": 0.5,
  "jobsPullArchetypeMultiplier": {
    "copper_country_declining": 0.0,
    "iron_range":               0.0,
    "cutover_lumber":           0.0
  },
  "stationTierPullMultiplier": { "halt": 0.25, "depot": 1.0, "terminal": 2.0 },
  "defaultEmployment": 30,
  "seedFloorPerMonth": 50,
  "seedFloorPopCap": 250,
  "maxAnnualGrowthRate": 0.08,
  "pullCurve": "sqrt"
}

Coefficient	First pass	Role
`archetypes.<id>`	see table	signed annual organic rate per archetype
`defaultArchetype`	`rural_farm_lp`	fallback when no override and county derivation is inconclusive
`railPullCoeff`	3.0	scales √throughput rail pull
`jobsPullCoeff`	0.5	scales √jobsWeight jobs pull — held small (≈3% of Detroit's organic term) so it nudges, never doubles, the auto boom already in the white-hot baseline
`jobsPullArchetypeMultiplier.<id>`	`0.0` for the three contracting-extraction archetypes; `1.0` (implicit default) for all others	per-archetype multiplier on the jobs term keyed on the settlement's own archetype; `0.0` suppresses phantom jobs-pull from a shrinking mine whose decline is already in the negative organic rate (copper / iron / cut-over). Unlisted archetypes default to `1.0`
`stationTierPullMultiplier`	0.25 / 1.0 / 2.0	tier weighting on rail pull (Economy — Migration)
`defaultEmployment`	30	employment fallback for an unauthored industry — an order of magnitude below the smallest named plant (Cadillac mill ~250) so a fallback can never out-pull an authored facility; most of the ~130 unauthored settlements' industries use it
`seedFloorPerMonth`	50	absolute ceiling allowance so a population-0 stop can take root; its contribution tapers to zero as population approaches `seedFloorPopCap`, so it only aids nascent stops and never subsidizes an established town's ceiling
`seedFloorPopCap`	250	population at/above which the `seedFloorPerMonth` allowance contributes nothing to the ceiling (linear taper from full at pop 0). Scopes the take-root allowance to nascent stops, keeping `maxAnnualGrowthRate` strictly binding for established — including declining — towns
`maxAnnualGrowthRate`	0.08	anti-runaway rate ceiling (just above the historical max, Pontiac at +6.6%)
`pullCurve`	`sqrt`	diminishing-returns shape on the pull terms

This is the cattle-town / lumber-stop dynamic made mechanical: plant a stop ahead of demand, and whether it becomes a town depends on the traffic you route through it and the jobs that accrete around it — now riding a baseline that keeps authored cities on their historical arc. Higher station tiers raise the rail pull; on-settlement industry raises the jobs pull. See Economy — Migration.

The population is not a uniform mass — it breaks down into interest groups, factions of the population aligned around shared political or economic positions. Most of the population is uninvolved by default — people living their lives, not bothered by local politics. The remainder belongs to active interest groups that take positions and produce concrete gameplay effects.

The interest-group pattern is a deep-simulation idiom (notably Victoria 3's pop model), where population composition drives political and economic dynamics. In Manifest Rail, it is the substrate underneath the population-driven stakeholders in Goodwill and the source of many county-local gameplay effects.

Default and Active Interests¶

Default: Uninvolved¶

Most of a region's population, in most scenarios, has no political interest. They are the background mass — neither friends nor enemies, just present. They live their lives, work their jobs, and don't pay close attention to which railroad is doing what.

Active Interests (Initial Set)¶

Local Union Supporters¶

People aligned with organized labor. A good relationship with the union supporters in a region produces a skilled-workforce buff for the railway: easier to hire engineers, foremen, and conductors; lower wage premiums; reduced strike risk; smoother contract negotiations. A bad relationship inverts these into strikes, slowdowns, sabotage, and work stoppages.

Company Men¶

People personally loyal to a specific company. Each major active company (the player's, a rival's, etc.) can have its own company-men contingent in any region.

Company men loyal to your company give you workforce loyalty and political support in the region.
Company men loyal to a rival make life difficult for you when you try to operate or expand there: rival projects face higher sabotage risk, violence against survey crews, vandalism, and political pushback. A region where one company has a dominant company-men base is effectively that company's regional stronghold.

Bondholders¶

People who personally hold bonds issued by a specific company. This interest forms when a company sells debt directly to a region's population — a common practice in early eras, when railroad agents traveled town to town hawking bonds. Each company-as-issuer has its own bondholder interest in regions where it sold debt.

A serviced bondholder population is a moderate positive constituency: they have a financial stake in the company's success, support its projects locally, and are willing to absorb additional issuance.
A defaulted bondholder population is catastrophic: they lost real money to the company's executives. The goodwill hit lands on both player and company tracks, the modifier is typically sticky, and the grievance can persist for decades — a town that lost savings to a defaulting railroad in 1873 may carry the resentment well into the 1890s.

Bondholders also gate further issuance: a region full of soured bondholders will not buy new bonds at any price.

Scenarios can introduce additional active interests as needed (regulatory advocates, anti-railroad activists, immigrant labor blocs, agricultural reform movements, etc.), each with its own gameplay effects when present in significant numbers.

Composition as a Property of Regions¶

Each region's population is tracked as a literal POP count — a discrete number of people resident in the region. The population is broken down into interest groups, also tracked as counts. Percentages surface to the player for at-a-glance reading, but underneath the simulation tracks raw numbers.

A region's breakdown might look like (percentages shown for clarity, with raw counts available on drilldown):

Uninvolved: 75%
Union supporters: 15%
Player Company men: 7%
Rival X Company men: 3%

The breakdown changes over time only in response to events — it does not drift autonomously. This is a deliberate choice given Manifest Rail's typical scenario time scale (years to decades, not centuries as in Crusader Kings, Victoria 3, or Europa Universalis); autonomous ideology drift over short scenario spans would be more confusing than illuminating. The design is open to revisiting this if longer Free Scenario play surfaces the need.

Events that shift composition include:

A successful project that employs many local workers grows the company-men contingent of the project's owner.
A strike that the company crushes radicalizes the uninvolved into union supporters.
Scandals erode the relevant company-men base (some convert to uninvolved, some defect to a rival's camp).
Scripted scenario events can shift composition directly (a national event spikes union sympathy across all regions).

Compositions are visible to the player, subject to information lag — distant regions may show last-known compositions weeks out of date in the postal era.

Relationship to Goodwill¶

The presence of populations and interests reshapes the goodwill system's stakeholder model into a hybrid:

Population-driven stakeholders (Labor, Public, Company Men) emerge from regional population composition and are tracked per region — Labor in Chicago is a separate stakeholder from Labor in St. Louis, each with its own goodwill score, modifier list, and Clout (derived from that region's interest-group sizes). This avoids a hidden cross-regional aggregation step and keeps each regional standing visible on its own terms. The trade-off is more stakeholders to scroll through; the UI groups them by category to keep the panel readable.
Cross-regional abstract stakeholders (national Government, Financial Markets, industrial barons, Competing Railroads) are not tied to populations. Their Clout remains an authored scenario value.

Per-stakeholder, per-track goodwill scores work the same way as before — the player has a goodwill score with the union supporters in a given region, and another with a specific company-men faction, and so on. There is no aggregate summary number; each entry stands on its own, presented as a list.

Gameplay Effects¶

Active interest groups produce direct gameplay effects in their region — not just goodwill modifiers. The pattern:

The interest group has a size (% of regional population, or absolute count — see Open Questions).
The player has a relationship score with that group (0–100 per Goodwill).
The combination of size × relationship produces a buff or debuff to specific gameplay variables in the region.

Examples:

Interest Group	High-Relationship Effect	Low-Relationship Effect
Union supporters	Skilled-workforce buff; lower strike risk; favorable contract terms with local labor	Strikes, slowdowns, sabotage, work stoppages
Your own Company Men	Workforce loyalty buff; reduced rival activity in the region; political support for your projects	Rare; scenario-specific (e.g., your loyalists feel betrayed)
Rival's Company Men	Not normally accessible (you don't have a relationship with their loyalists)	Sabotage, vandalism, political opposition for your projects in this region

A 30%-union region with a low relationship is far more dangerous than a 3%-union region with the same low relationship. Effect magnitudes scale with both the size of the group and the polarity of the relationship.

Player-Facing Display¶

Regional populations surface to the player in two complementary forms:

Detailed breakdown on the region's profile page — the full interest composition with raw counts and percentages, expandable to modifier lists, recent shifts, and trend. This is the primary surface.
Quick annotation in the map view — when the player calls up the map, hovering or focusing a region produces a small overlay summarizing total population, dominant interests, and any active anomalies (recent strike, rapid growth, license revocation, etc.).

Matches the design's general "summary at a glance, detail on demand" UI principle.

The Player Character and Interests¶

The player character does not carry an interest of their own. The player decides which gameplay options they want to pursue without their character being mechanically locked into a faction. (This may be revisited if scenarios want to explore identity-based gameplay, but the default is faction-agnostic — the player is free to court Labor one decade and crush them the next without their own identity getting in the way.)

Initial Composition Authoring¶

Scenario authors set starting populations using two complementary tools:

Scripted starting populations — explicit per-region population counts and interest breakdowns at scenario start, written into the scenario script. Used when the scenario needs specific historical accuracy.
Premade templates — reusable population profiles for common region archetypes (rural Pennsylvania mining region in 1880, urban Chicago in 1893, Plains farming region in 1870, etc.) that scenarios can drop in and override only where needed.

Template content is built outside the game engine using historical research combined with procedural generation. Authors don't need to redo demographic work for every scenario; they pick a template that fits the era and region, then override specifics where the scenario demands.

The framework is designed to be open to change — if playtesting reveals that, say, autonomous ideology drift would improve longer scenarios, or that a different composition format would better support a particular scenario, the schema should accommodate that without major restructuring.

Open Questions¶

All major Populations design questions are currently resolved. The settlement growth/decline model is specified above (baseline-plus-pull, archetype rates grounded in census CAGRs), including the M14_B_6 declining-extraction jobs-pull suppression that keeps copper / iron / cut-over towns on their census decline rather than inverting it on a contracting mine's payroll; its coefficients are first-pass and scenario-tunable. Remaining tunable values — strike-likelihood thresholds, regional template content, interest-shift magnitudes per event type — are scenario-tunable and will need playtesting. The framework is intentionally kept open to revisiting any of these decisions (notably autonomous ideology drift, if longer scenarios surface the need).