settled-reach/docs/workshops/generation-cascade/gestalt-round4.md

title, description, type, status, workshop, agent, round, created

title	description	type	status	workshop	agent	round	created
Gestalt — Round 4: Systems Requirements for the Planet-Down Cascade Brief	Systems design questions, game-mechanical decisions, interesting-factor analysis, resolved carry-forwards, and minimum viable scope for each of the four cascade layers	workshop	active	generation-cascade	gestalt	4	2026-04-30

Generation Cascade — Round 4 (Gestalt)

Role: Systems design requirements for the next workshop brief. This document does not design the implementation — it frames what the implementation must answer mechanically, what each layer's output means for gameplay, and what we already know well enough not to relitigate.

The lead's cascade reframe: Planet-down, not city-outward. The world exists before civilization. Civilization is layered onto it. The player enters at the bottom of that stack and reads upward.

The two rules that govern everything:

DETERMINISM RULE: Economic simulation's rolling state affects RENDERING (prosperity, repair state) but NOT LAYOUT (streets and buildings locked by seed). A player who leaves a city and returns a year later finds the same streets, richer or poorer.

LOD RULE: When a player spawns, the code "zooms in" on the planet — tracing all cascade steps to where the player sits, filling in street-level detail where the player is. Each layer's output is the next layer's input.

These two rules are the architectural spine. Every system design question below ultimately reduces to: does this belong in seed-locked layout, or economics-variable rendering?

---

The Sub-Settlement Hierarchy (Lead Inclusion)

Before the layer-by-layer breakdown: the lead has confirmed sub-settlements are included. This has systems-design implications across all four layers, so I'm stating the hierarchy here and referencing it throughout.

From the Round 3 consensus (Burnelli-Sheldon + Paula + Gestalt):

Tier	Population	Generation treatment	Placement driver
City	10,000+	Full district decomposition (Layer 3)	markers.json anchor + geography
Town	1,000–10,000	Single-district equivalent	Road network + economic role
Outpost	50–1,000	Purpose-typed single node	Corp presence + extraction trigger
Waypoint	<50	Infrastructure node, no district	Road midpoint formula
Rural cluster	Isolated	Type-tagged scattered nodes	settlement_pattern + economic role
Ruin	0	Historical footprint	Abandoned tether condition

Placement trigger conditions (from Burnelli-Sheldon Round 3):

• Mining camps: economic_role ∈ {extraction, mining} AND corp_presence with relevant commodity → 1 camp per 2 qualifying corps, 1 district (LogisticsHub + minimal Residential)
• Trade waypoints: Long roads (pixel_count > threshold) → waypoint at geometric midpoint, 1 Transit district
• Agricultural nodes: settlement_pattern ∈ {dispersed, dispersed_rural} AND economic_role = agricultural → farm clusters at interval proportional to 1/economic_tier
• Shadow nodes: collection_efficiency < 0.6 AND shadow-viable corps → 1 informal MixedUse settlement at city fringe

PoliticalTether: Every sub-city settlement has a tether to a city (Administered / EconomicallyDependent / Contested / Independent / Corporate / Abandoned). This determines road maintenance class, naming register, and ruin candidacy. Derivation: distance + economics data.

Sub-settlements appear in Layer 2 (placed onto the natural world) and are consumed by Layer 3 (if they receive district treatment) and Layer 4 (if the player approaches tile range).

---

The Economics Bridge (Burnelli-Sheldon Round 3)

The 6-field minimum read set and the weight table are foundational. I'm stating them here explicitly so the brief can reference them without recapping.

The 6-Field Minimum Read Set

All six fields are queryable from systems.db per city at generation time. They produce a spatially differentiated world on their own. Everything else is enrichment.

#	Field	Source table	Drives
1	economic_role	bodies	DistrictType distribution weights (weight table below)
2	settlement_pattern	bodies	District density mode, layout style, domed/underground special cases
3	economic_tier	system_economy	Infrastructure quality floor, wealth ceiling
4	distribution_index	system_economy	Prosperity gradient shape (stratified vs. moderate)
5	corp_presence count	corp_presence	Corporate district intensity, company town detection
6	headquarters_system/body match	corporations	HQ landmark flag, dominant building height

The 10×9 DistrictType Weight Table (D-C10 candidate)

