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

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

title	description	type	status	workshop	agent	round	created
Gestalt — Round 3: Phase 3 Spatial Pipeline Systems Design	Phase 3 layer map, economics bridge, LoD cascade, interesting-decisions analysis, and ticket dependency graph for the regional-to-city layer	workshop	active	generation-cascade	gestalt	3	2026-04-30

Generation Cascade — Round 3 (Gestalt)

Focus: Phase 3 systems design — the layer between atlas output (city dots on heightmaps) and Phase 5 tile generation. What sits here, how the layers interact, which economics data drives which spatial decisions, where the LoD cuts are, and what creates interesting player choices at the regional scale.

Given facts from Rounds 1-2 (not revisited):

• WorldTier enum: Epicenter / Regional / Backwater / Passage / Waypoint
• Seed boundary: atlas markers are the last stored layer; everything below is seed-derived
• No markers.json extension — cross-reference systems.db bodies table
• Atlas coordinates are UI-only; walkable world uses city-local coords
• Phase 1 DistrictSkeleton minimum = Stages 1-2 only
• prosperity_index and perimeter_treatment are INCLUDED in DistrictSkeleton before Phase 2
• political_archetype is a formal field in atlas_cities, derived by default, authored override allowed
• Heritage grammar, NPC population, social sites — all out of scope

Building on this round's peers:

• Tyre (Round 3) designed the technical layers and algorithms. I treat those as settled where they overlap with my analysis and add the systems view on top.
• Paula (Round 3) designed the political signals and settlement hierarchy. I'm treating those proposals as strong candidates and mapping them to the generation input/output model.

---

1. The Phase 3 Layer Map

Let me be clear about what Phase 3 is mechanically: it is a tooling phase that enriches systems.db. Every Phase 3 output is committed offline by generate_regional.py. The Rust server reads it at startup; no Phase 3 computation runs at game time.

The layers form a dependency graph. Here is the full picture with inputs, outputs, and what consumes each output:

Layer A — City Classification and Footprint

Inputs:

• bodies table: settlement_pattern, economic_role, planet_class, world_tier
• atlas_cities table: population, kind
• Economics tables: corporation presence by body, trade flow intensity

Outputs (new columns on atlas_cities):

• footprint_radius_km: REAL — physical extent; derived from population × density formula
• political_archetype: TEXT — CompanyTown | AdminCapital | FreePort | Contested | OrganicGrowth
• prosperity_index: REAL — 0.0–1.0 baseline prosperity for this city; district-level values derived from this
• founding_orientation: TEXT — PortFacing | RailHeadFacing | ResourceFacing | DefenseFacing | AdminFacing
• political_archetype_override: TEXT — NULL = always derived; non-NULL = wiki-authored value

Consumed by:

• Layer C (road graph — cities are nodes)
• Layer D (territorial status — city WorldTier is an input)
• Layer F (wilderness annotation — city footprints mark urban cells)
• Phase 5 district skeleton — via CityGenerationContext struct
• Phase 3 Atlas UI — displays footprint circles and archetype icons

No dependencies. Runs first.

---

Layer B — Regional Biome Grid

Inputs:

• Planet simulation terrain output: biome grid (512×256), elevation, moisture, surface_water

Outputs (new table atlas_regional_biomes):

• 64×32 cells per body: biome_class, mean_elevation, mean_moisture, terrain_roughness, is_coastal, water_fraction
• Later augmented with land_use (Layer F) and territorial_status (Layer D)

Consumed by:

• Layer D (TerritorialStatus — biome class + proximity drives zone type)
• Layer F (wilderness annotation — land use derived from biome + urban proximity)
• Phase 5 district skeleton — biome context at city position informs surrounding district types

Dependencies: planet_simulation terrain data (already in memory during generate_atlas.py). Can run in the same pipeline pass. Technically parallel with Layer A.

---

Layer C — Road Network Graph

Inputs:

