settled-reach/docs/workshops/generation-cascade/miri-round1.md

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

title	description	type	status	workshop	agent	round	created
Miri Round 1 — Worldbuilding and Cultural Input Inventory	Audit of cultural and worldbuilding inputs required at each generation pipeline layer; content gap analysis; ticket dependency observations	workshop	active	generation-cascade	miri	1	2026-04-30

Generation Cascade Workshop — Round 1: Miri (Worldbuilder)

Topic: Worldbuilding and cultural input inventory for the generation pipeline Date: 2026-04-30 Focus: At which layers do cultural inputs enter? What content data is needed? What's missing that would block generation even if code existed?

---

Preamble

This is an audit, not a design session. I am mapping what exists, what's missing, and where cultural content must be authored before code can run. The architecture is designed — I am not revisiting it. What I am verifying is whether the worldbuilding inputs that architecture requires are actually available.

Short answer: the content situation is better than I expected at the city-naming layer and substantially worse than expected at the district-interior layer. The cultural infrastructure that feeds Phase 1 district skeleton generation is underspecified. Phase 2 chunk fill has zero authored data to work with.

---

Setting Note — Van Maanen's Star Naming Ambiguity

Before the pipeline audit, I need to flag a setting inconsistency that will surface in every worldbuilding discussion about the primary test case.

D-036 identifies the primary setting as "Van Maanen's Star." In the current wiki, two systems are plausibly this:

• GJ-35 (Vuurkloof) — the real-astronomy Van Maanen's Star. DG white dwarf. South African (Cape/Afrikaner) heritage founding community. Geothermal habitation. No Station Sova. Its Calibration Note explicitly identifies it as "Van Maanen's Star, the nearest known solitary white dwarf."

• GJ-280B (Sova) — K-type star in the core. Slavic-heritage founding community of construction engineers. Manufacturing and habitat fabrication economy. Contains Station Sova. The GJ-280B wiki stub references D-036 setting details and matches the logistics hub character.

The cultural-generation-guide.md and culture-van-maanens-star.ron both label the working-class freight district culture as "Vuurkloof cultural profile" / "Van Maanen's Star Culture," suggesting the two names refer to the same cultural root, not the same star. This reading: Vuurkloof (GJ-35) produced the culture that spread outward; Station Sova (GJ-280B) is where that culture manifests in the current game setting.

The culture RON file culture-van-maanens-star.ron is the authoritative content. It is operational, validated in the voice pipeline, and correctly models the setting. The naming ambiguity is a wiki documentation gap, not a content error. What is needed is a formal wiki/cultural-groups/van-maanens-star.md entry that clarifies the relationship and serves as the canonical reference for generator inputs.

Action needed (content, not design): Author wiki/cultural-groups/van-maanens-star.md using the existing cultural-group template. The content exists across D-036, D-050, culture-van-maanens-star.ron, and cultural-generation-guide.md. It needs to be assembled into a single canonical page.

---

Layer-by-Layer Pipeline Audit

Layer 1: Galactic — System definitions, star data

Status: DONE (systems.db, wiki star-system pages, ~230+ system index entries)

Cultural inputs at this layer: None at generation time. System names, WorldTier, economic profile, faction presence, and settlement age are authored in wiki pages and systems.db. These are the source material for everything downstream.

What exists:

• wiki/star-systems/ — 230+ system directories with index.md entries at varying completion levels
• wiki/star-systems/catalog.md — system index
• GTTR guide files (gttr-core.md, gttr-north.md, etc.) — narrative characterizations per region
• systems.db — canonical economic data per system (populated by import_economics.py)

Content gaps at this layer:

• Many index.md files contain only stub content ("Pending generation"). The narrative character, faction notes, and silence topics are missing for a significant portion of the catalog. These don't block Phase 1 district skeleton generation directly — the required fields (world_tier, economic_profile) come from systems.db, not from the wiki narrative text. But they block cultural depth at later layers.

No action required to unblock Phase 1.

---