Probability weights mapping economic_role → DistrictType prior. Corp-presence modifiers stack on top. This is the canonical default — tunable but locked so it doesn't get relitigated.

economic_role	Res	Com	Ind	Adm	Log	Ent	Mix	Trn	Spe
manufacturing	25	5	35	5	20	2	5	3	0
agricultural	30	15	5	10	25	3	10	2	0
extraction	20	5	30	5	30	0	5	5	0
transit	10	20	5	5	25	10	15	10	0
research	20	5	5	15	5	5	10	0	35
commercial	15	35	5	5	10	15	15	0	0
service_mixed	25	20	5	10	5	15	20	0	0
mining	20	5	25	0	35	0	10	5	0
frontier	35	10	10	5	20	5	15	0	0
energy	10	0	20	5	30	0	5	5	25

political_archetype modifiers apply on top of these weights to shape district type distribution: CompanyTown amplifies the dominant type; FreePort flattens toward MixedUse/Transit/Commercial; Contested produces discontinuous spatial blocks.

---

Layer 1 — Empty World

What This Layer Produces

Start from the heightmap. Run water simulation (river drainage, lakes, coastlines). Refine sub-biomes into regional character. Output: a complete natural world with no civilization.

The existing pipeline already produces a 512×256 heightmap per body and a 64×32 regional biome grid (Layer B from Round 3). Layer 1 extends this with:

• River network at regional resolution: where major rivers run, where they meet, where they reach the sea. River confluences and river mouths are settlement attractors for Layer 2.
• Lake placement from biome/river basin dependency
• Sub-biome refinement within each regional cell: a "tropical" cell is "jungle with clearings" vs. "swamp" vs. "riverine forest" — 3-4 variants per biome class, seed-derived
• Terrain roughness signals at regional resolution: pass locations through mountain ranges, traversable vs. impassable zones

Systems Design Questions for the Brief

1. At what resolution does the river network get stored? The 64×32 regional grid gives coarse river paths. If rivers are future walkable obstacles (Phase 5), their exact courses need to be at a resolution the tile generator can use. But if rivers are navigation constraints only at regional scale, the coarse grid is sufficient. This is a scope question, not a design question — the brief needs to state which.

2. What is stored vs. seed-derived for Empty World data? The heightmap and 512×256 biome grid are committed artifacts from generate_atlas.py. The 64×32 regional grid is committed (Layer B, Round 3). River network routing below regional resolution is candidate for seed-derivation (same FNV-1a pattern). But river confluence locations (settlement attractors for Layer 2) must be stored or at least deterministically queryable before Layer 2 runs. This is the key architectural question.

3. How do sub-biome variants affect generation downstream? A "dense forest" cell requires terrain modification (clearing) before a settlement exists; a "grassland" cell does not. The Empty World layer needs to produce a signal that Layer 2 can act on. Concrete proposal: terrain_modification_cost: f32 per regional cell — how much effort is required to settle here. High cost = forest/hills; low cost = plains/coast.

4. Where do geographic bottlenecks get identified? Mountain passes, river crossings, and coastal access points are constraint features that later layers (roads, settlements) need to route around or through. These need to be extractable from the Empty World layer as named spatial features, not just implicit in the elevation data.

Game-Mechanical Decisions This Layer Produces

Feature	Player decision created
River network (regional)	Route choice: ford vs. bridge; upstream vs. downstream travel
Mountain passes	Overland route selection: fast valley route vs. hard mountain pass
Coastal access	Settlement approach: sea route vs. overland; port city vs. inland city
Sub-biome character	What to expect in wilderness between settlements; terrain hazard prediction
Lake positions	Dead-end vs. through-lake navigation; freshwater resource
River confluences	Settlement density prediction: confluences attract cities → player plans route accordingly

The key mechanic: the player reads terrain to predict settlement density and route quality before seeing a map label. A river confluence with coastal access is almost certainly a city. A mountain range with a single pass is almost certainly a chokepoint. Empty World teaches the player to read the world.

What Makes This Layer Interesting for Gameplay

The Empty World is the legibility layer. It explains why civilization sits where it does.

A player navigating from one city to another doesn't just move through abstract distance — they cross terrain that was there before the cities existed and will be there if the cities collapse. The terrain creates:

• Forced routes: A mountain range with one pass means all overland traffic converges there. That convergence is interesting — high encounter probability, possible chokepoint control, valuable for whatever faction controls it.
• Natural shelter: A river valley that widens into a delta is obviously where the port city is. The player arriving for the first time can orient themselves without a tutorial.
• Risk gradient: Moving away from rivers and coast into wilderness means moving away from the infrastructure support network. The player knows this before it's confirmed.

The ABSENCE of civilization in the Empty World layer is as informative as presence. A wide fertile valley with no settlement asks: why? That question is a gameplay hook.

Resolved Decisions Carrying Forward

• FNV-1a SeedChain (D-010, D-C6): river routing below regional resolution is seed-derived using the same pattern as district/chunk generation
• The 64×32 regional biome grid (Layer B, Round 3) is the base; Layer 1 refines it but does not replace it
• is_coastal, water_fraction, terrain_roughness on atlas_regional_biomes already exist — Layer 1 populates sub_biome_variant on the same table
• Heightmap is committed artifact from generate_atlas.py — Layer 1 consumes it, does not regenerate it

Minimum Viable Layer 1

• Sub-biome variant tag per regional cell (3-4 values per biome class): high vs. low modification cost
• River confluence identification (stored as point features in systems.db): "this regional cell has a confluence"
• Coastline identification: already done (is_coastal on atlas_regional_biomes)
• Mountain pass identification: regional cells with very high terrain_roughness adjacent to lower cells = candidate pass locations
• Defer: tile-resolution river routing, lake exact polygon, sub-regional terrain variation

---

Layer 2 — Population Overlay

What This Layer Produces

Layer economics onto the natural world. Settlement positions anchor from wiki population counts + markers.json, but the shape of civilization is determined by geography. Felled forests become farmland; flattened hills become towns. Road and rail networks connect settlements. Sub-settlement hierarchy placed.

This is the layer where the world becomes inhabited. It does not produce the internal structure of cities (Layer 3) or the walkable tiles (Layer 4) — it places civilization in the landscape and defines the relationships between settlements.

Systems Design Questions for the Brief

1. Does "geography determines shape" mean we re-evaluate atlas city positions? The current model places cities as authored dots in markers.json. If geography determines shape, does this mean: (a) city positions stay but the generator explains/validates them against geography, or (b) the generator produces city positions from geographic attractors and uses markers.json only as population counts? This is a foundational framing question the brief must answer. My read of the lead's intent: the positions are anchored, but the generator understands WHY they're there — which then informs how each city sits in its landscape and where sub-settlements cluster.

2. What is the "terrain modification" record? The lead says "felled forests become farmland, flattened hills become towns." This means the Empty World's terrain is visibly modified by civilization. Where is this stored? Options:

   • Layer 2 commits a terrain_modification table to systems.db (what was here before, what it became)
   • Layer 2 produces a land_use overlay on the regional grid (already in Layer F from Round 3)
   • Modification is implicit in the land_use classification (Urban = was something else; Agricultural = was forest/grassland)

   The simplest answer: the existing land_use column (Urban / Agricultural / Industrial / Wilderness / etc.) on atlas_regional_biomes IS the modification record. No separate table needed.

3. How are hinterland agricultural zones shaped? Burnelli-Sheldon's HinterlandType and InfrastructureDensity give us the character of the space between cities. But the SHAPE of farmland needs a placement rule. Proposal: agricultural cells cluster around cities with economic_role = agricultural and along river corridors, at a density inversely proportional to terrain_modification_cost from Layer 1. Rough terrain stays wilderness; gentle terrain becomes farmland.

4. What is the road placement algorithm? Currently, markers.json has authored road pixel-paths. The Population Overlay phase is supposed to generate road networks. Are these the same roads (authored once, never regenerated) or a new algorithm that derives roads from settlement positions? This is a key question for the brief to resolve. My position: authored roads for named highway routes (these encode setting decisions — Gate Corp built this highway, not the settlement network); generated roads for local connections between sub-settlements and their tether cities.

5. Sub-settlement exact placement: Given a body with economic_role = extraction and 3 qualifying corps in corp_presence, where exactly do the 1-2 mining camps sit? The brief needs to specify the placement algorithm. Proposal: mining camps sit at the closest regional cell to the corp's asset that has land_use = Industrial or land_use = Wilderness (not Urban), at seeded distance from the tether city within [15%–40%] of body scale.

