settled-reach/docs/workshops/planet-down-cascade/paula-round1.md

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

title	description	type	status	workshop	agent	round	created
Paula — Round 1: Narrative and Political Inventory	Inventory and framing of all open questions from the narrative/political depth lens; amendment absorptions; prerequisite ordering; positions on Layer 1-2 political legibility requirements	workshop	active	planet-down-cascade	paula	1	2026-05-01

Planet-Down Cascade — Round 1 (Paula)

Focus: Narrative and political depth. Layers 1-2 primary, Layer 4 prosperity rendering. Round 1 task: examine all open questions, identify what reuses vs. what is genuinely novel design work, establish prerequisite ordering from the narrative legibility requirement.

---

Absorbing the Amendments

Before the layer-by-layer inventory, three amendments materially affect my Round 4 positions and must be acknowledged up front.

Amendment 3 (Fully Generative Placement)

This is narrative-positive. My Round 4 argument was that the planet-down ordering makes FoundingOrientation readable from the geographic trigger without authoring. Amendment 3 extends this to city placement itself — cities land where geography says they should, not where a previous author put them on a pixel map. The narrative causality that I argued for in Round 4 is now architecturally guaranteed, not just recommended.

The amendment eliminates L1-Q1, L2-Q1, and CL-Q4. All three were questions about reconciling authored placements with generated terrain. That reconciliation problem no longer exists.

It adds two new questions I consider narrative-critical:

NEW-Q1 (Attractor-matching priority): The attractor-matching algorithm places N named cities at M geographic attractors. Corporate cross-references in systems.db establish that certain named cities must exist and be the kind of place where that corporation would plausibly sit. This creates a hard constraint: HQ cities must receive appropriate attractor assignments before unnamed settlements fill remaining attractors. The priority order for the matching algorithm has narrative consequences — if the algorithm can seat a corporate HQ at a ResourceConcentration attractor rather than a RiverConfluence, the city's character changes fundamentally. Getting the matching order right is not optional.

NEW-Q2 (OrganicGrowth disambiguation): Amendment 3 says placement is fully generative from geographic attractors. My Round 4 document flagged an unsolved problem: a settlement with no geographic trigger (OrganicGrowth archetype) is algorithmically identical to "no settlement placed here." Both conditions produce zero triggered attractors. The data model must distinguish them. OrganicGrowth settlements exist because a political decision overrode geographic logic — they need a flag or derivation rule that marks them as politically-placed rather than geographically-placed. This is not a new question; it was open in Round 4 and remains open.

Amendment 4 (Spatial Hierarchy)

My Round 4 proposals referenced "regional cells" and "regional grid" language inherited from the original brief. Under the 8-tier hierarchy, I need to remap:

My Round 4 language	Correct tier
"Regional cell" (64×32 grid)	Province (tier 4) — road-map travel region defined by natural boundaries
"City footprint"	Region (tier 3) — city footprint + surroundings
"Sub-settlement"	Region (tier 3) or smaller depending on population tier
"Atlas-level feature"	Area (tier 5) or Body (tier 6)

TerritorialStatus at Province granularity. My proposed TerritorialStatus classification belongs at Province (tier 4), not per-cell within a Province. TerritorialStatus describes the political character of a road-map travel region — the kind of answer you give when someone asks "what's that territory like between the two cities?" One Province = one primary TerritorialStatus. The derivation algorithm reads Province-level aggregates (settlement count, road density and authority distribution, corp_presence coverage, geographic tag presence).

The spatial dimension table (Amendment 4 workshop question) is Tyre's domain. But I need the Province dimensions confirmed before I can specify TerritorialStatus derivation thresholds with meaningful numbers — "high settlement density" means something different in a Province covering 50km vs. 500km.

Amendment 5 (Ghost City Effect Demoted)

This is a framing correction, not an architectural change. My Round 4 work was too fond of the ghost city as a design goal. Amendment 5 is correct: the determinism rule exists to protect the player's spatial memory, not to produce ghost towns. Ghost towns emerge when the prosperity system does its job across a settlement with a collapsed economic basis. That emergence is interesting precisely because it was not designed.

The two-field model (prosperity_baseline + prosperity_current, producing a derived prosperity_delta) is still the right rendering architecture. It is the mechanism that makes economic state visible at street level without changing layout. The ghost city effect is one possible consequence of that mechanism working correctly on an economically failed settlement. I should not design for the ghost case; I should design the mechanism well and let the case emerge.