Layer 2: System/Orbital — Body definitions, orbital mechanics

Status: DONE (systems.db, bodies tables)

Cultural inputs at this layer: System WorldTier assignment. This is the top-level simulation fidelity budget that everything downstream inherits.

What exists:

• Body tables in systems.db with gravity, atmosphere class, hydrosphere, economy type, settlement wave, industrial focus
• These fields implicitly carry cultural information (settlement wave → settlement age → architectural character)

Critical gap: No formal system → heritage root mapping.

The SocietyProfileRef field on DistrictSkeleton is typed as String — a stub. The generator will need to resolve a system to a heritage root blend to fill this field. Example: Van Maanen's Star → [Iron(0.4), Stone(0.3), Tide(0.3)]. No authored file establishes these mappings for any system.

This is the upstream content dependency for Phase 1 district social structure. The culture RON files (culture-van-maanens-star.ron, etc.) provide NPC voice/behavior data but do NOT include heritage root blend weights. The generator cannot derive heritage blend from the culture file as currently structured.

Content gap — CRITICAL for Phase 1: Heritage root blend specification per system is entirely missing. It must be authored before Phase 1 can assign SocietyProfileRef to districts with any cultural meaning.

---

Layer 3: Planetary Surface / Heightmaps

Status: DONE (tooling/planet-gen/planet_simulation.py)

Cultural inputs at this layer: None. Terrain is physically simulated from stellar parameters. Cultural inputs are not relevant at this stage.

No content gaps from a worldbuilding perspective.

---

Layer 4: Atlas Markers — City placement, roads, rail, rivers, mountains

Status: DONE (tooling/planet-gen/generate_atlas.py, markers.json per body)

Cultural inputs at this layer: City names, road network character, river/mountain names.

What exists:

• gemma_naming.py — operational cultural naming pipeline using Gemma 4 via sr-voice
• naming_core.py — cultural corridor-aware batch naming with dedup and blocklist
• City markers: {"id": "city_0", "name": "Glødberg", "kind": "capital", "center": [235, 394], "population": 8200} — names are populated by Gemma naming
• Earth blocklist (earth_blocklist.txt) prevents major real-world cities from appearing

What is missing from markers.json city entries: Current city marker fields: id, name, kind, center, population. That is all.

Ticket #899 (District skeleton generator — Phase 1 implementation) describes reading primary_function, planet_class, and settlement_pattern from city entries to derive SettingType, ComplexityTier, and DistrictLayoutMode. These fields do not exist in the current markers.json schema.

This is a data pipeline gap between Layer 4 (atlas markers) and Layer 6 (district skeleton). Either: a) The city marker schema needs extending with cultural/functional fields, or b) Phase 1 derives these from systems.db body/economy data cross-referenced by city position

Action needed: Clarify with Tyre which approach is intended. If option (a), define the new city marker fields and update generate_atlas.py to populate them. If option (b), document the cross-reference logic. Either way, markers.json is currently insufficient for Phase 1 input.

Cultural corridor definitions are embedded in naming_core.py prompts and not documented anywhere in the wiki. This is a maintainability gap — if a content author needs to understand why a region's names sound the way they do, there is no wiki document to consult. This is not a generation blocker but is a documentation debt.

---

Layer 5: Economics — Supply chains, corporations, brands, trade flows

Status: DONE (tooling/economy-db/, systems.db, wiki/economics/)

Cultural inputs at this layer: Corporation identities, brand heritage tags, currency zone characters.

What exists:

• wiki/economics/corporations/ — brand and corporation TOML files
• wiki/economics/commodities.toml — commodity catalog
• wiki/economics/currency_zones.toml — currency zone definitions
• wiki/economics/production_chains.toml — supply chain definitions

No significant content gaps from a worldbuilding perspective for current Phase 2 economics layer.

Setting note: the currency_preference field on corporations mirrors their HQ booking zone currency — this is consistent with the economics convention documented in memory. Economics layer is healthy.

---