Game-Mechanical Decisions This Layer Produces

Feature	Player decision created
Settlement network topology	Route planning: which settlements to visit and in what order
Sub-settlement placement	Opportunity discovery: finding the camp before knowing it's there
Hinterland agricultural extent	Resource geography: where food comes from, where it's vulnerable
Road connectivity gaps	Risk/reward: unconnected settlements are accessible but unprotected
Terrain modification extent	Historical reading: how long has this settlement been here?
PoliticalTether relationships	Faction awareness: is this outpost administered or corporate?

The key mechanic: the settlement network topology creates the player's opportunity map. Connected settlements are safe but competitive. Disconnected ones are risky but potentially profitable. The gaps in the road network are where interesting things happen.

What Makes This Layer Interesting for Gameplay

Population Overlay is where the world becomes a problem space. The empty world had terrain; now it has places to go and reasons to go there.

Three specific interesting structures this layer produces:

1. The underserved route: Two significant settlements with no direct road — only a wilderness crossing or a long detour through a third settlement. This is a player opportunity (carry trade between them directly) that the generator produces from the absence of infrastructure, not its presence.

2. The extraction hub: A cluster of mining camps orbiting a tether city at increasing distance. The outermost camps are the least administered, most economically exploitable, most isolated. The player can read this structure from the regional map and choose their engagement point.

3. The abandoned corridor: An old road leading to ruins — AbandonedZone status, former PoliticalTether now severed. The road's quality (Abandoned MaintenanceAuthority) signals that something was here. This is generated entirely from economic data (corporation left) without authored content.

Resolved Decisions Carrying Forward

• Burnelli-Sheldon's 6-field minimum read set: drives hinterland type and settlement character
• Dynamic settlement trigger conditions (Round 3): mining camps, trade waypoints, agricultural nodes, shadow nodes
• PoliticalTether struct (Round 3): every sub-city settlement classified
• land_use column on atlas_regional_biomes: Urban / Agricultural / Industrial / Wilderness / Corridor / Ruins / Ocean / Impassable
• MaintenanceAuthority on road edges: Administrative / Corporate / Communal / Trade / Abandoned
• TerritorialStatus per regional cell: CoreTerritory / FrontierTerritory / ExtractiveZone / ContestZone / WildernessBuffer / AbandonedZone

Minimum Viable Layer 2

• land_use on all regional cells (already in Layer F design from Round 3)
• Sub-settlement placement: mining camps and trade waypoints (highest frequency; most game-relevant)
• Road graph (already designed in Layer C, Round 3): nodes + edges with maintenance_authority
• TerritorialStatus per regional cell (Layer D from Round 3)
• Defer: agricultural node exact positions (land_use tag is sufficient for minimum), shadow node placement (needs collection_efficiency data quality improvement), authored road vs. generated road resolution

---

Layer 3 — City-Level Planning

What This Layer Produces

Given topography + economics + cultural parameters: plot the internal structure of cities. Suburbs, industrial zones, commercial districts, ports, stations, highways. The entire phase. This is the "Cities Skylines" layer.

This maps directly to the DistrictSkeleton work from Rounds 1-3, extended to include the city-scale spatial organization (not just individual district classification). The key addition over prior workshop work: this phase knows WHERE districts sit relative to each other, relative to the city's geographic position, and relative to the settlement's orientation.

Systems Design Questions for the Brief

1. What is the City Planning layer's exact output? I propose it is the DistrictPlacement vector + DistrictSkeleton (Stages 1-2) for every district in every city. This means Layer 3 = the city decomposition + Phase 1 district skeleton generation from Rounds 1-3. The workshop brief should confirm this equivalence explicitly so implementation teams don't design two separate systems.

2. How does FoundingOrientation constrain district placement? A PortFacing city has its logistics/transit districts on the water-edge. An AdminFacing city has its administrative district elevated/central. The district decomposition formula (D-C4) places N districts in a grid — but that grid should be oriented by FoundingOrientation. This is a spatial constraint that the current city decomposition formula does not include. The brief needs to specify whether FoundingOrientation modifies the district placement grid, or just the prosperity gradient.

