settled-reach/docs/workshops/world-generation/tyre-sw1r2.md

Tyre — SW1-R2: Feasibility Synthesis — Authored Content + Background Simulation

Sub-workshop 1, Round 2 — Cross-read synthesis with interview answers

---

1. The Authored Content Shift — What Changes in the Engineering Pipeline

The interview answers fundamentally reframe the generator. My R1b assessment assumed a procedural generation pipeline — seed in, world out. The product owner's model is an authored content pipeline with simulation-driven drift:

Layer	R1b Assumption	Interview Reality	Engineering Impact
Galaxy (300 systems)	Read-only dataset — correct	Fixed galaxy, same routes every run	No change. Assessment was already right.
Location profiles	Hybrid: generated baseline + authored overrides	Fully authored. Extend the wiki. Generator reads authored data, doesn't generate profiles.	Major simplification. Kill the generation grammar. Build a wiki → data pipeline instead.
Topography	Abstract tags or noise heightmaps	Authored world maps for all planets and moons. Hard constraint on generation.	Removes algorithmic terrain generation entirely. Adds an authored-map ingestion pipeline.
Replayability source	Seed-based variation	NOT seed-based. Background simulation drift over time. Same canonical starting state every run.	Fundamental architecture shift. The generator is a painter reading current state, not a builder from a seed.
Cultural framework	7 heritage roots with corridor weights	Heritage roots deprecated as generator inputs. Real-world cultural migration corridors from the wiki. D-104/D-105 are stale.	Simplification. Cultural data is authored per-system in the wiki, not derived from abstract roots. Miri's cascade framework (Q1-Q5) needs reframing — the authored data IS the cascade input.

What's Still Generated vs. What's Read from Authored Data

Read from authored data (engineering = data pipeline):

• Galaxy topology and system attributes (systems.db — already built)
• Per-planet/station/moon profiles (wiki — to be authored)
• World maps / topographic constraints (to be authored)
• Cultural identity per system (wiki — largely authored)
• GTTR entries with stats and art (to be authored)

Generated from authored data + simulation state (engineering = algorithms):

• Settlement layout on authored terrain (where do districts go, given the terrain map and the current economic state?)
• District skeletons (Phase 1 — block zoning, social sites, guarantees)
• Tile-level fill (Phase 2 — rooms, corridors, objects)
• NPC populations and their current states
• Economic/social conditions within generated spaces (derived from background sim pressure)

Generated on-demand from simulation events (engineering = hooks):

• NPC home neighborhoods (triggered by deep interaction)
• Damaged/changed locations (triggered by news events)
• LOD upgrades for player-invested entities (triggered by player economic engagement)

The Pipeline Simplification

cracks knuckles — This is actually elegant. The product owner has removed the two hardest algorithmic problems from the pipeline:

1. Location profile generation grammar — was going to be a constraint satisfaction problem (mapping 30+ system attributes to coherent planet profiles). Now it's a data ingestion pipeline. Authoring is hard, engineering is cheap.

2. Terrain generation — was either trivial (abstract tags) or expensive (hydraulic erosion, heightmaps). Now it's a fixed data pipeline: authored map → constraint extraction → "this area is coast, this area is mountain." The constraint data feeds district placement.

What remains as the algorithmic core:

• Phase 1 skeleton generation (constraint satisfaction with guarantees) — still hard
• Phase 2 tile fill (BSP + templates) — still medium
• District boundary stitching — still hard
• Background simulation pressure modeling — new and substantial

---

2. Background Simulation on Spare CPU Cores

The product owner wants full economic + social + political background simulation running on spare CPU cores at capped load. Let me be honest about what this means technically.

Architecture Options

Option A: bevy_ecs same-World, gated SystemSets

Background sim systems live in the same bevy World as the active sim but run on a separate schedule with a run_if(idle_budget_available) condition.

[Active tick schedule - 10 tps]
  ├─ perception, movement, dialogue, monologue (ActiveSim entities)
  └─ if cpu_idle_budget > 0:
       ├─ background_economic_pressure (all systems)
       ├─ background_social_drift (BackgroundSim entities)
       └─ background_political_shift (system-level)

• Pro: Single World, ECS queries work naturally, component access is straightforward.
• Con: Background systems share the tick budget. If the active sim takes 8ms of a 100ms tick, background gets 92ms. But if active sim spikes (combat, crowd scene), background gets squeezed to zero. Also: all background work must complete within the remaining tick budget or be interruptible.
• Determinism risk: LOW if background systems run in fixed order after active systems. The variable is how much runs per tick, not what order.