• City positions (Layer A outputs or atlas_cities directly)
• atlas_roads and atlas_railroads: pixel-path road data
• Economics tables: corporation presence, trade flow intensity

Outputs:

• atlas_road_nodes table: city nodes + junction nodes with grid position
• atlas_road_edges table: segments with kind, distance_px, maintenance_authority
• road_entry_directions: Vec<CardinalDirection> per city — which edges roads enter from

MaintenanceAuthority derivation rule (Paula's proposal, mapped to economics inputs):

Road endpoint types	Economics condition	→ MaintenanceAuthority
City ↔ City	admin road in atlas	Administrative
Corporate asset ↔ Corporate asset	same corporation in econ data	Corporate
City ↔ Sub-settlement	settlement prosperity-tracked	Communal
Any ↔ Any	high trade flow in econ data	Trade
Any ↔ Abandoned marker	no active tether	Abandoned

Consumed by:

• Layer D (TerritorialStatus — road corridors affect zone boundaries)
• Layer F (wilderness — cells adjacent to roads get Corridor land use)
• Phase 5 district skeleton — road_entry_directions drives access point placement
• Phase 3 Atlas UI — renders road graph as connectivity overlay

Dependencies: Layer A (need city node list to snap road endpoints).

---

Layer D — TerritorialStatus Zones

Inputs:

• Layer A outputs: city positions, WorldTier, political_archetype
• Layer B outputs: biome grid (terrain roughness affects zone boundaries)
• Layer C outputs: road graph (roads extend administrative reach)
• Economics: corporation asset locations, territory claims

Outputs:

• territorial_status: TEXT added to atlas_regional_biomes cells: CoreTerritory | FrontierTerritory | ExtractiveZone | ContestZone | WildernessBuffer | AbandonedZone

Derivation algorithm (systems design view):

For each regional cell, score against multiple signals:

base_status = WildernessBuffer  (default)

FOR each city C within range:
  influence = C.world_tier_weight / distance_to_cell
  if influence > FRONTIER_THRESHOLD:
    base_status = FrontierTerritory
  if influence > CORE_THRESHOLD:
    base_status = CoreTerritory

IF any corporation has an active extraction node in this cell:
  base_status = ExtractiveZone (overrides Frontier but not Core)

IF two cities with conflicting political archetypes both influence this cell:
  base_status = ContestZone

IF cell was once CoreTerritory (historical) but city tether is Abandoned:
  base_status = AbandonedZone

WorldTier weights: Epicenter → 5x; Regional → 3x; Backwater → 1x; Passage → 1.5x; Waypoint → 0.5x.

Consumed by:

• Layer F (wilderness annotation — TerritorialStatus determines settlement density)
• Phase 5 district skeleton — TerritorialStatus of surrounding region informs district perimeter_treatment baseline
• Phase 3 Atlas UI — renders zone overlays on regional map
• Naming system — ContestZone triggers DualNaming conditions

Dependencies: Layers A, B, C all needed.

---

Layer E — Station Module Topology

Inputs:

• Bodies with settlement_pattern = "orbital_only": economic_role, population

Outputs:

• atlas_station_modules: module list with type
• atlas_station_connections: module adjacency graph with passage type

Design note: Stations are handled as a separate code path. No biome data. No TerritorialStatus. The station's module topology is its "regional map" — it tells Phase 5 what zones to generate when a player enters the station. The AdminCore is always the hub; passage types (Pressurized | Airlock | EVA | Service) are the station equivalent of road quality.

Consumed by:

• Phase 5 district skeleton — station district types match module types
• Phase 3 Atlas UI — renders station topology diagram in wiki/implant app

Dependencies: Only station body data. Parallel with Layers B–D.

---

Layer F — Wilderness, Countryside, Settlement Hierarchy

Inputs:

• Layer A: city footprints (urban cells identified)
• Layer B: biome grid (biome_class per cell)
• Layer C: road graph (corridor cells identified)
• Layer D: TerritorialStatus per cell
• Economics: corporation presence, trade routes

Outputs:

• land_use: TEXT on atlas_regional_biomes cells: Urban | Agricultural | Wilderness | Industrial | Wasteland | Ocean | Impassable | Corridor | Ruins
• New table atlas_sub_settlements: towns, outposts, waypoints placed along road corridors
  • Each has: settlement_type, population, political_tether (city_id + relationship)
• DualNaming conditions flagged per cell/feature for contested naming regions

PoliticalTether derivation (Paula's proposal, mapped to generator inputs):

Condition	→ TetherRelationship
Distance to city < threshold AND city is AdminCapital	Administered
Distance to city < threshold AND city is CompanyTown AND corp presence	Corporate
Two cities within similar distance with different archetypes	Contested
Distance to city > threshold, no corp presence	Independent
Nearest city is AbandonedZone	Abandoned

Consumed by:

• Phase 5 district skeleton — wilderness districts use land_use to determine district type
• Phase 3 Atlas UI — renders countryside zones and sub-settlement markers
• Naming system — PoliticalTether drives naming register for sub-settlements

Dependencies: Layers A, B, C, D all needed. This is the last Phase 3 layer.

---

Phase 3 Output to Phase 5: CityGenerationContext

Everything Phase 3 produces feeds into Phase 5 through this struct:

pub struct CityGenerationContext {
    pub city_id: String,
    pub political_archetype: PoliticalArchetype,
    pub founding_orientation: FoundingOrientation,
    pub prosperity_index: f32,               // city baseline; district-level derived from this
    pub surrounding_biome: BiomeClass,        // from regional grid at city position
    pub surrounding_territorial_status: TerritorialStatus, // from Layer D at city position
    pub road_entry_directions: Vec<CardinalDirection>,
    pub footprint_radius_km: f32,
    pub district_count: u8,                   // from city decomp formula (Round 2)
}

This struct is populated by reading systems.db at game startup. Phase 5 uses it as the root input for all district generation.

---

2. The Economics Bridge

Economics data in systems.db is the hidden backbone of Phase 3. The pipeline already ran the economics layer (import_economics.py) before generate_atlas.py. Phase 3 consumes that output systematically.

Here is the full economics → spatial structure mapping:

economic_role → political_archetype (direct derivation)

economic_role	→ political_archetype
corporate_extraction	CompanyTown
administrative_center	AdminCapital
transit_hub	FreePort
mixed_economy	OrganicGrowth
contested_territory	Contested

Override slot (political_archetype_override) allows wiki authors to correct counterintuitive results for named cities. The default derivation handles 90%+ of cases correctly.

Corporation footprint → spatial structure

The economics tables track which corporations operate in which systems and what their role is. This drives:

1. ExtractiveZone identification: If a corporation has an active extraction operation in a body's regional zone, that zone gets TerritorialStatus = ExtractiveZone regardless of distance from administrative cities.

2. Road MaintenanceAuthority: Roads connecting corporation assets to their logistics chain are Corporate maintained. These roads have uniform quality within the corporate footprint — which means the quality boundary at the corporation's edge is visually sharp. The generator uses this: when a corporate road ends, the next segment drops to whatever the local standard is.

3. Sub-settlement PoliticalTether: Settlements near corporate assets that depend on that corporation's operations are Corporate-tethered. If the corporation ever leaves (detectable from economic data), those settlements become candidates for AbandonedZone reclassification.

4. Landmark naming: Named landmarks in minor cities can draw their names from the controlling corporation's name in the economics database. The generator already knows which corporation controls logistics in which system. ISC controlling logistics in a system → its depot is "ISC Logistics Hub," not "Port 7."

Trade flow intensity → road quality signals

Trade flow data (which routes carry what volume) feeds into:

1. Trade-maintained roads: High-flow trade routes get MaintenanceAuthority = Trade, producing good road quality even in politically marginal regions. This creates the interesting signal Paula identified: commerce went where administration didn't bother.

2. FreePort prosperity baseline: FreePort cities have prosperity_index derived partly from trade volume. High trade flow = higher baseline. This means FreePort cities can have high-prosperity districts even in Backwater WorldTier systems — trade beats administration as a wealth engine.

3. Contested boundary identification: When two corporations with conflicting interests both have significant trade flow through the same zone, that zone is a candidate for ContestZone or elevated perimeter_treatment at district level.

The economics feedback loop at district level

The economics bridge is not one-directional. Here is the feedback path:

systems.db economics data
  → Phase 3: political_archetype, prosperity_index, territorial_status
  → Phase 5 CityGenerationContext
  → DistrictSkeleton: DistrictType distribution, prosperity_index per district
  → Phase 2 tile generation: building density, road width, decay tiles
  → Player reads: "this is a corporate extraction zone, these workers are poor,
                   there are checkpoints, the road only goes to the mine"

The player reads the spatial output of economic decisions without the economics being labeled. This is asymmetric information operating at the generation level, not just the runtime level. The world makes economic sense spatially because the generator was driven by economic inputs.

---

3. LoD Cascade — Authored ↔ Derived Spectrum

Every Phase 3 element sits somewhere on this spectrum. Here is the full map:

Fully Authored (hand-written, changes require wiki edit)

Element	Who authors	Authoring scope
Planet definitions (bodies table)	Miri	All bodies
City names	Mellanie + Miri	All named cities
political_archetype_override	Wiki authors	Named cities only, when default is wrong
prosperity_override	Wiki authors	Named cities only, when lore demands
Named landmark names in major cities	Miri	Capital cities + named stations

The authored layer is intentionally small. The system is designed so that wiki authors make high-value lore decisions, not repetitive data-entry decisions.

Derived from Authored Sources (Python tooling, committed to systems.db)

These are computed deterministically from authored inputs. They live in systems.db and can be regenerated by make regen-db:

Phase 3 Layer	Element	Derivation root
A	footprint_radius_km	population + settlement_pattern formula
A	political_archetype	economic_role mapping
A	prosperity_index (city baseline)	WorldTier + economic data + trade flow
A	founding_orientation	settlement_pattern + economic_role
B	Regional biome grid (64×32)	planet_simulation terrain downsampled
C	Road graph nodes + edges	atlas road pixel-paths snapped to cities
C	maintenance_authority per road segment	road endpoint types + economics
D	territorial_status per cell	city proximity × WorldTier + economics
E	Station module topology	economic_role + population template
F	land_use per cell	biome + city footprints + road graph + territorial_status
F	Sub-city settlement placement	road graph + economics + WorldTier
F	political_tether per sub-settlement	distance + economics derivation

This is the bulk of Phase 3. It requires no ongoing authoring effort — it regenerates correctly when sources change.

Seed-Derived (Phase 5 runtime, never stored)

Element	Why seed-derived
DistrictSkeleton (all fields)	Function of (district_seed, city_context)
District count and positions	Function of (city_data, world_seed)
Exact sub-settlement position within cell	Seeded within corridor bounds
DualNaming common_name content	Seeded from culture pool when conditions met
Wilderness interior terrain variation	Seeded below regional resolution
Building footprints within districts	Seeded from block skeleton

The LoD Cut Between Phase 3 and Phase 5

The key architectural boundary: Phase 3 describes "what kind of place is this?" Phase 5 generates "what does this place look like tile by tile?"

Phase 3 never generates walkable space. It generates classification, context, and constraints. Phase 5 reads those constraints and generates the tiles that express them. A city in ExtractiveZone + CompanyTown archetype gets districts whose types, prosperity levels, and perimeter treatments reflect that context — but the actual tile layout is Phase 5's job, seeded deterministically.

---

4. What Creates Interesting Decisions at Regional Scale

This is the design question I care most about. Let me break down what "interesting decisions" means at regional scale and what the generator must produce to support them.

The Decision Types

Route decisions: multiple paths between settlements

The player navigating a regional map faces the core traversal question: which way do I go? For this to be a meaningful choice, routes must differ in ways that matter:

Route characteristic	What the generator must produce
Speed (road quality)	MaintenanceAuthority drives quality; Corporate roads are fastest, Communal roads follow prosperity
Political exposure	TerritorialStatus zone sequence along each route
Resource availability	Sub-settlement placement along route; Corridor land use guarantees supply nodes
Risk profile	WildernessBuffer / AbandonedZone → no infrastructure safety net
Cost (implied)	Trade route vs. administrative road → different access politics

For this to work, routes must not be equivalent. The generator must produce enough settlement hierarchy and road quality variation that two paths between the same cities have meaningfully different character. Paula's MaintenanceAuthority + TerritorialStatus combination is exactly what produces this.

Settlement access decisions: what is this place?

Before entering a settlement, the player should be able to read its political character from the regional map. The signals:

• PoliticalTether = Corporate → expect corporate security, corporate pricing, corporate rules
• PoliticalTether = Independent → expect local law (or none), opportunistic pricing
• PoliticalTether = Contested → expect double-sided checkpoints, unstable rules
• PoliticalTether = Abandoned → expect no services, possibly ruins worth investigating

These signals translate to "should I stop here or push on?" decisions with real consequences.

Risk/reward: wilderness and abandoned zones

WildernessBuffer and AbandonedZone regions have no infrastructure — no shelter, no repair, no trade. But they have:

• Ruins (AbandonedZone): historical footprint worth investigating
• Resources (WildernessBuffer): unclaimed, unguarded
• Escape routes (both): off the administered grid, less visibility to authority

The regional map must make wilderness legible as a risk-reward tradeoff, not random emptiness. This requires:

1. Clear visual distinction between zone types
2. Visible road quality degradation at zone entry
3. Distance markers to nearest administered settlement

Political navigation: zone-crossing as faction exposure

A player with corporate affiliations faces scrutiny in ContestZone or government CoreTerritory. A player avoiding authorities prefers WildernessBuffer routes despite the cost. The regional map is a political exposure map, not just a physical terrain map. Different players will read it differently based on their current faction relationships.

This is asymmetric information at the generation level — the generator knows the full political geography, but the player reads it through the lens of their current situation.

Founding orientation as navigation aid

FoundingOrientation provides directional information about city structure before entering. A ResourceFacing city has its industrial district on the resource-facing edge — a player who wants to avoid industrial (or specifically seek it) can predict which part of the city to enter from. This is readable from the regional map if the city icon or approach indicates orientation.

The Decision-Supporting Minimum

For regional decisions to be interesting, the generator must produce at minimum:

1. Route variety: ≥2 meaningfully different routes between major settlements (requires road graph + MaintenanceAuthority)
2. Zone legibility: TerritorialStatus visible per regional cell on the Atlas UI
3. Settlement hierarchy: At least towns and outposts along major routes (sub-settlements in Layer F)
4. Approach legibility: FoundingOrientation and political_archetype readable before city entry

Without #1 and #2, the regional map is a lookup table, not a decision space. The player consults it to find cities but doesn't navigate it strategically.

---

5. Ticket Dependency Graph for Phase 3

New tickets required for Phase 3

The dependency chain is layered. I've marked parallelizable branches.

NEW: generate_regional.py pipeline scaffolding   [0.5d]
  │ (Makefile integration, meta stamp, pre-push hook update,
  │  --body / --force / --dry-run flags, generator_sha tracking)
  │
  ├──▶ [A] City classification + footprint        [1.5d]
  │     (footprint_radius_km, political_archetype, founding_orientation,
  │      prosperity_index, override columns on atlas_cities)
  │     │
  │     ├──▶ [C] Road network graph               [1d]
  │     │     (atlas_road_nodes + atlas_road_edges tables,
  │     │      snap-to-city, distance, maintenance_authority)
  │     │     │
  │     │     ├──▶ [D] TerritorialStatus zones     [1d]
  │     │     │     (formula: proximity × WorldTier + econ;
  │     │     │      territorial_status column on atlas_regional_biomes)
  │     │     │     │
  │     │     │     └──▶ [F] Wilderness + settlement hierarchy  [1.5d]
  │     │     │            (land_use column, atlas_sub_settlements table,
  │     │     │             PoliticalTether derivation,
  │     │     │             DualNaming conditions)
  │     │     │                │
  │     │     │                └──▶ CityGenerationContext Rust struct  [0.5d]
  │     │     │                       (read-path only; queries all Phase 3 tables
  │     │     │                        from systems.db at game startup)
  │     │     │                             │
  │     │     │                             └──▶ Phase 5 wiring         [0.5d]
  │     │     │                                    (wire CityGenerationContext
  │     │     │                                     into DistrictSkeleton Stage 1)
  │     │     │                                          │
  │     │     │                                          └──▶ [MINIMUM VIABLE REGIONAL LAYER]
  │     │     │
  │     │     └──▶ Phase 3 Atlas UI (client, stig's ticket)
  │     │            [BLOCKED until C complete; can begin with stub data]
  │     │
  │     └──▶ [E] Station module topology          [1.5d]
  │            (atlas_station_modules + atlas_station_connections,
  │             template-based generator, separate code path)
  │            [PARALLEL with C — no dependency between them]
  │
  └──▶ [B] Regional biome grid                    [1.5d]
        (atlas_regional_biomes table, 64×32 sampling,
         integrated into generate_atlas.py terrain pass)
        [PARALLEL with A — different data sources]
        │
        └──▶ feeds into [D] (TerritorialStatus uses biome data)
             [D cannot complete until both A + B + C are done]

Parallelizable branches

• [A] and [B] are fully independent — different data sources, different tables.
• [E] (station topology) is independent of B-D. Can start immediately after scaffolding.
• [C] (road graph) needs Layer A city nodes, not Layer B biome data.
• [D] (TerritorialStatus) needs A + B + C. This is the merge point.
• [F] (wilderness/settlements) needs A + B + C + D. This is the final layer.
• CityGenerationContext Rust struct can begin development in parallel with Phase 3 tooling, stubbing out values, and wire to real systems.db data when Phase 3 is complete.

Effort summary

Ticket	Effort	Dependencies
generate_regional.py scaffolding	0.5d	None
[A] City classification + footprint	1.5d	Scaffolding
[B] Regional biome grid	1.5d	Scaffolding (parallel with A)
[C] Road network graph	1d	Layer A
[D] TerritorialStatus zones	1d	Layers A + B + C
[E] Station module topology	1.5d	Scaffolding (parallel with B-D)
[F] Wilderness + settlement hierarchy	1.5d	Layers A + B + C + D
CityGenerationContext Rust struct	0.5d	Layer A (for struct shape); full data after F
Phase 5 wiring	0.5d	CityGenerationContext + Phase 5 Phase 1 milestone
Phase 3 total	~9.5d	—
Phase 5 (from Round 2)	~6d	CityGenerationContext stub values

Critical path (sequential only):
Scaffolding → A → C → D → F → CityGenerationContext → Phase 5 wiring = ~5.5d

Phase 3 and Phase 5 can be developed in parallel. Phase 5 develops against stub CityGenerationContext values. After Phase 3 lands, Phase 5 wiring ticket wires the real data.

Relationship to existing tickets

Ticket	Phase 3 impact
#899 (rescoped Phase 1 Stages 1-2)	Must consume CityGenerationContext; add dependency on wiring ticket
Phase 3 Atlas UI (new)	Client-side; reads tables Phase 3 produces; assign to stig
generate_regional.py as generator	Add to GENERATOR_SOURCES in tooling/check-systems-db-stamp; update /pr-push source watch list

---

6. Positions on Round 2 Open Questions (Already Resolved by Tyre R3)

Tyre answered all Round 2 open questions. My positions align:

• OQ-R2-1 (prosperity_index and perimeter_treatment in minimum slice): YES. Include before Phase 2 is implemented. Retrofit cost > add-now cost.
• OQ-R2-2 (political_archetype — formal field or implicit): Formal field in atlas_cities. Derived by default. Override allowed. The district generator receives a value, does not compute lore classifications.
• OQ-R2-3 (tile algorithm — door-per-block-edge vs. density-driven rectangles): Both, in order. Street skeleton first (door-per-block-edge), then building fill (density-driven rectangles within that skeleton).
• OQ-R2-4 (Step 2b full city layout): Follow-on ticket. Data model must support N districts from day 1.
• OQ-R2-5 (naming register before Phase 2): Post-walkable. Naming is text overlay, not tile-generation prerequisite.
• OQ-R2-6 (prosperity_index authored or derived for named cities): Derived by default, prosperity_override column for wiki authors.
• OQ-R2-7 (naming register ownership): Paula proposes taxonomy, Mellanie populates name pools, Tyre reviews for spatial contradictions, lead locks as D-record.

---

7. Open Questions for Burnelli-Sheldon

The economics bridge in §2 is based on my reading of what economic data should drive spatial structure. Burnelli-Sheldon should review and fill gaps:

ID	Question	Priority
OQ-R3-G1	Does the economics data in systems.db have sufficient granularity to derive TerritorialStatus per regional cell? Specifically: can I tell from existing data whether a corporation has active presence in a given 8×8-pixel zone, or only at the body level?	HIGH
OQ-R3-G2	Trade flow intensity: is this derivable from existing systems.db supply chain and brand data, or does it require additional economics simulation? The road quality signal depends on this.	HIGH
OQ-R3-G3	Corporate extraction zones: is economic_role = "corporate_extraction" at the body level sufficient to identify ExtractiveZone regions, or do I need sub-body-level economic geography?	HIGH
OQ-R3-G4	FreePort prosperity baseline: my proposal is that FreePort cities derive prosperity from trade flow intensity rather than WorldTier. Does Burnelli-Sheldon agree with this economically? A Backwater transit hub should be prosperous in ways that a Backwater administrative center is not.	MEDIUM
OQ-R3-G5	When a corporation's economics data shows it no longer operating in a body (abandoned extraction), should the sub-settlements auto-reclassify to AbandonedZone, or does this require an explicit authored flag?	MEDIUM

---

8. Summary: What Phase 3 Is and Isn't

Phase 3 is:

• A tooling phase producing enriched systems.db data
• The layer that gives Phase 5 district generation its political and spatial context
• The generator for the Atlas of the Reach implant app (Phase 3 deliverable)
• ~9.5 developer days of Python tooling + Rust read-path work
• Parallelizable with Phase 5 (Phase 5 stubs out with CityGenerationContext values)

Phase 3 is not:

• Walkable tile generation (that is Phase 5)
• Heritage grammar, NPC population, social sites (out of scope)
• Room templates or building interiors (out of scope)
• Real-time computation (all Phase 3 data is offline, committed to systems.db)

The minimum Phase 3 for Phase 5 to function:

• Layer A: City classification (political_archetype + prosperity_index + founding_orientation)
• Layer C: Road graph (road_entry_directions per city)
• Layer B: Regional biome grid (surrounding biome context)

Layers D, E, F enrich Phase 5 and the Atlas UI but are not required for the first walkable district. This gives us a sequencing option: deliver minimum Phase 3 (A + B + C) to unblock Phase 5, then complete D + E + F in parallel with Phase 5 development.

---

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