Layer 6: District Skeleton — Phase 1 (STUB)

Status: STUB — data model exists, no generation logic

Key file: server/src/simulation/generator.rs

Cultural inputs at this layer (per workshop architecture):

Phase 1 has 5 stages. Cultural inputs enter at stages 1, 2, and 4:

Stage 1 — Classification (WorldTier, ComplexityTier, SettingType)

Cultural input needed:

• SettingType: derived from city kind + body economy type (Urban, Station, Agricultural, etc.)
• WorldTier: inherited from system-level data
• ComplexityTier: derived from WorldTier + population + economic function

Data available: systems.db has body economy type and settlement data. City kind (capital, settlement, outpost) provides coarse classification. Gap: No authored mapping rules from (economy_type, city_kind, world_tier) → SettingType. These rules need to be defined somewhere for the generator to apply them.

Stage 2 — Block Grid (DistrictLayoutMode, BlockSkeleton ×16)

Cultural input needed:

• DistrictLayoutMode: Grid (Commission-planned = power imposed) vs Organic (pioneer = power negotiated)
• Heritage root influences probability: Frost/Arc heritage → Grid bias; Tide/Vine/Dust → Organic bias

Gap: No authored heritage root → layout mode probability table exists. This decision was confirmed (L-2: "some blocks grid, some organic chaos") but the probability weights are not authored.

Stage 4 — Social Site + NPC (triangles, society profile)

Cultural input needed:

• SocietyProfileRef — references a culture profile for the district
• Heritage root blend — determines social grammar, trust model, observation density, etc.

What exists:

• server/content/global/culture-van-maanens-star.ron — COMPLETE culture profile for Van Maanen's Star. Includes naming, speech, values, voice persona, voice examples, behavior modifiers. Operational in voice pipeline.
• server/content/global/culture-vael.ron — Core-adjacent, administrative culture (exists)
• server/content/global/culture-osse.ron — Deep Frontier, extraction culture (exists)

Gap: Only 3 culture RON files exist for ~230 systems. 99% of systems have no culture profile. Also, culture RON files do not include heritage root blend weights — these are needed by Phase 1 for DerivedDistrictAnalysis computation (assassination difficulty, playstyle affinity).

---

Layer 7: Heritage Grammar Overlay — Phase 2 Chunk Fill (MISSING ENTIRELY)

Status: TYPE DEFINED, NO DATA, NO CODE

Cultural inputs at this layer: HeritageGrammarOverlay per heritage root (10 roots: Frost, Tide, Iron, Dust, Stone, Vine, Salt, Arc, Jade, Spice)

The D-READY-9 architecture (confirmed in workshop-outcomes.md) specifies:

struct HeritageGrammarOverlay {
    heritage_root: HeritageRoot,
    boundary_character: BoundaryCharacter,
    open_space_character: OpenSpaceCharacter,
    structure_spacing: f32,
    decorative_density: f32,
    gathering_anchor_near_work: bool,
    shared_infrastructure_preference: bool,
    repair_visibility: f32,
    facade_investment: f32,
    signage_density: f32,
    preferred_enclosure_tags: Vec<ObjectTag>,
    accent_object_tags: Vec<ObjectTag>,
    excluded_object_tags: Vec<ObjectTag>,
}

What exists:

• The struct specification in miri-round4.md — complete with values for all 10 roots
• The authoring domain allocation: Miri authors organizational principles; Araminta authors visual expression

What does NOT exist:

• Any heritage_grammar_overlay/*.ron (or equivalent) data files
• A HeritageRoot enum in server/src/simulation/generator.rs (the type is not defined; SocietyProfileRef = String is the only heritage-adjacent stub)
• The ObjectTag vocabulary that both heritage grammar and Araminta's asset categorization must share
• Any Phase 2 chunk fill code

This is the largest cultural content gap in the pipeline.

Every district's interior visual and spatial character — how property boundaries look, how open space is used, what objects appear, how dense and repaired the environment feels — flows from the HeritageGrammarOverlay. Without this content, Phase 2 chunk fill produces nothing differentiated. Every district looks the same regardless of whether it's a Frost-heritage frontier outpost or a Tide-heritage community hub.

The heritage grammar data in miri-round4.md is complete and ready to author into files. The work is translation from workshop spec to authored data, not design.

---

Layer 8: Zone Palette — District Zones

Status: STUB — type defined as type ZoneDefinition = String

Cultural inputs at this layer: Zone identity per district type (LogisticsHub, Residential, Commercial, etc.) with heritage modifiers.

What exists:

• server/content/global/zone-identity-spec.example.ron — example zone spec (rural, well-structured)
• server/content/global/van-maanens-star-rural-zone.ron — Van Maanen's Star rural zone (exists)
• server/content/global/van-maanens-star-industrial-zone.ron — Van Maanen's Star industrial zone (exists)

What is missing:

• Zone definitions for the 9 DistrictType enum values: LogisticsHub, Residential, Commercial, Industrial, Administrative, Entertainment, MixedUse, Transit, Specialized
• Heritage modifier variants for each zone type
• The ZoneDefinition type needs to be promoted from String stub to a proper struct before zone content can be consumed

Partial authoring exists for Van Maanen's Star only. Other systems have no zone definitions.

---

Layer 9: NPC Population

Status: STUB — SocietyProfileRef = String, NPC generation not implemented

Cultural inputs at this layer: Full culture profile (naming, voice, traits, behavior, heritage blend)

What exists:

• 3 culture RON files (Van Maanen's Star, Vael, Osse) — validated in voice pipeline Spike 1
• wiki/authoring/cultural-generation-guide.md — 5-dimension authoring framework
• wiki/authoring/culture-authoring-guide.md — RON file authoring process (Mellanie)

What is missing:

• ~227+ culture RON files (one per system, or per cultural corridor)
• Heritage root blend weights as an extension of the culture RON schema
• wiki/cultural-groups/ directory is EMPTY — no canonical wiki entries for any culture

The wiki/_templates/cultural-group.md template exists and is well-structured. No cultural group entries have been authored using it.

---

Summary Table

Layer	Status	Cultural Data Status	Content Blocker?
Galactic (star/system)	DONE	Partial wiki coverage	No (numeric data in systems.db complete)
System → heritage mapping	—	MISSING	YES — blocks Phase 1 social stage
Planetary surface/heightmaps	DONE	N/A	No
Atlas markers / city naming	DONE	Naming operational; functional fields absent	Partial (need city marker schema extension)
Economics	DONE	Healthy	No
Phase 1 — Classification	STUB	No SettingType mapping rules authored	Yes
Phase 1 — Block grid	STUB	No heritage→layout probability authored	Yes
Phase 1 — Social site + NPC	STUB	3/230+ culture files exist; no heritage blends	YES
Phase 2 — Heritage grammar overlay	MISSING	No authored data for any heritage root	YES
Phase 2 — Zone palettes	STUB	2 Van Maanen's Star zones only	Yes
NPC culture profiles	STUB	3 profiles, no wiki entries	Yes (can defer to first system)

---

Critical Content Gaps — Ordered by Blocking Impact

Gap 1: System → heritage root blend (CRITICAL, blocks Phase 1)

No authored document establishes which heritage root blend applies to any system. The SocietyProfileRef stub cannot be resolved without this mapping.

What's needed: A mapping table (or per-system annotation) of system_id → Vec<(HeritageRoot, f32)>. This could live in:

• An extension of the culture RON file (add heritage_blend field)
• A new heritage-map.ron or similar global file
• Per-system wiki pages (in wiki/star-systems/{sys}/index.md)

The mapping for Van Maanen's Star can be derived from the existing content: the culture guide describes "working-class pragmatic" + "community-oriented" + "suspicious of authority" + "shows up and does the work." Cross-referencing with heritage root definitions from miri-round4.md, this reads as: Iron (collective labor identity, shared work) + Stone (tenure-based trust, territorial memory, slow disclosure) + Tide (communal eating, community participation, warm surface). A reasonable starting blend: Iron(0.4), Stone(0.35), Tide(0.25).

This is not a design question. It is translation of existing characterization into the generator's vocabulary.

Gap 2: HeritageGrammarOverlay data files (CRITICAL, blocks Phase 2)

Ten heritage roots need authored overlay files. The full specification exists in miri-round4.md §OQ-R4-D. The values are already worked out for each root. What is needed is authoring them into a machine-readable format (RON or TOML).

Scope: This is Miri's content to author. Araminta then expresses the visual vocabulary against these overlays. The ObjectTag vocabulary must be agreed jointly.

Blocking relationship: Phase 2 chunk fill → HeritageGrammarOverlay data files → ObjectTag vocabulary → Araminta asset categorization.

Gap 3: City marker schema extension (MODERATE, blocks Phase 1 input)

The markers.json city format (id, name, kind, center, population) is insufficient for Phase 1 district skeleton generation as described in ticket #899. Either city markers need primary_function, planet_class, settlement_pattern fields added, or Phase 1 must derive these from systems.db cross-reference.

This is a Tyre/generator question as much as a worldbuilding question. I flag it here because if new city marker fields are required, Miri is responsible for defining what settlement_pattern values mean culturally (grid-planned vs organic-pioneer), and Tyre is responsible for how generate_atlas.py populates them.

Gap 4: Zone identity definitions for all DistrictType values (MODERATE)

The DistrictType enum has 9 values. Only 2 Van Maanen's Star zone files exist. Full zone coverage needs:

• One zone spec per DistrictType (base definitions)
• Heritage modifier variants (how does a LogisticsHub differ in Stone vs Tide vs Iron heritage?)

This is authoring work for Miri (social/organizational character) + Araminta (visual expression).

Gap 5: Cultural group wiki entries (LOWER, documentation debt)

wiki/cultural-groups/ is empty. The wiki/_templates/cultural-group.md template exists. Cultural data lives in authoring guides and RON files but has no canonical wiki presence.

For the generator, the RON files are what matter. For human authors (Mellanie, future content team), the wiki entries matter. This is documentation debt that should be addressed alongside Gap 1-3 but does not block code.

---

Ticket Dependency Observations

Existing tickets and their status

Ticket	Title	Status	Notes
#615	Tycoon small business owner starting state	backlog	Blocks #681 (apartment generator)
#616	Broad economic verb vocabulary design	backlog	No pipeline dependency
#619	Full character customisation	backlog	No pipeline dependency flagged
#679	Location-to-culture resolution system	DONE	Culture name resolved by location — but heritage root blend not included
#681	Apartment generator logic (server)	backlog	Blocked by #615 + #679 (done); needs culture
#682	Apartment visual rendering + first-moment	backlog	Blocked by #681
#694	Character creation screen	backlog	Blocked by #685 (done)
#899	District skeleton generator — Phase 1	backlog	Blocked by #897 (this workshop)

Formal pipeline blockers (worldbuilding content view)

Character work (#694) and apartment work (#681, #682) sit downstream of:

Phase 1 district skeleton (#899)
  ← blocked by heritage root blend content (Gap 1)
  ← blocked by city marker schema (Gap 3)
  ← blocked by #897 (this workshop producing D-records)

Phase 2 chunk fill (no ticket yet)
  ← blocked by HeritageGrammarOverlay data files (Gap 2)
  ← blocked by Phase 1 (#899)

Apartment generator (#681)
  ← blocked by tycoon starting state (#615)
  ← culture resolution (#679, done) resolves culture name but NOT heritage root blend
  
Character creation (#694)
  ← no generation pipeline dependency; can proceed independently
  ← but the world they're dropping into won't be culturally differentiated until Gap 1-2 resolved

The apartment generator (#681) can produce a culturally-voiced apartment (NPC tone, naming, dialogue voice) using the existing culture-van-maanens-star.ron. What it CANNOT do is produce a spatially differentiated apartment that reflects heritage-root spatial grammar (boundary character, decorative density, facade investment) — that requires the HeritageGrammarOverlay (Gap 2).

This means #681 can proceed to a first version that is culturally voiced but spatially generic. The heritage spatial grammar layer can be added in a subsequent pass once HeritageGrammarOverlay data files exist. This is probably the right sequencing: don't block #681 further waiting for heritage overlays; instead, build the apartment generator against the culture RON files, and plan a follow-on ticket for heritage spatial refinement.

New tickets needed (from worldbuilding perspective)

1. Heritage root blend mapping — Author heritage-blend field extension for culture RON schema + provide Van Maanen's Star blend. Prerequisite for Phase 1 meaningful district social assignment.

2. HeritageGrammarOverlay data files — Author all 10 overlay files from the miri-round4.md specification. Prerequisite for Phase 2 chunk fill.

3. ObjectTag vocabulary — Jointly author with Araminta. Prerequisite for heritage overlay files and asset categorization.

4. Zone identity definitions — Author canonical zone spec per DistrictType. Prerequisite for Phase 1 zone palette assignment.

5. Van Maanen's Star cultural group wiki entry — Formal wiki page consolidating all setting data. Documentation prerequisite; does not block generation.

6. City marker schema extension (coordination with Tyre) — Define and populate cultural/functional fields on city markers if Phase 1 requires them as inputs.

---

What the Pipeline Promises and What's Missing

The generator-architecture workshop outputs describe a generator that produces culturally differentiated worlds — districts that feel different based on whether they're Stone-heritage frontier settlements or Tide-heritage community hubs, with visual, social, and spatial grammar that reflects the culture. That promise requires authored cultural data at two critical points:

Point A — Phase 1 input: Each district must know what culture it is generating for. This requires a system → heritage root blend mapping that doesn't exist yet.

Point B — Phase 2 input: The chunk fill that produces visible tiles must have HeritageGrammarOverlay data to apply the spatial grammar. This data doesn't exist yet.

The voice pipeline is healthy — three culture RON files are operational and the Van Maanen's Star profile is production-quality. The NPC voice layer will work. The spatial and visual differentiation layer will not, because it has no data.

The minimum viable cultural content set for a first walkable world output:

1. Heritage root blend for Van Maanen's Star → system (to test Phase 1 social assignment)
2. HeritageGrammarOverlay files for Iron + Stone + Tide (the three roots that make up Van Maanen's Star blend) → to test Phase 2 chunk fill differentiation
3. Zone identity specs for LogisticsHub + Residential (the two district types most relevant to Station Sova) → to test Phase 1 zone assignment

This is achievable in one sprint of content work. It is scope-limited to the primary test system, not all 230+ systems.

---

Open Questions Raised by This Inventory

Q1: Is SocietyProfileRef intended to resolve to the culture RON filename (e.g., "van-maanens-star"), or to a more structured reference that includes heritage blend weights? The current String stub leaves this unresolved. If heritage weights are expected on the SocietyProfileRef rather than embedded in the culture RON, the culture RON schema needs a heritage_blend extension.

Q2: City marker schema — does Phase 1 read cultural/functional fields from markers.json city entries, or from systems.db body data? This changes both the atlas generator pipeline and the cultural data authoring requirements.

Q3: Are there 10 heritage roots or 7? The culture authoring guide (Mellanie) lists Frost / Tide / Iron / Dust / Stone / Vine / Salt (7). Miri Round 4 lists Frost / Stone / Tide / Iron / Dust / Vine / Salt / Arc / Jade / Spice (10). This needs resolution before HeritageGrammarOverlay files can be authored.

Q4: Should the wiki/cultural-groups/ directory be populated now (one entry per culture RON file) or deferred until Phase 3 (planetary maps + station layouts)?

---

Author: Miri Date: 2026-04-30 Status: Round 1 complete. Ready for Round 2 synthesis.