Option B: Separate bevy App (parallel world)

A second bevy App runs on a dedicated thread pool with its own World. It holds system-level economic/political state and BackgroundSim NPC state machines. Communication with the main App via channels (crossbeam or tokio mpsc).

[Main thread - Active tick schedule]          [Background thread pool - uncoupled]
  ├─ active sim systems                         ├─ economic pressure per system
  ├─ read channel: background results →         ├─ social drift per BackgroundSim NPC
  └─ write channel: → tier promotion requests   └─ political faction shifts

• Pro: True CPU isolation. Background sim can't impact active sim frame time. Natural CPU capping via thread pool size.
• Con: Data synchronization complexity. Two Worlds means entity state must be serialized across the channel boundary. Tier promotion (Background → Active) requires transferring entity state from one World to the other. This is architecturally messy.
• Determinism risk: HIGH. Two independent schedulers running at different rates produce ordering-dependent results. Must gate background sim on a deterministic clock (game-minutes), not wall-clock time.

Option C: tokio async tasks outside bevy

Background simulation runs as a set of tokio tasks, not bevy systems. They operate on a separate data model (not ECS components) and write results back to the ECS World via a command queue consumed once per tick.

[bevy tick]                                    [tokio thread pool]
  ├─ active sim                                  ├─ economic_sim_task(system_id)
  ├─ consume background_results queue →          ├─ social_sim_task(region_id)
  └─ publish state_snapshots →                   └─ political_sim_task(faction_id)

• Pro: Clean separation. Background sim doesn't touch ECS at all — it reads snapshots and writes deltas. CPU capping is trivial (tokio runtime with configured thread count). Already have tokio in the dependency tree (voice pipeline uses it).
• Con: The background sim needs its own data model, separate from ECS components. Duplication of entity state representation. More code to maintain.
• Determinism risk: MEDIUM. tokio task scheduling is non-deterministic, but if each task is internally deterministic and results are applied in a fixed order per game-minute, overall determinism is preserved.

My Assessment

Option C (tokio tasks) is the right architecture. Here's why:

1. CPU capping is trivial. Configure a tokio runtime with N worker threads. Set N based on available cores minus main-sim needs. This is exactly "spare CPU cores."

2. The background sim doesn't need ECS. Economic pressure, faction power shifts, and social drift operate on aggregate data (system-level economics, faction influence scores, population-level social indicators). These aren't per-entity ECS queries — they're mathematical models over structured data. An ECS is the wrong tool for "calculate GDP drift for 300 star systems."

3. D-010 determinism is solvable. Background tasks run on a game-minute clock. Every game-minute, the main sim snapshots relevant state, pushes it to the background task queue, and background tasks process it deterministically. Results are collected and applied in a fixed order at the next game-minute boundary. The variable scheduling only affects when results are ready, not what they contain.

4. Already have the precedent. The voice pipeline (server/src/voice/) already uses tokio with hardware detection, worker queues, and caching. Same pattern, different domain.

D-026 Interaction

The existing tier system (tier.rs) handles per-entity proximity-based promotion/demotion beautifully. Background simulation is a different axis — it's not about individual NPC simulation tiers, it's about system-level pressure modeling that affects all entities in a system regardless of their individual tier.

Think of it as two simulation layers:

Layer	Scope	Runs Where	Updates
Entity simulation (D-026 tiers)	Per-NPC: movement, dialogue, perception	bevy_ecs main tick	Every tick (Active) or every game-minute (Background)
Pressure simulation (new)	Per-system/per-settlement: economic health, faction balance, social tension	tokio background tasks	Every game-minute or game-hour

The pressure layer produces context that entity-layer systems read. Example flow:

1. Background pressure sim calculates: "Van Maanen's Station commercial district economic health dropped from Stable to Faltering this game-hour."
2. Main sim reads the updated pressure on next tick.
3. Active-tier NPCs in that district adjust behavior (merchants reduce stock, workers show stress, security increases patrols).
4. Background-tier NPCs in that district get a state-machine transition queued (some leave, some change routines).
5. When the player visits, the district looks different because the pressure changed the NPC population's state.

Cost Estimate