My Round 4 positions on this mechanism stand. My framing of it as a "ghost city architecture" is revised. The correct framing: the two-field prosperity model is a rendering legibility requirement — without it, the economic simulation's state is invisible to the player at street level, and the relationship between the macroeconomic layer and the world the player walks through is severed.

---

Layer 1: Empty World — Inventory

My role: Geographic feature tag layer is the primary Layer 1 narrative output. Everything else at Layer 1 is terrain/hydrology work for Tyre and Burnelli-Sheldon.

What exists or can be reused

planet_simulation.py already computes elevation, temperature, moisture, biome classification, and a river network. The river network from the simulation is usable as-is for confluence identification — confluence points are where rivers merge, and the simulation's drainage network already produces this as a geometric property. No novel algorithm is needed for confluence identification; it is a post-processing step on the existing drainage network output.

Sub-biome refinement within a biome class is also not novel design. It is a conditional probability distribution over sub-biome variants, conditioned on local elevation, moisture, and temperature within the biome cell. The inputs exist; the logic is classification, not novel simulation.

What is genuinely novel

The geographic feature tag layer. This does not exist. The simulation produces terrain values but does not produce named semantic tags (RiverConfluence, CoastalHarbor, MountainPass, ArablePlain, ResourceConcentration, Defensible, NaturalBarrier). These tags must be derived from terrain + drainage network output and stored as point or cell features. The derivation rules for each tag are novel design work:

• RiverConfluence: junction point in drainage network where two named-scale rivers meet. Threshold: both contributing rivers above minimum navigable flow at the confluence.
• CoastalHarbor: coastal cell with protected geometry — bay geometry detectable from heightmap contour adjacent to ocean. Threshold: coastline curvature > threshold at sea level.
• MountainPass: local saddle point in high-elevation terrain — cell with elevation above mountain threshold where adjacent cells in two cardinal directions are significantly lower (pass geometry). Threshold: elevation gap > X between saddle and neighboring valley cells.
• ArablePlain: flat terrain (low roughness) above minimum fertility threshold (temperature + moisture combined index). Threshold: roughness < Y, fertility index > Z.
• ResourceConcentration: this tag is NOT purely terrain-derived. Mineral outcrops and energy sources are placed by economic generation (from systems.db economic_role data). The tag should be placed at Layer 1 only where economic_role from systems.db indicates extraction potential — this is L1-Q4 (biome prior) applied specifically to resource attractor placement.
• Defensible: elevated cell with clear sightlines — above terrain mean for the Region, with lower terrain on at least 3 of 4 cardinal neighbors. Threshold: relative elevation > W, neighbor gradient > V.
• NaturalBarrier: contiguous high-roughness or deep-ocean cells that form a traversal barrier — identified as connectivity barriers in the Province-level graph. No single threshold; barrier quality is a Province-level graph property.

What is a data/schema question

The new atlas_geographic_features table (point features stored in systems.db) needs to be defined. Under Amendment 1's corrected execution model, this table does NOT go in systems.db — Layer 1-2 now runs as Rust runtime background generation, storing output in the Session DB. The feature tag table belongs in the Session DB, not the build-time systems.db.

This has an important implication: the attractor-matching algorithm (NEW-Q1) runs at Layer 1-2 background time, not at build time. Corporate cross-reference resolution must also happen at background time. This is feasible — systems.db is available at runtime, and the background generator can read it.

Open question positions (Layer 1)

L1-Q2 (river resolution): Position (c) — Province-resolution only stored in Session DB (confluence points as point features, coarse river paths as Province-level graph edges). Tile-resolution river courses are seed-derived at Phase 5. The narrative requirements for Layer 2 are satisfied by confluence point storage alone — settlement placement only needs to know WHERE confluences are, not the precise course of every tributary.

L1-Q3 (stored vs. derived): Confluence points must be stored in Session DB (Layer 1 output, consumed by Layer 2 settlement placement). Full river course derived at runtime. No systems.db entries needed for rivers — rivers are Session DB content.

