settled-reach/docs/workshops/generation-cascade/round-4-notes.md

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

title	description	type	status	workshop	agent	round	created
Round 4 Notes — Generation Cascade Workshop	Compiled Round 4 outputs: planet-down reframe, two governing rules, layer-by-layer requirements, ghost city effect, latent settlements, and Tyre's brief assembly	workshop	active	generation-cascade	qatux	4	2026-04-30

Generation Cascade Workshop — Round 4 Notes

Compiled by: Qatux
Source files:

• docs/workshops/generation-cascade/gestalt-round4.md
• docs/workshops/generation-cascade/paula-round4.md
• docs/workshops/generation-cascade/burnelli-sheldon-round4.md
• docs/workshops/planet-down-cascade/BRIEF.md (Tyre's assembled brief)

Scope: Requirements gathering for the planet-down cascade brief. Round 4 does not design algorithms — it frames what each layer must answer mechanically, narratively, and economically. The output is a new workshop brief, not implementation decisions.

---

Summary

Round 4 produced a reframe. The workshop entered Round 4 with a Phase 3 map (city classification, biome grid, roads, stations, wilderness) and a Phase 5 scope (district generation, chunk streaming). The lead rejected the city-outward framing and stated the correct ordering: planet-down. Civilization is layered onto the natural world. The player enters at the bottom of the stack and reads upward.

Gestalt provided two governing rules that become the architectural spine of all future implementation decisions. Paula provided a narrative rationale for the reframe and resolved the last major Round 3 disagreement (OQ-R3-1: TerritorialStatus is a Layer 2 post-processing output, not a dedicated layer). Burnelli-Sheldon confirmed where economics enters each layer and introduced the latent settlement principle. Tyre assembled all Round 4 material into a new workshop brief (docs/workshops/planet-down-cascade/BRIEF.md), converting resolved decisions into Given Facts and surfacing the remaining open questions into structured workshop sections.

Round 3 open questions OQ-R3-1 through OQ-R3-4 were resolved by the planet-down reframe or by participant convergence during Round 4.

---

Out-of-Scope Flags

1. No Phase 5 tile generation crept back in. All four participants maintained the clean Phase 3/Phase 5 boundary from Round 3. Gestalt explicitly notes that the LoD zoom-in cascade is an architectural description of runtime behavior, not new Phase 5 scope.

2. Named city overrides are noted but not designed. Paula flags that named cities may need political_archetype_override, prosperity_override, and landmark names. This is deferred to workshop participants in the next brief's sections — the scope is noted, not designed here.

3. Sub-settlement tier exhaustiveness is not resolved. The sub-settlement hierarchy (city / town / outpost / waypoint / rural cluster / ruin) is confirmed from Round 3 consensus. How deep each tier goes through district skeleton generation (OQ-R4-G6) is explicitly an open question carried forward.

---

The Planet-Down Reframe

Why the reframe

Rounds 1-3 audited an existing implementation (Phase 5 tile generation, chunk streaming, DistrictSkeleton) and then designed Phase 3 to feed it. This was city-outward: start from what exists inside a city and work backwards to what the world needs to provide.

The lead identified this as the wrong causal direction. The world exists before civilization. Civilization is layered onto it. The player enters at the bottom of that stack and reads upward. The city-outward audit was not wrong — its findings (DistrictSkeleton, SeedChain, CityGenerationContext, all Round 2 D-records) are valid and carry forward. But the framing that organized those findings is replaced.

The four-layer model

Layer	What it is
1. Empty World	Heightmap → water simulation → sub-biome refinement. Complete natural world, no civilization
2. Population Overlay	Economics onto geography. Settlements anchor at geographic nexus points. Farmland, roads, sub-settlements
3. City-Level Planning	Districts, suburbs, industrial zones, ports, stations. The "Cities Skylines" layer
4. Street-Level Rendering	Streets, buildings, walkable tiles. On demand as the player moves

Each layer's output is the next layer's input. The layers are causal, not taxonomic.

---

The Two Governing Rules

Gestalt identifies two rules as the architectural spine. Every system design question reduces to: does this belong in seed-locked layout, or economics-variable rendering?

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.

Layer	Seed-locked (generated once, never changes)	Economics-variable (runtime updates)
1 — Empty World	Heightmap, river network, biome grid, pass locations	Nothing — terrain is fixed
2 — Population	Settlement positions, road topology, sub-settlement placement, PoliticalTether	Road condition (edge case: abandoned roads degrade further)
3 — City Planning	District positions, district types, block grid, prosperity_baseline, perimeter_treatment	prosperity_current (rolling sim update); building availability
4 — Street-Level	Street positions, building footprints, door positions, all tile layout	Tile condition states (Intact/Worn/Cracked/Broken); building activity signals

The felled-forests exception: "Felled forests → farmland" is regional land-use (Layer 2, coarse biome-cell resolution), not city-internal tile mutation (Layer 4). Regional land-use CAN update as economics shifts. City-internal street and building geometry is permanently seed-locked.

LOD/ZOOM 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. The cascade is lazy — only what the player needs is computed.

Planet in systems.db (Layers 1+2 data committed)
  │
  ├── Player within planet rendering range?
  │   → Regional biome overlay activates 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 per 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+)