3. What drives the arterial road layout within the city? The district grid implies roads at district boundaries, but not internal arterials. In Cities Skylines terms: we zone the land (district type assignment) but we also lay the major roads first. The brief should clarify whether internal arterials are:

   • Implicit in the district boundary positions (streets exist at every district edge — sufficient for minimum viable)
   • Explicitly generated as an arterial graph (more realistic but more complex)

4. How does topography (Layer 1) constrain city planning? A city built into a hillside has different arterial possibilities than one on a plain. The brief should specify whether Phase 3/Layer 3 has access to terrain roughness at city-local resolution, or whether it treats all cities as flat for the minimum slice.

5. Port/spaceport positioning: Burnelli-Sheldon proposed Transit and LogisticsHub districts at the city edge closest to the orbital station (if one exists). This requires knowing which direction the orbital station is from the city's geographic position. The brief needs to confirm: does Layer 3 receive directional information about nearby stations?

6. How does the political archetype shape the district placement pattern, not just distribution? From Paula (Round 3): CompanyTown has a SPINE (facility at one end, workers radiating back); AdminCapital has a CENTER (administrative hub with residential radiating outward); FreePort has MULTIPLE NODES (no single center). These are spatial arrangements, not just type frequency distributions. The brief needs to specify whether Layer 3 implements these arrangement patterns, or whether they emerge from the weight table without explicit arrangement logic.

Game-Mechanical Decisions This Layer Produces

Feature	Player decision created
District type layout	Navigation: where to go for what purpose
Perimeter treatment distribution	Access route choice: Checkpoint vs. Open approaches
Prosperity gradient direction	Economic reading: which end of the city is wealthy/poor
Political archetype spatial arrangement	City legibility: player learns CompanyTown vs. AdminCapital patterns
FoundingOrientation	Approach prediction: player knows which end has the port
Corporate district positions	Faction geography: where to find/avoid corporate presence
Port district placement	Entry/exit: where ships dock, where the city opens to outside

The central mechanic here is city legibility as player skill. A player who understands the political archetypes, WorldTier patterns, and economic roles can walk up to a city they've never visited and make accurate predictions about its internal structure before entering. This is meaningful gameplay — the player's knowledge of the system is a form of power.

What Makes This Layer Interesting for Gameplay

City planning is where systemic knowledge pays off. This layer is interesting not because of individual cities but because of what patterns the system reliably produces.

Legibility patterns the player learns:

• CompanyTown: one huge industrial/logistics section, worker housing packed behind it, no entertainment, checkpoint at the facility edge
• FreePort: transit and commerce everywhere, no dominant center, multiple competing entry points, high perimeter treatment variance (some Gated compounds next to Open street markets)
• AdminCapital: wide boulevards converging on a central elevated point, residential quality degrades outward, strong checkpoint presence at city limits but relatively open inside

Why this is interesting: Each archetype creates a different navigation and interaction challenge. The player's tactical approach to a CompanyTown is different from their approach to a FreePort. This differentiation is generated, not scripted — the same city archetype produces consistent behavior across every city of that type, which makes player investment in understanding patterns worthwhile.

The determinism rule's role here: The city layout never changes. The player can memorize it. This transforms city navigation from a puzzle (solve it once) into a familiar space (navigate it repeatedly with increasing fluency). The economics affecting rendering means the player sees the city get richer or poorer over time while the bones remain recognizable.

Resolved Decisions Carrying Forward

• District count formula (D-C4): max(1, floor(population / 50_000)), log-scaled, WorldTier ceiling
• WorldTier district ceiling: Epicenter uncapped, Regional 8, Backwater 4, Passage 2, Waypoint 1
• City-local coordinate system (D-C5): districts at (col × 512, row × 512) sim tiles
• Phase 1 Stages 1-2 minimum (Round 2 consensus): classification + block grid only
• prosperity_index and perimeter_treatment on DistrictSkeleton (confirmed all participants)
• political_archetype formal field with override (confirmed all participants)
• FoundingOrientation drives prosperity gradient direction (Paula/Gestalt Round 3)
• 6-field minimum read set and 10×9 weight table (Burnelli-Sheldon Round 3)
• prosperity_index derivation formula (Burnelli-Sheldon Round 3):

  base = economic_tier / 5.0
  role_modifier: extraction -0.1, research +0.15, service_mixed +0.1, frontier -0.2 ...
  if stratified: district_i = base + role_modifier + (prestige_rank(i) - 0.5) × 0.7
  if moderate:   district_i = clamp(N(base + role_modifier, 0.1), 0.2, 0.8)
  