L1-Q4 (biome prior): YES, apply economic_role as a soft sub-biome prior. The narrative justification: a world that has been exploited for extraction should feel geologically harsh; an agricultural world should feel fertile and temperate. This prior affects sub-biome variant distribution and the placement threshold for ResourceConcentration tags. The risk of self-contradictory worlds from excluding it is real — a frontier economic_role world with a tropical paradise biome distribution is dissonant without explanation.

NEW-Q1 (attractor-matching priority): This is prerequisite for Layer 2 and must be resolved before the attractor-matching algorithm can be specified. My position: HQ-reserved cities (named cities with corporate cross-references) have first priority in attractor assignment. The matching algorithm must fulfill name reservations before assigning unnamed settlement slots. A reserved HQ city without a plausible geographic attractor is a data quality problem — the economic role of the corp should constrain which attractor types are acceptable (extraction corp HQ → ResourceConcentration or ArablePlain acceptable; CoastalHarbor acceptable if maritime trade; RiverConfluence acceptable universally). The algorithm should flag mismatches for lead review rather than silently placing a mining corp HQ at a harbor attractor.

Prerequisite status: L1-Q2 and L1-Q3 are prerequisites for Layer 2 (confluence storage design must be settled before Layer 2 algorithm reads it). L1-Q4 is independent but should be resolved early to inform sub-biome distribution work. NEW-Q1 spans Layers 1-2 and must be resolved before Layer 2 algorithm design.

---

Layer 2: Population Overlay — Inventory

My role: TerritorialStatus derivation, FoundingOrientation derivation, sub-settlement PoliticalTether, road MaintenanceAuthority. All of these are post-processing passes on the settlement placement + road generation output.

What exists or can be reused

The road graph algorithm (Phase 3 Layer C, from prior workshop) can be reused for generating inter-settlement road topology. The amendment eliminates authored road paths, but it does not eliminate authored road identities — systems.db knows which named highway routes exist (their names and economic significance), and the generator must assign generated road edges to these named identities.

The settlement placement algorithm has conceptual precedent in constraint satisfaction literature (assignment problem). The specific formulation needed here — N named settlements with known economic roles and populations, M geographic attractors with known characteristics, maximize plausibility — is a priority-ordered assignment, not a pure optimization. This is novel implementation but not novel algorithm design.

TerritorialStatus derivation is a classification post-processing step. It reads Province-level aggregates that the settlement placement and road generation steps have already produced. The novel work is specifying the derivation thresholds.

What is genuinely novel

The attractor-assignment algorithm. This produces the settlement-to-attractor mapping that makes city positions geographically legible. From a narrative standpoint, the algorithm's output must be auditable — it must be possible to explain why a given city was placed at a given attractor. The algorithm is novel and is the core design work of Layer 2.

My proposed assignment logic (to be detailed in Round 2):

1. Fulfill name reservations for HQ cities in economic role order (extraction corps first — most geographically constrained; service/commercial corps last — most flexible).
2. Assign remaining named cities by population (largest first — highest population cities have the strongest geographic pull, and the best attractors should be theirs).
3. Place unnamed cities (generated) at remaining attractors by best-fit economic profile.
4. OrganicGrowth settlements (the remaining population quota after all attractors are consumed) are placed at politically significant points: midpoints between two large cities, or at Province centroids for administrative capital bodies.

OrganicGrowth disambiguation (NEW-Q2). The data model must distinguish OrganicGrowth settlements from "no settlement placed." My proposed resolution: a boolean flag geographically_triggered: bool on every settlement record in Session DB. True = settlement was assigned to a geographic attractor. False = settlement exists because of population quota or political decision. FoundingOrientation for geographically-untriggered settlements is always AdminFacing — the settlement exists because someone decided it should.

TerritorialStatus quantitative thresholds. These are novel — they have no prior precedent in the codebase. Proposed thresholds (subject to iteration in Round 2):

Status	Settlement count	Road coverage	Corp presence condition
CoreTerritory	≥ 2 per Province	≥ 0.6 Province-wide	Any
FrontierTerritory	≥ 1 per Province	0.3–0.6 OR quality < 0.5 at Province edge	Any
ExtractiveZone	≥ 1 at ResourceConcentration	extraction corridor ≥ 0.7, off-corridor < 0.3	corp_presence > 0
ContestZone	≥ 2 from competing road authority types	Any	Any, overlapping claim
WildernessBuffer	0	0	None
AbandonedZone	≥ 1 at generation (runtime: 0 active)	Exists (maintained = false)	was present, now absent