Cities outside player range have no DistrictMap in memory — only their CityGenerationContext loaded from systems.db at startup.

---

Gestalt — Systems Requirements by Layer

Layer 1: Empty World

What this layer must produce beyond the existing heightmap and 64×32 biome grid:

• Sub-biome variant tag per regional cell (3-4 variants per biome class: e.g., tropical → jungle_clearing, swamp, riverine_forest, lowland_marsh)
• terrain_modification_cost: f32 per regional cell — how much effort is required to settle here (high cost = forest/hills; low cost = plains/coast)
• River network at regional resolution: confluence points, river mouths (these are settlement attractors for Layer 2)
• Terrain roughness signals at regional resolution: pass locations through mountain ranges, traversable vs. impassable zones

Game-mechanical value: The Empty World is the legibility layer. A 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. Forced routes, natural shelter, risk gradient — all derivable from terrain before civilization exists.

Open questions (OQ-R4-G1, OQ-R4-G5):

• What is stored vs. seed-derived for Empty World data? River confluence points (Layer 2 settlement attractors) must be stored or deterministically queryable before Layer 2 runs. Full river course may be seed-derived.
• At what tile-resolution do rivers appear in walkable generation? If rivers are walkable obstacles (Phase 5), the Phase 2 tile generator needs tile-precision courses. If they're regional navigation constraints only, the 64×32 grid suffices. This is a cross-layer scope question.

Minimum viable Layer 1:

