Construction and Project Management¶

Deep dive on how the player builds and modifies the rail network. The defining design choice here is that the player commissions projects; staff executes them. Planning is abstracted away. Cost transparency is not.

→ Parent: GDD.md

Design Intent¶

Most rail games put the player in the role of a track-laying engineer. Manifest Rail puts the player in the role of an executive who orders work and signs the checks. The shift in perspective:

The player decides what should be built, where, when, and how it is funded.
Subordinate staff (the company's engineers, surveyors, project managers) decide how to execute it.
The player evaluates outcomes against the projected plan and intervenes when something goes wrong.

This frames every construction decision as a managerial bet, not a tile-painting exercise.

Staff and Labor¶

Projects don't execute themselves. The company runs on two distinct layers of personnel: a small set of named key staff who lead planning and execution, and a broader labor pool that supplies the workers. Both layers respond to the company's structural choices and to its goodwill standing.

Key Staff (Named Individuals)¶

The company hires a small roster of named individuals — its key staff. They are company-level assets, not tied to any specific project. The player chooses what each one focuses on, and they remain focused on that assignment until the player reassigns them.

Focus and Assignment¶

Each staffer holds exactly one focus at a time. The focus determines what the staffer's traits apply to. A focus can be:

A role (open-ended) — leading a domain across all the company's activity. Starting set: Chief Engineer (construction), Surveyor-in-Chief (route planning and land acquisition), Construction Superintendent (field execution), Mechanical Superintendent (rolling stock and equipment), General Counsel (permits, eminent domain, regulatory exposure). The role list is a working set; see Open Questions.
A specific project (finite) — concentrated oversight on one project, where the individual's traits apply heavily there while other concurrent activity falls back to defaults.
A specific region (open-ended) — focusing on operations within one region, useful when a region has unusual demands (difficult terrain, hostile population, fraught regulatory environment).

Reassignment rules differ by focus type:

Open-ended focuses (role, region) can be reassigned freely at any time. The trait benefit moves with the staffer to the new focus; there is no penalty for the change.
Finite focuses (specific project) lock the staffer in. They remain on the project until it completes. Removing them prematurely incurs a penalty that is defined at project outset and fixed for the duration — it does not scale down as the project nears completion. The penalty is shown on the project sheet alongside the projected costs, so the player sees what pulling out would cost before they commit. This is intentional: the design wants the player to grapple with sunk-cost trade-offs as a project drags on, not to be rewarded for waiting longer to walk away. Penalty magnitudes are scenario-tunable, and the consequences are a mix of cost overruns and delays on the abandoned project as a replacement is brought up to speed, goodwill damage with stakeholders who counted on the named individual's involvement, and (depending on contract terms) contractual breach penalties.

Assigning a star engineer to a prestige trunk-line project therefore carries planning weight: they are committed for the project's duration, and pulling them out costs the same whether you do it on day 30 or day 300. A role-focused or region-focused staffer can be redirected as priorities shift.

Traits¶

Each staffer carries one to three traits. Traits are modifiers that adjust the mechanics within the individual's current focus — they make projects faster or slower, cheaper or costlier, smoother or rougher.

Initial trait pairs (the system is extensible; scenarios can define their own):

Positive	Negative	Effect
Efficient Planner	Disorganized Planner	± project time to completion
Logistics Expert	Logistics Bungler	± materials line-item costs
Diplomat	Abrasive	± goodwill movement on project events involving stakeholders
Stickler	Slapdash	± incident rate on focused operations

Stacking. Trait modifiers stack additively across all sources affecting a given mechanic. Two staffers each contributing a 10% reduction to planning time on the same project yield a 20% reduction; mixed-sign traits cancel (a +10% from one and a −10% from another sum to 0%).

Hard cap. Any value modifiable by traits is capped at ±75% of base. Stacked modifiers continue to accumulate on the books, but the applied value never exceeds this bound. This prevents any combination of staff and traits from completely trivializing or breaking a mechanic.

Pairing rule. Every positive trait has a mirrored negative trait in the candidate pool. Procedurally generated characters draw from both sides — the talent market is textured, not uniformly heroic. A character may carry multiple traits, positive and negative mixed, so a "brilliant but abrasive" Chief Engineer is a familiar archetype: their Efficient Planner trait shortens projects while their Abrasive trait costs goodwill on contentious decisions. Hiring a flawless individual is rare; the player typically picks among tradeoffs.

Trait stability. Traits are fixed at character generation in the initial design. The data model and authoring schema are designed to accommodate future trait progression (traits acquired or upgraded on the job, or eroded under poor management) without breaking the system, but progression is not implemented in the initial scope.

Scenarios can define new trait pairs as needed — a Pioneer Era scenario might add Frontier Hardened / Tenderfoot; a labor-strife scenario might add Strike Breaker / Worker's Champion — each with their own effect modifiers and pairing logic.

Reputation¶

Like the parent company and the player character, each named individual carries their own reputation — per-stakeholder goodwill scores tracked on the same modifier system as every other reputation in the game (see Goodwill).

A staffer arrives with a starting reputation that reflects their pre-railroad history: a former senator-turned-counsel arrives with positive standing in National Government; a former union organizer-turned-superintendent arrives with positive standing with Labor; a notorious cost-cutter arrives with negative Labor standing wherever they have worked before.

While employed, the staffer's reputation evolves with their actions on the job — projects they lead, events they handle, decisions made under their focus. Strong, well-handled staff can rehabilitate their image; mishandled or notorious staff damage theirs further. When a staffer leaves the company (dismissed, retired, hired away), they take their reputation with them, and may resurface elsewhere — including, sometimes, working for a competitor.

Scouting and Hiring¶

Named individuals are not handed to the player. Most must be scouted — the player commissions a search and the company's recruiting effort returns a candidate list after some time. Like project planning, scouting is plan-shaped: it takes time, the result is a roll within variance ranges (which candidates surface, what their traits look like), and the player can re-roll by ordering another search at the cost of the time another search takes.

Scouting can target a region or run broadly. Targeted searches surface candidates with regional connections (mining engineers in Pennsylvania, alpine surveyors in the Rockies, etc.) and are subject to information lag for distant regions. General searches surface a broader, less-targeted pool.

The candidate pool is a mix of:

Historical characters — real figures available in the scenario, defined per-scenario by the scenario script. Some are always in the pool when the right region and date are in play; others are unlocked by scripted events ("the Panic of 1893 puts Hill-style operators back on the market," "after Theodore Judah dies, his protegés become available"). Some events even hand a historical character directly to the company without scouting.
Procedurally generated characters — randomized names, biographies, and traits filling the gaps. These are the default for scenarios that don't have well-known historical figures to draw on.

Salary, Poaching, and Departure¶

Hired individuals draw a fixed salary, shown upfront when the player decides whether to hire. There is no salary negotiation — the player either accepts the cost or declines the hire.

Poaching runs both directions. The player can lure away staff from competing companies by offering a value above the staffer's current compensation; the target decides whether the increase is worth a move. There is no negotiation — the player names a number, the target accepts or declines.

When the player's own staff is poached by a rival, the company's reputation mediates whether the player gets to fight back:

A well-liked company gets a chance for a "save" — the rival's offer is surfaced as an event, and the player can match or beat it to retain the staffer.
A reviled company gets no save opportunity. The staffer simply resigns; the player learns of it after the fact.

Departure is bigger than poaching alone — staff also retire, get fired, or leave under scandal. In all cases the staffer takes their reputation, traits, and personal modifiers with them and may resurface elsewhere — including, sometimes, working for a competitor. Replacing a respected staffer can damage goodwill (their connections leave with them); firing a popular one ripples through stakeholder reactions.

Labor Pool¶

The broader workforce — surveyors' assistants, graders, track layers, masons, carpenters, mechanics — is modeled as a labor pool, not as named individuals. The pool is tracked per region — each region has its own count of available workers, separate from every other region's pool. Skilled trades (engineers, masons, ironworkers, etc.) are abstracted into a single pool per region for now; this may split into trade-specific sub-pools later if scenarios warrant the granularity (the Victoria 3 parallel: pops aren't subdivided by trade until the design needs them to be).

The pool's effective size and cost, alongside materials sourcing, shape every construction project's pace and budget. The company sources both in one of two ways: through an owned construction subsidiary, or by contracting externally.

Owned Construction Subsidiary¶

If the company owns (or holds significant equity in) a construction firm, that firm functions as a captive supplier of both labor and construction materials — see Business Dealings — Equity. Effects:

Favorable contracts. Internal procurement happens at favorable rates, lowering the materials and labor line items on construction projects sourced through the subsidiary.
Distance-scaled costs over the region graph. The subsidiary operates from one or more regional offices. Construction project costs rise the further a project sits from the nearest office, measured along the region graph — a project in the same region as an office is at distance 0, an adjacent region is distance 1, two hops away is distance 2, and so on. Coverage is a gradient: same-region projects get the full cost benefit, and the benefit tapers smoothly with each additional region of distance until it becomes negligible.
Debuff softening on over-cap projects. When the company is running over its project soft cap, the subsidiary absorbs some of the operational burden. Over-cap construction projects within the subsidiary's effective coverage area get a flat debuff reduction — the softening is a fixed magnitude when in range, and zero when out of range. The cap itself doesn't move; the slip just costs less for in-range projects.
Independent reputation. The subsidiary tracks its own reputation separate from the parent company's, with the same per-stakeholder modifier system used elsewhere (see Goodwill). The subsidiary's regional reputation has two effects: it gates expansion (a subsidiary reviled in a target area cannot extend there cleanly; founding a sister subsidiary with a clean slate is the better play), and it modulates how much of the regional labor pool the subsidiary can mobilize for any given project contract — a well-liked subsidiary attracts willing workers, a reviled one finds the local pool effectively shrunk.
Expansion via projects. Adding a new office in a new region is itself a project the player can commission (an Industrial-type project; see Project Types). The expand-vs-found decision turns on distance (region-graph hops to the target — too far and the existing operation can't manage it cleanly) and on the existing subsidiary's regional reputation in the target.

Multiple subsidiaries do not compound their effects in the same area. They are useful for coverage — large projects spanning many regions (an inter-regional rail corridor, say) benefit from having offices in each — but doubling up in the same region buys nothing.

External Contracting¶

Without an owned subsidiary in range, the company contracts with existing construction firms in the relevant region — a procurement-style arrangement subject to the same goodwill and leverage rules as other procurement (see Procurement.md). Distance and goodwill both factor in: a hostile region with no nearby firms means high prices, slow delivery, and sometimes no bidders at all.

Mixed strategies are common: an owned subsidiary may not cover every region, so external contracts fill the gaps.

Goodwill Effects on Labor¶

Whether sourced internally or externally, the effective size and cost of the labor pool respond to the company's goodwill — primarily with Labor (population-driven, regional; see Populations.md) and with the relevant supplier when contracting externally:

Respected company — larger pool of willing workers, lower wage premium, better availability of skilled trades, faster project completion, fewer labor incidents.
Reviled company — smaller pool of willing workers, higher wages demanded, fewer skilled tradesmen accepting offers, slower projects, more frequent strikes and walkouts.

Reviled companies can still build, but every project costs more and takes longer than it would for a respected operator working the same scope. The size of the difference scales with how reviled — at extreme negative goodwill some projects become effectively unbuildable in the affected region.

Effects on Project Mechanics¶

Both layers flow into the project mechanics described in the rest of this doc:

Plan quality — the named Chief Engineer and Surveyor-in-Chief shape how tightly projected line items track actuals. Strong staff means accurate projections; weak staff means more variance and surprises.
Execution pace and risk — the Construction Superintendent and the labor pool's size/cost together drive completion time and incident-event frequency.
Goodwill consequences of project outcomes — well-liked staff can absorb minor setbacks without much reputational damage; resented staff multiply the goodwill cost of every problem.

Delegation: Staff Running the Company¶

The named-staff roster is also what makes delegation work. The player can hand any operational layer — fleet allocation, maintenance funding, routine procurement, contract triage — or an entire owned company to its staff, who then make those decisions themselves rather than waiting on the player (the delegation surface is described in UIArchitecture).

Delegated decisions run on the same traits that shape project execution. A delegated company led by an Efficient Planner / Diplomat head commissions and runs work differently than one led by a Slapdash cost-cutter — the staff act according to their competence and what their traits value, exactly as they would under the player's direction, only without the player in the loop. Delegation quality is therefore hiring quality: to delegate a company well, the player must staff it well, starting with a capable head (a hired leader or general manager) and the key roles beneath them.

Delegation is never a black box. What a delegated staffer decided — a contract signed, a project commissioned, a maintenance lever cut — is reported in the inbox and on the company's records, traceable to the responsible staffer, so the player can audit the call and decide whether to step back in or replace them. This is the mechanism behind the portfolio play in Business Dealings: lead one company hands-on, delegate the rest, intervene only when the inbox warrants.

The same engine also drives rival companies: a rival is a company fully delegated to an AI head, so the player and the AI exercise one delegation path, not two (see Rivals as Full Companies). A rival's strategic posture is modeled as the head's traits + scenario mandate weighting that engine's priorities — not a separate AI.

This section is delegation's canonical design home; the shipped engine behavior — how a delegated head's competence and latency shape day-to-day contract decisions — is pinned in Operations: the capacity-aware, highest-margin-first accept a delegate runs, the competence-scaled active-contract churn (the active-vs-delegated gap is latency + competence, both hireable-against), and active-contract term-expiry / re-seat.

Commissioning a Project¶

A project is a high-level order. Examples:

"Establish a new rail connection from this urban region to a neighboring rural region. Bring the rural region's infrastructure online at Halt tier."
"Upgrade the trunk line between A and B to a heavier rail standard."
"Build a new factory in this rural region as a wholly-owned subsidiary." (also touches business dealings)
"Upgrade Detroit's infrastructure from Depot to Terminal to qualify for Ford's mainline freight contract."

The project lifecycle has two distinct phases — planning and execution — separated by an explicit activation step that lets the player decide when each project actually starts.

stateDiagram-v2
    [*] --> Planning: player commissions
    Planning --> Planned: staff produces plan
    Planned --> Active: player activates
    Planned --> Planning: player requests revised plan
    Planned --> Cancelled: player cancels
    Planned --> Expired: shelf life passes
    Expired --> Planning: replan
    Active --> Complete: project succeeds
    Active --> Cancelled: player cancels (penalty)
    Active --> Failed: simulation kills (resources exhausted, etc.)
    Complete --> [*]
    Cancelled --> [*]
    Failed --> [*]

Planning Phase¶

When the player commissions a project, the company's staff produce a plan offscreen. The plan determines:

A set of line items (survey work, grading, bridges, track laying, station construction, equipment, land acquisition, etc.).
A projected cost for each line item.
A projected timeline with milestones.
A projected outcome — the nodes and edges that will exist when the project completes, with their service and capacity profile.
A projected regional maintenance increment — the ongoing maintenance cost the project will add to its region once complete, shown up front so the player sees the ongoing cost before activating (see Operations.md).
A fixed premature-removal penalty for any staff who lock in on this project once it activates (see Focus and Assignment).

The projected values are rolls within underlying variance ranges. A given plan returns specific values (e.g., $105k for grading; 18 weeks for bridges), but each value is one possible outcome from a range. Different plans of the same project will land in different places within the range — the Request a revised plan option is essentially a re-roll, at the cost of the time it takes to redo the plan. Better staff (per the trait system) tighten variance ranges and improve rolls — a Logistics Expert at the Chief Engineer slot produces lower-variance materials estimates; a Disorganized Planner produces wide ones.

The variance ranges and projected values also reflect the project's terrain profile — an edge through mountainous terrain costs far more (and varies more) than the same edge across plains; see MapAndRegions — Regions. Weather and seasonal effects are not simulated in the current design — terrain difficulty alone carries the geographic friction that historically would have included winter shutdowns and storm delays.

The player cannot override the plan or dictate specific line items. Their options on a returned plan are limited to Activate, Hold, Revise (re-roll), or Cancel. The player character is likely worse at the underlying technical planning than the competent executives in the named-staff roles, and the abstraction is intentional — the player's job is to commission, fund, and decide; the staff's job is to plan and execute.

Planning consumes some staff effort but does not count toward the concurrent project soft cap. Multiple plans can be in production at once.

After Planning: Activate, Hold, Revise, or Cancel¶

When the plan is ready, the player sees it as a project sheet and can:

Activate immediately — the project enters execution and begins counting toward the soft cap.
Hold for later activation — useful when waiting for funding, soft-cap room, scenario timing, or staff availability. Held plans do not count toward the cap.
Request a revised plan with different scope or standards.
Cancel the project.

Held plans have a shelf life — a deadline by which the project must be activated. After that, the plan expires and must be replanned (conditions, costs, and circumstances may have shifted in the interim). This prevents the player from hoarding indefinitely-fresh plans.

Shelf life varies by region, scaled by the company's goodwill there: well-regarded operators get longer windows (favorable local authorities issue permits with generous expirations), reviled operators get shorter ones (hostile authorities issue tight expirations, hoping the project never takes root). The shelf-life mechanic primarily abstracts local permits and approvals — they are easier to keep alive when the populace and local government want the project to happen. Specific base values and goodwill scaling are scenario-tunable.

Executing a Project¶

Once approved, the project runs in game time as the player advances the clock — a day at a time, or via Sim-to until a stop point (a project milestone or completion is a natural one). As work progresses:

Line-item line items show projected vs. actual costs as each phase completes. A grading phase budgeted at $X may come in at $X + overrun or $X − savings; the delta is visible immediately.
The project sheet updates continuously: completed line items, in-progress line items, upcoming line items.
Events fire on the project: a bridge collapse, a labor dispute, a surveying error, a windfall on cheap land. Each surfaces in the inbox as a decision or notification, stopping the sim if the player has flagged its category.

The player's tools during execution are limited and deliberate:

Approve or reject mid-project change orders (when staff need more money or want to alter scope).
Push for acceleration, accepting cost or quality risk.
Cancel the project, paying penalties on contracted work and writing off the partial result.
Replace staff on a chronically failing project (touches goodwill).

The player does not micromanage which crew is grading which mile. The abstraction is intentional and load-bearing.

Milestone Check-Ins¶

Every project has a completion time. Longer projects carry milestone check-ins — scheduled progress reports that surface in the inbox at authored points along the timeline (e.g. survey complete, grading complete, track-laying half done). Each check-in:

Reports projected-vs-actual progress so far — is the project on time, on budget, on quality, or drifting?
Presents a genuine go / no-go choice: continue, push (spend to accelerate), or stop and cut losses if it's gone off the rails (a cost blowout, a grading disaster, a souring local relationship). Stopping pays the cancellation penalty but caps the bleed.

Check-ins are how a long, expensive project stays accountable without the player babysitting it day to day — they advance the sim toward the next check-in (a natural Sim-to stop point), read the report, and decide. Higher-rated staff produce tighter projections, so their check-ins carry fewer nasty surprises.

Feasibility Studies¶

Before committing to a major build, the player can commission a feasibility study — itself a project (it takes time, is run by a role, and produces a report), but one that informs a decision rather than building anything. This is the engine of expansion planning: the player picks a target — an unconnected settlement, an open-country site, or a route between two settlements — and delegates the study to a staffer (the Surveyor-in-Chief for routes; General Counsel for permitting-heavy local studies). The study runs over sim-days, subject to information lag for distant targets, and lands its report in the inbox — a natural stop point to sim toward.

A local (station-site) study projects: - Whether the project can win approval at all — some sites are blocked by hostile county leaders or landowners regardless of money. - Land cost at the site (a station in or near a populous settlement costs far more than open country). - Taxes and permitting cost — the ongoing and one-time civic charges. - Projected passenger revenue and contract opportunities the site would open.

A route study (building track to another settlement) projects: - Permission and land acquisition along the corridor (right-of-way through each county the route crosses). - The route length — and here the surveyor's quality and integrity matter: a weak or self-dealing surveyor returns a longer, serpentine route (historically, planners paid a flat fee per mile padded the mileage), inflating cost and maintenance. - The route grade / quality — was the corridor laid over terrain the locomotives handle easily, or forced over high grades that slow every train and burn extra fuel?

Staff quality shapes the study, not just its accuracy. A higher-rated Surveyor doesn't merely report more precisely — they produce a better thing to report: a tighter route, a better-graded corridor, cleaner permitting. The geometry and terms the player ends up paying for are a direct consequence of who they hired to plan it (the surveyed route the line stores). A poor study can also come back "no" — the project simply isn't feasible on acceptable terms — which is itself valuable: the player spent a little time and money to avoid a ruinous build.

The study's projections are estimates within variance ranges (like any plan); the eventual real project may come in better or worse. The player can act on the study by commissioning the actual build (carrying the study's surveyed route and terms forward), shelve it, or study an alternative.

A frontier (open-country) build always routes through a study — there is no direct-build shortcut. The study's surveyed route is the only thing that authorizes the build, so the staffing choice at commission has real downstream weight.

The Verdict and Approval Model¶

Every study returns a verdict the player reads first. Approval is goodwill-gated, not money-gated (Pillar 2): the verdict, its approval odds, and the permitting cost are driven by the company's standing with the target county's stakeholders (see Geographic Goodwill (County Scope)), not by how much the player is willing to spend.

Where approval legally sits. The build/extend certificate historically sat with the higher (state/federal) authority, with county and local boards holding consent-, land-, and tax-leverage but not issuing the construction permit. This model takes the period-honest influence path: county goodwill gates land cost and permitting cost through the local-consent layer, and the weight of community support/opposition the higher authority hears — which rises to a binding "no" when opposition is organized enough. The verdict is presented county-first for legibility; that is a deliberate, labeled abstraction (the binding certificate is a higher-authority node the county standing rolls up to). The full justification and the driving pillar are in Goodwill — Gating the Feasibility Path.

Verdict input. The verdict is driven in two stages. First, a blended county standing from the target county's four company-track stakeholder scores:

G_county = 0.40·CountyBoard + 0.25·LocalBusiness + 0.20·FarmersLandowners + 0.15·CountyPublic

Second, the standing the verdict actually consumes folds the player character's personal standing into G_county as a bounded convex blend (not an additive term):

G_verdict = (1 − w_player)·G_county + w_player·PlayerStanding     (default w_player = 0.20)

PlayerStanding reads through the M14_C C-6 seam — a constant 50 until the player-character entity lands. Both formulas' weights are scenario-tunable defaults; the full specification, the bound proof, and the seam are in Goodwill — Player Personal Standing as a Weighted Input and Gating the Feasibility Path. G_verdict — not bare G_county — is the standing the verdict, approval odds, and permitting cost read. The report shows:

Verdict — Feasible or Not feasible. If G_verdict < HostileThreshold (default 25) the county defeats the build regardless of money; the study returns a "no." This is the cheap, valuable "no" — a little time and money spent to avoid a ruinous build.
Approval odds — a monotonic, non-decreasing banded read of G_verdict: odds = clamp01((G_verdict − 25) / (60 − 25)), presented as bands Contested (25–40), Likely (40–60), Clear (≥60). A marginal study reads as uncertain rather than a clean yes (the build can still hit local objections during execution).
Permitting / civic cost — a one-time and ongoing charge that scales inversely with G_verdict (hostile authorities charge more): PermitCost = BasePermit × PermitMultiplier(G_verdict), where PermitMultiplier is monotonic non-increasing in G_verdict, pivots to ≈1.0 at the Neutral midpoint (50), rises above 1 toward hostility and falls below 1 toward favor, clamped to a [0.5, 2.5] band (defaults). Same mechanic as the shelf-life scaling in After Planning.
Land cost — the existing population base, now multiplied by a goodwill factor keyed specifically to the Farmers & Landowners standing (they set the right-of-way price): LandCost = (BaseLandCost + population × LandCostPerCapita) × LandMultiplier(Farmers), where LandMultiplier is monotonic non-increasing in the Farmers & Landowners standing and equals 1.0 at Neutral (50) — so at neutral standing land cost equals today's SiteLandCost, backward-compatible. Land cost keys off the raw Farmers & Landowners standing, not G_verdict — the right-of-way price is a property-owner negotiation, so the player-standing term does not enter it. Open country is cheap; a station in or near a populous town with hostile landowners is dearest.
Projected revenue — a passenger-revenue estimate from the target's population, plus the freight-contract opportunities the connection would open.
Surveyed route (route studies) — length and grade, an output of the surveyor's competence (above).

Acceptance criteria (Phase F asserts). With the county-goodwill model loaded:

A target county with G_verdict < 25 (hostile) returns Not feasible; a target county with G_verdict ≥ 25 returns Feasible. Concrete seed targets (Goodwill — Authored test counties): lenawee (G_county 14.1 → G_verdict 21.3) → Not feasible; huron (G_county 71.35 → G_verdict 67.1) → Feasible; an unlisted neutral county (G_verdict 50) → Feasible.
Approval odds are non-decreasing in G_verdict and band as above (huron → 1.0 / Clear; neutral → 0.714 / Likely).
Permitting cost is non-increasing in G_verdict (hostile county costs more than neutral; friendly costs less).
Land cost at neutral Farmers & Landowners standing equals the current population-only SiteLandCost; hostile landowners raise it, friendly lower it. Land cost reads the raw Farmers standing, not G_verdict.
The verdict is keyed off the target county's standings via G_county, blended with the player term into G_verdict; changing either the county standings or the player standing changes the verdict/odds/permitting accordingly.
Player-standing seam: G_verdict reads PlayerStanding through a single input slot (constant 50 until M14_C C-6); swapping the proxy for the real entity changes only that slot, not the formula, w_player, or the bounds.

Closing the MVP stub. The live engine ships the B-2/B-3 stub FeasibilityReport(bool Approved, decimal LandCost, SurveyedRoute? Route) with Approved hard-coded true and land cost as population-only. Phase F makes Approved the real G_verdict-driven verdict, adds approval-odds and permitting fields, and applies the Farmers & Landowners multiplier to land cost. All thresholds, weights, and multiplier coefficients are scenario-tunable and authored to JSON (never hardcoded) — the goodwill seeds and w_player in goodwill.json, the verdict thresholds in economy.json's feasibilityStudy block.

Studies Are Return-Only¶

Feasibility studies do not carry milestone check-ins. They are short relative to construction, and there is no meaningful mid-flight go/no-go: the route isn't known until the surveyor returns, so there is nothing to report on partway through (Pillar 4 — the information doesn't exist yet). The single return report is the only stop point the study produces. The player's "I've changed my mind" path is to cancel (below), not an interim check-in.

Cost, Duration, and What They Scale With¶

A study is a small, cheap "buy information" bet — cheap enough that the "no" is genuinely cheap. Cost and duration scale with route length (region-graph hops from the network to the target) and are shaped by surveyor competence (a strong Surveyor-in-Chief returns faster and with tighter variance, via the existing trait modifiers, ±75% capped). Site population drives the land cost, not the study cost.

Starting playtest defaults (scenario-tunable, authored in scenario JSON — not hardcoded):

Tunable	Starting value
Study base cost	$2,000
Study cost per hop of distance	$600
Study base duration	21 days
Study duration per hop	7 days
Surveyor competence effect	reuse the existing trait pipeline (Efficient Planner ± duration & variance)

On the live 13-region graph (targets 1–2 hops out) this lands a study at roughly $2,600–3,200 and 28–35 days — small against a frontier build, and a clean Sim-to "study returns" stop point.

Cancelling an In-Flight Study¶

A study can be cancelled while in flight (Pillar 6 — the player is never trapped). The study cost is paid upfront at commission and is sunk on cancel — no refund, no additional penalty — and the assigned surveyor is freed immediately. This mirrors the doc's sunk-cost philosophy (see Focus and Assignment): a cheap bet, forfeit if abandoned. No report is produced. (The richer premature-removal penalty applies only to staff locked onto construction projects, not to studies.)

The Project Sheet¶

The project sheet is the central UI artifact for the construction system. It always shows:

Project name, scope description, commissioning date.
Status (planning, planned (held, in shelf life), active, complete, cancelled, failed, expired).
Line-item table with: description, projected cost, actual cost to date, variance, status.
Total projected cost, total actual cost, total variance.
Projected completion date and actual progress against it.
Funding source (cash, specific bond issue, partner equity contribution).
Outcome preview — the nodes/edges that will be added or modified.
Linked events (decisions taken during the project, incidents that fired).

The line-item table is intentionally detailed rather than summarized. Manifest Rail is a heavy-management game for an audience that wants to see the work — line items reflect the actual planned and completed work at whatever granularity the staff produces them, with no UI-driven cap on count. Major projects may show dozens of line items; small projects may show a handful. The visual budget is text-and-tables, not iconography, and the design wants the player engaged with the numbers.

The sheet is the player's main accountability surface. It is also the trail of evidence for goodwill effects: a sheet full of overruns and incidents is what damages company goodwill when the project closes.

Project Outputs: Operations on the Region Graph¶

Every project, when completed, performs one or more operations on the settlement graph described in MapAndRegions.md:

Build infrastructure — bring a region onto the rail network for the first time at Halt tier.
Upgrade infrastructure — raise a region's station tier (Halt → Depot → Terminal). Unlocks contracts gated by station capacity. See Station Capacity Tiers.
Add rail line — a new line between two settlements at the chosen line tier (Branch / Standard / Trunk), along the surveyed route. Cost scales with the chosen tier and the route's length and grade through the county terrain it crosses.
Upgrade rail line — raise a line's tier (Branch → Standard → Trunk). Heavier rail, more sidings or double-tracking, modern signalling, grade-handling improvements. Unlocks contracts gated by line capacity. See Line Capacity Tiers.
Decommission — abandon infrastructure or a rail line (especially relevant in decline-style scenarios; see goodwill consequences).

A single project can stack several of these operations into one commissioned scope. The classic "establish a connection to this rural region" project bundles Build infrastructure (in the rural region) + Add rail line (between the urban hub and the new region's capital) + possibly Upgrade infrastructure on the urban end if the contract that motivated the project demands a higher capacity tier than is currently in place.

Funding a Project¶

Projects are funded out of one or more of:

Cash on hand from the company treasury.
Bond issuance — see Business Dealings. Issued to finance specific projects, usually sized to the projected cost plus a margin.
Partner equity — when the company holds an equity stake in a related business, the partner may co-finance projects that benefit them (e.g., a refinery the company part-owns may co-fund a feeder line to its plant).
Government grants or subsidies — only available under high company goodwill and/or scenario-specific conditions.

Funding is committed at project approval. If actuals exceed projection, the player must cover the gap from elsewhere; running out of funds mid-project is one of the failure paths.

Project Types (Initial Set)¶

Not exhaustive — scenarios may add more. Categories to support at minimum:

Connection — add a new rail line between two settlements at the chosen line tier (Branch / Standard / Trunk), and build a station on either settlement (connecting an existing town, or creating a new settlement at an open-country site) if it isn't already on the network.
Station Infrastructure — build or upgrade a region's station tier (Halt → Depot → Terminal). Drives contract eligibility on the station-capacity dimension.
Track Upgrade — raise an existing rail line's tier (Branch → Standard → Trunk). Drives contract eligibility on the line-capacity dimension.
Industrial — commission a new business owned by the company, or expand an existing subsidiary by founding a new regional office (e.g., extending the construction subsidiary into a new region). Intersects with business-dealings equity.
Urban Transit Network — build or upgrade an intra-regional urban transit facility within an urban region (era-appropriate: horsecars, electric streetcars/trams, elevated rail, subway/metro, modern light rail). Capital cost scales with regional population and quality tier (basic / mid / premium); generates ongoing revenue based on regional population × ridership rate × quality multiplier; adds to regional maintenance footprint. Feeds regional population dynamics — well-served urban regions attract migrants. Distinct from suburb-to-city commuter rail (which is a main-line passenger service). See MapAndRegions — Passenger Service.
Acquisition Integration — physically integrate a recently-acquired competitor's track or facility into the company network.
Decommission — formally abandon a node or edge, with cleanup costs and goodwill consequences.

Concurrent Project Capacity¶

The number of projects a company can run at once is hard-limited only by the player's available resources — cash, staff, materials, labor pool. There is no artificial hard cap.

There is, however, a soft cap representing how many projects can realistically get adequate executive attention. Borrowing the Crusader Kings 3 domain-limit pattern: exceeding the soft cap is allowed, but it costs.

Soft Cap Mechanics¶

The company has a base soft cap of 3 active projects — what a default executive team can credibly oversee. The number is a working playtest default, scenario-tunable.
Only active projects count toward the cap. Projects in the planning phase, or held in the planned state awaiting activation (see Commissioning a Project), sit outside the cap entirely. The player can queue multiple plans for later activation without paying any cap cost up front.
When the player activates projects beyond the soft cap, the over-cap projects carry debuffs for as long as they remain over-cap. Debuffs include extended completion times, increased cost variance, higher incident rates, and reduced effectiveness of trait modifiers from focused staff.
Debuffs are graduated and accelerating — each project past the cap carries a heavier penalty than the one before it. The first over the cap is a mild slip; the second over takes a larger step worse; the third over, a larger step still. The curve is intentionally punitive at the high end: a player running far over their cap should feel paralysis, not a manageable tax. Specific magnitudes are scenario-tunable.
Debuffs are continuous: if a project completes and the company falls back to or below the cap, debuffs lift on the remaining projects. The system continuously evaluates current state and applies or removes debuffs accordingly.

Cap-Modifying Traits¶

The soft cap itself can be raised or lowered by named-staff traits focused on broad oversight. Initial pair:

Positive	Negative	Effect
Master Delegator	Micromanager	± soft cap (integer)

Strong delegators raise the cap; control freaks who can't trust subordinates lower it. These integer modifiers stack additively across relevant staff. Unlike percentage-based trait modifiers (bounded by ±75% of base), cap modifiers are integers with no percentage cap — though scenarios may set a hard floor (typically 1, so the company can always run at least one project).

What the Player Should Feel¶

The intent matches the texture of CK3 domain management: you can always take on more, but past the comfortable limit every project starts to slip. Hiring better executives, owning a construction subsidiary (which offloads some labor-allocation overhead), or focusing on fewer-but-larger projects are all defensible strategies. The wrong choice is overcommitting without the staff to back it up.

Ongoing Operations¶

Day-to-day work to keep the existing network running — track upkeep, equipment maintenance, payments to local governments, ongoing service contracts — is handled by a separate operations system, kept distinct from project management because it is continuous rather than episodic. Each completed project adds a maintenance increment to its region's ongoing operations cost, shown up front on the project sheet at planning so the player sees the long-tail cost before activating.

→ Full detail: Operations.md

Open Questions¶

All major construction design questions are currently resolved. Specific tunable values (variance magnitudes, debuff curves, scaling coefficients, premature-removal penalties) are scenario-tunable and will need playtesting.