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

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

title	description	type	status	workshop	agent	round	created
Gestalt — Round 1: Inventory and Framing	Per-layer inventory of reusable algorithms, novel design work, and data/schema questions. Prerequisite dependency map. Weight table challenge analysis. Systems design framing for the planet-down cascade.	workshop	active	planet-down-cascade	gestalt	1	2026-05-01

Planet-Down Cascade — Round 1 (Gestalt)

Role: Systems design inventory and framing. For each layer: what algorithm exists or can be reused, what is genuinely novel design work, what is a data/schema question only. Prerequisite dependency map. Weight table challenge from Amendment 6.

---

Part 0: Amendment Inventory — What Changed Before Round 1 Starts

The consultant review rewrites several foundational assumptions. These are lead directives, not proposals. Every layer analysis below operates within them.

Amendment	What changed	Effect on workshop
1: Three-tier execution	Phase 3/Phase 5 split replaced with build-time/runtime-background/runtime-on-demand	Layer 1-2 algorithms must be Rust-implementable on background threads. Python generate_regional.py becomes reference + validation only.
2: Background priority queue	Layer 1-2 generates per body on priority queue: Immediate > High (player-facing mentions) > Medium (gate-adjacent) > Low	Performance target: low single-digit seconds per body for Layers 1-2. Algorithms must be designed to that budget.
3: Fully generative placement	markers.json stripped to topographic features only. All city positions, river polylines, road paths become generator output.	L1-Q1, L2-Q1, CL-Q4 eliminated. Two new questions added: attractor-matching algorithm, name reservation fulfillment.
4: Spatial hierarchy locked	8-tier naming: System > Body > Area > Province > Region > District > Block > Chunk. Body size absorbed at Area tier. Fixed dimensions tiers 0-4.	All layer resolution references must use this vocabulary. Grid resolution confirmation required before Layer 1.
5: Determinism rationale corrected	Player spatial memory, not ghost town narrative. prosperity_delta = derived-only, never stored. CL-Q3 reduced to emergent rendering consequence.	Ghost town framing retired from architectural descriptions. Prosperity rendering split unchanged, but motivation is explicit.
6: Weight table unlocked	10×9 table moved to open question. Lead challenge: table encodes what a city produces, not what it needs.	Workshop must evaluate population+age-driven baseline district mix. Weight table may be retained, replaced, or hybridized — must justify.

Questions eliminated before Round 1 begins:

• L1-Q1 (authored rivers vs. drainage) — all rivers generated from drainage
• L2-Q1 (city positions anchored vs. re-derived) — all positions derived
• CL-Q4 (authored rivers elevated) — same as L1-Q1

New questions added by Amendment 3:

• Attractor-matching algorithm (see Layer 2 section)
• Name reservation fulfillment (see Layer 2 section)

---

Part 1: Layer 1 — Empty World

Inventory

Category	Item	Status
Reusable	planet_simulation.py drainage/river algorithm	Exists in Python — must port to Rust. Algorithm is the reference; outputs must be identical.
Reusable	64×32 regional biome grid	Already generated by generate_atlas.py, stored in systems.db. Layer 1 reads this as input, extends it.
Reusable	is_coastal, water_fraction, terrain_roughness columns	Already on atlas_regional_biomes. Layer 1 adds columns to this table.
Reusable	Heightmap (512×256)	Already generated by generate_atlas.py, stored in systems.db as build-time artifact.
Novel design	Sub-biome variant classification	3-4 variants per biome class, seed-derived. No existing algorithm. Needs a seed-driven variant selection rule per biome class.
Novel design	terrain_modification_cost: f32 per cell	No existing field. Needs a derivation formula from biome class + terrain_roughness + water proximity.
Novel design	Geographic feature tag extraction	No existing algorithm for identifying RiverConfluence, CoastalHarbor, MountainPass, ArablePlain, ResourceConcentration, Defensible, NaturalBarrier from the generated drainage network + heightmap.
Novel design	Mountain pass identification	No existing algorithm. Candidate: regional cells with high terrain_roughness adjacent to lower cells on opposite sides. Needs threshold.
Data/schema	sub_biome_variant column on atlas_regional_biomes	New column, no schema conflict.
Data/schema	terrain_modification_cost column on atlas_regional_biomes	New column.
Data/schema	Geographic feature points storage	Under Amendment 1, this is session DB (runtime background), not systems.db. The BRIEF's proposal to store confluence points in systems.db is overridden by Amendment 1 — all Layer 1 data is runtime Rust, session DB.