• sub_biome_variant column on atlas_regional_biomes
• terrain_modification_cost column on atlas_regional_biomes
• River confluence points stored as point features (new atlas_geographic_features table)
• Mountain pass candidate cells tagged
• Geographic feature tags (Paula's taxonomy — see below) attached to regional cells
• Defer: tile-resolution river routing, exact lake polygons, authored river vs. generated network reconciliation

Layer 2: Population Overlay

What this layer produces:

• land_use on all regional cells (Urban / Agricultural / Industrial / Wilderness / Corridor / Ruins / Ocean / Impassable)
• Sub-settlement positions (all latent dynamic settlements placed, seed-derived)
• Road graph with MaintenanceAuthority per edge
• TerritorialStatus per regional cell (post-processing output — see Paula below)
• political_archetype per city (derived from geographic trigger + economic data)
• FoundingOrientation per city (derived from geographic trigger)
• PoliticalTether per sub-city settlement

Game-mechanical value: Population Overlay is where the world becomes a problem space. Settlement network topology creates the player's opportunity map. Underserved routes (two settlements, no direct road), extraction hubs (mining camps orbiting a tether city at increasing distance), abandoned corridors (roads leading to ruins) — all generated from absence or presence of infrastructure without authored content.

Open questions (OQ-R4-G1, OQ-R4-G6):

• Does "geography determines shape" mean city positions in markers.json are re-evaluated by Layer 2, or stay fixed as anchors with Layer 2 explaining them? The lead's phrasing ("anchored by wiki population counts and markers.json") implies anchored, but this must be confirmed. This determines whether generate_regional.py can write back to markers.json or only extends systems.db.
• What is the exact sub-settlement placement algorithm for mining camps, trade waypoints, agricultural nodes?
• Sub-settlement tiers: does a Town (1,000-10,000 population, single-district equivalent) go through the same DistrictSkeleton generation path as a city district, or does it get a simplified code path?

Minimum viable Layer 2:

• land_use column on all regional cells
• Mining camps + trade waypoints (highest-frequency sub-settlements)
• Road graph with MaintenanceAuthority per edge
• TerritorialStatus per regional cell
• political_archetype per city (derived, override column)
• FoundingOrientation per city (derived from geographic trigger)
• Defer: exact agricultural node positions, shadow node placement

Layer 3: City-Level Planning

What this layer produces:

• N-district grid per city (positions in city-local sim tiles using D-C4 formula)
• DistrictSkeleton Phase 1 Stages 1-2 for each district (classification + 4×4 block grid)
• prosperity_baseline per district (seed-locked, from WorldTier + economic data)
• perimeter_treatment per district
• District spatial arrangement shaped by FoundingOrientation + political_archetype
• Prosperity gradient direction and magnitude across districts

Game-mechanical value: City legibility as player skill. A player who understands political archetypes, WorldTier patterns, and economic roles can walk up to an unfamiliar city and make accurate predictions about its internal structure before entering. CompanyTown = spine pattern; AdminCapital = center-radiating; FreePort = multiple nodes. These are consistent, generatable, and learnable by the player.

Open questions (OQ-R4-G3, OQ-R4-G4):

• prosperity_index naming: the Round 3 field must be renamed to prosperity_baseline (seed-locked Layer 3 output) as distinct from prosperity_current (runtime simulation state). These must never be conflated. Tyre's brief implements this naming.
• Does FoundingOrientation modify the district placement grid (spatial rotation/alignment), or only modify the prosperity gradient direction without changing grid positions? Explicit spatial orientation produces more legible cities; gradient-only is simpler.
• Does City-Level Planning produce explicit arterial road layout, or are district boundaries the implicit road network?
• Does Layer 3 receive topographic constraints per district, or does it treat all cities as flat for the minimum slice?

Minimum viable Layer 3:

• Phase 1 Stage 1: classification per district (DistrictType from weight table, LayoutMode, prosperity_baseline, perimeter_treatment)
• Phase 1 Stage 2: 4×4 BlockSkeleton grid
• political_archetype consumed from systems.db (Layer 2 output)
• Defer: FoundingOrientation spatial grid orientation, explicit arterials, topographic constraints per district, Stages 3-5

Layer 4: Street-Level Rendering

What this layer produces:

• 64×64 TileEntry grids (GeneratorChunkData) per chunk, on demand
• 3 canonical tile types: floor_street, floor_interior, wall
• Tile condition state per tile: Intact | Worn | Cracked | Broken (economics-variable, not seed-locked)
• Building footprints with door positions (door-per-edge boundary)

Game-mechanical value: Street level is where the player has physical presence. Seed-locked layout means cities reward familiarity — return visits operate on remembered spatial knowledge rather than re-exploring unfamiliar territory. Economics-variable tile conditions create observable history: a district in decline shows accumulating decay tiles; a developing district shows repair states.

Open questions (OQ-R4-G2, OQ-R4-G6 partial):

• How exactly does economics-variable rendering work? Three options: bake at generation + update on event; compute live from prosperity_current each frame; cache per chunk, invalidate on threshold crossing. The brief must specify: mechanism, update trigger, caching model.
• What triggers interior tile generation? Pre-generate when player approaches door threshold (avoids stall, wastes compute); generate on door crossing (simplest); pre-generate with exterior (memory cost).
• Does "scatter civilization" include prop spawn points, surface decals, entity spawn points? Layer 4 scope vs. runtime entity system must be defined.

Minimum viable Layer 4:

• 3 tile types generating walkable, navigable space
• Seed-locked layout from district_seed via FNV-1a
• Chunk streaming hookup: load_chunk() calls tile generation via DistrictMap
• Defer: tile condition overlays, building interior generation, prop/decal scatter

Gestalt Open Questions Summary

ID	Layer	Question	Stakes
OQ-R4-G1	2	City positions in markers.json: anchored with geographic explanation, or re-derived from attractors?	Architecture — determines whether generate_regional.py can write back to markers.json
OQ-R4-G2	4	Economics-variable rendering mechanism: bake, live, or threshold-cached?	Implementation — determines tile condition system architecture
OQ-R4-G3	3+4	prosperity_index naming: prosperity_baseline (stored, seed-locked) vs. prosperity_current (runtime sim state) — two distinct fields, must not be conflated	Data model
OQ-R4-G4	3	Explicit arterial road layout vs. district boundaries as implicit streets	Scope
OQ-R4-G5	1→4	River resolution: regional constraint only, or walkable tile-level obstacle?	Cross-layer scope
OQ-R4-G6	2→3	Sub-settlement tiers: unified DistrictSkeleton path, or simplified code path for Towns?	Implementation scope

---

Paula — "Geography Is Political History"

The narrative framing

"Cities don't create geography. Geography creates cities — and then political structures grow to control what geography made valuable."

The planet-down cascade corrects causality for narrative purposes. In the city-outward framing, geographic logic had to be inferred backwards from settlement positions. In the planet-down framing, geographic logic comes first. Settlement character is immediately legible from founding conditions because the generator doesn't need to be told what a pass city is administratively oriented toward — the geography tells it.

Layer 1: Geographic feature tags

Paula establishes that Layer 1 must produce a tagged geographic feature layer for Layer 2 settlement placement to work without re-deriving everything from raw heightmap data.

Mandatory tags for narrative-legible settlement generation:

Tag	What it marks	Political potential
RiverConfluence	Where two navigable rivers meet	Trading nexus; FreePort or AdminCapital archetype
CoastalHarbor	Natural harbor, protected anchorage	Maritime commerce; FreePort archetype
MountainPass	Lowest crossing point in a range	Checkpoint/control; AdminCapital or Contested
ArablePlain	Flat land with soil quality above threshold	Agricultural settlement; dependent on nearest nexus
ResourceConcentration	Mineral outcrop, energy source, rare material	Extraction; CompanyTown archetype
Defensible	Elevated with sightlines, natural chokepoint	Military/administrative; AdminCapital
NaturalBarrier	Range, wide river, dense terrain	Future political boundary

Layer 1 does not name anything. Rivers, mountains, and passes exist but have no names. Geographic names are first assigned at Layer 2 when settlement begins. Major atlas-visible terrain features may receive geographic placeholder names at Layer 1 for atlas UI labeling.

Layer 2: TerritorialStatus as post-processing output (resolves OQ-R3-1)

Paula settles the Round 3 disagreement definitively:

"TerritorialStatus doesn't need its own dedicated layer — it is a post-processing output of the settlement placement and road generation steps that already exist in Layer 2."

The six values are derived after settlement placement completes:

Value	Derivation
CoreTerritory	High settlement density + road network well-maintained throughout
FrontierTerritory	Settlements placed + roads thin at distance from major city
ExtractiveZone	Settlement at ResourceConcentration + corporate presence + excellent extraction corridor + absent off-corridor
ContestZone	Two settlement clusters with competing road networks in overlapping territory
WildernessBuffer	No settlement placed — no geographic trigger or economics rationale
AbandonedZone	Settlement placed (geographic rationale existed at generation time), but economic basis exhausted

This resolves OQ-R3-1. TerritorialStatus is a post-processing classification pass at Layer 2 — it costs one classification step after settlement placement, not a dedicated layer. The Gestalt/Tyre Layer D debate is closed.

Layer 2: FoundingOrientation is geography, not authoring

FoundingOrientation is directly readable from the geographic trigger:

Layer 2 trigger	FoundingOrientation
CoastalHarbor or RiverConfluence with port	PortFacing
Transit/rail junction	RailHeadFacing
ResourceConcentration	ResourceFacing
Defensible terrain	DefenseFacing
No geographic trigger (AdminCapital placed by political decision)	AdminFacing

No authoring pass required. The exception: named cities where setting lore explicitly overrides the geographic logic.

Layer 2: Road networks and MaintenanceAuthority

MaintenanceAuthority falls directly from road endpoint relationships at road generation time — no separate authored pass required:

• Corporate extraction site → corporate depot: Corporate
• Administrative capital → administered sub-settlement: Administrative
• Settlement cluster with trade flow but no administrative relationship: Trade
• Settlement → settlement with no economic or administrative tie: Communal
• Connection whose rationale has since dissolved: Abandoned

This resolves OQ-R3-4 — MaintenanceAuthority is derivable at generation time without a separate schema decision beyond adding the column.

Layer 3: FoundingOrientation shapes spatial direction

FoundingOrientation + political_archetype determines which direction the city grows and which end is oldest:

• PortFacing + FreePort: older districts near water, newer development inland
• ResourceFacing + CompanyTown: city is a spine, not a circle; the resource is at one end
• DefenseFacing + AdminCapital: city radiates from the fortified high point
• No trigger + OrganicGrowth: city grew around multiple centers; no single direction is oldest

The prosperity gradient runs from founding end toward expansion end: oldest districts (closest to founding geography) are most organic, lowest-prosperity; newest development (expansion end) is planned, higher-prosperity. This is a district placement rule, not a separate computation.

The Ghost City Effect and prosperity_delta

Paula identifies the most powerful narrative consequence of the Determinism Rule:

"A district's current state and its intended state are always both visible."

The two-field architecture:

• prosperity_baseline: f32 — seed-locked Layer 3 output. What the district was planned as. Stored in CityGenerationContext and atlas tables.
• prosperity_current: f32 (or prosperity_delta: f32 = prosperity_current - prosperity_baseline) — runtime simulation state. What current economic health says.
• Effective prosperity = prosperity_baseline + prosperity_delta (clamped to [0.0, 1.0]). Drives tile selection.

The narrative: When these diverge significantly, the player is looking at the ghost city effect. A CompanyTown where the corporation has departed still has company-town street vocabulary (wide factory roads, tight worker housing grids, no civic center). Streets broadcast what the district was planned to be. Tile decay broadcasts that no one is maintaining that plan. The gap is the story, without a word of dialogue.

This is not a technical refinement. If prosperity_baseline is just a sim-updated value with no seed-derived component, the ghost city effect disappears.

Ruins as structural permanence

When the economic sim flags a settlement for ruination (resource depleted, corporation departed, route obsoleted), the physical structure remains — streets, building footprints, cleared ground. What changes:

• prosperity_delta drops sharply
• perimeter_treatment degrades (Checkpoint → Fenced → Open)
• Landmark condition deteriorates

The ruin is a ghost city at settlement scale. The geography tagged it as worth settling. Someone built there. Now no one maintains it. The gap between structure (still present) and tile state (decayed) is the full story.

Accepted proposals remapped to planet-down layers

Proposal	Origin	Planet-down position
prosperity_baseline: f32 on DistrictSkeleton	Round 2 (as prosperity_index)	Layer 3 output (seed-locked baseline); economic sim produces prosperity_current at runtime
perimeter_treatment: PerimeterTreatment	Round 2	Layer 3 output (derived from DistrictType + WorldTier + prosperity_baseline at generation time)
political_archetype (derived + override)	Round 2	Layer 2 output (derived from geographic trigger + economic data; override slot for named cities)
Naming registers (lookup table)	Round 2	Layers 2-4: geographic register at Layer 2, functional/commemorative at Layer 3, street names at Layer 4
Sub-settlement hierarchy	Round 3	Layer 2 output (settlements from geographic triggers; PoliticalTether from why they exist)
MaintenanceAuthority on roads	Round 3	Layer 2 output (from road endpoint relationships; no separate pass)
TerritorialStatus	Round 3	Layer 2 post-processing output (after settlement placement completes)
FoundingOrientation	Round 3	Layer 2 → Layer 3 handoff (directly from geographic trigger)
DualNaming	Round 3	Layer 2 initialization (ContestZone conditions) → Layer 3 proliferation → Layer 4 display

---

Burnelli-Sheldon — Economics Integration

Where economics enters

Layer 1: Weakly (optional biome probability prior)

Economics does not shape terrain geometry. But a body's economic_role is the outcome of someone deciding the terrain was worth exploiting. This creates a plausibility constraint: an agricultural world had to have arable soil. Burnelli-Sheldon proposes using bodies.economic_role + bodies.planet_class as a soft biome probability prior in sub-biome refinement. This is optional — planet_class may encode this well enough already. The risk of excluding it is self-contradictory worlds (agricultural role on volcanic terrain).

Layer 2: In full (primary economics entry point)

The atlas_cities, bodies, corp_presence, atlas_roads, atlas_railroads, and system_economy tables all enter at Layer 2. Economic role determines hinterland character:

economic_role	Hinterland fill
agricultural	Cleared farmland, irrigation networks, processing nodes
extraction	Access corridors, mining infrastructure, stockpile areas
manufacturing	Industrial fringe, rail freight yards, supply zones
transit	Dense road/rail, relay stations, fuel depots
research	Exclusion zones, observatory sites, quiet buffer
service_mixed	Suburban residential spread, civic infrastructure

The latent settlement principle

Under the Determinism Rule, settlement positions must be seed-locked at generation time. But economic conditions change. The reconciliation:

The generator places ALL economically plausible settlement positions at Layer 2 generation time. Whether each settlement is ACTIVE is determined by the economic simulation's rolling state. An inactive settlement exists spatially — as ruins, empty structures, cleared ground — but it is dark, unmaintained, and depopulated.

This is economically accurate. Ghost towns exist. The buildings are there; no one lives in them. The road to the closed mine still exists.

Per settlement type:

• Mining camps: Placed at Layer 2 from corp_presence trigger conditions. Active when corp_financial_state.health_metric > 0.4 for the operating corp. The geological deposit doesn't move when the corp fails.
• Trade route waypoints: Long roads (atlas_roads with point_count > 5) get a seed-derived waypoint at the geometric midpoint. Active when the terminal system remains connected. Even abandoned trade routes leave ruins.
• Agricultural dispersed nodes: settlement_pattern IN ('dispersed', 'dispersed_rural') AND economic_role = 'agricultural' → farm cluster positions at interval derived from 1/economic_tier. Active by corp health. Fallow farms differ from ghost towns: cleared land, overgrown structures, but clearing and track remain.
• Shadow economy nodes: collection_efficiency < 0.6 → one informal settlement adjacent to the largest atlas city. Active/character changes if enforcement conditions change.

Prosperity as render parameter, not tile mutation

The most important implication of the Determinism split:

prosperity_index (now prosperity_baseline/prosperity_current) should NOT be implemented as tile-level ChunkMutations for routine decay. It is a single float per district. The renderer reads it and applies a decay probability to tile selection.

When prosperity_current drops from 0.6 to 0.3: streets don't change, building footprints don't change — only the tile SELECTION changes (cracked pavement variant, boarded windows, rust on facades). This happens purely in the rendering path, with no world mutation. ChunkMutations remain reserved for player-caused or explicit-event damage.

This distinction matters for performance: prosperity changes don't generate millions of tile mutations.

Per-layer economic field mappings

Layer 1:

Field	Source	Usage
economic_role	bodies	Biome probability prior (optional)
planet_class, atmosphere, surface_gravity	bodies	Primary physical inputs

Layer 2 (full list):

Field	Source	Usage
City positions, populations, kinds	atlas_cities	Settlement anchors
economic_role, settlement_pattern, industrial_corridor, population	bodies	Hinterland character
economic_tier, economic_base_primary/secondary	system_economy	Infrastructure density
gate_connections, gate_topology	system_gates	Trade route intensity
corp_id, location_id, primary_operation, behavioral_archetype	corp_presence + corporations	Corporate cluster positions
Road/rail entries	atlas_roads, atlas_railroads	Existing infrastructure
collection_efficiency	system_fiscal	Shadow node trigger
health_metric	corp_financial_state	Settlement active/ghost at generation time

Layer 3: The 10×9 matrix applies here, modified by topographic constraints from Layer 1 and infrastructure access from Layer 2. Matrix provides zoning prior; terrain provides spatial constraints. Key additions: distribution_index sets prosperity gradient magnitude; FoundingOrientation (from Layer 2) sets gradient direction.

Layer 4 at generation time:

Field	Source	Usage
bulk_class	commodities via corp_presence	Building archetype
base_premium_multiplier	brand_products	Landmark building height
prosperity_baseline	Per-district Layer 3 output	Initial tile variant selection

Layer 4 at runtime (no tile mutation):

Signal	Source	Render effect
prosperity_current (updated by sim)	Economic simulation	Tile variant selection
corp_financial_state.health_metric	Economic simulation	Corporate signage presence
Active/ghost settlement status	Economic simulation	Lighting, population density rendering

Data quality issues (blockers before Layer 3)

1. behavioral_archetype is mostly NULL on corporation rows. Fallback chain: behavioral_archetype → supply_chain_role → commodity tier from primary_operation. A backfill step in import_economics.py should fill NULL values before generate_regional.py runs.

2. scope field is mixed-type text (enum-ish strings + prose descriptions). Generator cannot reliably parse prose. Until normalized, treat any non-matching value as system-tier.

Burnelli-Sheldon Open Questions

ID	Question	Recommended answer
OQ-R4-B1	Where does the settlement active/ghost flag live?	In a systems.db Phase 3 output table (settlement positions + trigger conditions). Sim reads these alongside corp_financial_state.
OQ-R4-B2	Does "felled forests → farmland" generate ChunkMutations?	No — it's a regional_land_use column update at biome-cell resolution, not tile mutation. Different resolution from Layer 4.
OQ-R4-B3	prosperity_baseline at district-level or block-level?	Per-district scalar for now (consistent with Phase 5 architecture). Can migrate to BlockSkeleton in a later pass if too coarse.
OQ-R4-B4	How does distribution_index = stratified interact with topography?	Topography sets gradient DIRECTION (which end is high-prosperity); distribution_index sets gradient MAGNITUDE (how steep).

---

Tyre — Planet-Down Cascade Brief Assembly

What Tyre's brief does

Tyre assembled all Round 4 material into docs/workshops/planet-down-cascade/BRIEF.md. This brief is the output of the generation-cascade workshop and the input to the next workshop. It has three components:

1. The Lead's Cascade Vision — reproduced verbatim (four layers + two critical rules)
2. Given Facts — all decisions from Rounds 1-4 that are locked and must not be revisited
3. Workshop Sections — the open questions that the next workshop must resolve

What became Given Facts

The brief treats the following as locked:

• Phase 3 = Python tooling + systems.db; Phase 5 = Rust runtime + seed-derived; fully parallelizable
• generate_regional.py as the third pipeline generator (runs after generate_atlas.py in make regen-db)
• Atlas markers are the last stored layer; everything from Layer 3 down is seed-derived
• No markers.json extension — city attributes via systems.db cross-reference on body_id
• Atlas coordinates are UI-only (no pixel-to-sim-tile formula)
• FNV-1a SeedChain (D-010, D-C6)
• CityGenerationContext struct with prosperity_baseline field name (replaces prosperity_index — implements OQ-R4-G3)
• City decomposition formula (D-C4)
• District Skeleton Phase 1 Stages 1-2 minimum
• WorldTier enum (corrected to Epicenter | Regional | Backwater | Passage | Waypoint)
• GeneratorChunkData upgrade to Vec<TileEntry> (D-C7)
• 6-field minimum read set (D-C9) and 10×9 weight table (D-C10)
• Sub-settlement hierarchy and placement triggers (Round 3 consensus)
• Latent settlement principle (Burnelli-Sheldon Round 4)
• Determinism boundary table per layer
• LoD zoom-in cascade

The CityGenerationContext update

The brief's canonical struct resolves OQ-R4-G3 (naming question) and OQ-R3-2 (FoundingOrientation scope):

pub struct CityGenerationContext {
    pub city_id: String,
    pub political_archetype: PoliticalArchetype,
    pub prosperity_baseline: f32,        // seed-locked Layer 3 output — NOT prosperity_index
    pub surrounding_biome: BiomeClass,
    pub road_entry_directions: Vec<CardinalDirection>,
    pub footprint_radius_km: f32,
    pub founding_orientation: FoundingOrientation,  // now included (OQ-R3-2 resolved)
    pub world_tier: WorldTier,
}

prosperity_current: f32 is a separate runtime simulation field. These two must never be conflated in implementation.

What became open questions in the new brief

The brief surfaces the remaining unresolved questions as structured workshop sections with specific question IDs:

• L1-Q1 through L1-Q4: Layer 1 — authored rivers vs. drainage network, resolution, stored vs. derived, biome prior
• L2-Q1 through L2-Q6: Layer 2 — anchor vs. re-derive positions, sub-settlement placement algorithm, road generation algorithm, hinterland shapes, TerritorialStatus quantitative thresholds, latent flag storage
• L3-Q1 through L3-Q7: Layer 3 — FoundingOrientation spatial effect, political_archetype spatial arrangement, arterial roads, topographic constraints, prosperity_baseline formula, sub-settlement code path, port/station direction
• L4-Q1 through L4-Q6: Layer 4 — economics rendering mechanism, condition update trigger, tile algorithm parameters, interior generation trigger, "scatter civilization" scope, prosperity_delta two-field architecture
• CL-Q1 through CL-Q4: Cross-layer — prosperity naming confirmation, regional land-use evolution, ruin lifecycle, authored rivers vs. drainage network (elevated)

---

Round 3 Open Questions Resolved by Round 4

Round 3 OQ	Question	Resolution	Source
OQ-R3-1	TerritorialStatus: dedicated Phase 3 layer or absent?	Layer 2 post-processing output. One classification pass after settlement placement + road generation. Not a dedicated layer.	Paula Round 4
OQ-R3-2	FoundingOrientation: include in Phase 3 Layer A + CityGenerationContext?	Yes. Directly readable from geographic trigger. In CityGenerationContext.	Paula/Tyre Round 4
OQ-R3-3	Sub-settlement hierarchy: include atlas_sub_settlements table in Phase 3?	Included as lead inclusion (confirmed by brief Given Facts). Sub-settlements are part of Layer 2 output.	Tyre's brief
OQ-R3-4	MaintenanceAuthority on atlas_road_edges: include?	Yes. Derivable from road endpoint relationships at generation time.	Paula Round 4

---

Open Questions Carried Forward

These feed directly into the planet-down-cascade workshop brief:

Must be resolved before Layer 1 can be implemented:

• OQ-R4-G5 / L1-Q1: Authored rivers vs. seeded drainage network — relationship and reconciliation
• L1-Q2: River network resolution (regional-only or intermediate)
• L1-Q3: Stored vs. derived for river network data

Must be resolved before Layer 2 can be implemented:

• OQ-R4-G1 / L2-Q1: City positions — anchored (generate_regional.py explains geography) vs. re-derived from attractors
• L2-Q5: TerritorialStatus quantitative derivation thresholds
• OQ-R4-B1 / L2-Q6: Latent settlement active/ghost flag storage location

Must be resolved before Layer 3 can be implemented:

• OQ-R4-G3 / CL-Q1: prosperity_baseline vs. prosperity_current naming — confirmed in brief; must be enforced in implementation
• L3-Q1: FoundingOrientation spatial grid orientation vs. gradient-only modification
• L3-Q2: political_archetype spatial arrangement — explicit vs. emergent

Must be resolved before Layer 4 can be implemented:

• OQ-R4-G2 / L4-Q1: Economics-variable rendering mechanism (bake/live/threshold-cached)
• OQ-R4-B2 / CL-Q2: Regional land-use evolution resolution boundary — runtime regional_land_use update vs. ChunkMutations
• L4-Q6 / CL-Q1: prosperity_delta two-field architecture — formal adoption

---

Notes compiled by Qatux from Round 4 source files. All positions attributed to source participant. No editorial opinions added.