The critical design decision in this table: WildernessBuffer and AbandonedZone both have no active settlements at runtime, but their histories are different. AbandonedZone requires a placed_at_generation: bool marker on the Province to distinguish "never settled" from "was settled, now gone." This marker is set at Layer 2 generation time and is immutable.

What is a data/schema question

Road identity assignment. systems.db holds named route records (highway names, administrative designations). The Layer 2 generator produces a road graph (nodes + edges). Road identity assignment — which generated edge segment corresponds to which named route — is a data join problem. The schema needs a road_segment table in Session DB with an optional named_route_id foreign key to systems.db. This is schema design work, not algorithmic design.

PoliticalTether derivation. This is direct enumeration, not algorithmic. For each sub-settlement:

• Corporate: settlement placed at ResourceConcentration attractor AND corp_presence > 0 in parent city
• Administered: settlement placed at geographic inevitability (pass waypoint, river crossing) AND parent city is AdminCapital archetype
• Contested: settlement placed in ContestZone Province
• EconomicallyDependent: settlement placed at agricultural or agricultural-adjacent attractor, parent city is primary market
• Independent: OrganicGrowth sub-settlement with no corporate or administrative tie
• Abandoned: active flag = false at runtime

Open question positions (Layer 2)

L2-Q2 (sub-settlement placement): The brief's proposed algorithm (camp_position = closest regional cell to corp's location_id asset with land_use ∈ {Industrial, Wilderness}, at seeded distance from tether city within [15%–40%] of body scale) is mechanistically reasonable. The narrative concern: the placement direction from the tether city should match the ResourceConcentration attractor direction — a mining camp should be "out toward the resource," not "randomly offset from the city." This is an additional spatial constraint on the seeded distance formula: seed the angle toward the Resource tag, then add noise. Count formula: 1 camp per 2 qualifying corps (as proposed) is reasonable for Phase 1. Shadow node placement is correctly deferred.

L2-Q3 (road algorithm): With Amendment 3 eliminating authored road paths, the road algorithm generates all topology. Named highway routes receive their identity via post-generation assignment (the schema question above). I agree with the proposed resolution: named routes = generated topology + identity assignment from systems.db; local sub-settlement roads = generated by road graph algorithm from Phase 3 Layer C. MaintenanceAuthority derivation is unchanged from my Round 4 position.

L2-Q4 (hinterland shapes): I do not support Voronoi for hinterland fills. The narrative of farmland is rivers and gentle slopes — agricultural cells should cluster along river corridors and coastal lowlands, weighted by terrain_modification_cost from Layer 1 (lower cost = more likely to be farmed). A simple weighted probability assignment per Province cell is sufficient for Phase 1. Voronoi introduces region boundaries that don't correspond to anything the player would observe or that matters politically. Reserve algorithmic complexity for things that matter narratively.

L2-Q5 (TerritorialStatus thresholds): Proposed thresholds are above in the novel work section. These need iteration and Burnelli-Sheldon's input on road coverage quantification. The qualitative derivation logic I proposed in Round 4 stands; the numbers are initial proposals.

L2-Q6 (latent settlement flag storage): Option (b) confirmed — Session DB Phase 1-2 output table stores latent settlement positions + activation conditions (the specific corp or resource condition that would activate each). The economic sim evaluates activation by reading current corp_financial_state against the stored activation condition. This integrates cleanly with the background generation model (Amendment 1): the Layer 1-2 background pass populates the Session DB; the sim reads it alongside its own corp state data at runtime.

Prerequisite status: NEW-Q1 (attractor-matching) is prerequisite for all Layer 2 settlement placement. NEW-Q2 (OrganicGrowth disambiguation) is prerequisite before settlement placement algorithm is specified. L2-Q5 (TerritorialStatus thresholds) is prerequisite for producing the Province classification that Layer 3 reads. L2-Q3, L2-Q4 are independent of each other and can be resolved in parallel.

---

Layer 3: City-Level Planning — Inventory

My role: FoundingOrientation spatial effect on district layout, political archetype as spatial arrangement, prosperity gradient direction and magnitude.

What exists or can be reused

The DistrictSkeleton generation framework (Stages 1-2) is the existing stub. The field for founding_orientation is in the CityGenerationContext struct. The concept exists; the spatial application does not.