Minimum Viable Layer 3

• Phase 1 Stage 1: classification (WorldTier, ComplexityTier, SettingType, DistrictType, LayoutMode)
• Phase 1 Stage 2: block grid (4×4 BlockSkeletons with ZoningType, density_pct, seed)
• prosperity_index and perimeter_treatment computed in Stage 1 from the 6-field read set
• political_archetype consumed from systems.db (Layer 2 output)
• Defer: FoundingOrientation-modifying district placement grid (Stages 3-5, guarantee audit, reservations, social sites)
• Defer: explicit arterial road layout within city (district boundary = implicit street)

---

Layer 4 — Street-Level Rendering

What This Layer Produces

Take city-level data (Layer 3). Render streets, buildings, scatter civilization into tiles. The player walks through this.

Mechanically: generate 64×64 tile grids (ChunkData) from BlockSkeletons, on demand as the player moves.

Systems Design Questions for the Brief

1. Precisely what does the DETERMINISM RULE mean at implementation level?

   The lead says: economic simulation's rolling state affects RENDERING but NOT LAYOUT. The brief needs to make this concrete:

   Category	Seed-locked (never changes)	Economics-variable (changes per tick state)
   Layout	Street positions, building footprints, door positions, room layouts, district boundaries	—
   Rendering	—	Tile decay state (intact → cracked → broken), building activity signals (lights on/off, signs present/absent), repair scaffolding presence

   Implementation proposal: the tile generation function produces a canonical tile type (floor_street, floor_interior, wall). The economics rendering pass then applies a decay overlay — each canonical tile has a condition modifier (intact | worn | cracked | damaged | rubble) derived from prosperity_index at render time, not at generation time. The seed generates the layout; the economics tick generates the condition.

2. When exactly does Street-Level fire in the "zoom in" cascade? The existing chunk streaming system (load_chunk()) fires when the player's ChunkLoadRadius includes a chunk coordinate. This is already the LoD trigger. The brief should confirm: Layer 4 runs on-demand inside the existing chunk streaming architecture, not as a separate batch process. No new trigger mechanism needed; the hookup ticket from Round 2 is the wiring.

3. What is the minimum tile vocabulary that supports economics-variable rendering? The Round 2 minimum was 3 tile types: floor_street, floor_interior, wall. For the determinism-plus-rendering model, we need tile variants or a condition modifier system. Proposal: keep 3 canonical types; add a condition enum (Intact | Worn | Cracked | Broken) that the economics rendering pass applies. This is 4 condition states × 3 tile types = 12 visual variants, but only 3 generation types.

4. Where does the economics rendering pass execute? Options:

   • At chunk generation time (bake prosperity_index into tile conditions when the chunk first generates)
   • As a live overlay per tick (tile conditions computed from current prosperity each time the chunk is rendered)
   • As a periodic re-render (chunk conditions recomputed when prosperity changes significantly)

   The determinism rule implies the LAYOUT is baked at generation time, but tile CONDITIONS should not be baked — they need to reflect current economic state. The brief needs to specify the condition update mechanism.

5. Building interiors: when do they generate? Door-per-edge is the confirmed boundary. The brief should specify what triggers interior tile generation: (a) when the player is within threshold of the door, (b) when the player opens/enters the door, or (c) pre-generated with the exterior but not rendered until entered. Performance implications differ significantly.

6. What is "scatter civilization into tiles"? The lead's phrasing suggests more than just floor/wall. Does this include: prop placement (furniture, vehicles, crates), surface decals (signage, paint), entity spawn points? These are distinct from tile types. The brief needs to establish what Street-Level Rendering is responsible for vs. what is runtime placement by the entity system.

Game-Mechanical Decisions This Layer Produces

Feature	Player decision created
Walkability (tile positions)	Pathing: which routes through a district are possible
Building footprint positions	Navigation: where doors are, which buildings block line of sight
Door-per-edge thresholds	Interior access: which buildings can be entered
Street connectivity	Approach routing: dead-ends, through-routes, alleys
Tile condition (economics)	Reading the district: visible decay signals current prosperity
Density variation	Area character: packed warehouse district vs. open boulevard