Open Questions After Amendments

ID	Question	Prerequisite?	Type
L1-Q2	River resolution: 64×32 regional-only vs. intermediate vs. tile-resolution seed-derived	Yes — determines Layer 2 settlement placement precision and Layer 4 tile generation	Scope decision
L1-Q3	Under Amendment 1: Layer 1-2 lives in session DB. "Stored confluence points" now means session DB, not systems.db. Confirm this interpretation.	Yes — affects what Layer 2 can query at startup vs. what requires Layer 1 to complete first	Architecture
L1-Q4	Economic role as biome prior in sub-biome selection	No — low-risk addition, can be deferred	Design
NEW	Spatial hierarchy dimension locking (Amendment 4)	Yes — Area tier dimensions determine how many areas per body; Province tier resolution determines Layer 1 grid coverage	Architecture
NEW	Body-size to area-count formula	Yes — prerequisite for all layer dimension calculations	Architecture

Systems Design Assessment

What Layer 1 produces for gameplay: The legibility layer. Players read terrain to predict where civilization sits before seeing a map label. River confluences → city probability. Mountain passes → chokepoints. Coastal harbors → trade hubs.

Performance constraint (Amendment 2): Drainage simulation + sub-biome classification + feature extraction must complete in ~1-2 seconds per body budget, leaving room for Layer 2. The 64×32 grid (2,048 cells) is small — this should be fast. The constraint is the drainage algorithm, which may require iteration to convergence. Needs a performance evaluation in Round 2.

The geographic feature tag set is the key output for Layer 2. Everything else (sub-biome variants, terrain modification costs) is either enrichment or downstream-derivable. The seven feature tags (RiverConfluence, CoastalHarbor, MountainPass, ArablePlain, ResourceConcentration, Defensible, NaturalBarrier) are what Layer 2's attractor-matching algorithm uses. Getting this right is Layer 1's most critical contribution.

---

Part 2: Layer 2 — Population Overlay

Inventory

Category	Item	Status
Reusable	Sub-settlement placement triggers	Fully designed (Round 3): mining camps, trade waypoints, agricultural nodes, shadow nodes. Algorithms specified.
Reusable	Road graph algorithm (Phase 3 Layer C)	Designed in Round 3. Under Amendment 3, ALL roads are generated (authored roads eliminated). The algorithm applies to all roads, not just local connectors.
Reusable	TerritorialStatus derivation (Paula Round 4)	Algorithm described qualitatively. Thresholds (L2-Q5) still open.
Reusable	PoliticalTether derivation	Distance + economic data approach established.
Novel design	Attractor-matching algorithm (Amendment 3 new)	Constraint satisfaction: N named cities (known economic roles, populations, corp cross-refs) → M geographic attractors (known types, locations, capacities). Biggest novel design item in this workshop.
Novel design	Name reservation fulfillment (Amendment 3 new)	How does the generator assign city names from systems.db to generated positions? Hard constraints: corp HQ cities must exist by name. Everything else: match by economic plausibility + cultural naming pool.
Novel design	Hinterland shape algorithm (L2-Q4)	The spatial SHAPE of farmland, extraction corridors, wilderness buffers. Algorithmic proposal exists (cluster around agricultural cities + river corridors at density ∝ 1/terrain_modification_cost) but not locked.
Data/schema	land_use column on regional cells	Already in Layer F design (Round 3). Enum: Urban / Agricultural / Industrial / Wilderness / Corridor / Ruins / Ocean / Impassable
Data/schema	TerritorialStatus per regional cell	Six-value enum confirmed. Column or separate table? Under Amendment 1: session DB.
Data/schema	atlas_sub_settlements session DB table	Table design needed. Fields: position, tier, PoliticalTether, active/ghost flag, founding trigger.
Data/schema	Latent settlement active/ghost flag (L2-Q6)	Under Amendment 1: session DB is the right answer. Sim reads session DB settlement records + corp_financial_state to determine active/ghost.

