Information and Communication¶

Deep dive on the cross-cutting system that constrains what the player knows, when they know it, and how stale that knowledge is. This system layers underneath the others: it determines how fresh the prices, sentiment, events, and goodwill standings the player sees actually are.

→ Parent: GDD.md

Design Intent¶

Real railroad operators in 1840 did not get same-day commodity prices from a city 800 miles away. They got week-old newspapers. Real operators in 1890 read same-morning prices off a telegraph wire. Real operators in 1920 picked up a telephone. The texture of running a network — where to ship, which contract to sign, how to react to a strike — was fundamentally shaped by what information was reachable and how stale it was.

Manifest Rail makes that texture playable. Information about distant places lags by an amount determined by (a) the era's dominant communication technology and (b) the distance from the player character's location. Once information is in the player's hands it is fully transparent — every line item visible — but its as-of date matters.

The Player's Reference Point¶

Information lag is computed from the player character's current residence — typically the company headquarters, but scenarios can set a different residence. A player whose HQ is in St. Louis but who relocates to New York for a stretch will see information lag relative to New York during that stretch.

Local information — anything within or near the player's current location — is fresh, refreshed at the natural simulation tick.
Distant information lags by an amount determined by the era and distance.

Distance and Lag Computation¶

Distance Is Graph Distance¶