Component	Effort	Notes
Pressure simulation data model	1-2 weeks	Per-system economic state, per-settlement social indicators, per-faction political influence. Separate from ECS.
tokio task infrastructure	1 week	Runtime setup, snapshot/result channels, game-minute clock integration. Pattern exists in voice pipeline.
Economic pressure model	2-3 weeks	Supply/demand between systems, trade route effects, industry health, prosperity cascades. The intellectual design work dominates.
Social pressure model	2-3 weeks	Population satisfaction, cultural tension, crime pressure, public services quality.
Political pressure model	1-2 weeks	Faction influence shifts, governance stability, external pressure (Commission, Institute).
Pressure → entity behavior bridge	1-2 weeks	How pressure state modifies NPC routines, dialogue topics, building conditions.
CPU budget management	1 week	Core detection, thread pool sizing, load capping, idle detection.
Total	9-14 weeks	This needs its own dedicated workshop (as the product owner flagged).

Tier classification: HARD. Not because any single piece is beyond reach, but because the design of what economic/social/political pressures to model, and how they cascade to visible changes, is a major game design task that requires Gestalt, Paula, and Nigel alongside engineering.

---

3. NPC-Driven and News-Driven Generation Hooks

NPC-Driven Generation

Scenario: Player meets Kira from Barnard's Star. Through deep interaction (not casual), they learn Kira's address. Now that address must be a real visitable place.

Architecture:

Player meets Kira (deep interaction trigger)
  ├─ Kira.home_location already exists in wiki data:
  │    system: GJ-699 (Barnard's Star)
  │    settlement: Proxima Station, District 7
  │    address: Block 3, Unit 12
  │
  ├─ Is GJ-699 generated?
  │    No → Queue: generate LocationProfile for GJ-699 (background)
  │    Yes → Is District 7 skeleton generated?
  │         No → Queue: generate Phase 1 skeleton for District 7 (background)
  │         Yes → Is Block 3 filled?
  │              No → Queue: generate Phase 2 fill for Block 3 (background)
  │              Yes → Mark Unit 12 as "Kira's residence" (ChunkMutation)
  │
  └─ Kira's home is now visitable. Player can travel there.

Latency budget: NOT immediate. The player meets Kira now, but traveling to Barnard's Star takes game-time. Generation runs in background during that interval. Even if the player teleported instantly, Phase 1 skeleton generation for a single district is ~50-200ms (BSP is fast). Phase 2 for a single block is ~5-50ms. Total worst case: <1 second of generation, easily hidden behind a door transition or transit loading.

Consistency constraint: Kira's home must match Kira's presentation. If Kira is wealthy, Unit 12 should be in a prosperous block. If Kira is struggling, it should be in a declining area. This means the generation mandate carries economic/social constraints that Phase 1 must respect when placing Kira's block.

Feasibility: MEDIUM. The generation itself is cheap. The hard part is the constraint propagation: Kira's attributes → home block requirements → Phase 1 must place that block appropriately. This is a focused version of the guarantee system — "this specific block must have property X." Estimate: 1-2 weeks for the hook system + constraint interface.

News-Driven Generation

Scenario: Reach-wide news reports "Gas main explosion at Kepler Haven, East District." Player travels there three game-days later. The explosion damage must exist.

Architecture:

News event fires
  ├─ Event specifies: location (Kepler Haven), district (East), type (gas explosion)
  │
  ├─ Is Kepler Haven generated?
  │    No → Queue: generate with explosion as a ChunkMutation
  │         The explosion becomes part of the initial generation —
  │         no "pristine then damaged" needed
  │    Yes → Apply ChunkMutation: damage overlay on affected blocks
  │         Replace tiles, add rubble objects, modify NPC states
  │
  └─ When player visits, damage is present and consistent

Latency budget: Days of game-time. News events are sparse (the product owner said "sparse frequency to avoid disruption"). The generation mandate is queued and processed in background during normal idle-time sim cycles.

The hard edge case: The news event references something that must already exist at the location. "Explosion at the hospital" means the location must have a hospital. Two approaches:

1. News events are generated from existing content: The storyteller only generates news about things that already exist in the world state (including generated-but-unvisited locations). This means the event system reads the Phase 1 skeleton to know "East District has a hospital block" before deciding to blow it up.

2. News events mandate content: The event says "there must be a hospital here" and the guarantee system ensures it during generation. If the district isn't generated yet, the hospital is a Tier 1 guarantee. If it IS generated, the hospital must already exist or we have a contradiction.

My strong recommendation: Approach 1. Events read world state, don't mandate content. This is consistent with the product owner's statement: "Only from real simulation events. No fabricated history." The background simulation produces pressures → pressures cause events → events are reported as news. The sequence is simulation → event → news, not news → content.

Feasibility: MEDIUM. The news event hook itself is cheap (1 week). The integration with the background simulation event system is the real work — and that's part of the background simulation workshop scope.

---

4. Full Simulation Primitives with LOD

The product owner's model: "A visited bar needs monthly turnover, cost, employee count, current staff and visitors. If the player BUYS the bar, deeper simulation activates."

LOD Architecture

This maps cleanly to bevy_ecs component composition:

LOD Level	Trigger	Components Added	Simulation Cost
LOD 0: Exists	Phase 1 skeleton generation	SocialSite { site_type, block_id }	Zero — metadata only
LOD 1: Observable	Player is within same district	BusinessStats { turnover_bracket, cost_tier, employee_count, patron_density, condition }	Near-zero — derived from pressure sim, updated per game-hour
LOD 2: Visited	Player enters the building	BusinessState { current_staff: Vec<StableEntityId>, current_patrons: Vec<StableEntityId>, today_revenue, inventory_level }	Low — entity list management, per-tick patron flow
LOD 3: Invested	Player purchases / takes job	BusinessFinancials { daily_revenue, daily_expenses, staff_satisfaction, supply_chain: Vec<SupplyLink>, customer_demographics }	Medium — full economic tick, supply chain queries

The LOD transition is component promotion — same pattern as D-026 tier transitions. bevy_ecs is literally designed for this. Add components on trigger, remove on distance/disengagement.

Economic Success Follows Regional Prosperity

This is the key design insight. A bar's LOD 1 turnover_bracket is NOT independently seeded — it's derived from the district's economic pressure state:

district_economic_health: Prosperous
  → BusinessStats.turnover_bracket for all businesses in district: High ± noise
  → When economic_health drops to Faltering:
       turnover_bracket shifts to Medium ± noise
       condition may degrade over game-time
       some businesses close (entity removal)

This means the tycoon game IS the regional economic game. Buying a bar in a declining district means fighting against the pressure. Buying a bar in a prosperous district means riding the wave. The player reads the economic landscape, invests accordingly, and their investment feeds back into the pressure sim.

LOD Transition Cost

Transition	What Happens	Latency
LOD 0 → LOD 1	Derive BusinessStats from pressure sim + district profile	Instant (~microseconds, table lookup)
LOD 1 → LOD 2	Generate or load current staff/patron entities. Activate NPC routines for building occupants.	Fast (~1-10ms, entity spawning + component attach)
LOD 2 → LOD 3	Attach financial simulation components. Connect to supply chain graph.	Instant (component attach, supply chain is a graph edge)
LOD 3 → LOD 2	Detach financial sim, snapshot state to save data	Instant
LOD 2 → LOD 1	Despawn transient patron NPCs, save staff state	Fast (~1ms)

Feasibility: MEDIUM. The ECS component composition is natural. The harder work is designing the BusinessStats → BusinessState → BusinessFinancials data model, and the rules for how pressure drives them. Estimate: 3-5 weeks for the full LOD system with financial simulation at LOD 3.

---

5. Revised Pipeline Cost Estimate

The shift from procedural generation to authored content + simulation changes the cost profile significantly.

What Got Cheaper

Layer	R1b Estimate	Revised Estimate	Why
Layer 2: Location profiles	3-4 weeks (grammar + gen + hybrid authoring)	1-2 weeks (wiki → data pipeline + validation)	Authoring replaces generation. Engineering is just data ingestion.
Layer 3: Topography	Days (tags) to 3-5 weeks (heightmaps)	1-2 weeks (authored map → constraint extraction)	Authored maps eliminate terrain generation entirely.
Seed-based variety	Implicit cost across all layers (deterministic RNG management, seed-driven variation logic)	Removed	No seed variation. Canonical starting state + simulation drift.

What Got More Expensive (New Systems)

System	Estimate	Why It's New
Background pressure simulation	9-14 weeks	Economic + social + political pressure modeling. The product owner's core replayability mechanism.
LOD simulation primitives	3-5 weeks	Per-business economic sim at 4 LOD levels.
NPC/news generation hooks	2-3 weeks	On-demand generation triggered by simulation events.
Authored content pipeline	2-3 weeks	Wiki → structured data ingestion, map ingestion, GTTR compilation.

Revised Total

Layer / System	Revised Cost	Notes
Layer 1: Galaxy	Days	Unchanged — systems.db loader
Layer 2: Location profiles	1-2 weeks	Wiki pipeline engineering. Content authoring is external.
Layer 3: Topography	1-2 weeks	Authored map ingestion + constraint extraction
Layer 4: Gateways	Included in Station	No change
Layer 5: Content spidering	3-4 weeks	Add simulation-driven triggers alongside exploration triggers
Layer 6: Settlement generation	2-4 weeks	Simpler with authored terrain constraints. Boundary stitching still hard.
Layer 7: District → Building	6-10 weeks	Phase 1 + Phase 2 for 3 zone families. Core algorithmic work unchanged.
Layer 8: Rendering	2-4 weeks	Unchanged
NEW: Background simulation	9-14 weeks	Economic + social + political pressure. Needs own workshop.
NEW: LOD primitives	3-5 weeks	Business simulation at multiple LOD levels
NEW: Generation hooks	2-3 weeks	NPC-driven + news-driven on-demand generation
NEW: Content pipeline	2-3 weeks	Wiki → data, map → constraints, GTTR compilation
TOTAL	~30-50 weeks	Up from 20-30, but different in character

The Character Shift

The R1b estimate was ~20-30 weeks of generation engineering. The revised estimate is ~30-50 weeks of mixed engineering:

• Generation engineering (Layers 5-7): ~11-18 weeks — actually cheaper per layer because authored inputs simplify constraint satisfaction
• Simulation engineering (background sim + LOD): ~12-19 weeks — this is the new load-bearing work
• Data pipeline engineering (Layers 2-3 + content pipeline): ~5-7 weeks — unglamorous but critical
• Rendering (Layer 8): ~2-4 weeks — unchanged

The headline number is bigger, but the risk profile is better. R1b's pipeline had a "generation grammar for 300 locations" problem that was open-ended and hard to validate. The revised pipeline has a "build a data pipeline" problem that's well-understood and a "design an economic simulation" problem that's complex but decomposable.

The critical path has shifted. It was: Layer 2 grammar → Layer 6 settlement → Layer 7 districts. It's now: Background simulation design → Pressure-to-entity bridge → Phase 1/2 generation reading pressure state. The background simulation is the new load-bearing wall. Everything else reads from it.

---

6. Follow-Up Questions and Technical Risks

Q1: What fidelity does the background simulation need at launch?

The interview says "full economic + social + political background simulation." That's the endgame. But background sim is the kind of system where you can ship LOD levels of the sim itself:

Sim LOD	What It Models	Cost	Player-Visible Effect
LOD 0: Static authored	Wiki data is the "simulation." No drift.	Zero	None — world is a snapshot
LOD 1: Economic pressure only	System-level GDP drift, trade route effects, industry health	3-4 weeks	Prices change, some businesses open/close, NPC complaints shift
LOD 2: Economic + social	Add population satisfaction, crime pressure, cultural tension	+2-3 weeks	NPC behavior changes, district condition drifts, security presence varies
LOD 3: Full pressure model	Add political faction shifts, governance stability, external events	+3-4 weeks	Faction control of districts changes, political events fire, governance type shifts

The question for the product owner: Is LOD 1 sufficient for the first playable build, with LOD 2-3 as enrichment? Or is the full pressure model needed for the core game loop to work?

Why this matters architecturally: LOD 1 can ship in weeks. LOD 3 needs a dedicated workshop to design the pressure interaction model. The data architecture should support all levels from day one, but the simulation rules can layer.

Q2: How are authored world maps represented?

The product owner said "authored world maps for all planets and moons." What format?

Format	Engineering Cost	Authoring Tool
Tagged regions (JSON/YAML: region name → terrain type + bounding polygon)	Cheap (1 week)	Any text editor. Low fidelity.
Annotated images (PNG heightmap + region overlay, like Crusader Kings province maps)	Medium (2-3 weeks for ingestion pipeline)	Image editor. Medium fidelity.
d2/SVG vector maps (topology diagram with named regions and connections)	Cheap-Medium (1-2 weeks)	d2 tool (already in the stack). Good for settlement placement, bad for terrain detail.
Tiled/Godot TileMap (authored in a map editor with terrain brushes)	Medium (2-3 weeks)	Tiled or Godot editor. High fidelity, high authoring effort per planet.

My recommendation: Start with d2 vector maps for topology (regions, connections, terrain types) and add image heightmaps later for the visual world map. The generation pipeline only needs the topology — "District A is coastal, District B is mountain, they connect via a valley corridor." That's a graph, not a heightmap.

Q3: How does determinism work without seeds?

D-010 mandates deterministic simulation. The current architecture uses SimRng (seeded RNG). If replayability comes from simulation drift rather than seed variation, the determinism requirement shifts:

• Same starting state + same player actions → same world state. This is traditional determinism and is preserved.
• Same starting state + different player actions → different world state. This is the intended replayability — player agency creates divergence.
• Background simulation must be deterministic. Even though it runs on "spare cores" with variable timing, results must be identical given the same inputs. This means background sim tasks must be gated on a deterministic clock (game-minutes) and applied in a fixed order.

Risk: Wall-clock-dependent background sim. If background tasks process "as much as they can" in available CPU time, two machines with different CPU speeds produce different world states at the same game-time. This VIOLATES D-010. The fix: background sim advances in discrete game-minute steps regardless of CPU availability. Slower machines fall behind (sim debt) but produce identical results when they catch up. Same pattern as frame-independent physics.

Q4: Content authoring bottleneck

The pipeline now depends on authored content for 300+ systems. Who authors this? At what pace? And what blocks engineering while authoring is in progress?

Risk: Engineering builds a wiki → data pipeline, but the wiki isn't populated fast enough for testing. Mitigation: generate placeholder profiles from systems.db attributes for engineering testing, with a validation flag that marks them "generated, not reviewed." Authored content replaces placeholders over time. The generation grammar from R1b isn't wasted — it becomes the placeholder generation tool that produces testable-but-not-final location profiles.

Q5: Miri's heritage root framework — what survives the deprecation?

D-104 and D-105 are flagged as stale. Miri's R1b questions (Q1-Q5) are built on the 7 heritage roots (Frost/Stone/Tide/Vine/Dust/Iron/Salt). The interview replaces these with real-world cultural corridors (Commonwealth, Iberian/Latin American, East Asian, Northern European).

The room-grammar framework (Miri Q5) still applies — the token layers (privacy_default, sightline_character, gathering_orientation, threshold_character) are excellent regardless of whether the cultural axis is "Frost" or "Northern European isolationist tradition." The labels change, the architecture doesn't.

Risk: If the cultural framework is in flux, the generation pipeline can't lock its cultural input format. Need a decision on whether cultural identity is a continuous parameter space (Miri's option C) or a discrete set of authored cultural profiles. I recommend the product owner settle this before generation engineering begins.