FoundingOrientation derivation is now trivially readable from the geographic trigger (as I argued in Round 4). No novel algorithm needed for the derivation — it is a direct lookup from the attractor tag to the orientation enum. Novel work is in the spatial application.

What is genuinely novel

Explicit spatial arrangement patterns by political archetype. This is my strongest position in this workshop. The weight table alone does not produce CompanyTown spine topology. It can produce a slightly higher proportion of Industrial and Logistics districts relative to Residential, but it cannot produce the physical arrangement where the resource is at one end and everything else radiates back from it. That arrangement requires explicit logic.

The five arrangements I proposed in Round 4 (reformulated for Round 1 framing, not Round 2 algorithm detail):

• CompanyTown spine: District grid is oriented along a single axis with the ResourceFacing/Logistics end at the resource-adjacent edge. Districts are placed sequentially along the spine, not in a 2D grid. The spine orientation IS the FoundingOrientation direction.
• AdminCapital radial: District grid expands outward from a central Administrative district. The first district placed is the Administrative district at or near the founding-feature-facing edge (DefenseFacing = high ground center; AdminFacing = geometric center). Remaining districts radiate.
• FreePort multi-node: Two or three independent district clusters, each anchored around a commerce/logistics node, without a single civic center. No single-district grid — multiple sub-grids.
• Contested overlay: Two partial district grids meeting at a boundary. Each grid is internally consistent with one archetype's arrangement but they meet awkwardly — the contested boundary is where grid coherence breaks down.
• OrganicGrowth irregular: Districts placed by local density attractors (sub-feature geography within city footprint), no single directional arrangement.

This is novel design work. It requires a district placement function that accepts political_archetype and founding_orientation and produces a spatial layout rather than just sampling from a distribution.

FoundingOrientation as spatial grid rotation. My position: spatial rotation, not gradient direction only. The player should be able to look at a city map and see the PortFacing city's harbor at one end. This is the narrative payoff that justifies the planet-down ordering — the geographic rationale is physically visible in the city's layout. Gradient-direction-only produces a more uniform city layout with a prosperity slope, which is weaker narrative signal. The implementation cost is higher (the district grid must be oriented, not just a fixed NxM grid), but the narrative requirement is satisfied only by spatial rotation.

What is a data/schema question

prosperity_baseline derivation formula: Burnelli-Sheldon's formula is a schema/calculation question more than a narrative question, except for one point — topographic contribution. I advocate for a small topographic modifier: hilltop districts (elevation in top 30% for the city) receive +0.05 to prosperity_baseline; flood-adjacent districts (elevation in bottom 20% relative to sea level for the city) receive -0.05. This is historical — high ground is consistently higher prestige in pre-industrial settlement patterns. Whether to include this modifier is the question; the magnitude is tunable.

Open question positions (Layer 3)

L3-Q1 (FoundingOrientation spatial effect): Spatial rotation/alignment. Not gradient direction only. See above.

L3-Q2 (political archetype as spatial arrangement): Explicit arrangement patterns. Not emergent from weight table. See above.

L3-Q5 (prosperity_baseline derivation): Agree with Burnelli-Sheldon's formula as the base. Advocate for small topographic modifier. Topography should set gradient direction (Burnelli-Sheldon's recommendation) AND contribute a modest magnitude offset for extreme elevation.

L3-Q6 (sub-settlement depth): Unified code path — town with district_count = 1 uses the same DistrictSkeleton generation. Architectural cleanliness, no divergence in the narrative content the player encounters in a town vs. a city district.

L3-Q7 (port/station direction): Defer from minimum viable. Design the mechanism: the Layer 3 generator reads orbital station atlas position from systems.db, derives a directional vector from city center to station, maps that to the nearest cardinal edge, places Transit/LogisticsHub district at that edge. This is a one-query, one-lookup, one-edge-assignment operation. The mechanism is simple enough to be worth designing even if deferred in implementation.

Prerequisite status: L3-Q1 and L3-Q2 must be resolved before the district placement algorithm can be specified. L3-Q5 is independent and can be resolved in Round 2 alongside the economics formula. L3-Q6 is independent. L3-Q7 is deferred.

---

Layer 4: Street-Level Rendering — Inventory

My role: Prosperity rendering mechanism (CL-Q1), condition update trigger design (L4-Q2), ruin lifecycle (CL-Q3 — now demoted).