The central mechanic: the street level is where the player has physical presence. All decisions above this layer were about where to go and why. This layer is about how.

What Makes This Layer Interesting for Gameplay

Street-Level Rendering is where the player's understanding of the system becomes tactile.

The determinism dividend: Because layout is seed-locked, every visit to a city produces the same physical space with potentially different economic conditions. This creates two distinct player experiences:

1. First visit: Exploration — finding routes, locating key buildings, understanding the district's arrangement
2. Return visit: Operational — applying remembered knowledge to new conditions ("The Checkpoint guard post is in the same place, but the district looks richer than last time")

The player's spatial memory becomes an asset. Cities reward familiarity. This is a different and richer relationship with procedurally generated space than "different every time."

The economics-variable rendering creates observable history. A district in decline shows decay tiles accumulating over time. A district being developed shows repair states. The player who visits frequently sees the arc; the player who returns after absence sees a snapshot difference. Neither requires exposition — it's written into the tiles.

Sight lines as political geometry (Paula Round 2 principle, applicable here): High-prosperity/Checkpoint districts have open corridors — surveillance optimization creates navigable sightlines. Organic/low-prosperity districts have broken sightlines — buildings jut into streets, alleys angle away. This is a tile placement rule, not a separate computation: Checkpoint + Grid layout → buildings placed to maintain corridor sightlines; Organic + low prosperity → buildings placed to break them. The player navigating these districts has different information horizons.

Resolved Decisions Carrying Forward

• GeneratorChunkData upgrade: Vec<bool> → Vec<TileEntry> with tile_id: TileId + walkable: bool (D-C7)
• 3 minimum tile types: floor_street, floor_interior, wall (Round 2 consensus)
• Phase 2 minimal tile generation: density-driven rectangle placement (Tyre Round 2 algorithm)
• FNV-1a SeedChain: chunk_seed = child_seed(district_seed, (cx << 32 | cy)) (D-C6)
• 64×64 tiles per chunk, 2×2 chunks per block, 4×4 blocks per district (existing architecture)
• Door-per-edge building interiors: boundary confirmed; descriptor + catalog behind it (CLAUDE.md)
• Phase 2 tile generation algorithm: street skeleton first (door-per-block-edge), then building fill (density-driven rectangles within skeleton) — Tyre/Gestalt Round 2 consensus
• Chunk streaming → generator wiring: DistrictMap resource + load_chunk() hookup ticket (Round 2 design)

Minimum Viable Layer 4

• 3 tile types generating a walkable, navigable space
• Seed-locked layout from district_seed via FNV-1a
• Chunk streaming hookup: load_chunk() calls generate_chunk_tiles() via DistrictMap
• Prosperity affects building density (already in Phase 2 algorithm — high density at low prosperity, low density at high prosperity)
• Defer: tile condition overlays (economics-variable rendering) — implement after minimum walkable world exists
• Defer: building interior generation beyond door-per-edge boundary
• Defer: prop/decal scatter

---

Cross-Layer Systems: The Two Rules Applied

Determinism Rule — Boundary by Layer

Layer	Seed-locked (generated once, never changes)	Economics-variable (changes per tick state)
Layer 1 (Empty World)	Heightmap, river network, biome grid, pass locations	Nothing — terrain is fixed
Layer 2 (Population)	Settlement positions, road topology, sub-settlement placement, PoliticalTether	Road condition (Abandoned roads could degrade further — edge case)
Layer 3 (City Planning)	District positions, district types, block grid, prosperity_index baseline, perimeter_treatment	prosperity_index current value (rolling simulation updates this); building availability in commercial districts
Layer 4 (Street-Level)	Street positions, building footprints, door positions, all tile layout	Tile condition states (Intact/Worn/Cracked/Broken), building activity signals

The key implementation note: prosperity_index at Layer 3 is a BASELINE value derived from economic role and WorldTier. The simulation's rolling state produces a CURRENT value. Layer 4 uses the current value for condition overlays, not the baseline. The baseline is stored in systems.db; the current value is runtime economic state. These are two different data fields.