Technical Risk Summary

Risk	Severity	Mitigation
Background sim non-determinism from variable CPU timing	HIGH	Gate on game-minute clock, not wall-clock. Apply results in fixed order.
Content authoring bottleneck blocks engineering testing	MEDIUM	Placeholder generation from systems.db attributes for dev/test.
Cultural framework in flux delays room grammar implementation	MEDIUM	Lock cultural input format early. Labels can change, data shape shouldn't.
Background sim design underspecified — "needs its own workshop"	HIGH	Don't start sim engineering until the workshop produces a pressure model spec.
LOD transition edge cases (player sells a business, what happens to LOD 3 state?)	LOW	Design LOD demotion rules alongside promotion rules. Snapshot on demotion.
Authored world maps — format not decided	MEDIUM	Decide format in this workshop. Don't build ingestion pipeline for a format that changes.

---

Summary for the Team

The product owner's model is simpler to generate, harder to simulate. The generator reads authored data and paints spaces based on current simulation state. The replayability engine is the background simulation, not the seed. This is architecturally sound — it means the generator is a relatively straightforward painter, and the complexity lives in the simulation model where it belongs.

The critical path has shifted from "build a procedural generation grammar" to "design and implement a background economic/social/political simulation." That simulation needs its own workshop. Everything else — the data pipelines, the Phase 1/2 generation, the LOD system — is well-understood engineering that can proceed once the simulation design is specified.

Gestalt's economic cascade framework (Q1: economic axes, Q5: room-level cascade) is now MORE important, not less. In R1b, economic data was one of many generation inputs. In the revised model, economic pressure IS the primary driver of world variety. The cascade must be designed explicitly: pressure → district condition → business stats → room interior signals.

Nigel's replayability framework (Q1: fixed galaxy / seeded drama, Q4: world lives before player arrives) is confirmed by the interview. The implementation mechanism shifts from "seed-based variation" to "background simulation drift," but the player-facing outcome is identical: two playthroughs produce different worlds because the simulation trajectory diverged.

Ozzie's environmental archaeology (Q3) gets stronger in this model. "Only from real simulation events" means every piece of environmental evidence has a genuine causal chain. The generator doesn't fabricate history — it renders the consequences of simulation events. This is the highest-integrity version of Ozzie's vision.