settled-reach/docs/workshops/generation-cascade/workshop-outcomes.md

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

title	description	type	status	workshop	agent	created	decision_refs
Workshop Outcomes — Generation Cascade Workshop	Authoritative record of the generation-cascade workshop: original intent, scope corrections, round-by-round journey, all resolved decisions, what was locked and deferred, and how the workshop output became a new workshop brief	workshop	complete	generation-cascade	qatux	2026-04-30	D-194

Generation Cascade Workshop — Outcomes

Compiled by: Qatux
Dates: 2026-04-30 (all four rounds)
Status: Complete. Output delivered. Successor workshop brief produced.

---

What This Document Is

This is the authoritative record of the generation-cascade workshop. It documents the full journey — what the workshop set out to do, what changed and why across each round, what was resolved, what was deferred, and how the output became input to the next workshop.

The technical decisions are captured in detail in the per-round notes files. This document captures the narrative: why this workshop ran, what shape it took, and what came out of it.

---

Original Intent

The generation-cascade workshop was initiated to answer a specific question: can we implement the generation pipeline now, and if so, what's blocking us?

The context: character creation work (#694) and apartment generation (#681) were queued. Before committing implementation capacity to these systems, the team needed to know whether the world generation pipeline that would feed them was solid.

The brief framing: A 3-round implementation audit using a city-outward approach — start from the walkable city environment that the player would inhabit, trace every generation layer the city required, and determine which layers were implemented, which were stubs, and which were missing entirely.

The blocking intent: Several tickets (#681, #694, character apartment work) would not be formally unblocked until the generation pipeline was either proven complete or proven to have a clear implementation path with scoped tickets.

Initial participants: Gestalt (systems design), Tyre (technical architecture), Miri (worldbuilding and content).

---

Round 1: The Inventory

Question: What does the pipeline look like? What works, what's stubbed, what's missing?

What the round found

All three participants independently converged on the same finding: the pipeline has a hard operational cliff at Layer 5 (atlas markers). Everything above the cliff — galactic definitions, planetary heightmaps, city placement, economics layer — is working production code. Everything below the cliff is either missing or compiled stubs with no generation logic.

The two critical missing layers:

• Layer 6: City → District decomposition — no design, no code, no ticket. The missing link between atlas output and walkable world.
• Layer 9: Phase 2 ChunkData tile generation — entirely absent. GeneratorChunkData = Vec<bool>. No tile vocabulary. No fill logic.

Additional findings:

• WorldTier enum in generator.rs uses wrong values (Peripheral | Connected | Core) instead of the workshop-canonical values (Epicenter | Regional | Backwater | Passage | Waypoint). Hard blocker for all downstream work.
• DistrictSkeleton fields compile but are pub type Foo = String — zero generation logic.
• The triangle system (triangle.rs) is substantially more complete than the brief indicated — it was incorrectly labeled as stubs. Wiring gap, not code gap.
• chunk_streaming.rs is architecturally sound and tested; load_chunk() just creates blank placeholders instead of calling a generator.

Content gaps (Miri)

Miri's audit identified content gaps orthogonal to the code gaps:

• Heritage root blend specification missing — culture RON files don't include heritage blend weights
• HeritageGrammarOverlay data files don't exist for any of the 10 heritage roots
• Zone identity definitions missing for 7 of 9 DistrictType values
• City marker schema insufficient for Phase 1 inputs (primary_function, planet_class, settlement_pattern not in markers.json)

Round 1 open questions: 8 items (OQ-R1-A through OQ-R1-H). Critical blockers: heritage root count disagreement (7 vs. 10), SocietyProfileRef type design, atlas coordinate translation question.

---

Scope Correction: Between Round 1 and Round 2

The lead intervened between rounds to restructure scope.

Before Round 2 launched, the lead issued a directive removing the following from workshop scope:

• Heritage grammar overlay (#615, all associated heritage content)
• NPC population systems
• Social sites generation
• #615 (Tycoon starting state) — treated as out of scope for this workshop entirely

Why this mattered: Tyre's Round 1 estimate (~9 dev-days for the minimum vertical slice) was contaminated by heritage grammar scope. Once removed, estimates would converge. More importantly, the city-outward audit had been dragging attention to Phase 6 content (cultural room grammar, NPC bundles, heritage overlay) when Phase 5 walkable world generation hadn't been designed yet.

What got dropped from the participants list: Miri did not have a role in Round 2 or later. Her content audit (Round 1) was valid, but the workshop pivoted to spatial pipeline work.

Round 2 added: Paula (narrative + political depth), who had spatial analysis relevant to the pipeline that neither Gestalt nor Tyre were covering.

---

Round 2: The Spatial Pipeline

Question: Given spatial-only scope, what does the implementation order look like? What are the key architecture decisions?

New participant: Paula (narrative/political depth, spatial signals in generation).

Technical resolutions

Two Round 1 open questions resolved by independent convergence:

OQ-R1-C (City marker schema): Do not extend markers.json. primary_function, planet_class, settlement_pattern are read from systems.db bodies table by cross-reference on body_id. markers.json stays as a pure spatial + naming store.

OQ-R1-D (Atlas coordinate translation): No formula needed. Atlas coordinates are UI-only (display coordinate system for the atlas UI). The walkable world uses city-local sim-tile coordinates from (0,0). Districts in a city are placed at (col × 512, row × 512) sim tiles in city-local space.

Stored-vs-derived boundary locked: Atlas markers are the last stored layer. Everything at Layer 6 and below is seed-derived at runtime. Save files store: world_seed + markers snapshot hash + ChunkMutations only.

SeedChain algorithm confirmed: FNV-1a child_seed(parent, discriminant) for all randomness below the atlas layer. Any district or chunk can be generated in isolation without generating neighbors first.

Effort converged: ~6 dev-days (spatial scope only, Stages 1-2 minimum). Round 1's 9d estimate was heritage-contaminated.

Implementation order locked (5-step sequential chain):

1. Fix WorldTier enum (0.5d)
2. Single-district decomposition stub (0.5d)
3. Phase 1 Stages 1-2 generation (1.5-2d)
4. Phase 2 minimal tile generator (1.5d)
5. Chunk streaming wiring (0.5-1d) → Minimum Viable Walkable World

Paula's additions

Paula introduced four spatial concepts not addressed by Gestalt or Tyre. These required Round 3 disposition:

• prosperity_index: f32 on DistrictSkeleton — scalar driving tile decay, road width, building density, green space
• perimeter_treatment: PerimeterTreatment on DistrictSkeleton — boundary marker enum (Open/Fenced/Walled/Gated/Checkpoint)
• political_archetype per city — formal derived field (CompanyTown/AdminCapital/FreePort/Contested/OrganicGrowth)
• Naming registers — (DistrictType, WorldTier) → register lookup table; name pool population deferred as cultural content

Paula's argument for including prosperity_index and perimeter_treatment before Phase 2: if they're not on DistrictSkeleton before Phase 2 is implemented, tile generation produces spatially indistinguishable spaces regardless of district type — and retrofitting is a Phase 2 rewrite.

D-record candidates from Round 2 (D-C1 through D-C8)

ID	Decision
D-C1	Generation pipeline layer definitions (canonical layer sequence with storage policies)
D-C2	Stored-vs-derived transition — atlas markers are the last stored layer
D-C3	Phase 1 minimum spatial scope — Stages 1-2 mandatory, Stages 3-5 deferred
D-C4	City → district decomposition formula (population/50,000 + WorldTier ceilings)
D-C5	City-local coordinate system for districts (atlas is UI-only; no pixel-to-tile formula)
D-C6	SeedChain algorithm — FNV-1a child_seed(parent, discriminant)
D-C7	GeneratorChunkData type upgrade — Vec<bool> → Vec<TileEntry> with tile_id + walkable
D-C8	Spatial class legibility requirements — prosperity_index, perimeter_treatment, layout_mode on DistrictSkeleton (Paula; not yet confirmed by Gestalt/Tyre)

Round 2 open questions: 7 items (OQ-R2-1 through OQ-R2-7). Most critical: prosperity_index and perimeter_treatment inclusion (OQ-R2-1), political_archetype formality (OQ-R2-2), Phase 2 tile algorithm choice (OQ-R2-3).

---

Round 3: The Phase 3 Reframe

Question: What does Phase 3 (the map/atlas layer, before Phase 5 runtime generation) actually need to produce?

New participant: Burnelli-Sheldon (economics + simulation modeling), added to provide quantitative economic grounding for the district generation bridge.

The corrective

Early in Round 3, Tyre identified a structural problem with the workshop framing:

"Rounds 1 and 2 were auditing and designing Phase 5 (runtime tile generation). Phase 3 — which produces the regional maps that Phase 5 consumes — had not been designed at all."

This was correct. The city-outward audit had jumped from atlas markers (Phase 3 output) directly to district generation (Phase 5), skipping the intermediate layer that was supposed to enrich the atlas with regional data: road networks, biome grids, station topology, city classification data.

The reframe: Phase 3 requires a new Python generator (generate_regional.py) running third in the make regen-db pipeline. It enriches systems.db with city classification, regional biome data, road graphs, station topology, and (debated) sub-settlement hierarchy. All Phase 3 computation is offline. Phase 5 reads its output at startup via a Rust struct (CityGenerationContext). Both phases are fully parallelizable during development.

Key consensus

All four participants independently arrived at the same Phase 3/Phase 5 boundary:

• Phase 3 = Python tooling, offline, committed to systems.db
• Phase 5 = Rust runtime, seed-derived, never stored
• The two phases do not block each other during development

All four participants agreed on Phase 1 scope (OQ-R2-1 resolved): prosperity_index and perimeter_treatment must be on DistrictSkeleton before Phase 2. Retrofit cost exceeds add-now cost.

All seven Round 2 open questions resolved by Round 3.

Paula's Phase 3 additions

Paula introduced six new spatial/political fields all derivable from existing systems.db data:

• TerritorialStatus — six-value enum for regional political classification (CoreTerritory/FrontierTerritory/ExtractiveZone/ContestZone/WildernessBuffer/AbandonedZone)
• FoundingOrientation — five-value enum for city founding direction (PortFacing/RailHeadFacing/ResourceFacing/DefenseFacing/AdminFacing)
• MaintenanceAuthority on road segments — five-value enum (Administrative/Corporate/Communal/Trade/Abandoned)
• PoliticalTether per sub-city settlement — relationship classification to nearest tether city
• DualNaming/RegionalFeatureName — ContestZone naming conditions
• Settlement hierarchy (town/outpost/waypoint/rural cluster/ruin tiers)

Burnelli-Sheldon's economics bridge

Burnelli-Sheldon provided:

• 6-field minimum read set — all fields queryable from systems.db per city; sufficient to produce a spatially differentiated Phase 1 skeleton without additional authoring
• 10×9 economic_role → DistrictType weight table — canonical probability weights mapping all 10 economic_role values to all 9 DistrictType values
• Three concrete differentiation cases demonstrating how the same DistrictType produces different spatial character from economic data alone (Tributarium/Bluebank/Strata)
• prosperity_index derivation formula with distribution_index = stratified vs. moderate paths
• Three narrow fields requiring post-generation reporting back to the economics simulation (effective port tile count, corp district allocation, shadow economy footprint)

Disagreements remaining after Round 3

Gap	Gestalt/Paula position	Tyre's implicit position
TerritorialStatus	Dedicated Phase 3 Layer D, in CityGenerationContext	Not addressed; absent from layer design
FoundingOrientation	Layer A output, in CityGenerationContext	Absent from struct
Sub-settlement hierarchy	atlas_sub_settlements table, PoliticalTether derivation	Land-use annotation only
MaintenanceAuthority on roads	atlas_road_edges schema column	Absent from schema

D-record candidates from Round 3 (D-C9 through D-C17)

ID	Decision
D-C9	Economic fields → generator parameter mapping (6-field minimum read set, 3-query pattern)
D-C10	economic_role → DistrictType weight table (10×9 canonical default)
D-C11	Phase 3 layer sequence and tooling architecture (generate_regional.py as third generator)
D-C12	CityGenerationContext as Phase 3 → Phase 5 handoff struct (minimum agreed fields)
D-C13	Phase 3 LoD cascade — stored boundary extended to include Phase 3 outputs
D-C14	generate_regional.py pipeline integration rules (meta stamp, GENERATOR_SOURCES, flags, order)
D-C15	TerritorialStatus enum definition (6 values, derivation algorithm) — Paula/Gestalt; Tyre not yet reviewed
D-C16	FoundingOrientation enum (5 values, derivation from settlement_pattern + economic_role) — Paula/Gestalt; Tyre not addressed
D-C17	MaintenanceAuthority on road segments (5 values, derivation from endpoint relationships) — Paula/Gestalt; absent from Tyre schema

Four lead decisions identified before Phase 3 schemas could be finalized (OQ-R3-1 through OQ-R3-4):

1. Is TerritorialStatus in Phase 3 scope?
2. Is FoundingOrientation in Phase 3 Layer A?
3. Does Phase 3 include sub-settlement hierarchy?
4. Does atlas_road_edges include maintenance_authority?

---

Round 4: The Planet-Down Reframe

Question: Requirements gathering for the next workshop brief. What does each cascade layer need to produce, and for what purpose?

The lead's reframe: The lead rejected the city-outward framing at the start of Round 4 and restated the correct causal direction:

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

This reframe replaced the Phase 3 layer map (which had been designed city-outward as "what does the city need") with a four-layer cascade (which starts from geology and civilizes down to street tiles):

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

The two governing rules

Gestalt identified two rules that became the architectural spine:

DETERMINISM RULE: Economic simulation's rolling state affects RENDERING (prosperity, repair state) but NOT LAYOUT (streets and buildings locked by seed).

LOD/ZOOM RULE: When a player spawns, the code "zooms in" on the planet — tracing all cascade steps to where the player sits, filling in street-level detail where the player is. The cascade is lazy; only what the player needs is computed.

How Round 3's disagreements resolved

The planet-down reframe resolved all four Round 3 lead decisions without requiring a separate decision session:

OQ-R3-1 (TerritorialStatus scope): Resolved by Paula. TerritorialStatus is a Layer 2 post-processing output — one classification pass after settlement placement and road generation complete. Not a dedicated layer. Costs one pass, not a separate architecture layer. The Gestalt/Tyre debate about Layer D is closed.

OQ-R3-2 (FoundingOrientation): Resolved by Paula. In the planet-down cascade, FoundingOrientation is directly readable from the geographic trigger that caused the settlement to exist. No authoring pass required. Included in CityGenerationContext.

OQ-R3-3 (Sub-settlement hierarchy): Resolved by the lead's cascade description. Sub-settlements are explicitly stated as included in Layer 2 ("Sub-settlements INCLUDED"). Confirmed in Tyre's brief as a Given Fact.

OQ-R3-4 (MaintenanceAuthority on roads): Resolved by Paula. MaintenanceAuthority falls directly from road endpoint relationships at road generation time. Derivable at generation — no separate schema decision beyond adding the column.

Paula's "Geography Is Political History" framing

Paula provided the narrative rationale for the planet-down ordering and connected all accepted proposals to their correct cascade layer positions. Key contributions:

• Layer 1 geographic feature tags (RiverConfluence/CoastalHarbor/MountainPass/ArablePlain/ResourceConcentration/Defensible/NaturalBarrier) as mandatory named settlement attractors
• FoundingOrientation is readable from geographic trigger — no authoring
• TerritorialStatus derivation confirmed as Layer 2 post-processing
• prosperity_delta architecture: seed-locked prosperity_baseline (what the district was planned as) + sim-driven prosperity_delta (what current state says) = ghost city effect narrative
• Ruins as structural permanence: settlement physical structure persists even when economic basis is gone

Burnelli-Sheldon's latent settlement principle

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

The generator places ALL economically plausible settlement positions at Layer 2. Whether each settlement is ACTIVE is determined by the economic simulation's rolling state. An inactive settlement exists spatially as ruins or empty structures.

This means ghost towns are generated, not scripted. The road to the closed mine still exists. The buildings of the abandoned outpost are still there.

Tyre's brief assembly

Tyre assembled all Round 4 material into docs/workshops/planet-down-cascade/BRIEF.md. This is the primary deliverable of the generation-cascade workshop.

The brief separates:

• Given Facts — all decisions locked by Rounds 1-4, not to be revisited
• Workshop Sections — the open design questions the next workshop must resolve

Notable decisions encoded in Given Facts:

• CityGenerationContext struct with prosperity_baseline field name (resolves the Round 4 naming question: prosperity_baseline = seed-locked Layer 3 output; prosperity_current = runtime simulation state — these must never be conflated)
• Latent settlement principle
• Determinism boundary table per layer
• LoD zoom-in cascade diagram
• All D-C1 through D-C12 candidates treated as locked

---

Full D-Record Candidate Register

All D-record candidates produced by this workshop, with current status:

ID	Decision	Status in planet-down brief
D-C1	Generation pipeline layer definitions	Incorporated as Given Facts (pipeline architecture section)
D-C2	Stored-vs-derived transition — atlas markers are last stored layer	Given Facts: "Atlas markers are the last stored layer"
D-C3	Phase 1 minimum scope — Stages 1-2 mandatory, Stages 3-5 deferred	Given Facts: "District Skeleton (Phase 1 Minimum Scope)"
D-C4	City → district decomposition formula	Given Facts: "City Decomposition (D-C4)"
D-C5	City-local coordinate system (atlas = UI-only)	Given Facts: "Atlas coordinates are UI-only"
D-C6	SeedChain algorithm (FNV-1a child_seed)	Given Facts: "Seed Chain" section with full code
D-C7	GeneratorChunkData upgrade to Vec<TileEntry>	Given Facts: "GeneratorChunkData Upgrade"
D-C8	Spatial legibility requirements (prosperity_baseline, perimeter_treatment)	Given Facts: "District Skeleton (Phase 1 Minimum Scope)" — field names updated to prosperity_baseline
D-C9	6-field minimum economics read set	Given Facts: "Economics: 6-Field Minimum Read Set"
D-C10	10×9 economic_role → DistrictType weight table	Given Facts: full table reproduced
D-C11	Phase 3 layer sequence and tooling architecture	Given Facts: "Pipeline Architecture" table
D-C12	CityGenerationContext as Phase 3 → Phase 5 handoff struct	Given Facts: full struct definition with prosperity_baseline
D-C13	Stored boundary extended to Phase 3 outputs	Given Facts: "Pipeline Architecture"
D-C14	generate_regional.py pipeline integration rules	Given Facts: "generate_regional.py is the third pipeline generator"
D-C15	TerritorialStatus enum (6 values)	Resolved: TerritorialStatus is Layer 2 post-processing output (Paula Round 4). Enum confirmed. Layer D debate closed.
D-C16	FoundingOrientation enum (5 values)	Resolved: directly readable from geographic trigger. In CityGenerationContext (Given Facts struct).
D-C17	MaintenanceAuthority on road segments (5 values)	Resolved: derivable at road generation time. Included in Layer 2 Required Outputs.

Note on formal D-NNN assignment: These D-C candidates were assigned permanent IDs (D-194 through D-219) during the planet-down-cascade workshop. See docs/workshops/planet-down-cascade/workshop-outcomes.md for the full placeholder-to-real-ID mapping table.

---

What Was Locked

The following architectural decisions are locked. The planet-down-cascade workshop brief treats them as Given Facts and they must not be revisited:

1. Phase 3/Phase 5 split: Python tooling + systems.db / Rust runtime + seed-derived
2. Phase parallelizability: Phase 5 can stub CityGenerationContext and wire to systems.db when Phase 3 is done
3. generate_regional.py as the third pipeline generator with meta stamp and pre-push hook integration
4. Atlas markers as the last stored layer — everything from Layer 3 down is seed-derived
5. No markers.json extension — city attributes via systems.db cross-reference on body_id
6. Atlas coordinates are UI-only — no pixel-to-sim-tile formula
7. FNV-1a SeedChain — child_seed(parent, discriminant) for all randomness below atlas layer
8. CityGenerationContext struct with prosperity_baseline: f32 (seed-locked) — distinct from prosperity_current: f32 (runtime sim state)
9. prosperity_baseline naming — the field previously called prosperity_index is now prosperity_baseline to prevent conflation with runtime state
10. City decomposition formula — max(1, floor(population / 50_000)) with WorldTier ceilings
11. Phase 1 Stages 1-2 minimum — classification + 4×4 block grid; Stages 3-5 deferred
12. WorldTier enum — Epicenter | Regional | Backwater | Passage | Waypoint (replaces the wrong Peripheral | Connected | Core)
13. GeneratorChunkData upgrade — Vec<TileEntry> with tile_id: TileId + walkable: bool
14. Minimum tile vocabulary — floor_street | floor_interior | wall
15. 6-field minimum read set — the economics query pattern for Phase 3/Phase 5
16. 10×9 DistrictType weight table — locked canonical default, tunable but not relitigated per sprint
17. Sub-settlement hierarchy — six tiers included as lead confirmation; placement triggers confirmed
18. Latent settlement principle — all economically plausible positions placed at Layer 2; active/ghost driven by sim
19. Determinism boundary per layer — explicit table of what is seed-locked vs. economics-variable
20. LoD zoom-in cascade — lazy cascade from planet level to player tile; DistrictMap only exists for cities the player is near
21. TerritorialStatus as Layer 2 post-processing — six values, derived after settlement placement + road generation complete
22. FoundingOrientation from geographic trigger — directly readable; no authoring required
23. MaintenanceAuthority on road segments — derivable from endpoint relationships at generation time
24. Ghost city effect architecture — prosperity_baseline (seed-locked) + prosperity_delta (sim-driven) = effective prosperity; the gap is the narrative

---

What Was Deferred

The following items were proposed, discussed, and explicitly deferred:

From Phase 1 (DistrictSkeleton):

• Stage 3: Reservations (MultiBlockReservation, terminal sites)
• Stage 4: Social sites + NPC population
• Stage 5: Guarantee audit
• FoundingOrientation-modified district placement grid (gradient direction only in minimum slice)
• Explicit arterial road layout within city (district boundaries = implicit streets in minimum slice)
• Topographic constraints per district (all cities treated as flat in minimum slice)

From Phase 2 (tile generation):

• Tile condition overlays (economics-variable rendering) — implement after walkable world exists
• Building interior tile generation beyond door-per-edge boundary
• Prop/decal scatter and entity spawn points
• Heritage grammar overlay (removed from scope entirely — Phase 6 territory)

From Phase 3 (generate_regional.py):

• Agricultural dispersed node exact placement (land_use tag sufficient for minimum)
• Shadow node placement (needs collection_efficiency data quality improvement first)
• DualNaming/common_name generator vs. authored-only

From the economics layer:

• behavioral_archetype backfill pass in import_economics.py (needed before Layer 3 but not blocking Layer 2)
• scope field normalization on corporations table

Naming registers:

• Lookup table (DistrictType, WorldTier) → register deferred to post-walkable world
• Name pool population deferred entirely (cultural/heritage content, not spatial pipeline work)

---

Open Questions Carried into the Next Workshop

These are the questions the planet-down-cascade workshop must answer before Layers 1-4 can be implemented:

Must be resolved before Layer 1:

• L1-Q1: Authored rivers vs. seeded drainage network — what is the relationship? Do authored markers.json river polylines get replaced by generated drainage, or do they anchor the generated network?
• L1-Q2: River resolution — regional-only (64×32) or intermediate resolution? Determines whether river data belongs in systems.db or is seed-derived at Phase 5.
• L1-Q3: Stored vs. derived for river data — confluence points must be queryable before Layer 2 runs.

Must be resolved before Layer 2:

• L2-Q1: City positions — anchored with geographic explanation attached (generate_regional.py reads geography for each city but cannot move its position) vs. re-derived from attractors (generator places cities from geography, uses markers.json for population counts only).
• L2-Q5: TerritorialStatus quantitative derivation thresholds — what are the concrete numbers for CoreTerritory vs. FrontierTerritory vs. ContestZone?
• L2-Q6 / OQ-R4-B1: Latent settlement active/ghost flag storage — in a systems.db Phase 3 output table (recommended) vs. runtime ECS component vs. purely computed from current sim state.

Must be resolved before Layer 3:

• L3-Q1: FoundingOrientation spatial grid orientation — does it modify district placement grid positions (spatial rotation), or only modify the prosperity gradient direction?
• L3-Q2: Political archetype as spatial arrangement — explicit spine/center/nodes patterns, or emergent from weight table?

Must be resolved before Layer 4:

• L4-Q1 / OQ-R4-G2: Economics-variable rendering mechanism — bake at generation + update on event; compute live from prosperity_current per frame; or cache per chunk, invalidate on threshold crossing.
• CL-Q2 / OQ-R4-B2: Regional land-use evolution resolution boundary — runtime regional_land_use column update vs. ChunkMutations.
• L4-Q6 / CL-Q1: prosperity_delta two-field architecture — formal adoption as named architectural decision.

---

The Output: docs/workshops/planet-down-cascade/BRIEF.md

The primary deliverable of the generation-cascade workshop is a new workshop brief.

docs/workshops/planet-down-cascade/BRIEF.md was assembled by Tyre from Round 4 material. It contains:

1. The Lead's Cascade Vision — reproduced verbatim as authoritative framing
2. Given Facts — all decisions from Rounds 1-4 that are locked, including: pipeline architecture, seed chain, CityGenerationContext struct, city decomposition formula, Phase 1 minimum scope, WorldTier enum, GeneratorChunkData upgrade, 6-field read set, 10×9 weight table, sub-settlement hierarchy, latent settlement principle, determinism boundary per layer, LoD cascade
3. Four workshop sections (Layer 1 through Layer 4) each with specific open questions (L1-Q1 through L4-Q6)
4. Cross-layer questions (CL-Q1 through CL-Q4)
5. Workshop format — 3 rounds: Round 1 inventory and framing, Round 2 algorithm proposals, Round 3 convergence and D-records
6. Required reading list — round-3 notes, tyre-round3.md, existing server code files, decisions/architecture.md, Round 4 domain files
7. Expected outputs — algorithm specifications, data format handoffs, D-records, implementation ticket dependency chain, resolved open questions

---

How the Workshop Evolved

The generation-cascade workshop did not end where it started. The journey:

1. Started as: A 3-round implementation audit with a city-outward framing — trace the generation layers a walkable apartment would need
2. After Round 1: Scope narrowed (heritage grammar / NPC / #615 removed); participant list adjusted; city-outward framing retained
3. After Round 2: Phase 3 corrective — the workshop had been designing Phase 5 without designing Phase 3; generate_regional.py framing introduced
4. After Round 3: Four unresolved lead decisions; planet-down reframe needed; a fourth round launched to gather requirements for a new brief
5. After Round 4: All Round 3 decisions resolved; governing rules (Determinism + LoD) named; new workshop brief assembled; workshop closed

The city-outward framing produced valid technical work (Rounds 1-2: all D-C1 through D-C8 candidates, effort estimates, implementation order). The Phase 3 corrective (Round 3) caught the missing layer. The planet-down reframe (Round 4) gave the correct causal ordering that makes the full cascade coherent.

The workshop did not produce implementation — it produced a brief that will enable the implementation workshop to proceed without foundational architecture questions.

---

Document compiled by Qatux from all four round sources. This is the authoritative record of what happened in the generation-cascade workshop. For technical details, see round-1-notes.md through round-4-notes.md. For the output brief, see docs/workshops/planet-down-cascade/BRIEF.md.