---
title: "Workshop Brief"
description: "Audit the generation pipeline implementation state, map all layers from heightmap to walkable tile, produce D-records and ticket dependency flows"
type: workshop
status: active
workshop: generation-cascade
agent: ""
round: 0
created: 2026-04-24
---

# Generation Cascade Workshop Brief

**Goal:** Audit the full generation pipeline from planetary heightmaps to walkable tile environments. For each layer: document what exists, what's stub, and what's missing. Produce D-records and a ticket dependency chain that formally blocks character and apartment work behind the complete pipeline.

**Ticket:** #897
**Priority:** HIGH — load-bearing for Sprint 38 and all downstream Phase 4/5 work
**Participants:** Gestalt (systems design), Tyre (architecture/feasibility), Miri (worldbuilding/cultural inputs)
**Source:** Lead directive (2026-04-24): "we keep cycling back to these topics. I want them parked behind the full cascade from now on."

---

## Context

The generator-architecture workshop (2026-02-27) designed the full data model: DistrictSkeleton, BlockSkeleton, ChunkData, two-phase generation (Phase 1 skeleton, Phase 2 chunk fill). The outcomes are at `docs/workshops/generator-architecture/workshop-outcomes.md`.

**The architecture is designed. The implementation is mostly stubs.** The Rust types in `server/src/simulation/generator.rs` compile but no code actually produces filled instances. The team keeps drifting to character creation, apartment generators, and tycoon starting states — all of which sit several pipeline layers below what's actually built.

This workshop is NOT a redesign. It's an implementation audit and cascade formalization.

### What exists (confirmed working)

| Layer | What | Status |
|-------|------|--------|
| Galactic | System definitions, star data | Done — `systems.db`, wiki |
| System | Body definitions, orbital mechanics | Done — `systems.db` |
| Planetary surface | Heightmaps, terrain simulation | Done — `tooling/planet-gen/planet_simulation.py` |
| Atlas markers | City placement, roads, rail, rivers, mountains | Done — `tooling/planet-gen/generate_atlas.py`, `markers.json` |
| City naming | Gemma-driven cultural naming | Done — `tooling/planet-gen/gemma_naming.py` |
| Economics | Supply chains, corporations, brands, trade flows | Done — `tooling/economy-db/`, `systems.db` |

### What exists as types only (stubs, no generation logic)

| Layer | What | Location |
|-------|------|----------|
| District skeleton | `DistrictSkeleton`, `BlockSkeleton`, enums | `server/src/simulation/generator.rs` |
| Chunk streaming | Load/unload system | `server/src/simulation/chunk_streaming.rs` |
| Triangle system | `TriangleAssignment`, `TrianglePurpose` | `server/src/simulation/triangle.rs` |

### What's missing entirely

This is what the workshop must map. Suspected gaps include:
- Regional/continental subdivision (between heightmap and city)
- City-to-district decomposition (how does a city marker become N districts?)
- District skeleton generation (the actual Phase 1 code)
- Block fill / zoning assignment
- Chunk tile generation (Phase 2)
- Infrastructure placement within districts (roads, utilities at local scale)
- Vertical structure generation (multi-floor buildings)

---

## Key Questions to Resolve

### 1. Pipeline Inventory (all participants)

For each layer from planetary heightmap to walkable tile:
- What is the layer's input and output?
- What code/data exists today?
- What's the minimum viable implementation?
- What decisions from the generator-architecture workshop apply?

### 2. Layer Dependencies (Tyre)

- What is the strict dependency order? Which layers can be parallelized?
- Where are the data format boundaries (file vs. runtime, Python vs. Rust)?
- What's the testing strategy per layer? Can each layer be validated independently?

### 3. Cultural and Worldbuilding Inputs (Miri)

- At which layers do cultural inputs (society profiles, naming, architectural style) enter the pipeline?
- What wiki/content data is needed before each layer can generate?
- Are there content gaps that block generation even if the code existed?

### 4. System Interactions (Gestalt)

- How does each generation layer interact with the economics layer?
- Where do social sites, NPC population, and zone palettes enter?
- What's the minimum viable "viewable world" — the thinnest vertical slice from heightmap to rendered tiles?

### 5. Ticket Dependency Chain (all participants)

- What tickets exist for missing layers? What new tickets are needed?
- What is the formal dependency chain that blocks character work (#694, #619) and apartment work (#681, #682)?
- Which existing tickets (#615, #616) should be re-scoped or deferred?

---

## Workshop Format

**3 rounds:**

### Round 1 — Inventory
Each participant audits the pipeline from their domain perspective. List every layer, its state (done / stub / missing), inputs, outputs, and the key file paths. Write findings to `docs/workshops/generation-cascade/{agent}-round1.md`.

### Round 2 — Proposals
Based on the combined inventory, propose: the ordered implementation plan, the ticket dependency graph, and the D-records needed. Identify the thinnest vertical slice that produces viewable output. Write proposals to `docs/workshops/generation-cascade/{agent}-round2.md`.

### Round 3 — Convergence
Lock the D-records, finalize the ticket dependency chain, and produce the formal blockers. Each participant reviews the proposed D-records and flags disagreements. Write final positions to `docs/workshops/generation-cascade/{agent}-round3.md`.

---

## Required Reading

Before Round 1, all participants must read:
- `docs/workshops/generator-architecture/workshop-outcomes.md` — the designed architecture
- `server/src/simulation/generator.rs` — the current data model (stubs)
- `server/src/simulation/chunk_streaming.rs` — chunk load/unload system
- `tooling/planet-gen/generate_atlas.py` — what the atlas generator produces
- `decisions/architecture.md` — D-110 (signed z-levels), D-108 (MobileChunk)
- CLAUDE.md §Development Cascade — the phase definitions

---

## Expected Outputs

1. **D-record(s)** in `decisions/` defining the generation pipeline layers, their order, and their implementation status
2. **Ticket dependency graph** — new tickets for missing layers, `ticket_deps` entries blocking character/apartment work
3. **Updated existing tickets** — #615, #616, #619, #681, #682, #694 re-scoped or formally blocked
4. **Implementation priority order** — which layer to build next (informs #899 and future sprints)