Open Questions After Amendments

ID	Question	Prerequisite?	Type
Attractor-matching	How does generator match N named cities with known roles to M geographic attractors? What resolves conflicts? What are the matching heuristics?	Yes — Layer 2 cannot place settlements without this	Novel design
Name reservation	What data structure represents name reservations from systems.db? When in the cascade does the generator fulfill them?	Yes — corporate cross-references in systems.db must resolve to actual city positions	Novel design
L2-Q2	Sub-settlement exact positioning: seeded distance from tether city within [15%-40%] of body scale? Camp count formula?	No — partially specified, refinement in Round 2	Design
L2-Q3	Road algorithm: under Amendment 3, all roads generated. The algorithm from Phase 3 Layer C now handles ALL inter-settlement connections. Does this require any redesign?	No — simplifies the question (no authored road reconciliation needed)	Scope clarification
L2-Q4	Hinterland spatial shape — cluster algorithm vs. Voronoi region-growing	No — minimum viable uses land_use tag; exact shape deferred	Design
L2-Q5	TerritorialStatus quantitative thresholds	No — can be proposed in Round 2, doesn't block minimum viable	Design
L2-Q6	Latent settlement flag storage: session DB (under Amendment 1 — clear answer)	No — Amendment 1 resolves this in favor of session DB	Architecture

The Attractor-Matching Algorithm — Systems Design Framing

This is the most novel design item in the entire workshop. Let me break down what it actually requires mechanically.

Inputs:

• N settlements from systems.db: each has {name, population, economic_role, corp_presence refs, world_tier}
• M geographic attractors from Layer 1: each has {type, location_cell, capacity_score}
• Hard constraints: if corp X is headquartered at city Y, city Y must be placed at an attractor of appropriate type for corp X's industry

The matching problem:

• Hard constraints first: corp HQ cities get attractor-locking priority
• Soft constraints: agricultural economic_role prefers ArablePlain attractors; extraction prefers ResourceConcentration; transit prefers CoastalHarbor/RiverConfluence
• Population-proportional: larger cities should claim larger/higher-capacity attractors
• Conflict resolution: when two cities compete for the same best attractor, resolve by population (larger wins) + economic fit score

Algorithm sketch (for Round 2 proposals):

1. Score all (city, attractor) pairs by fit: base score from economic_role × attractor_type match, weighted by population / attractor capacity
2. Hard constraint pass: lock corp-required assignments first
3. Greedy assignment: highest-scored pairs assigned first, consuming attractor capacity
4. Remainder: less-ideal placements for cities that couldn't get their preferred attractor type

What this creates for gameplay: Cities sit where they make geographic sense. A player approaching a harbor city knows before arrival that it's likely commercial/transit-oriented. The geography teaches the economic character. This is legibility.

---

Part 3: Layer 3 — City-Level Planning

Inventory

