settled-reach/docs/workshops/wheres-the-fun/round5-tyre.md

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

title	description	type	status	workshop	agent	round	created
Round 5: Tyre -- Deep Dive on 15 Locked Decisions	Tyre's technical architecture reactions to the 15 locked decisions	workshop	archived	wheres-the-fun	tyre	5	2026-03-05

Round 5: Tyre -- Deep Dive on 15 Locked Decisions

Workshop: Where's the Fun? | Round: 5 (Decision Reaction) | Agent: Tyre (Technical Architect)

---

Overview

cracks knuckles

Fifteen decisions locked. Three of my Round 4 questions answered directly (proof-of-life scope, character creation depth, career model). The answers are clearer and more aggressive than I expected. Let me be honest about what each means technically, where the architecture aligns, where it strains, and where I need Jeroen's input on implementation strategy.

I'm organizing this by architectural impact tier:

• Tier 1 (Foundation-changing): Decisions that redefine what we're building
• Tier 2 (System-scoping): Decisions that define new systems or significantly change existing ones
• Tier 3 (Content/production): Decisions that primarily affect content pipelines and authoring workflows
• Tier 4 (Tonal/design): Decisions that I acknowledge but that don't directly change architecture

---

Tier 1: Foundation-Changing Decisions

Decision 1: Proof-of-life = generator + graphics, not hand-built slice

My Round 4 asked: Can we use Tier A (hand-built Sova Transit) to prove the life-sim loop first?

Jeroen's answer: No. The proof-of-life IS the generator. The v0.1 lesson was that descoping led to the wrong game. Building a hand-built vertical slice would repeat that mistake in a different form.

What this means technically:

This is the single most consequential decision in the workshop. My Round 4 proposed a 3-4 sprint hand-built proof followed by the generator. Jeroen is saying the generator IS the proof. That inverts my timeline.

The Generator Architecture workshop (D-042 through D-055, 14 D-records) already scoped the pipeline: geography seed -> infrastructure graph -> zone placement -> population seeding -> routine generation. That work was done. What changes is WHEN it needs to be production-ready -- not "eventually" but "this is the v0.2 milestone."

Scope-wise, this means the generator pipeline is the critical path for v0.2. Everything else -- NPC legibility, character creation, career systems, diegetic tools -- builds ON TOP of generated output. If the generator produces garbage, nothing on top of it matters.

Feasibility assessment:

The generator pipeline as designed in D-042-D-055 is a multi-sprint system. But -- and this is important -- it doesn't need to produce Cities Skylines output for v0.2. It needs to produce:

1. A location with functional zones (residential, commercial, logistics, administrative)
2. NPCs that fill positions based on zone characteristics
3. An economy tick (wages, rents, goods flow)
4. Routines that make the world feel alive

That's my Tier B from Round 4: template-generated locations with seeded populations. The D-records already describe this. The question becomes: how minimal can the first generator output be while still proving the concept?

My technical recommendation:

Sprint 25-26: Generator produces a single location from templates. Not fully procedural geography -- zone templates assembled into a functional location with seeded NPCs and economy parameters. Think of it as a level editor that runs automatically, not a terrain generator. The location has enough variation between seeds to demonstrate "different world each time" without requiring the full geography pipeline.

Sprint 27-28: Graphics pipeline produces legible characters and environments from the generator's output. This is where Araminta's work and the sprite/tile pipeline become critical.

Sprint 29: First playable proof-of-life. Generated location, legible characters, economy running, player can walk around and interact.

4-5 sprints to proof-of-life. That's more than my Tier A estimate but less than Tier C. The key insight: we don't need procedural GEOGRAPHY for v0.2 -- we need procedural POPULATION and ECONOMY in a template-assembled location.

Risk flag: The generator pipeline has never produced output. We have 14 D-records of design but zero running code. The gap between "designed" and "produces usable game content" is where projects die. I strongly recommend a generator spike in sprint 25 -- get the pipeline producing ANY output, even ugly, before committing to the full graphics integration.

---

Decision 7: ALL NPCs are generated. No named characters.

This is the companion to Decision 1 and equally foundation-changing.

Kael doesn't exist. Naia doesn't exist. The smuggling ring's specific characters don't exist. The generator produces NPCs that fit positions based on location characteristics.

What this means for the server architecture:

The current NPC pipeline (content/spawn.rs) creates entities from hand-authored definitions. Template IDs, specific component configurations, specific NpcMemory seeds. This entire pipeline needs to become a CONSUMER of generator output rather than the source of truth.

The flow changes from:

Authored NPC definition -> spawn_npc() -> ECS entity

To:

Generator seed -> population algorithm -> NPC specification -> spawn_npc() -> ECS entity

spawn_npc() itself stays mostly the same -- it still creates an ECS entity with the right components. But its INPUT changes from hand-authored JSON/YAML to generator-produced NPC specifications. The NPC specification needs to carry:

• Culture (affects voice, behavior patterns, social expectations)
• Skills (proficiency distribution)
• Role/position (what job they hold, where they work)
• Relationships (who they know, how well)
• Personality traits (affects decision-making in the sim)

This is a new data structure. Call it NpcBlueprint -- the generator's output format that the spawn system consumes. Designing this struct is one of the first architectural tasks.

Relationship to D-026 (simulation tiers):

Generated NPCs still need tier assignment. The generator needs to produce not just individual NPCs but a POPULATION with tier distribution -- 30-80 Active (full sim), 500-2K Background (state machines), 10K+ State-saved (minimal). The generator's population algorithm needs to understand which NPCs are near the player's starting position (Active), which are in the same district (Background), and which are elsewhere (State-saved).

This is actually cleaner than hand-authored placement because the generator can assign tiers procedurally based on spatial distance from the player's bookmark location. No manual tier tagging needed.

Relationship to D-041 (Knowledge Graph):

Generated NPCs need knowledge graph entries. When the generator creates a bartender, that bartender needs to KNOW things appropriate to their role -- local gossip, regular customers, economic conditions. The generator needs to seed the knowledge graph, not just the entity components.

This is the hardest part of generated NPCs. A hand-authored Kael has hand-authored knowledge. A generated bartender needs procedurally generated knowledge that's CONSISTENT with their role, location, relationships, and the world state. The knowledge seeding algorithm is a significant new system.

Effort estimate: NpcBlueprint struct + spawn pipeline refactor: 1-2 sprints. Knowledge seeding algorithm: 2-3 sprints. Total NPC generation pipeline: 3-5 sprints, running in parallel with generator location work.

---

Decision 8: Generative AI for NPC content templating

And Decision 9: Possible in-game ollama for live NPC dialogue (deferred but door open)

These two decisions describe a content pipeline that doesn't exist yet and an aspirational runtime system.

Decision 8 -- AI templating for NPC content:

The content pool for generated NPCs needs to be enormous. Every generated NPC needs dialogue lines, behavioral patterns, voice characteristics. With hand-authored NPCs, Mellanie writes 50 lines for Kael. With generated NPCs, the system needs to produce contextually appropriate dialogue for thousands of NPCs across multiple cultures, roles, and personality types.

The proposed solution: AI-assisted content templating. Culture vectors, tone parameters, accent prompts as inputs to a generative system that produces NPC-specific content.

Technical architecture for AI templating:

This is a BUILD-TIME pipeline, not a runtime system. The distinction matters enormously:

Build-time (Decision 8):
  Culture definition + Role template + Personality params
    -> AI generation pass (Claude API or similar)
    -> Human review/curation pass
    -> Content database (tagged line pools)
    -> Generator draws from pools at world-gen time

Runtime (Decision 9, deferred):
  NPC context + Player action + Conversation state
    -> Local LLM (ollama with small model)
    -> Real-time dialogue generation
    -> Direct display to player

For v0.2, we're building Decision 8 (build-time templating), not Decision 9 (runtime LLM). The build-time pipeline is:

1. Define culture vectors (Van Maanen's Star, Burnelli, etc.) with tone, vocabulary, speech pattern parameters
2. Define role templates (bartender, dock worker, merchant, etc.) with role-specific knowledge and concerns
3. Use AI to generate large line pools tagged by culture x role x situation x emotion
4. Human review pass to curate quality and consistency
5. Generator draws from these pools when creating NPCs, selecting lines that match the NPC's culture + role + personality

This is essentially a content factory. The technical architecture is straightforward -- it's a tagged database with a query interface. The hard part is the PROCESS: defining the vectors, running the generation, curating the output, and making it feel coherent rather than procedurally bland.

Decision 9 -- runtime ollama (deferred):

Jeroen explicitly said "a problem for later." But the door being open has architectural implications NOW:

• The NPC entity model should include fields that a future LLM could consume (personality summary, relationship context, current emotional state, conversation history)
• The dialogue system should be designed as a PLUGGABLE interface -- currently draws from content pools, but the interface could later be swapped for an LLM call
• Network architecture: if ollama runs locally, it's a localhost HTTP call. If it runs on a separate machine, it's a network call with latency implications. The dialogue system should be async regardless.

My recommendation: Design the NPC dialogue interface as async with a content-pool backend for v0.2. Document the interface contract so that an LLM backend can be swapped in later without changing the caller. This costs almost nothing now and preserves the option cleanly.

Question for Jeroen: For the build-time AI templating pipeline (Decision 8) -- what's the quality bar? Are we aiming for "good enough that players don't notice it's generated" or "obviously templated but with enough variation to not feel repetitive"? The first requires significant curation effort. The second can be shipped faster. For v0.2 proof-of-life, I'd recommend the second -- limited vocabulary is explicitly acceptable per the interview.

---

Tier 2: System-Scoping Decisions

Decision 2: Skills + bookmark only for character creation

And Decision 3: Religion is NOT a game system

My Round 4 asked about character creation scope. The answer is clear: skills + bookmark. No family, no culture selection (for creation -- culture still drives NPC voice per Decision 6), no religion.

What this means technically:

Character creation is a focused system:

struct PlayerCharacter {
    skills: SkillSet,          // Proficiency allocations
    bookmark: BookmarkId,       // Starting scenario
    appearance: Appearance,     // Visual customization (Decision 11)
}

struct SkillSet {
    // Proficiencies -- affect verb outcomes per Decision 5
    social: u8,
    technical: u8,   // Hacking, electronics
    mechanical: u8,  // Repair, construction
    combat: u8,      // Shooting, melee
    // Budget: total points allocated <= BUDGET_CAP
    // skill_ceiling: conceptually unbounded (Gore's transhumanist hook)
}

This is a 2-3 week system. Skill definitions, budget allocation UI, starting state derivation from bookmark + skills. The bookmark determines your starting location, initial contacts, tools, and first appointment. Skills determine how well you do things.

The skill_ceiling note: Gore flagged in Round 4 that skills should be structurally unbounded at the top. I agree. Use u8 for now (0-255 range), but the game balance only uses 0-20 at v0.2. The transhumanist ladder (v0.3+) can raise the effective ceiling without changing the data type. Don't hardcode MAX_SKILL = 20 -- use a configurable cap that the game state can modify.

Religion removal: This simplifies the faction system significantly. No religious faction tracking, no belief-based NPC reactions, no worship locations in the generator. One less dimension in every system that touches social dynamics. Clean scope cut.

---

Decision 4: Tycoon is the v0.2 bookmark. Zero investigation.

This answers my Round 4 Question 3 AND the Q-WTF-008 career bookmark question.

Not law enforcement (my revised Round 4 recommendation). Not smuggler (my original Round 3 recommendation). Tycoon.

What this means technically:

The tycoon bookmark naturally demonstrates the three career models Jeroen described:

• Active: Manage your business location directly (the bar, the shop, the warehouse)
• WFH/Remote: Monitor investments and make remote decisions via the insert
• Gig: One-off deals, contracts, negotiations at other locations

This is elegant. ONE bookmark that exercises all three career model rhythms. Instead of building three separate career systems, we build one tycoon career that BLENDS the three models. The player shifts between Active/WFH/Gig naturally based on what they're doing.

Systems needed for tycoon:

1. Property/asset system: The player owns or manages a business. This is the "Ownership Moment" Ozzie described. The business has revenue, costs, employees, inventory, reputation.

2. Economic verbs: Buy, Sell, Negotiate, Hire, Fire, Invest, Price. These are the tycoon's primary interaction set. The VerbPriorityProfile for tycoon puts economic verbs high.

3. NPC employee relationships: The tycoon's staff are Active-tier NPCs with routines, skills, and opinions. Managing them IS the Active gameplay. This naturally creates the "quietly responsive" social proximity gradient (Decision 10).

4. Market system: Prices, supply/demand, economic events. The generator produces market conditions; the player operates within them. This is the "uncaring world" substrate that the tycoon bookmark sits on top of.

5. Insert tools for tycoon: Financial dashboard, market alerts, contract tracking, employee management. One diegetic tool suite tailored to economic gameplay.

Effort estimate:

• Property/asset system: 2-3 sprints
• Economic verb set: 1-2 sprints
• Market system (basic): 1-2 sprints
• Insert tools (tycoon): 1-2 sprints

Total: 5-9 sprints of tycoon-specific systems. BUT -- these overlap significantly with generator work (the market system IS part of the economy tick the generator produces) and with general infrastructure (the property system is reusable for all career bookmarks).

The zero-investigation clause is architecturally freeing. No evidence system. No case tracking. No deduction mechanics. No information-puzzle gameplay. The entire D-017 perception modes system that I built for detective gameplay is irrelevant for v0.2. We can defer it completely. The knowledge graph still matters (NPCs need to know things, the player needs asymmetric information about market conditions and NPC reliability) but the INVESTIGATION layer on top of it is deferred.

---

Decision 5: Skills affect outcome (mostly C)

Gestalt's Round 4 question, answered cleanly.

Everyone sees the same verbs. Skills determine how well you do. Bad at social? You can still Talk, just badly.

What this means for the verb system:

The verb computation stays clean. No skill-gating on verb availability (simplest model). The resolution layer gains a skill modifier:

Verb outcome = base_success_rate(verb, context) + skill_modifier(player_skill, verb_skill_requirement)

The VerbPriorityProfile still matters -- career-aware ordering of which verbs appear first. But the verb LIST is the same for everyone. Only the outcomes differ.

The "some advanced verbs may still be gated" caveat: This is a spec question. Which verbs? My recommendation: gate only on TOOL possession, not on skill. You can't Hack without a hacking tool. You can't Shoot without a weapon. But if you HAVE the tool, you can attempt it regardless of skill -- you'll just be bad at it. This keeps the system clean: tool-gating (binary, equipment-based) and skill-modifying (gradient, character-based) are separate, orthogonal systems.

Effort: The resolution layer needs a skill modifier. This is ~1 week of server work on top of the existing verb system. Moderate effort, clean integration.

---

Decision 6: Voice -- culture-driven, job modifies

Mellanie's critical question, answered.

The character IS their background. Job adds a layer. A Van Maanen's Star tycoon sounds like a Van Maanen's Star person who runs businesses.

What this means for the content architecture:

Voice cards are authored at the CULTURE level, not the career level. This inverts Mellanie's current content structure. Instead of:

smuggler_voice_card.yaml  (job-level)
detective_voice_card.yaml (job-level)

We get:

van_maanens_star_voice.yaml          (culture-level base)
  + tycoon_modifier.yaml  (job-level overlay)
burnelli_voice.yaml       (culture-level base)
  + tycoon_modifier.yaml  (job-level overlay)

Server implications:

The NPC entity needs a culture field that the voice system reads. The generator assigns culture based on location demographics. The content pipeline (Decision 8's AI templating) generates line pools tagged by culture, and the job modifier selects/adjusts from the culture pool.

For v0.2 with the tycoon bookmark, the PLAYER's culture isn't selected at creation (Decision 2: skills + bookmark only). This means the player character's voice is either:

• A default/generic culture (simplest)
• Derived from the bookmark's starting location (the generated location's dominant culture)

Question for Jeroen: Since character creation is skills + bookmark only (no culture selection), does the player character have a culture for voice purposes? If so, how is it determined? Options: (a) default culture for v0.2, (b) derived from bookmark location, (c) culture is an implicit part of the bookmark definition. This affects Mellanie's voice card work directly.

---

Decision 11: Full character customization

Araminta's Round 4 question, answered aggressively.

Full customization. Hair, clothing, colors. The creation screen is part of identity investment. Readability solved through outline/highlight.

What this means technically:

The character rendering pipeline needs a layered appearance system:

Base sprite (body type/silhouette)
  + Hair layer (style + color)
  + Clothing layer (type + color)
  + Accessory layer (career-specific items)
  + Outline/highlight layer (readability at tile scale)

This is primarily a CLIENT system (Godot sprite composition) but the SERVER needs to store and transmit appearance data. The Appearance struct in the player character needs to be part of the ObserverSnapshot so that other players (future multiplayer) and the rendering system can reconstruct the character's look.

For generated NPCs, the generator needs to produce appearance data consistent with their culture and role. A Van Maanen's Star dock worker looks different from a Burnelli merchant. The appearance generation is another dimension of the NPC generation pipeline.

Effort: Character appearance system (client-side sprite composition + server-side data model): 2-3 sprints. NPC appearance generation (culture + role -> appearance parameters): integrated with NPC generation pipeline, adds ~1 sprint to that work.

Risk: Full customization at tile scale is Araminta's hardest unsolved problem. The outline/highlight solution needs prototyping before we commit. If outlines don't provide sufficient readability at normal zoom levels, we may need to revisit. Recommend a visual prototype in sprint 25-26 alongside the generator spike.

---

Tier 3: Content/Production Decisions

Decision 10: Quietly responsive world, not indifferent

Gore's Kenshi-indifference premise rejected.

The world doesn't care globally but notices locally. Primary social contacts develop responsiveness over time.

What this means for the simulation:

The social proximity gradient is a SYSTEM, not just a content decision. NPCs need:

Social proximity tiers:
  - Stranger: no responsiveness (Kenshi-weight)
  - Acquaintance: recognizes player, basic reactions
  - Regular: remembers interactions, adjusts behavior
  - Colleague: active responsiveness, opinions about player
  - Friend: deep responsiveness, emotional reactions

This maps onto the knowledge graph. An NPC's knowledge about the player determines their social proximity tier, which determines their behavioral responsiveness. The knowledge graph already tracks "what does NPC X know about entity Y" -- the social proximity tier is a DERIVED VALUE from the knowledge graph state.

This is actually easier than it sounds. The knowledge graph (D-041) already stores per-entity knowledge with confidence levels. Social proximity is a function of: number of interactions, recency, emotional valence of interactions, and role relationship. We query the KG, compute a proximity score, and use it to gate behavioral responsiveness.

The generator needs to seed initial social proximity for NPCs that have pre-existing relationships (colleagues who've worked together for years, neighbors who see each other daily). This is part of the knowledge seeding algorithm from Decision 7.

---

Decision 12: Setting delivery -- both layers (visual + insert)

And Decision 13: First moment -- apartment + insert activation

And Decision 14: Groundhog Day alarm clock homage

These three decisions define the ONBOARDING SEQUENCE architecture.

Technical architecture for the first session:

1. Character creation (skills + bookmark + appearance)
2. World generation (generator produces location, population, economy)
3. Apartment generation (reflects economic position from bookmark)
4. Wake-up sequence:
   a. Alarm clock audio (Groundhog Day homage, first day only)
   b. Camera on apartment interior (auto-generated, reflects wealth)
   c. Insert activation (neural implant powers on -- career-specific HUD)
   d. Calendar ping (first appointment from bookmark)
5. Player exits apartment -> enters generated world

Apartment generation is a sub-system of the generator. The player's bookmark determines their economic tier, which determines their apartment template. This is a small but visible system -- the apartment is the player's FIRST impression of the generated world. It needs to feel specific, not generic.

The apartment is also where the "two layers" of setting delivery converge: the physical space (visual, Araminta's domain) and the insert overlay (UI, Mellanie's domain). The apartment should communicate the player's economic position through BOTH channels simultaneously -- cramped space + insert showing your debt, or spacious space + insert showing your portfolio.

Audio note: The Groundhog Day alarm clock is a one-shot audio asset. Click pa-pa pa-pa, cut short. First game day only. This needs to be flagged for the audio pipeline but is trivial to implement technically -- a conditional audio trigger on day_number == 1.

---

Decision 15: Player choices ARE the content (Rimworld model)

The framing question is resolved.

A job is rails to take off from, not a script to follow. The world provides opportunity and consequence; the player provides the story.

What this means for the storyteller (D-023):

The storyteller's job is NOT to tell a story. It's to calibrate pressure. The Rimworld model: escalate when things are quiet, back off when things are stressful. The storyteller injects EVENTS (market crashes, NPC conflicts, economic opportunities), not MISSIONS.

For the tycoon bookmark, storyteller events might be:

• A supplier raises prices (economic pressure)
• An employee threatens to quit (relationship pressure)
• A competitor opens nearby (competitive pressure)
• A Commission inspector visits (institutional pressure)

These are SITUATIONS, not quests. The player decides how to respond. The consequence engine tracks what they did and feeds it back into the world state.

This is simpler than my Round 4 mission system proposal. No ObjectiveId tracking. No mission state machine. Just events that create situations, and a consequence engine that tracks outcomes. The "mission" is whatever the player decides to do about the situation.

My revised effort estimate for the consequence/storyteller system: 2-3 sprints (down from 4-6 in Round 4, because we're building a situation injector, not a quest tracker).

---

Tier 4: Tonal/Design Decisions

Decision 3: Religion is NOT a game system

Acknowledged. Simplifies faction system. No architecture needed.

Decision 14: Groundhog Day alarm clock

Acknowledged. One audio asset, one conditional trigger. Trivial.

---

Cross-Agent Reactions

Gestalt's storyteller-per-career-model question

Gestalt asked whether the storyteller calibrates pressure per career model. With the tycoon bookmark blending all three models, this question partially resolves itself -- the storyteller doesn't need to distinguish Active/WFH/Gig because the tycoon player shifts between them fluidly. The storyteller tracks "time since last meaningful player decision" and injects when the gap is too long, regardless of which model the player is currently in.

For future multi-career releases, the storyteller WILL need career-model awareness. But for v0.2 with one blended-model bookmark, a simple pressure-gap tracker is sufficient.

Mellanie's voice attribution question

Decision 6 answers this cleanly: culture-driven, job modifies. But for v0.2, the player doesn't select culture. This creates a gap: NPC voice cards are culture-driven, but the PLAYER'S voice card needs a culture assignment that doesn't come from character creation. See my question for Jeroen above.

Araminta's visual near-miss concern

Araminta worried about designing archetypes for the detective/smuggler binary. Decision 4 (tycoon bookmark) eliminates this risk entirely -- we're designing for an economic world, not a crime world. The visual vocabulary is: merchants, workers, managers, officials. Not investigators and suspects.

Paula's Phase Zero

Paula's Phase Zero concept maps cleanly onto the tycoon bookmark. Phase Zero for a tycoon is: your business runs. Your employees show up. Your customers come and go. You learn the rhythm of your economic life. Nothing dramatic happens. Then the storyteller starts injecting pressure -- a competitor, a Commission audit, a market shift. Phase Zero is the calm before the storytelling begins.

With generated NPCs (Decision 7), Phase Zero warmth isn't with a hand-authored Kael -- it's with your generated employees and regular customers. The player builds attachment to NPCs that the generator created. This is the Sims model: you care about generated characters because you spent time with them, not because they were written to be compelling.

Miri's zone identity spec

Miri is right that the generator needs worldbuilding rules to produce the Settled Reach rather than generic sci-fi space. The zone identity spec is a direct input to the generator pipeline. I'd sequence it as: Miri writes zone identity rules -> generator consumes them as zone template parameters -> Araminta produces visual grammars per zone type. This is the dependency chain Miri identified and it's correct.

Nigel's career-aware content distribution

Decision 15 (player choices are the content) partially addresses this. The storyteller doesn't distribute authored content by career -- it injects SITUATIONS. The career determines which situations are relevant (economic situations for tycoons, criminal situations for smugglers). Career-aware content distribution is therefore a storyteller configuration question: each career has a pool of situation types, and the storyteller draws from the career-appropriate pool.

---

Technical Dependency Map

Sprint 25-26: Foundation
  Generator spike (first output from templates)
  NpcBlueprint struct design
  Visual prototype (character customization readability)
  Zone identity spec (Miri)
  AI content templating pipeline design (build-time)

Sprint 27-28: Integration
  Generator -> NPC population pipeline
  Knowledge seeding algorithm
  Character creation system (skills + bookmark + appearance)
  Property/asset system (tycoon core)
  Economy tick (market system basics)

Sprint 29-30: Playable
  Apartment generation
  Onboarding sequence (wake-up -> insert activation -> first appointment)
  Storyteller situation injection (basic)
  Consequence tracking (basic)
  Tycoon verb set (Buy, Sell, Negotiate, Hire, etc.)

Sprint 31: Proof-of-life playtest
  Generated location with legible characters
  Tycoon bookmark from creation to Day 3
  Economy running, NPCs responsive, consequences visible

7 sprints to proof-of-life. That's between my Round 4 estimates of Tier A (4-5 sprints) and Tier B (6-8 sprints). The generator is the long pole, but much of the other work parallelizes around it.

---

Questions for Jeroen

Question 1: Generator fidelity for v0.2 -- template assembly or procedural geography?

Decision 1 says generator + graphics IS the proof-of-life. The Generator Architecture D-records describe a full pipeline from geography seeds to populated locations. For v0.2, do we need the FULL pipeline, or can we start with template assembly (pre-designed zone templates, procedurally assembled and populated)?

Concretely: does v0.2 need to generate terrain/geography from noise, or can it assemble pre-built zone blocks into a location layout and then procedurally populate them? The first is Tier C (8-12+ sprints). The second is Tier B (4-6 sprints for the generator piece).

Template assembly still produces different locations each seed -- different zone arrangement, different population distribution, different economic parameters. It just doesn't produce different geography. My strong recommendation is template assembly for v0.2, with procedural geography as a v0.3 upgrade.

Question 2: Player character culture -- how is it determined if not selected at creation?

Decision 2 says skills + bookmark only. Decision 6 says voice is culture-driven. But culture isn't part of character creation for v0.2.

Options:

• (a) Default culture: All v0.2 player characters share a generic culture. Voice cards use a baseline register. Culture variation exists only in NPCs.
• (b) Bookmark-derived: The tycoon bookmark implies a culture based on its starting location. "You're a tycoon in Sova Transit" gives you Sova Transit's dominant culture.
• (c) Culture IS part of the bookmark: The bookmark definition includes a culture assignment. Multiple tycoon bookmark variants (Van Maanen's Star tycoon, Burnelli tycoon) would each be a separate bookmark with a different culture.

Option (a) is simplest but contradicts Decision 6's spirit. Option (b) is natural but ties culture to location. Option (c) is most faithful to Decision 6 but expands the bookmark system.

Question 3: AI content templating -- Claude API, local ollama, or manual for v0.2?

Decision 8 establishes AI-assisted content templating as the direction. For v0.2's actual production pipeline, what's the approach?

• Claude API (build-time): Generate large content pools via API, human-curate the output, ship curated pools. Highest quality, API cost, requires curation workflow.
• Local ollama (build-time): Generate content pools locally with a smaller model. Lower quality per-line but faster iteration. No API cost. May need more curation.
• Manual with AI assist: Mellanie authors content with AI as a drafting tool, not a pipeline. Traditional authoring with productivity boost.

For v0.2's "limited vocabulary acceptable" scope, even the manual approach might be sufficient. The AI pipeline becomes critical when we need thousands of lines across dozens of culture x role combinations. But designing the pipeline now (even if we don't run it at full scale) means we're ready to scale when needed.

Question 4: How many culture definitions for v0.2?

Generated NPCs need cultures (Decision 6 + Decision 7). How many cultures should the generator produce NPCs from? Options:

• Minimal (2): One dominant culture for the location, one minority. Enough to show cultural variation exists.
• Moderate (4-5): A cultural mix that feels like a real transit hub. More content needed but richer world.
• Full setting: Every culture in the Settled Reach lore. Maximum authenticity, maximum content pipeline demand.

My recommendation: minimal (2) for v0.2. The system supports any number -- the content is the bottleneck, not the architecture. Start with 2 well-developed cultures, prove the culture-driven voice system works, then expand.

---

My Single Most Important Recommendation

Spike the generator in sprint 25. Before anything else.

Every other system builds on generated output. Character creation puts you IN a generated world. NPC legibility makes generated NPCs readable. The tycoon bookmark manages a generated business. The economy tick runs on generated market parameters. The apartment is generated. The population is generated.

If the generator can't produce usable output, nothing else matters. If it CAN, everything else has a foundation.

The spike doesn't need to produce beautiful output. It needs to produce FUNCTIONAL output: a location with zones, NPCs in positions, an economy with flows, routines that tick. Ugly is fine. Broken is information. The worst outcome is building 6 sprints of systems on top of a generator that turns out to need fundamental redesign.

One sprint. Generator spike. First output. Then we know what we're building on.

That's actually easier than it sounds -- the D-records are thorough. The spike is translating design into code. The hard part was the design, and that's done.

---

Tyre -- Round 5 complete. The architecture serves the vision. The generator is the critical path. Let's pour the foundation.