LoD Rule — Zoom-In Cascade

When a player spawns, the code traces the full cascade from planet level down to the player's tile position. The cascade is lazy — only what the player needs is computed:

Planet exists in systems.db (Layer 1 + 2 data committed)
  │
  ├── Player within planet rendering range?
  │   → Activate regional biome overlay for atlas UI
  │
  ├── Player within city footprint range?
  │   → Generate city district grid (Layer 3 / Phase 1)
  │   → Build DistrictMap in memory
  │
  ├── Player within district range (chunk load radius)?
  │   → load_chunk() fires for each chunk in radius
  │   → Layer 4 / Phase 2 generates tile data from BlockSkeleton + chunk_seed
  │
  └── Player at building door threshold?
      → Interior descriptor + catalog loaded (door-per-edge)
      → Interior tiles generated (Phase 4+)

Nothing above the player's current resolution is generated at tile level. Nothing below the player's current resolution is generated at all. The cascade is the implementation of the LoD rule.

One concrete implication: The DistrictMap resource (city district grid) is built when the player enters a city's footprint radius. If two players are in different cities, two separate DistrictMap instances exist. If neither player is near a given city, that city has no DistrictMap — only its CityGenerationContext in the startup read from systems.db.

---

Open Questions for the Brief

These are not design questions — they are decisions the lead or the brief must make explicit before implementation teams can proceed without ambiguity.

ID	Question	Layer	Stakes
OQ-R4-G1	Does "geography determines shape" mean city positions in markers.json are re-evaluated by Layer 2, or do they stay fixed as anchors with Layer 2 explaining them? The answer determines whether generate_regional.py can write back to markers.json or only extends systems.db.	2	Architecture-level
OQ-R4-G2	What exactly does Layer 4's economics-variable rendering produce? The brief should specify: condition enum values, what triggers condition recalculation (prosperity threshold change? periodic tick?), and whether conditions are cached per chunk or computed live per render.	4	Implementation-level
OQ-R4-G3	Is prosperity_index on DistrictSkeleton the BASELINE (from economic role, stored) or the CURRENT (from rolling simulation, runtime)? The brief should use distinct names to prevent confusion in implementation. Proposed: prosperity_baseline: f32 (Layer 3 output, stored) vs. prosperity_current: f32 (runtime simulation state).	3 + 4	Data model
OQ-R4-G4	Does the City-Level Planning layer produce explicit arterial road layout, or are district boundaries the implicit road network? Full arterials require a road placement algorithm; implicit streets require only district grid positions.	3	Scope
OQ-R4-G5	At what tile-resolution granularity do rivers appear in walkable generation? If rivers are navigable obstacles at street level, the Phase 2 tile generator needs to know where the river is at tile precision. If they're only regional navigation constraints, the 64×32 grid suffices.	1 → 4	Cross-layer scope
OQ-R4-G6	Does the sub-settlement hierarchy (towns, outposts, waypoints) receive Layer 3 (City Planning) treatment? A town is described as "single-district equivalent" — does it go through the same DistrictSkeleton generation path, or is it a simplified code path?	2 → 3	Implementation scope

---

Summary: What This Document Is Asking For

The planet-down cascade is architecturally elegant. Four layers, clean dependencies, clear deliverables. The systems design questions above are not blockers to the vision — they are the specific implementation decisions that will determine whether each layer actually creates interesting player choices.

The brief that comes out of this round needs to make these things explicit:

1. The determinism boundary at each layer — exactly what seed-locks and what economics can update
2. The stored/runtime distinction for prosperity_index — baseline vs. current, two different fields
3. The "geography determines shape" question — anchor or re-derive?
4. The sub-settlement depth — which tiers get full district treatment, which get lightweight nodes
5. River resolution — regional constraint or walkable obstacle?
6. Economics-variable rendering mechanism — condition states, update triggers, caching

Everything else in Rounds 1-3 carries forward cleanly into this new framing. The 6-field economics read set works at Layer 3. The weight table works at Layer 3. The DistrictSkeleton, SeedChain, DistrictMap, ChunkData upgrade — all of it maps directly to the Layer 3/4 boundary. This workshop produced solid foundational work. The planet-down reframe doesn't invalidate it; it gives it the right context.

---

Gestalt — Round 4. Written 2026-04-30.