Category	Item	Status
Reusable	DistrictSkeleton classification system	Rounds 1-3 design: Stage 1 (classification), Stage 2 (block grid).
Reusable	City decomposition formula (D-C4)	max(1, floor(population / 50_000)) with WorldTier ceilings. Locked.
Reusable	CityGenerationContext struct	Defined in Given Facts. Needs body_id field added (confirmed open item).
Reusable	SeedChain for districts	district_seed = child_seed(world_seed, district_id). Locked.
Reusable	prosperity_baseline derivation formula	Burnelli-Sheldon Round 3. Needs topography contribution decision.
Novel design	FoundingOrientation spatial grid orientation (L3-Q1)	Does it modify district placement positions or only gradient direction? Prerequisite decision before Layer 3 implementation.
Novel design	Political archetype spatial arrangement (L3-Q2)	Explicit spine/center/nodes vs. emergent from weight table. Prerequisite decision.
Novel design	Weight table challenge (Amendment 6)	Population+age-driven baseline evaluation. See Part 5 of this document.
Data/schema	body_id on CityGenerationContext	Missing. Multi-body scoping requires it.
Data/schema	Grid resolution confirmation	64×32 grid predates spatial hierarchy. Province/Region tier dimensions need confirmation.

Open Questions After Amendments

ID	Question	Prerequisite?	Type
L3-Q1	FoundingOrientation: spatial grid rotation vs. gradient direction only	Yes — Layer 3 implementation blocked until resolved	Architecture
L3-Q2	Political archetype: explicit arrangement patterns vs. emergent	Yes — Layer 3 implementation blocked until resolved	Design
L3-Q3	Arterial road layout: explicit vs. district boundary implicit	No — minimum viable uses implicit (district boundary = street)	Scope
L3-Q4	Topographic constraints on zoning: city-local terrain roughness vs. treat all cities as flat	No — deferred in minimum viable slice	Design
L3-Q5	prosperity_baseline topographic contribution	No — gradient direction from FoundingOrientation already set; topography as secondary input	Design
L3-Q6	Sub-settlement depth: unified DistrictSkeleton path vs. simplified codepath for towns	No — functional, but cleaner architecture choice	Architecture
L3-Q7	Port/station direction: orbital station directional info in Layer 3	No — deferred	Scope
Weight table	Evaluate population+age baseline vs. retain/replace 10×9 table	Yes — Layer 3 generation blocked on this choice	Design
Multi-body	Add body_id to CityGenerationContext	Yes — cascade runs per body, struct must reflect this	Schema

Systems Design Assessment for Layer 3

The key insight from Amendment 6: The weight table is wrong about what it's modeling. It answers "what does this city PRODUCE" not "what do people in this city NEED." These are different questions with different correct answers.

• What a city produces → determines the dominant character and primary district types
• What a city needs → determines the baseline of services that exist regardless of production

Every populated settlement needs residential space, food access (commercial/agricultural), social venues (entertainment in some form), and some administrative presence. The weight table's mining row has zero Entertainment — but miners drink. The energy row has zero Commercial — but energy workers buy things.

See Part 5 for the full weight table challenge analysis.

FoundingOrientation spatial orientation (L3-Q1): This is a prerequisite, and I have a position. The spatial grid should rotate. Here's why it creates interesting gameplay:

A player arriving at a PortFacing city knows the logistics and transit districts are at the harbor edge. They approach from that direction to find work, access, trade. A DefenseFacing city has its administrative core at the elevated/central point — the player looking for governance contacts approaches the high ground. This directional legibility is an important gameplay mechanic. If FoundingOrientation only changes the prosperity gradient without spatial rotation, the player has no directional prediction advantage. Gradient direction change alone doesn't produce the navigation legibility that makes archetypes meaningful.

My recommended answer for L3-Q1: Spatial grid rotation. FoundingOrientation defines which edge of the district grid faces the founding attractor (water edge, resource edge, high ground, etc.) and weights district type placement toward that edge. This is more complex than gradient-only but produces legible city orientation that the player can read from approach.

Political archetype spatial arrangement (L3-Q2): My recommended answer: explicit arrangement for the primary archetypes (CompanyTown, AdminCapital, FreePort), emergent for secondary archetypes. The three primary archetypes each produce a recognizably different navigation challenge that the player can learn. Emergent-only produces less consistent legibility and wastes the investment in the archetype system.