What exists or can be reused

The tile condition state enumeration (Intact/Worn/Cracked/Broken) does not exist as implemented code but the concept is well-defined in the brief. The economic sim already computes prosperity_current per entity. The rendering mechanism connects these two things.

What is genuinely novel

Prosperity rendering integration. The sim produces prosperity_current per city/district. The tile generator receives prosperity_baseline at generation time. The renderer needs to derive effective prosperity (prosperity_baseline + prosperity_delta clamped to [0, 1]) and map it to tile condition state. This requires a handoff channel from the sim to the renderer that is neither ChunkMutations (too granular, wrong ownership) nor a full regen (too expensive). This channel design is novel.

My preferred mechanism: prosperity_current is a per-district value updated by the sim and readable by the renderer. The renderer computes prosperity_delta = prosperity_current - prosperity_baseline at chunk-load time. Tile condition state is cached per chunk and invalidated when prosperity_current crosses a threshold (Option C from brief L4-Q1). The threshold crossing check is a sim-side trigger — the sim emits a "district prosperity crossed threshold X" event; the renderer invalidates the chunk cache for that district on receipt.

This is clean: the sim is not involved in rendering; it only emits events at meaningful economic transitions. The renderer handles the rest.

What is a data/schema question

prosperity_current storage: this lives in the ECS (per-city/per-district component), not in Session DB. It is sim state. The renderer reads it from the ECS at chunk load. No schema change needed beyond adding the prosperity component to the entity definition.

Open question positions (Layer 4)

L4-Q1 (economics-variable rendering mechanism): Option (c) — cache per chunk, invalidate on threshold crossing. Option (a) (bake and update on event) is similar but requires a stored cache per chunk, which is the same as option (c). Option (b) (live computation per frame) is too expensive. The distinction between (a) and (c) is whether the cache is invalidated on any prosperity_current change or only on threshold crossings — threshold crossings is correct because most districts are economically stable most of the time.

L4-Q2 (condition update trigger): Threshold crossings. Proposed thresholds (offset from round numbers to avoid oscillation at boundaries):

• Intact: effective_prosperity ≥ 0.63
• Worn: 0.43 ≤ effective_prosperity < 0.63
• Cracked: 0.23 ≤ effective_prosperity < 0.43
• Broken: effective_prosperity < 0.23

L4-Q6 (prosperity_delta): Adopt the two-field model with prosperity_delta as a derived-never-stored value. Frame it as the rendering legibility requirement, not as ghost city architecture. The economic simulation's state must be legible at street level; this model is how that legibility is achieved.

CL-Q3 (ruin lifecycle): Per Amendment 5 — scope as emergent rendering outcome. When the economic sim evaluates an AbandonedZone settlement: prosperity_current drops to near-zero; at the next threshold crossing check, tile condition transitions toward Broken; perimeter_treatment degrades as a renderer-side parameter driven by prosperity (not a separate authored sequence). No designed decay path. The lifecycle is the prosperity system working correctly on an economically failed settlement.

---

Cross-Layer: Naming

The naming register framework I proposed in Round 4 (Geographic/Functional/Commemorative/Aspirational/Folk registers by settlement character) maps to the spatial hierarchy as follows:

• Area/Body level (Layer 1): Geographic placeholder names for major terrain features large enough to appear on body-atlas UI. These are pre-political register names — purely descriptive.
• Province/Region level (Layer 2): Settlement names (Geographic register for confluence/harbor placements, Functional register for extraction sites, Commemorative register for administrative capitals, Folk register for agricultural clusters). DualNaming initialization for ContestZone Provinces.
• District level (Layer 3): District names from (DistrictType × WorldTier) → register lookup. political_archetype modifier applied.
• Street level (Layer 4): Working street names (pragmatic names used by inhabitants, which may differ from official planning names). DualNaming proliferates here in Contested cities.