Distance for lag purposes is computed along the settlement graph, not as straight-line geography. Each rail edge — and the base geographic gap between places not yet connected — carries a baseline distance (reflecting the geographic gap, as a number of days at the era's default postal pace).

Rail infrastructure shortens effective distance. A region-graph edge that carries the player's track is closer for information purposes than one that does not, because mail (and later telegraph traffic) rides the rails. The more efficient the rail — better track, faster locomotives, more frequent service — the shorter the effective distance.

This creates a real feedback loop: building track to a distant region doesn't just enable freight and contracts, it shortens information lag from that region to the player's location. The Pioneer-era insight — mail rides the train — is preserved as a mechanical incentive, not just flavor.

Lag Is Per Region¶

Lag operates at the region level: every region has its own as-of-date relative to the player's current location, and all information from that region (prices, sentiment, events, etc.) shares that single lag value. There is no per-stakeholder lag; the model is coarser and more performant.

Entity Information Uses the Nearest Location¶

When the player needs information about a specific entity (a supplier, a rival company, a government body, a named individual), the simulation reads from the entity's nearest office or location to the player:

Small entities — a single rural farm, a small mill, a local merchant — have one location. Information about them lags by that region's lag.
Medium entities — a manufacturer with offices in a few urban regions, a railroad with stations across its network — have several locations. Information lags by the nearest one.
Large entities — a federal government with offices in many regions, a major industrial baron with holdings spread across the country — have presence in many regions; the player's view of them lags by the nearest accessible office.

A practical effect: entities with broader presence are easier for the player to keep tabs on — when the same entity has a nearby office, the player doesn't wait for news from a far-away region. Conversely, a single-location entity in a distant region is harder to track until rail connects to it or the player relocates.

The Three Communication Eras¶

Each scenario starts in a specific era. Some scenarios span an era transition; new technology becomes available over time and can be adopted by the player or by competitors.

Postal Era (pre-~1840s)¶

The dominant medium is the printed newspaper or written letter, carried by mail.

Lag: days to weeks, scaled by distance.
New York → Boston: a few days.
New York → Chicago: one to two weeks.
New York → San Francisco (where applicable): a month or more.
Information arrives in detailed form (full newspaper articles, full letters), but it is unavoidably old.

Telegraph Era (~1840s onward)¶

The telegraph collapses cross-continental lag from weeks to hours.

Lag: minutes to hours, largely independent of distance once the wire is connected.
Information arrives in summary form — headlines, prices, short bulletins. Detailed reporting still arrives via mail behind the wire, but the simulation does not model per-message volume or terse-vs-detailed trade-offs. The lag benefit of telegraph access is what matters mechanically; the cost of composing an individual message is not part of the model.
The wire is not everywhere. Towns without a telegraph office still rely on post until the wire reaches them.
Newspapers continue to exist alongside the wire and pick up wire stories, re-printing them within a day.

Telephone Era (~1880s onward)¶

The telephone enables real-time voice conversation between specific locations.

Lag: negligible for any conversation the player or staff initiates with a counterparty reachable by phone.
Information fidelity is high: tone, nuance, and follow-up questions all become possible.
Public news cycles still have their own pace, but the player's operational picture (their own network, their own contracts) becomes effectively real-time.

Era Progression Within a Scenario¶

When a scenario spans an era transition — the telegraph arriving in the 1840s, the telephone in the 1880s, etc. — adoption happens through two mechanisms running in parallel:

Automatic World Adoption¶

The wider world adopts new communication technology as the era progresses, regardless of the player's actions. Major urban centers gain telegraph offices first, then secondary towns, then rural areas; later, telephone exchanges spread similarly. This represents the historical reality that the player is operating in a changing world, not driving the change single-handedly.

Mechanically: regions of the map gain authored or scenario-scripted access to new tech at progress points along the era timeline. A region "has telegraph access" once the world's general adoption reaches it.

Once a new tech is available in a region, the player can leverage it through one of two paths — or a mix:

Subscribe to an existing service. Western Union (telegraph) and the era's equivalent telephone services exist as third-party companies. The player pays an ongoing fee for access; the service's coverage depends on the third-party network's reach. Lower up-front cost, ongoing operating cost, dependent on someone else's infrastructure.
Build the infrastructure themselves. A Construction project (per ProjectManagement.md) — telegraph lines along the company's track, telephone exchanges at major stations. Higher capital cost, but the company owns the infrastructure and can potentially sell access to it as a service to other operators (a revenue stream alongside the lag benefit).

Either path gives the player access to better information lag in the regions covered. Most companies will mix: subscribing in early adoption (when build costs aren't justified by limited use) and building later as the network matures and self-ownership pays back.

AI Competitor Approach¶

AI competitor companies make the same choices the player does — subscribe, build, or mix — based on their authored profile. A scrappy upstart in a Pioneer-Era scenario might subscribe to Western Union; a major established rival in a Golden-Age scenario might build their own private wire network. Scenarios can script specific competitor behavior (e.g., "this rival aggressively builds telephone exchanges in its territory by 1890") or let the AI choose autonomously based on its general behavior model.

What Information Is Affected¶

Lag applies broadly:

Commodity prices in distant regions (business dealings). The price the player sees for cotton in New Orleans may be two weeks stale — and the actual market may have moved.
Public sentiment and goodwill in distant regions and with distant stakeholders. A strike that started yesterday in Chicago may not surface in New York for a week.
Map events. Scripted and emergent events in distant regions are reported with delay. By the time a player learns of a fire at a refinery they own three regions away, the cleanup may already be underway.
Contract opportunities. A request for proposal posted in a distant region may already be closed by the time word reaches the player.
Network status. The state of the player's own trains, stations, and projects in distant regions. This is one of the strongest motivators for adopting telegraph along the line — operations themselves get faster and safer when status is real-time.

What is not lagged:

The player's own treasury, headquarters status, immediate-vicinity information.
Bookkeeping internal to the company at the player's location.

Disinformation and Rumors¶

The simulation models information lag — what was true at time T may not be current. Beyond that, the design supports deliberately false or uncertain information through scenario-scripted rumor events, not through a generalized always-on system.

How Rumor Events Work¶

Scenarios that want rumor-rich gameplay (corporate-warfare scenarios like the Erie War, financial-panic scenarios, stock-manipulation hooks) script specific events that surface uncertain or false information using the standard event system:

A scenario fires the event when its trigger conditions are met — "Sources claim Western & Atlantic is on the brink of bankruptcy."
The event presents typical options, each with concrete labeled consequences:
Believe and act on the rumor — short the rival's stock, refuse interchange, push out a competing rumor. The labeled consequences are concrete costs and effects; if the rumor turns out to be false, the player is committed to those actions regardless.
Investigate — pay a cost in cash and time to learn more. A follow-up event fires later with verified information and a new option set.
Wait for confirmation — do nothing now; the truth surfaces as a later event. Risk: by the time confirmation arrives, the moment to act may have passed.
Spread the rumor further — corporate-warfare amplification. Carries goodwill cost and possible blowback if the player is identified as the source.
The rumor's underlying truth is set by the scenario script. The player never sees that truth directly — only the consequences of their chosen option as they unfold.

Why Event-Driven, Not Generalized¶

A generalized always-on rumor mechanic was considered and rejected. Reasons:

The event system is already purpose-built for surfacing decisions with labeled consequences. Rumors fit cleanly as a flavor of event.
Authoring overhead is concentrated where it matters. Erie War-style scenarios get rich rumor content; routine industrial scenarios don't pay the always-on cost.
A simulated reliability/provenance system across all information would be expensive to balance and verify, and risks producing arbitrary-feeling outcomes that don't tell the historical stories scenarios are written for.

Unreliable Sources¶

A scenario can flag a region or stakeholder as a source of unreliable information using a region tag (e.g., a YellowPress tag) or a scenario-defined stakeholder property. The flag affects how often rumor events fire there and how wide their possible truth-versus-falsehood swing is. Scenario-tunable, not a global mechanic.

Wartime and Disaster Disruptions¶

Beyond normal era-driven lag, scenarios can introduce lag disruptions for wartime, natural disasters, sabotage, pandemics, and other extraordinary conditions. Like rumor events, this is event-driven and scenario-scripted — but the simulation provides a standard lag-disruption modifier primitive that scenarios apply via events, so each scenario doesn't have to reinvent the bookkeeping.

The Lag-Disruption Modifier¶

A scenario-fired event can apply a lag-disruption modifier tag to one or more regions with these parameters:

Magnitude — a multiplier on the region's effective lag (war = 2–3×; major hurricane = 1.5–2×; sabotage outage on a wire = 5× for a few days; pandemic on long-haul travel = 1.5×).
Duration — how long the disruption persists in in-game time.
Scope — which regions are affected (a hurricane hits coastal regions only; a war hits border regions and travel routes between them; a sabotage event hits a specific corridor).
Recovery shape — sudden (war ends with peace treaty, lag snaps back), linear (hurricane infrastructure rebuilds over weeks), or quadratic (per the design's default curve preference for time-based effects).

The modifier tags stack like any other modifier in the design — multiple disruptions on the same region apply together, expiring or fading independently.

Use Cases¶

Wartime. "Civil War begins; lag multiplier 2.5× applies to all Confederate–Union border regions for the duration of hostilities; recovery sudden on peace."
Natural disaster. "Galveston hurricane hits; lag multiplier 2× on the Galveston region for 4 weeks; linear recovery."
Sabotage. "Telegraph wire cut between Pittsburgh and Cleveland by saboteurs; lag multiplier 5× for 3 days; sudden recovery once the wire is repaired."
Pandemic. "Yellow fever outbreak in New Orleans; lag multiplier 1.8× on the affected region while the outbreak persists; gradual recovery as it subsides."

Connection to Other Mechanics¶

Lag disruptions compose naturally with the rest of the design:

A wartime lag spike makes scripted events fire later from affected regions, potentially pushing past their deadlines into the "no good options" zone described under Time Pressure.
Sabotage events can be paired with goodwill effects (the player or a rival is implicated) and Construction projects (the player must repair their own infrastructure if they own the affected wire).
Disasters reduce population in affected regions per Economy.md, creating cascading effects beyond just lag.

UI Representation¶

Every information panel that displays remote data carries an explicit "as of [date]" stamp. Old data does not pretend to be current.
Out-of-date data may be visually distinguished in a way consistent with the hand-drawn map aesthetic — slightly faded, parchment-yellowed, or marked with a period-appropriate "received [date]" stamp.
Once the player opens a screen, what is shown is fully transparent — every line item, every modifier, every contract clause. The lag is in when the data becomes available, not in what is hidden once it arrives.
The player can compare the as-of date with the in-game date to gauge how stale the data is at the moment of decision.

Player Levers¶

The player is not passive against lag — there are ways to reduce it:

Hire correspondents and agents in distant cities. A small recurring cost in exchange for faster, more frequent reports from that city.
Subscribe to wire services (telegraph era). Paid feeds of headlines and prices from key cities.
Build telegraph infrastructure alongside track (a construction project type). Physical wire installed along owned rail dramatically reduces lag for stations on the line and improves operational coordination.
Build telephone exchanges at major facilities (later eras). Eliminates lag entirely for facility-to-facility communication.

These are real-world tools that operators of the period used; here they appear as gameplay levers with capital costs, ongoing operating costs, and goodwill implications.

Connections to Other Systems¶

Goodwill. Standings with distant stakeholders are filtered by lag. Acting on a stale read of public sentiment can produce nasty surprises. The flip side: the player's own decisions are reported outward at the same pace — a scandal in New York reaches San Francisco only as fast as the era allows, which can be exploited or defended against.
Construction. Communication infrastructure (telegraph, telephone) is itself a project type. Adopting newer communication tech is a strategic capital decision with payoffs in operational tempo, contract responsiveness, and information freshness.
Business Dealings. Stale commodity prices mean speculative shipping contracts carry information risk: by the time the cargo arrives, the favorable price may have moved. Sweetheart contracts in distant cities are harder to negotiate without on-the-ground agents. Government mail contracts in the postal era are particularly valuable precisely because there is no faster channel for news yet.

Open Questions¶

All major Information and Communication design questions are currently resolved. Specific tunable values — region-edge baseline distances per era, rail-shortening multipliers, lag-disruption magnitudes for typical disaster types — are scenario-tunable and will need playtesting.