---

Part 4: Layer 4 — Street-Level Rendering

Inventory

Category	Item	Status
Reusable	Chunk streaming architecture (chunk_streaming.rs)	Architecturally sound and tested. load_chunk() creates blank placeholders — needs hookup to generator.
Reusable	TileEntry struct upgrade	D-C7: Vec<TileEntry> with tile_id: TileId + walkable: bool. Locked.
Reusable	Phase 2 tile algorithm	Street skeleton first (door-per-block-edge), then building fill (density-driven rectangles). Confirmed Rounds 2-3.
Reusable	SeedChain for chunks	`chunk_seed = child_seed(district_seed, (cx << 32
Novel design	Economics-variable rendering mechanism (L4-Q1)	Three options — must choose. See analysis below.
Novel design	Condition update trigger (L4-Q2)	When/how does tile condition recalculate?
Novel design	Interior generation trigger (L4-Q4)	Pre-fetch, on-entry, or pre-generate?
Data/schema	Tile condition enum	`Intact
Data/schema	prosperity_delta (Amendment 5)	Always derived (prosperity_current - prosperity_baseline), never stored. Confirm this is the rendering input.

Open Questions After Amendments

ID	Question	Prerequisite?	Type
L4-Q1	Economics rendering mechanism: bake+event / compute live / cache+threshold	Yes — implementation decision blocks tile generator design	Architecture
L4-Q2	Condition update trigger	No (follows from L4-Q1 choice)	Design
L4-Q3	Phase 2 algorithm parameters: street corridor width, max building rectangle dimensions, gap rules	No — existing algorithm confirmed; parameters tunable	Tuning
L4-Q4	Interior generation trigger: pre-fetch / on-entry / pre-generate	No — on-entry (option b) is correct for minimum viable	Scope
L4-Q5	"Scatter civilization" scope: prop spawn points vs. decals vs. entity spawn	No — deferred to post-walkable-world	Scope
L4-Q6	prosperity_delta two-field model formal adoption	No (Amendment 5 resolves: derived only, never stored)	Data model

Systems Design Position: L4-Q1 — Economics Rendering Mechanism

My recommended answer: threshold-crossing cache invalidation (option c).

Reasoning:

• Districts are economically stable most of the time. A district crossing from Intact to Worn is a notable event — it should FEEL notable because it happens rarely.
• Thresholds: Intact ≥ 0.6, Worn 0.4-0.6, Cracked 0.2-0.4, Broken < 0.2. These match the four condition states and map to the prosperity_current value.
• Cache per chunk: condition state computed once on load, stored in chunk's in-memory representation, invalidated when prosperity_current crosses a threshold boundary.
• Threshold crossings are cheap to check each tick: one float comparison per district, not per chunk.

What this creates for gameplay: The transition is visible and discrete. A player who visits a district and returns later sees it has crossed a threshold — noticeably different tile conditions. This is more legible than continuous micro-degradation the player can't perceive. The discrete transition signals: "something changed here economically." That signal is meaningful.

Option (b) — compute live per frame — is wrong for a different reason: tile conditions are conceptually stable between economic events. Recomputing from prosperity_current every frame wastes cycles and produces no additional fidelity, since prosperity_current doesn't change every frame.

Option (a) — bake at generation + event update — requires an event system for prosperity changes to invalidate the baked conditions. More complex than threshold-crossing, and produces similar results.

Systems Design Position: L4-Q4 — Interior Generation

Recommended: option (a), pre-fetch when player is within N tiles of a door.

On-entry (option b) is simpler but creates a frame stall at the door threshold. Pre-fetch avoids the stall for the common case (player walks toward a door they intend to enter). The pre-fetch radius can be tuned — 2-3 tiles is sufficient to generate ahead of player movement speed.

For minimum viable: on-entry is acceptable and simpler. Pre-fetch is the target behavior.

---