This is a content pipeline question more than an algorithm question. The registers and pools need to be defined (Mellanie's domain). The generator only needs the lookup table and the pool references.

---

Prerequisite Map — What Must Be Resolved First

This is the narrative-legibility dependency graph:

NEW-Q1 (attractor-matching priority)
  └── blocks: all Layer 2 settlement placement algorithm design
      └── blocks: L2-Q5 (TerritorialStatus thresholds — need Province-level aggregates)
          └── blocks: Layer 3 reads TerritorialStatus

NEW-Q2 (OrganicGrowth disambiguation)
  └── blocks: FoundingOrientation derivation (AdminFacing = no attractor trigger)
      └── blocks: L3-Q1 (spatial grid orientation design)
          └── blocks: L3-Q2 (explicit arrangement patterns — orientation is prerequisite)

L1-Q3 (confluence storage)
  └── blocks: Layer 2 attractor identification (confluences must be queryable)

L2-Q6 (latent settlement flag storage)
  └── blocks: AbandonedZone classification (runtime active/ghost state)

Amendment 4 (Province dimensions locked)
  └── blocks: L2-Q5 quantitative thresholds (density ratios depend on Province area)

Independent questions (no narrative-legibility blocking dependency):

• L1-Q4 (biome prior) — independent
• L2-Q3 (road algorithm) — independent after attractor-matching
• L2-Q4 (hinterland shapes) — independent
• L3-Q5 (prosperity baseline formula) — independent
• L4-Q1, L4-Q2 (rendering mechanism, condition triggers) — independent from spatial design

---

Questions I Am Not Positioned to Answer

L3-Q4 (topographic constraints on zoning at district resolution): Tyre's domain. My input: the narrative requirement is that topography should be visible in district layout. Whether the Layer 1 64×32 data is sufficient depends on how many districts fall per regional cell — Tyre needs to confirm that district count × district size doesn't exceed the regional cell size. If it does, finer terrain data is needed.

L4-Q3 (tile algorithm parameters — minimum street corridor width, max building dimensions): Gestalt's domain primarily. My only narrative input: street width should vary by DistrictType as a planning investment signal. Administrative districts → wide boulevards. Organic Residential → narrow alleys. The width variation is not just aesthetic; it tells the player who planned this district and how much they invested.

L4-Q5 ("scatter civilization" scope — prop spawn points vs. entity spawn points): Layer 4 minimum viable should produce prop spawn points only (type-tagged spatial anchor points). Entity placement is runtime. Decal slots are a visual detail that can be addressed post-walkable-world.

Amendment 4 (spatial dimension table): Tyre and Burnelli-Sheldon own the quantitative dimension confirmation. My only requirement: Province dimensions must be confirmed before TerritorialStatus thresholds are finalized in Round 2.

---

Summary of My Round 1 Positions

Question	My position	Priority
NEW-Q1 (attractor-matching)	HQ-reserved cities first, by economic role constraint; flag mismatches	PREREQUISITE
NEW-Q2 (OrganicGrowth disambiguation)	geographically_triggered: bool flag, AdminFacing orientation	PREREQUISITE
L1-Q2 (river resolution)	Province-resolution confluence points in Session DB; tile-res seed-derived	Early
L1-Q3 (confluence storage)	Session DB, not systems.db	PREREQUISITE
L1-Q4 (biome prior)	Yes — apply economic_role as soft sub-biome prior	Early
L2-Q2 (camp placement)	Direction toward ResourceConcentration tag + seeded noise, 1 per 2 corps	Round 2 detail
L2-Q4 (hinterland shapes)	No Voronoi — weighted probability along rivers + terrain cost	Independent
L2-Q5 (TerritorialStatus thresholds)	Proposed thresholds above; needs Province dimensions	Round 2 finalize
L2-Q6 (latent settlement flag)	Session DB table, activation condition referenced	Confirmed
L3-Q1 (FoundingOrientation spatial)	Spatial rotation, not gradient-direction-only	PREREQUISITE
L3-Q2 (political archetype spatial)	Explicit arrangement patterns, not emergent	PREREQUISITE
L3-Q5 (prosperity_baseline)	Burnelli-Sheldon formula + small topographic modifier	Round 2
L3-Q6 (sub-settlement depth)	Unified code path, district_count = 1	Confirmed
L4-Q1 (rendering mechanism)	Cache per chunk, invalidate on threshold crossing	Independent
L4-Q2 (condition triggers)	Threshold crossings at 0.63 / 0.43 / 0.23	Independent
L4-Q6 / CL-Q1 (two-field model)	Adopt — rendering legibility requirement, not ghost city architecture	Confirmed
CL-Q3 (ruin lifecycle)	Emergent rendering outcome only — no designed decay path	Per Amendment 5

---

Paula — Round 1. Written 2026-05-01.