Part 5: Weight Table Challenge — Systems Design Analysis

What the 10×9 Table Does

Maps economic_role → DistrictType probability weights. It answers: given what this city produces, what district types are likely?

What It Gets Wrong

It treats economic production as the sole driver of settlement composition. People who live in a settlement create demand regardless of what the settlement produces. A mining town's workers need:

• Residential (where they sleep)
• Commercial (basic goods, food, equipment)
• Entertainment (rough taverns, gambling, fighting arenas — exactly the kind miners would have)

The current extraction row weights: Ent = 0. That's wrong. The extraction row weights LogisticsHub at 30 and Industrial at 30 — but zero Entertainment produces a settlement where people live with no social venues. That's not a mining town, that's a labor camp.

The Proposed Alternative: Two-Layer Model

Layer 1 — Population baseline: What every settlement has because people live there.

Population	Minimum district set
< 1,000 (outpost)	1 Residential + economic role type
1,000–10,000 (town)	1 Residential, 1 Commercial/Mix, 1 primary economic type
10,000–50,000 (small city)	2+ Residential, 1 Commercial, 1 Entertainment, remainder from economic role
50,000+ (full city)	All essential types represented; economic role scales the proportions and character

WorldTier maps to district count ceiling (D-C4, locked). This doesn't change count — it changes the guaranteed minimum composition within that count.

Layer 2 — Economic role character modifier: Within each guaranteed type, the economic role determines CHARACTER, not presence.

Economic role	Residential character	Commercial character	Entertainment character
extraction	Worker barracks, austere	Supply depot, company store	Rough taverns, gambling
research	Faculty housing, lab districts	Specialist equipment, academic bookshops	Cultural venues, quiet bars
commercial	Varied, well-maintained	Dense, varied retail	Upscale entertainment
mining	Worker housing, dormitories	Company store, equipment	Brawling bars, fight clubs
frontier	Scattered, improvised	General goods, survival gear	Campfire social, informal

The character variations don't require different DistrictType labels — they're expressed through density_pct, prosperity_baseline, perimeter_treatment, and ultimately the tile-level building patterns.

What This Produces for Gameplay

• Every settlement with people feels inhabited. No zero-entertainment mining towns.
• District character varies meaningfully within types. Two Residential districts are distinguishable by their economic context.
• Player knowledge compounds. Learning "extraction Commercial is always a company store" is a useful prediction. Learning "research Entertainment has specific character" helps find contacts. The archetypes become player knowledge that pays off over time.
• Richer emergent variety. Same district type, different character → more distinct settlements without adding more types.

Recommendation

Replace the 10×9 weight table with the two-layer model. Retain the economic role → DistrictType proportionality concept (extraction cities DO have more Industrial and LogisticsHub), but add a guaranteed baseline floor from population, and express role differences through district character rather than district presence/absence.

The weight table can be repurposed as a character modifier table rather than a presence/absence table.

---

Part 6: Prerequisite Dependency Map

The order in which questions must be resolved. Questions higher in this map must be answered before questions below them can be implemented.

BEFORE ANY LAYER:
  [A] Spatial hierarchy dimensions locked (Amendment 4)
       └─ body-size to area-count formula
       └─ Province / Region tier dimensions confirmed

BEFORE LAYER 1:
  [B] Spatial hierarchy confirmed against 64×32 grid
       └─ Does 64×32 correspond to Province grid? Or Area grid?

LAYER 1 (independent of Layer 2 except via geographic feature output):
  [C] L1-Q2: River resolution decision
  [D] L1-Q3: Session DB confirmation (Amendment 1 replaces systems.db proposal)
  [E] Drainage algorithm performance evaluation (can it run in ~1s per body?)

BEFORE LAYER 2:
  [F] Layer 1 geographic feature tags computed (Layer 1 output)
  [G] Attractor-matching algorithm designed (Amendment 3 new)
  [H] Name reservation fulfillment data structure (Amendment 3 new)

LAYER 2:
  [I] L2-Q5: TerritorialStatus thresholds
  [J] L2-Q3: Road algorithm scope under Amendment 3

BEFORE LAYER 3:
  [K] Layer 2 political_archetype + FoundingOrientation per city (Layer 2 output)
  [L] Weight table challenge resolved (Amendment 6) — PREREQUISITE
  [M] L3-Q1: FoundingOrientation spatial grid orientation — PREREQUISITE
  [N] L3-Q2: Political archetype spatial arrangement — PREREQUISITE

LAYER 3:
  [O] L3-Q5: prosperity_baseline topography contribution
  [P] L3-Q6: Sub-settlement unified vs. simplified codepath
  [Q] CityGenerationContext body_id field added

BEFORE LAYER 4:
  [R] Layer 3 DistrictSkeleton Stages 1-2 (Layer 3 output)
  [S] L4-Q1: Economics rendering mechanism — PREREQUISITE

LAYER 4:
  [T] L4-Q2: Condition update trigger (follows from S)
  [U] L4-Q4: Interior generation trigger

Critical path: A → B → [C, D, E] → F+G+H → [I, J] → K+L+M+N → [O, P, Q] → R+S → [T, U]

Parallelizable work:

• Layer 1 and Layer 3 development can proceed in parallel once [A, B, L, M, N] are resolved
• Layer 2 and Layer 4 development can proceed in parallel once their respective prerequisites are met
• Economics simulation does NOT need Layers 1-2 spatial data (Amendment 1 rationale) — economics development proceeds independently

---

Part 7: Questions I'm Bringing to Round 2

I'm not waiting for convergence on these — I'm stating my positions now for other participants to react to.

Question	My position
L3-Q1: FoundingOrientation spatial effect	Spatial grid rotation, not gradient-only. Directional legibility is a gameplay mechanic.
L3-Q2: Political archetype arrangement	Explicit arrangement for primary archetypes (CompanyTown, AdminCapital, FreePort). Emergent for secondary.
L4-Q1: Economics rendering mechanism	Threshold-crossing cache invalidation. Discrete visible transitions, not continuous micro-degradation.
L4-Q4: Interior generation trigger	Pre-fetch within N tiles for target; on-entry for minimum viable.
Amendment 6: Weight table	Replace with two-layer model. Population baseline + economic role character modifier.
Attractor-matching	Constraint satisfaction: hard constraints (corp HQs) first, then scored greedy assignment by economic fit + population.
L1-Q3: River confluence storage	Session DB, not systems.db. Amendment 1 makes this the correct answer.
CL-Q3: Ruin lifecycle	Emergent rendering consequence only (Amendment 5 settled this). Not a design question for Round 2.

---

Part 8: One Question for Each Participant

Before Round 2 proposals, I want to understand where each participant stands on the design questions that touch their domains.

For Tyre: Amendment 1 changes the execution model significantly. What is the session DB actually? Is it SQLite (in-memory or file)? A custom Rust cache structure? How is it invalidated between game sessions? The session DB is referenced in the amendment but not defined. This affects how Layer 1-2 data is queried by Layer 3-4.

For Paula: The attractor-matching algorithm has a hard constraint: corp HQ cities must exist at name. But what about cities that are referenced by political structures (seat of government, contested region capital)? Are there additional hard constraints from the narrative layer beyond corporate cross-references?

For Burnelli-Sheldon: The weight table challenge. Do you defend the 10×9 table as producing plausible settlements at the extreme cases (energy row: 0 Commercial, 0 Entertainment), or do you see the same problem the lead identified? If you see the problem, what's your preferred resolution — baseline floor on the existing table, or full replacement?

For Ozzie: This is the first round with Ozzie on the team. My specific question: for each of the four cascade layers, what's the moment where the player should feel something? What's the "wow" the generation is building toward? I want to make sure the systems design produces those moments, not just functional generation.

---

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