Files
settled-reach/decisions/content.md
T
jpmschweitzerandClaude Opus 4.6 1254e41dc5 docs(decisions): amend stale D-records, close resolved Q-records
Amend 7 high-priority D-records with supersession notes:
- D-012: map size superseded by D-094 (256x256)
- D-044: outline color scoped to perception mode per D-154
- D-061: width corrected from 640px to 1200px per D-076
- D-086: smuggler scope removed per D-117/D-122
- D-090: marked [SUPERSEDED] by D-117 (tycoon replaces smuggler/detective)
- D-035: character enum marked obsolete post-D-117
- D-119: sequencing superseded by D-166 cascade

Close 4 resolved scope questions (Q-002, Q-004, Q-005, Q-007).
Fix questions.md index — was 61, actually 96 (33 architecture Qs missing).

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-04-05 15:16:27 +02:00

108 KiB
Raw Blame History

Content Decisions

How narrative, NPCs, and world content are created: content tiers, NPC generation, templates, dialogue, population, audio aesthetic identity.


D-023: Three-tier content model with life-sim substrate

  • Date: 2026-02-10
  • Decision: The game uses a three-tier content architecture: Tier 1 (authored drama modules drawn from a pool at game start — plural, optional, relocatable), Tier 2 (templated content with combinatorial variation — both intrigue and life templates), Tier 3 (procedural filler with systemic hooks for Tier 2 colonization). Daily life is the substrate; conspiracies are weather. Players can investigate, pursue careers/relationships, or both. All are valid playthroughs. The storyteller activates Tier 1 modules based on player proximity and engagement, not timers.
  • Rationale: A galaxy-spanning game needs content architecture that scales without hand-crafting everything. The life-sim substrate creates attachment that gives conspiracies emotional weight. Pool-based Tier 1 modules enable replayability and DLC expansion.
  • Raised by: Team Leader (Jeroen), with full team endorsement across 3 rounds
  • Dissent: None
  • Amendment (2026-03-05, Where's the Fun? Workshop): Tier 1 "authored drama modules" concept is deferred for v0.2. D-114 (generator-first proof-of-life) and D-127 (player choices are the content) establish that v0.2 ships zero authored drama modules. The three-tier architecture remains valid for the full game, but the Tier 1 pool is empty by design in v0.2 — generator-first validates Tier 2 and Tier 3 before Tier 1 modules are authored. Tier 1 will be authored after the generator spike (D-119) proves legible characters and readable relationships.

D-024: NPC generation model — 10 axes + combat component

  • Date: 2026-02-10
  • Decision: NPCs are generated with 10 axes: 7 essential (Want, Secret/vulnerability, Relationships 1-3, Tolerance threshold, Daily routine, Information inventory, Contentment) and 3 supporting (Personality traits 2-3, Tell system, Skill set including combat tag). Combat capability lives as an optional CombatCapability ECS component triggered by the combat-trained skill tag, not as an axis. Faction loyalty is folded into Relationships+Secret (discoverable, not labeled). Romantic profile is folded into Want+Personality+compatibility tag. Cultural/origin template is generation-time flavor, not a runtime axis. Triangles (3 NPCs with conflicting interests) are the atomic unit of social intrigue — 2 per template minimum, 1 cross-template.
  • Rationale: Axes that create contradictions within NPCs produce player decisions. The 5 key interactions (Want×Secret, Routine×Secret, Tolerance×Relationships, Want×Relationships, Personality×Tolerance) drive the full investigation-and-social gameplay loop. Contentment axis (proposed by Gore) connects generated NPCs to the thematic spine. Combat as component follows the same pattern as perception modes (D-017).
  • Raised by: Gestalt (consolidation), Gore (contentment axis), Paula (triangle model), Tyre (combat component). Full team endorsed.
  • Dissent: None
  • Amendment (2026-03-05, Where's the Fun? Workshop): The 10-axis model and core generation logic survive. However, D-122 (all NPCs generated) removes all named hand-authored NPCs from v0.2. Named NPCs and hand-authored triangles are now generator outputs, not authored content. The 10 axes apply to all generated NPCs. The NpcBlueprint struct (Tyre prerequisite for D-119 generator spike) must encode these axes as generator output format. Cultural/origin template (previously called "generation-time flavor") is now the primary driver per D-128 and D-121.

D-025: Social site / functional cluster as atomic template unit

  • Date: 2026-02-10
  • Decision: The atomic Tier 2 template unit is a "social site" (mechanical term) housed in a "functional cluster" (spatial term): 4-8 NPCs who regularly interact, within 15-40 tiles of connected space with internal sightlines. Social group defines systemic identity (who, what triangles). Physical cluster defines spatial identity (sightlines, overhearing, public/private). Templates define roles; NPCs fill roles. One NPC can hold roles in multiple social sites. NPC identity is independent of template instantiation. NPCs are owned by exactly one template with reference links (carrying relationship metadata) to others.
  • Rationale: Life in the Settled Reach happens in clusters of connected spaces. The functional cluster is the natural unit of social observation, which is the natural unit of gameplay. Single-ownership with reference links prevents lifecycle conflicts while enabling cross-template contamination.
  • Raised by: Gestalt (social site), Miri (functional cluster), Tyre (ownership model), Paula (reference metadata)
  • Dissent: None

D-028: Dialogue architecture — tagged line pools with four relational layers

  • Date: 2026-02-10
  • Decision: Dialogue uses tagged line pools with systemic selection, not branching trees. Four relational layers, all planned from authoring day one, built in sequence: (1) Access tiers — insider/outsider/authority/peer filter on every line, (2) Relationship history — interaction log modifying greeting and topic selection, (3) Trust-gated gossip — three disclosure tiers per role (surface/real/secret), (4) Unprompted disclosure — NPCs volunteer information weighted by trust and mood. Trait modifiers (not per-trait scripts) reshape delivery — base lines + trait transformation guide per template. Template content packs as writing deliverable: role voice kits, situation scripts, monologue hooks, environmental text, trait transformation guide. ~165-210 authored lines per Tier 2 template, generation-expanded 4x. Social dialogue budgeted 40% more than investigation. Line previewer CLI required as authoring tool and regression test harness.
  • Rationale: All four layers are load-bearing — each enriches the previous ones. Tagged pools avoid combinatorial explosion while trait modifiers produce character variety. The generation pass (write 10, generate 40) scales authored content. Every memorable line needs a human hand; the generation pass fills the background.
  • Raised by: Mellanie (authoring model), Paula (relational layers), Gestalt (axis-to-pipeline mapping), Tyre (previewer feasibility)
  • Dissent: None on model. Minor ordering difference: Mellanie front-loads access tiers (structural), Paula front-loads relationship history (narrative). Both sequences work.
  • Amendment (2026-03-05, Where's the Fun? Workshop): The tagged line pool architecture survives for authored content, but the v0.2 NPC content pipeline pivots to AI-assisted templating. D-123 (generative AI for NPC content) replaces the hand-authoring model for NPC dialogue pools. The four relational layers remain valid as a selection architecture, but pools will be populated by template assembly (culture vectors + job modifiers + AI generation) rather than hand-authoring. Hand-authored content (anchor lines per D-092, player monologue) remains hand-authored.

D-029: Population entanglement ratio — 30/50/20

  • Date: 2026-02-10
  • Decision: NPC population split: ~30% truly flat (routine + greeting, social wallpaper), ~50% mundane triangles (neighbor disputes, workplace rivalries, relationship tensions — no conspiracy connection), ~20% entangled with intrigue content. The entanglement rate varies per seed to prevent metagaming calibration. Module attachment to known NPCs uses a ~60-70/30-40 ratio (known vs stranger), also varying per seed. The unentangled majority is both thematically essential ("is this enough?" needs honest counterweight) and mechanically essential (investigation signal requires noise floor).
  • Cross-reference: Simulation tier budgets in D-026.
  • Rationale: If every NPC is suspicious, investigation collapses. The mundane triangles ARE the life-sim game — hours of play that never touch conspiracy. Variable entanglement rate defeats metagaming across playthroughs. Quiet life must feel genuinely good, not empty.
  • Raised by: Gore (thematic), Paula (30/50/20 split), Nigel (anti-metagaming), Team Leader (majority unentangled)
  • Dissent: None
  • Amendment (2026-03-05, Where's the Fun? Workshop): The 30/50/20 population split rationale survives but implementation context changes. D-122 (all NPCs generated) means no NPC is hand-authored. The "entangled 20%" are generated NPCs whose triangles happen to be flagged for intrigue content. For the tycoon v0.2 bookmark (D-117), the split applies to economic, social, and mundane triangles rather than investigation-intrigue triangles. The specific ratios will be revisited after the generator spike (D-119) proves what population density the generator can sustain.

D-032: Separate monologue pools per character [SUPERSEDED]

  • Date: 2026-02-11
  • Superseded by: D-117 (single tycoon character in v0.2 eliminates the smuggler/detective hard partition). The principle of character-specific monologue pools survives — the tycoon has their own monologue pool. The hard partition between smuggler and detective does not apply when there is only one playable character. Per D-127, the player's monologue reflects their character background. The partition design is preserved as a pattern for when multiple playable characters are reintroduced.
  • Decision: Internal monologue content is hard-partitioned by playable character. The smuggler and detective have completely separate monologue pools — no shared lines. The character tag on monologue lines is a hard partition, not a filter. File structure uses separate files per character per location (e.g., monologue-smuggler.yaml, monologue-detective.yaml).
  • Rationale: Shared monologue would dilute character voice and undermine the dual-lens experience. Each character's internal voice must be independently coherent. Same trigger, different pool — this is how mirror moments work without either pool knowing about the other.
  • Cross-reference: Dialogue lines remain character-agnostic — the access tier system (D-028 Layer 1) handles per-character filtering without separate pools.
  • Raised by: Mellanie (Round 1 proposal), confirmed as non-negotiable by project lead
  • Dissent: None

D-034: THE FRIEND — production-level NPC pattern

  • Date: 2026-02-11
  • Decision: Each playable character has one "FRIEND" NPC — a production-level complex character that exercises every content and systems pipeline at full depth. THE FRIEND is the emotional centerpiece of v0.1 and carries D-027 success criterion #3 ("player names an NPC they felt conflicted about"). THE FRIEND follows a reusable pattern: 3+ relationship phases (warmth → trust → doubt → conflict), observable contradiction discoverable through observation not dialogue, sympathetic motivation, no clean resolution, dual-lens resonance, triangle integration, tell progression, and dialogue shift pre/post discovery.
  • Assignments:
    • Smuggler's FRIEND: Kael Davan — dock worker, ring member, smuggler's closest colleague. Contradiction: meeting with unknown contact in restricted corridor (trying to exit the ring to protect partner Naia). Exercises: full 10-axis model, multi-phase dialogue, tell system, named monologue, dual-lens notes.
    • Detective's FRIEND: Sera Venn — Commission field tech, bar regular, detective's social anchor. Contradiction: avoids Torek Lintar (sitting on unreported evidence about Kael's manifest discrepancies, protecting friend Naia). Exercises: institutional access + personal loyalty conflict, avoidance pattern as tell, trust-contamination arc.
  • Content requirements per FRIEND NPC: ~70-100 authored lines (25-35 dialogue, 15-20 trust-gated, 5-8 unprompted, 10-15 monologue per character, 5-8 tell observation, 3-5 contradiction discovery). No generation expansion — all hand-authored.
  • Cross-reference: NPC triangle model (D-024), relationship web (D-029), vertical slice criteria (D-027)
  • Raised by: Ozzie (emotional concept, Round 1), Paula (structural design and both FRIEND profiles, Round 2), project lead (confirmed, directive #4). Sera Venn confirmed by project lead over Mellanie's alternative proposal (Lera Sessik).
  • Dissent: Mellanie proposed Lera Sessik (bar owner) as detective's FRIEND. Project lead selected Paula's Sera Venn design. Lera remains bar owner / mundane triangle member.
  • Amendment (2026-03-05, Where's the Fun? Workshop): The FRIEND pattern (3+ relationship phases, observable contradiction, sympathetic motivation, no clean resolution, tell progression, dual-lens resonance) survives as a generator template for v0.2. Kael Davan and Sera Venn do not exist — D-122 eliminates all named hand-authored NPCs. In v0.2, the FRIEND role is filled by a generated NPC whose generator profile matches the FRIEND pattern template. The FRIEND pattern is now a generator instruction set, not an authoring assignment. Workshop convergence note: warmth with generated NPCs is earned through observed relationship progression, not authored backstory — this may produce stronger emotional investment than the hand-authored approach (Paula, Mellanie in Where's the Fun? Workshop §Phase Zero).

D-035: Converged tag taxonomy for dialogue and monologue line pools

  • Date: 2026-02-11
  • Decision: Tagged line pools (D-028) use a converged taxonomy of 6 structural tags + 3 selection tags per dialogue line. Monologue lines add 3 additional tags.
  • Structural tags (required on every dialogue line):
    • id (string): {template}_{d|m|e}_{###} — machine-parseable, stable
    • text (string): the authored line
    • role (enum): template-defined role (not NPC name — NPC assignment is runtime)
    • access (list<enum>): public, insider, authority, peer, hostile — D-028 Layer 1 hard filter
    • trust (enum): surface, real, secret — D-028 Layer 3 hard filter
    • situation (list<enum>): 13 situations for v0.1 — D-028 Layer 2 context filter
  • Selection tags (recommended, defaults if empty):
    • topic (list<enum>): 9 topics for v0.1 — D-028 Layer 4 weighted selection
    • mood (list<enum>): 8 moods for v0.1 — D-028 Layer 4 weighted selection
    • tags (list<string>): freeform escape hatch for author intent
  • Monologue-specific additions:
    • character (enum): smuggler, detective — hard partition per D-032 [Obsolete post-D-117: smuggler/detective eliminated. v0.2 uses culture-driven voice per D-121; this enum is unused.]
    • trigger (enum): 9 trigger types (enter_location, observe_npc, hear_sound, observe_anomaly, post_conversation, discover_evidence, witness_interaction, time_idle, return_visit)
    • prerequisite (map or null): knowledge state gate
  • Authoring-only tags (not consumed by engine): dual_lens (map, per-character notes), notes (string)
  • Key design choices: Location and content type dropped from per-line tags (implicit from directory structure and file naming). access is list (a line can be eligible for multiple tiers). topic and mood are lists. Layer 2 relationship history expressed through engine-state-to-situation mapping, not per-line tags.
  • Cross-reference: Dialogue architecture (D-028)
  • Raised by: Gestalt (schema design, Round 1/2), Mellanie (authoring validation, Round 1/2). Converged across both agents in Round 2.
  • Dissent: None. Minor consolidations: Mellanie's 8 moods mapped to Gestalt's 8 (different names, same concepts). Mellanie's crime topic deliberately excluded (NPCs think of it as cargo or money).
  • Amendment (Sprint 8): focused added as 9th mood (used in Kael dialogue at The Terminal and maintenance corridors). greeting added as 14th situation (used in PC dialogue pools for initial contact lines). Schema updated to match.
  • Amendment (Sprint 14): Mood vocabulary renamed to match voice guide (monologue-voice-guide.md). Old → new: fondwarm, comfortablecontent, worriedanxious, concernedfrustrated. Dropped: analytical (merged into focused), conflicted (modeled as suspicious+warm collision). Added: hostile. Final 8 moods: anxious, frustrated, content, suspicious, warm, hostile, relieved, focused. Neutral = untagged.
  • Amendment (Sprint 24): triangle_activated added as 15th situation (fires post-TriangleActivated when player observes anchor NPCs). Two freeform tags registered as conventions: triangle-signal (line is part of the triangle activation sequence) and tell-observation (line observes a behavioral tell without naming its cause). npc_in_los prerequisite added for LOS-gated monologue lines. Schema updated to match.
  • Amendment (Sprint 15): Line ID namespace changed from location-scoped to NPC-scoped. Old scheme: {location_slug}_{d|m}_{###} (e.g., the-terminal_d_039) — all NPCs at a location share one ID sequence, requiring cross-file coordination and causing collisions at scale. New scheme: {npc-slug}_{d|m}_{###} for dialogue, {npc-slug}_m_{s|d}_{###} for monologue (e.g., kael-davan_d_001, dock-worker_d_001). Each NPC's IDs are independent — no cross-file coordination needed. Auto-generated NPCs use their generated slug. Schema regex patterns unchanged (prefix is still ^[a-z][a-z0-9-]*), only the description field and convention documentation update. Migration: mechanical rename of all existing line IDs across ~20 dialogue files and monologue pools.

D-036: Sova Transit District / Van Maanen's Star as v0.1 setting

  • Date: 2026-02-11
  • Decision: The v0.1 vertical slice is set in Sova Transit District, a freight logistics hub on Station Sova in Van Maanen's Star. This is the first concrete, named star system in The Settled Reach. Van Maanen's Star is a mid-Reach G3V system, ~180 years settled, population ~2.4 million, working-class pragmatic culture. Station Sova is a logistics hub (~12,000 population). Sova Transit District is a 40-year-old prefab-modular-retrofitted freight district with three social sites: The Terminal (logistics hub), The Last Shift (bar), and maintenance corridors/smuggling spaces.
  • Setting details (canonical):
    • NPC naming: Van Maanen's Star conventions — compact, consonant-heavy, first-name-primary in social contexts (Kael, Voss, Lera, Torek, Drin, Maret, Naia, Sera, Nils, Kosse, Pael, Tev, Ren)
    • Bar naming: "The Last Shift" (official), "Lera's" (informal, used by regulars)
    • Atmosphere: "quotidian-with-undertow" — comfortable enough to be complacent, tight enough that extra income is tempting
    • Sensory: span gate hum, industrial lubricant, recycled air, cargo machinery
  • Cross-reference: Vertical slice (D-027), contraband (D-037)
  • Raised by: Miri (Sova setting brief, Round 1; Van Maanen's Star profile, Round 2), project lead (confirmed as worldbuilding milestone, directive #6)
  • Dissent: None
  • Amendment (2026-03-05, Where's the Fun? Workshop): Station Sova / Van Maanen's Star confirmed as the v0.2 setting. D-128 makes Van Maanen's Star culture the cultural context for the tycoon bookmark — Van Maanen's Star IS Van Maanen's Star culture by default. The setting details (naming conventions, atmosphere, sensory palette) survive as generator inputs and culture profile content. However, the Sova Transit District spatial layout (D-093) was designed for the v0.1 hand-built slice. v0.2 generates the location via the generator (D-114); the Van Maanen's Star culture profile (Miri prerequisite for D-119) captures the setting identity as generator inputs. Sova remains the canonical example system and the first culture profile to author.

D-037: Contraband specification — unlicensed lattice components

  • Date: 2026-02-11
  • Decision: The primary contraband in the v0.1 smuggling scenario is unlicensed lattice components — aftermarket neural lattice modifications that bypass Commission regulation. Secondary contraband: medical-grade neural lattice replacements (diverted from Syndic supply chains) and Severance counter-surveillance technology.
  • Moral dimension: The ring is smuggling access, not weapons. People want better lattice capability than Commission-regulated channels provide. Medical-grade replacements serve people whose lattices are degrading and who can't afford institutional replacement. This creates genuine moral ambiguity: the smuggler isn't a villain, they're providing a service the legitimate system won't.
  • Gameplay relevance: Lattice components connect to the perception system (D-017) — a smuggled upgrade could theoretically change what the player perceives. Manifest discrepancies are the primary investigation vector. The detective's analytical lattice can flag cargo anomalies.
  • Cross-reference: Perception modes (D-017), setting (D-036)
  • Raised by: Miri (Round 1 proposal, Round 2 validation), Paula (moral dimension endorsement), full team validated
  • Dissent: None

D-050: Velen — Van Maanen's Star primary world

  • Date: 2026-02-12
  • Decision: Velen is the canonical name for Van Maanen's Star's primary habitable world. Temperate-maritime climate, ~0.9G, regular rain, morning/evening fog, mild temperature range, occasional heavy squalls. Station Sova orbits Velen. The span gate connects Sova to a planetary freight depot on Velen's surface. Naming convention: compact, consonant-weighted, two-syllable, Nordic-influenced.
  • Weather as gameplay (cross-ref D-046): Fog degrades everyone's vision cones equally — shared vulnerability. The storyteller can time weather for dramatic effect without breaking environmental neutrality (D-045). Foggy mornings = shorter cones = smuggler's early drops safer, detective's dawn surveillance harder.
  • Cross-reference: Setting (D-036)
  • Canonical reference: docs/workshops/art-direction-mood-board/workshop-outcomes.md §1.13, §1.15
  • Raised by: Miri (Round 2 proposal), confirmed by project lead (Round 3). Unanimously endorsed.
  • Dissent: None

D-062: Invisible locked dialogue options

  • Date: 2026-02-13
  • Decision: Dialogue options the player hasn't unlocked are completely invisible. No grayed-out options. No lock icons. No hint that more options exist. The player doesn't know what they don't know. Exception: NPC holding back is communicated via monologue ("She changed the subject. Fast."), not via locked UI elements.
  • Rationale: Four reasons: (1) Asymmetry — you don't know what you don't know. (2) Dopamine — new options appearing on repeat visits IS the reward. (3) Anti-metagaming — no checklist to complete. (4) Confrontation surprise — Confront option appearing for the first time is a dramatic moment. Strongest consensus point of the entire workshop — unanimous across all 8 participants.
  • Cross-reference: Dialogue architecture (D-028), knowledge graph confidence tiers (D-041), dialogue box (D-061)
  • Source: Control & Interaction Workshop (2026-02-13)
  • Raised by: Gestalt (proposal + four-reason rationale), Nigel (emphatic reinforcement: "non-negotiable")
  • Dissent: None. Unanimous.

D-063: Confrontation — same box, different weight

  • Date: 2026-02-13
  • Decision: Confrontation uses the same dialogue UI as casual conversation — no separate confrontation mode. Different weight communicated through four mechanisms: (1) Confrontation options written in character's internal voice — italicized, first-person (regular: "Shift schedule" / confrontation: "I saw you in corridor B-7"). (2) Pre-delivery monologue beat (1-2 seconds: "This changes things. No taking it back.") — character hesitates internally before speaking. (3) World responds — NPC shifts to Tier 2 animation (D-047), entity D-033 color may fade, monologue frequency spikes, available topics narrow post-confrontation. (4) Walk-away mid-confrontation contaminates social space — NPC routine may shift, KG records incompleteness.
  • v0.1 staging: Proximity check + audio dip + text styling. Camera tighten deferred to post-v0.1.
  • Explicitly NOT: Separate confrontation UI, timed responses, visible relationship meter, correct/incorrect dialogue approaches.
  • Rationale: Confrontation should feel heavy because of what you're saying, not because the UI changed. The weight comes from pacing, voice, and consequence.
  • Cross-reference: Dialogue architecture (D-028), two-tier animation (D-047), entity color (D-033), walk-away (D-064)
  • Source: Control & Interaction Workshop (2026-02-13)
  • Raised by: Paula (four mechanisms), Ozzie (physical staging), Stig (UI container)
  • Dissent: None.

D-064: Walk-away — three-phase consequences

  • Date: 2026-02-13
  • Decision: Walking away from dialogue (WASD during conversation) triggers three distinct phases: (1) Immediate break — dialogue fades over 300ms, silence. No close button. (2) NPC reacts — animation shifts, may call after player, routine may change. (3) KG records incompleteness — the knowledge graph logs that the interaction was initiated but not completed. This is queryable and affects future dialogue, monologue, and NPC behavior. Walk-away consequences vary by NPC tolerance threshold per seed — no universal social rules to metagame.
  • Rationale: Walking away is an action with meaning. Leaving mid-confrontation is different from leaving mid-smalltalk. The KG recording means the game remembers what you started. Per-seed tolerance prevents players from learning universal "safe to walk away" rules across playthroughs.
  • Cross-reference: Confrontation (D-063), knowledge graph (D-041), dialogue box (D-061)
  • Source: Control & Interaction Workshop (2026-02-13)
  • Raised by: Paula (three phases + KG recording), Stig (WASD mechanic + 300ms fade), Ozzie (consequences), Nigel (tolerance per seed)
  • Dissent: None.

D-074: Audio aesthetic identity — insert-tech vs organic

  • Date: 2026-02-16
  • Decision: Audio design uses two sonic families with distinct aesthetic identities:
    • Insert-tech sounds: Synthetic, precise, clinical, no reverb. Monologue chimes (D-038 assets 7-8), UI feedback, future: lattice interface sounds, biometric scan confirmations. Represents neural lattice interface — artificial, computational, clinical.
    • Organic sounds: Warm, breathy, natural decay, environmental reverb. Footsteps, ambient layers, NPC movement, environmental events. Represents human cognition and physical reality — warm, imperfect, lived-in.
  • Thematic mapping: Insert-tech = neural lattice (computational precision, trustworthy but inhuman). Organic = human cognition and environment (warm, ambiguous, interpretive). Maps to D-018 trust model: close/organic sounds = reliable, long-range/insert sounds = potentially compromised.
  • Station palette — "functional warmth":
    • Low-freq foundation (60-120Hz): station hum, span gate vibration, machinery drone.
    • Mid-freq texture (200-800Hz): footsteps, object handling, conversation murmur.
    • High-freq detail (2-8kHz, sparse): scanner pings, metal impacts, environmental detail.
    • No harsh frequencies, no industrial brutality. The station is SETTLED — lived-in, maintained, comfortable enough to be complacent.
  • Environmental neutrality per D-045: Ambient audio does NOT shift with narrative state. Same station hum before and after conspiracy discovery. No music stingers for investigation progress. Emotional weight comes from monologue and player knowledge, not audio cues.
  • Cross-reference: Audio assets (D-038), sound model (D-018), environmental neutrality (D-045), setting (D-036)
  • Raised by: Inigo (insert-tech/organic split), Paula (cognitive architecture framing and trust model connection)
  • Dissent: None

D-075: Dialogue filtering — layered confidence gate on trust tier (OQ-18 resolution)

  • Date: 2026-02-19
  • Decision: KnowledgeConfidence (D-041) acts as a co-gate on TrustTier (D-028 Layer 3), not on AccessTier (Layer 1). Access tier and trust tier remain two separate filtering dimensions with different drivers:
    1. AccessTier (Layer 1): Gated by RelationshipState only. Social position determines what categories of dialogue are available. No change from current implementation. Character archetype effects are emergent — the detective's investigation naturally creates PersonOfInterest relationships (Authority access), the smuggler's social arc naturally creates Known/Friendly relationships (Peer/Insider access). No archetype tag on the pipeline.
    2. TrustTier (Layer 3): Gated by both RelationshipState AND KnowledgeConfidence:
      • Surface: any relationship + any confidence — baseline, always available.
      • Real: (Friendly or Known) + KnowsOf+ — requires both rapport and substantive knowledge.
      • Secret: Friendly + KnowsDetails+ — requires both deep rapport and actionable knowledge.
    3. KnowledgeConfidence does NOT gate AccessTier. Access is a social/positional concept ("who are you to me?"), not an information concept ("what do you know about me?"). A stranger can have Authority access (detective flashes badge) with zero knowledge. An insider can have Peer access before they know anything specific about the target.
  • Key design choice — no archetype dimension. The dialogue pipeline does not add a character-archetype tag (detective/smuggler) as a filtering axis. Instead, archetype effects on dialogue emerge from: (a) different starting RelationshipStates driven by gameplay (detective institutions → Authority access, smuggler social network → Insider access), (b) different knowledge accumulation rates (detective's analytical lattice gains KnowsOf faster → Real trust earlier), (c) D-028 Layer 1 access tags on lines already encode "this line is for authority figures" vs "this line is for insiders." This is architecturally consistent with D-010 principle 3 (no baking player identity into the game loop).
  • Rationale: Three reasons for layered-but-not-archetype:
    1. Separation of concerns. Access (social position) and trust (relationship depth x knowledge depth) answer different questions. Collapsing them into one axis would require rewriting D-028's four-layer model and D-035's tag taxonomy — both confirmed and implemented.
    2. Minimal code change. The only implementation change is adding a KnowledgeConfidence parameter to relationship_to_trust() in server/src/simulation/dialogue.rs. The caller already has access to the observer's KnowledgeGraph. No new components, no new tags, no content format changes.
    3. Emergent archetype distinction. Hardcoding archetype tags creates a maintenance burden (new character = new tag = new content variant) and reduces the "two keyholes on the same world" experience. When the detective and smuggler experience different dialogue from the same NPC, it should be because they have different relationships and knowledge, not because a tag excluded them.
  • Implementation change to #305: relationship_to_trust() gains a confidence parameter. Mapping: (Friendly, KnowsDetails+) → Secret, (Friendly|Known, KnowsOf+) → Real, (_ , _) → Surface. Caller in process_talk_interaction passes observer_kg.confidence_of(&target_sid) to the updated function.
  • Resolves: OQ-18
  • Amends: D-041 (confirms confidence-to-trust mapping; supersedes the preliminary 1:1 sketch in D-041 "Key design choices" bullet 3 with the layered model above), D-028 (Layer 3 trust now requires both relationship AND confidence)
  • Cross-reference: D-028, D-035, D-041, D-062 (confidence progression naturally unlocks new trust tiers, creating the "new options appearing" reward)
  • Raised by: Tyre (technical analysis, architecture synthesis)
  • Dissent: Gestalt endorses D-075 (reviewed 2026-02-19). The emergent archetype distinction is sufficient: access tier tags already encode "authority figure lines" vs "insider lines" in content; starting knowledge differentials produce different dialogue gate timings per character; adding an archetype filter would create per-character content maintenance burden and dilute the "two keyholes on the same world" experience (D-027). Knowledge vocabulary doc (#368) confirms this works in practice — same fact IDs, different starting confidence levels, different gate-open timing per character. Nigel's input still pending.

D-084: Dual-namespace line ID scheme — role pool + instance override

  • Date: 2026-02-25
  • Decision: Line IDs for auto-generated NPC content use a dual-namespace approach that eliminates the Q-028 collision problem without altering the existing ID format.
    • Role namespace (unchanged, primary): {role-slug}_{d|m|e}_{###} — e.g., dock-worker_d_001. These are shared lines delivered by any instance of the role. One file, one ID sequence per role-at-location. No per-instance authoring, no collision possible. All existing authored content is unaffected.
    • Instance namespace (new, opt-in): {role-slug}-{zero-padded counter}_{d|m|e}_{###} — e.g., dock-worker-07_d_001. Counter is the generation-order rank within the role group for that district, starting at 01, assigned deterministically from the world seed. Used only when a specific generated NPC needs authored content that differs from the role pool.
  • Key design choices:
    • Why the collision problem is mostly already solved: The Q-028 collision framing assumed NPC-scoped IDs require per-instance ID sequences. They don't. D-028 tagged line pools are role-scoped: dock-worker_d_001 is content that any dock worker can deliver. Forty dock workers all drawing from dock-worker_d_### is correct behavior, not a collision. A collision would only occur if two distinct authored lines shared the same ID — which the role namespace prevents by definition (one file, one sequence).
    • Instance namespace scope: Opt-in only. Tier 3 (flat wallpaper) and Tier 2 (mundane triangles) auto-generated NPCs use the role pool exclusively. Instance pools are authored only when a specific generated NPC needs content variation the role pool cannot supply (e.g., a generated NPC flagged as a triangle member with unique tell lines).
    • History log disambiguation: The speaker of a line is identified by StableId, not by line ID. Line ID identifies content; StableId identifies the speaker. (StableId: 42, line_id: "dock-worker_d_001") and (StableId: 43, line_id: "dock-worker_d_001") are two different log entries for the same content line — no collision in the log.
    • Counter stability: Generation order within a role group is seeded from the world seed. Same seed → same order → same counter assignments. Counter is recorded in the district's NPC roster at world-gen time. The counter survives save/load because it is part of the generated NPC's profile, not recomputed at runtime.
    • Schema compatibility: The existing ID regex ^[a-z][a-z0-9-]*_[dme]_\d{3}$ already accepts dock-worker-07_d_001. No regex change required. No content migration required.
  • Rejected alternatives:
    • StableId prefix (npc-00042_d_001): StableId is assigned at load time from sorted canonical IDs. Authors cannot know it before writing files. A generate-then-bake pipeline would break the content/generation separation principle. Rejected.
    • UUID suffix (dock-worker-a3f2_d_001): UUIDs are stable per seed but change across seeds, orphaning any authored instance content on replay. Rejected.
    • Slug registry with collision resolution (dock-worker, dock-worker-2, ...): First instance gets a privileged non-suffixed slug while all others get a counter, creating asymmetry with no upside. Rejected.
  • Implementation requirement: The content registry (server/src/knowledge/registry.rs or a new server/src/content/npc_slug.rs) tracks a RoleCounter: BTreeMap<String, u32> per district. Incremented when a generated NPC claims an instance namespace slot. Stored in the district manifest. Provides generate_instance_slug(role_slug) -> String returning {role-slug}-{counter:02}.
  • Hand-authored NPCs: Unchanged. kael-davan, sera-venn, and all named authored NPCs keep their current slugs and ID sequences. No migration.
  • Resolves: Q-028
  • Cross-reference: Line ID scheme (D-035), population model (D-029), NPC generation (D-024)
  • Raised by: Gestalt (Sprint 18, #544). Endorsed by Tyre pending implementation review.
  • Dissent: None.

D-090: PC voice registers — smuggler and detective speech patterns [SUPERSEDED]

  • Date: 2026-02-12
  • Superseded by: D-117 (2026-03-05). The smuggler/detective dual-lens frame is eliminated for v0.2. The tycoon is the single playable character. Voice register design for v0.2 follows culture-driven voice (D-121) applied to the player character, not the smuggler/detective partition below.
  • Decision: Each playable character has a defined voice register for monologue and dialogue:
    • Smuggler: Feeling-first. Sentence fragments. Concrete/physical vocabulary. Notices bodies, spaces, exits. Emotional baseline: wary comfort. Lies by omission. Relationship to authority: avoidance.
    • Detective: Analysis-first. Complete sentences. Institutional vocabulary. Notices patterns, inconsistencies, procedural gaps. Emotional baseline: professional detachment. Lies by reframing. Relationship to authority: representative. These registers govern all authored content per character (monologue pools per D-032, dialogue access per D-028).
  • Rationale: Register differences must be architectural, not incidental. Without defined registers, authors default toward a single generic voice and the dual-lens effect (D-027 criterion 2) collapses. The registers encode the characters' relationships to the world, not just vocabulary preferences.
  • Raised by: Mellanie, Paula
  • Dissent: None
  • Source: v0.1 Content Scoping Workshop, Mellanie Round 2 synthesis
  • Cross-reference: D-032 (separate monologue pools), D-034 (THE FRIEND pattern)

D-092: Anchor line requirement in NPC style guide

  • Date: 2026-02-12
  • Decision: Every NPC at Tier 1 and Tier 2 depth must have anchor lines — signature phrases or verbal tics that make them instantly recognizable in text. Requirements: Tier 1 NPCs (THE FRIEND, key triangle members): minimum 2 anchor lines per arc phase. Tier 2 NPCs (triangle periphery): minimum 1 anchor line. Tier 3 NPCs (background): no anchor requirement, generic pool lines only. Anchor lines must be authored, never generated.
  • Rationale: Anchor lines create the "I know that voice" moment on repeat encounters. Generation cannot produce this — generated lines are statistically average, not distinctively characteristic. The generation expansion pass (D-028) fills volume; anchor lines create identity.
  • Raised by: Mellanie
  • Dissent: None
  • Source: Wiki Review Workshop, Mellanie Round 2 proposal, consensus C-19
  • Cross-reference: D-034 (THE FRIEND pattern), D-028 (dialogue architecture), D-023 (three-tier content model)

D-093: Sova Transit District — Spatial Layout and District Topology

  • Date: 2026-02-25
  • Decision: The Sova Transit District spatial layout is confirmed. Four social sites (D-025): Terminal (Sova Logistics Hub, 44×28 visual), Bar/Last Shift (28×22 + 6m east ext.), Gate Cluster (40×32 visual, 7 zones — see zone spec below), Sector 3 residential (Drin/Naia anchor, ~15×12 visual, adjacent maintenance spine). Transit platform (The Loop stop, ~12×8 visual, bar-side) is classified as an encounter node, not a social site. District bounding box: 256×256 visual tiles (4×4 blocks per D-094). Three investigation paths confirmed: Path A (pattern recognition via camera logs/manifest), Path B (physical traversal via acoustic gap at restricted storage door seal → maintenance hatch), Path C (institutional, via Commission inspector relationship). Zone palette (surface hex / fog tint): gate cluster #b8bec4 / #0a1222; terminal #7a8490 / #0d1520; bar #6b4018 / #200c04; maintenance #4e5054 / #101214. Gate cluster zone spec (Araminta): aperture chamber 8×4 (restricted); freight staging 24×8 (private); passenger arrival 12×8 (semi-public); freight customs 20×10 (semi-private, 35 lanes at 2vt/lane); pedestrian customs 12×10 (semi-public, 3 lanes at 1vt); gate concourse 40×8 (public); observation gallery z=2 32×10 (Commission-only). Corridor widths: maintenance 2vt; internal building 34vt; secondary public 4vt; transition 6vt; gate concourse 8vt; service alcoves 12vt. Z-level scheme: z=0 maintenance corridor (Era 1, no Meridian), z=1 all main structures, z=2 gate cluster observation gallery only. Cross-z LOS: gallery rail = transparent low wall (player on z=2 sees z=1 below; upward LOS blocked except at staircase). Gate cluster social triangle: operations manager + senior freight handler + Commission inspector. Invisible infrastructure principle (G-08): every ring location reads as mundane; criminal function visible only to those who know. G-11: detective enters via gate cluster (Commission arrival); workers enter via transit platform (bar-side).
  • Rationale: Emerged from three-round workshop synthesis. Layout satisfies D-025 (social sites), D-036 (Sova Transit District), D-054 (tile movement), D-059 (fog zone palette), D-066 (dual-scale grid), D-011 (fog of perception), D-018 (sound model), D-027 (vertical slice criteria). Chunk/district hierarchy establishes architectural precedent for Q-036 generator.
  • Raised by: Full team — Gestalt (gameplay constraints), Miri (worldbuilding/lore), Araminta (visual/spatial), Tyre (technical), Paula (narrative), Ozzie (player experience). Compiled by Qatux.
  • Dissent: Araminta preferred 32×32 visual chunk size (overruled by lead and team majority). No other dissent.
  • Source: Station District Layout Workshop, Ticket #153, Sprint 20. Round document: docs/discussions/round-20-station-district-layout.md
  • Cross-reference: D-025 (social sites), D-036 (Sova setting), D-054 (tile movement), D-059 (fog system), D-066 (dual-scale grid), D-094 (district hierarchy), D-095 (transport lore), Q-036 (generator), Q-040Q-044 (transport lore questions)

D-095: Horizon Stations and Gate Infrastructure — Transport Lore

  • Date: 2026-02-25
  • Decision: Span gates are human-built structures with a single aperture enabling near-instantaneous transit. Operating schedule uses dual-use windows: freight (bulk of hours) and passenger (scheduled slots). Physical layout: aperture chamber → freight staging / passenger arrival → customs lanes → gate concourse. Horizon stations are alien-built installations (no identified builder species), self-maintaining, located at Oort-cloud distance, with 18 apertures per station (revised from 48; single-aperture stations are valid and produce isolated dead-end systems with one way in and one way out). Per-system canonical name: "The Ring." Travel is sequential-hop only (A→B→C through intermediate systems; no direct long-range transit). Per-system access tiers vary (4 tiers — some systems allow single-hop to orbital customs; no direct planetary span gate). Station Sova's horizon gates are located at The Ring (Oort-cloud orbital); the Administrative Hub contains booking offices only (not the gates themselves — correction to prior station profile text). "The Loop" is Sova's internal tram network: 6 districts, 4-minute run from Residential Core to Transit District. Workers arrive at the transit platform (bar-side) and disperse to Terminal or bar.
  • Rationale: Resolves transport lore questions Q-040, Q-041, Q-043, Q-044 raised during Workshop #153. Miri's Round 3 contribution. Horizon station as alien-built infrastructure adds worldbuilding depth without requiring a named builder species. Sequential-hop travel creates natural story hooks (layover locations, transit records, smuggling route complexity). Aperture count revised to 18 (from 48) to allow single-aperture stations, which produce the most isolated and narratively interesting dead-end systems — and leave open the question of what a single-aperture station pointing at an unknown destination means.
  • Raised by: Miri (worldbuilding), confirmed by team.
  • Amendment (2026-03-13): Aperture count range revised from 48 to 18 per project lead direction. Single-aperture horizon stations are valid; they are the mechanism for the most isolated dead-end systems, and for any system whose single gate points to a destination that is not (or not yet) part of the Reach. This change has downstream implications for the Earth question — see note in systems-framework-miri.md §7.
  • Amendment (2026-03-14): Clarified the inter-system / intra-system gate distinction and technology lineage:
    • Inter-system gates (horizon gates / founder gates): Alien-built. Aperture count and connections are properties of the alien infrastructure. Humans cannot add, remove, activate, or deactivate inter-system apertures. Gate topology is given, not chosen. The one known exception — a dormant aperture at Struve activating ~40 years ago — was not a human action; the alien infrastructure did something on its own, for reasons the Veil Institute has not explained. Whether dormant apertures exist elsewhere, and what triggers activation, is unknown.
    • Intra-system gates (span gates): Human-built technology, derived from the Veil Institute's study of alien horizon station architecture. The Institute reverse-engineered the principles governing short-range aperture formation and licensed the technology to a gate construction corporation, which now owns and operates span gate infrastructure across the Reach (and owns an entire system as its industrial base). Span gates are well-understood engineering: buildable, modifiable, commercially operated.
    • Key constraint for wiki authors: No system's aperture count or inter-system connections are the result of human decisions. Systems cannot "vote for" or "apply for" additional horizon gate apertures. A system's gate topology is an alien-determined fact that humans have adapted to, not chosen.
  • Dissent: None.
  • Source: Station District Layout Workshop, Ticket #153, Sprint 20. Round document: docs/discussions/round-20-station-district-layout.md
  • Cross-reference: D-093 (gate cluster spatial layout), Q-040 (gate dual-use topology — resolved), Q-041 (horizon station model — resolved), Q-042 (intra-system transport — partially resolved), Q-043 (station internal transit — resolved), Q-044 (gate-train integration — resolved)

D-098: TrianglePurpose Enum

  • Date: 2026-02-27
  • Decision: Social triangles carry Vec<TrianglePurpose> — a multi-tag set for playstyle accessibility. Enum values: Investigation, Economic, Social, Political, Tactical, Mundane. Tactical encodes the assassination contract in spatial form (target + protector + informant/witness). Multiple purpose tags per triangle: a smuggling operation can be Economic + Tactical simultaneously. Purpose tags ensure the right drama is surfaced to the player whose active lens matches — they add no generation cost, categorizing existing output.
  • Rationale: Purpose tags are the bridge between the generator's social structure and the player's active playstyle. The generator doesn't build for one playstyle — it tags what's already there.
  • Source: Generator Architecture Workshop (#562), 2026-02-27. docs/workshops/generator-architecture/workshop-outcomes.md §D-READY-3.
  • Raised by: Gestalt (triangle purpose model). Full team sign-off.
  • Dissent: None.
  • Cross-reference: D-025 (social site / functional cluster — triangles populate social sites), D-097 (guarantee tier system — triangles feed the audit)

D-104: Heritage Grammar Overlay for Non-Urban Palettes

  • Date: 2026-02-27
  • Decision: Data-driven HeritageGrammarOverlay structs (10 per heritage root). Loaded once at generator startup, applied at Phase 2 chunk fill by weighted blending. Blend rules: continuous fields (decorative_density, repair_visibility, etc.) use weighted average; categorical fields (boundary_character, open_space_character) use dominant heritage weight; object tag lists use union of preferred/accent tags and intersection-exclusion of excluded tags. Phase 1 exception: gathering_probability evaluated at block planning for quarter pre-assignment. Authoring domain separation: Miri authors organizational principles, boundary character, spacing, social grammar (HeritageGrammarOverlay Rust struct / authored data). Araminta authors visual expression — object sets, arrangement algorithms, floor surface variants, overhead flora density and character, wall/structure material character, boundary material type, lighting temperature (TOML modifier files, one per heritage root). Shared: ObjectTag vocabulary must be co-maintained (see Q-049).
  • Rationale: Heritage roots must be spatially legible — the visual grammar of a Frost community versus a Tide community must be apparent to the observant player without a label.
  • Source: Generator Architecture Workshop (#562), 2026-02-27. docs/workshops/generator-architecture/workshop-outcomes.md §D-READY-9.
  • Raised by: Miri (cultural grammar spec), Araminta (TOML modifier design and authoring domain). Full team sign-off.
  • Dissent: None.
  • Cross-reference: D-101 (ZonePalette — heritage modifier axis A), D-105 (informal zone typology — heritage correlations), Q-049 (ObjectTag co-maintenance)
  • Superseded by: D-167 (2026-03-24). The 7 abstract heritage roots and their grammar overlays are retired. Cultural grammar is now authored per-system using the corridor framework.

D-105: Non-Urban Informal Zone Typology

  • Date: 2026-02-27
  • Decision: Informal zones (spaces outside the community's social field) are defined by the type of social permission governing them, not by institutional absence. Three types: physical_distance — sparse objects, unmaintained floor; isolation is the visual. social_permission — normal zone palette; gathering infrastructure present; cover is about convention, not geography. utilitarian_cover — functional work objects; space reads as work space; unofficial use invisible to casual observation. Heritage root correlations: Frost/Stone → physical_distance; Tide/Vine/Dust → social_permission; Iron/Salt → utilitarian_cover. (Dust = maximum communal observation, privacy is negotiated not physical; Iron = labor function covers presence.) Location within terrain seeded independently. Visual grammar per type: docs/workshops/generator-architecture/araminta-round4.md.
  • Rationale: Privacy mechanics emerge from community culture. How you hide in a Frost community (physical distance) is architecturally different from how you hide in a Dust community (social agreement). The typology makes privacy mechanics culturally legible.
  • Source: Generator Architecture Workshop (#562), 2026-02-27. docs/workshops/generator-architecture/workshop-outcomes.md §D-READY-10.
  • Raised by: Miri (heritage root correlations, canonical mapping corrected Round 5), Araminta (visual grammar per type). Full team sign-off.
  • Dissent: None.
  • Cross-reference: D-104 (heritage grammar overlay)
  • Superseded by: D-167 (2026-03-24). Heritage root correlations (Frost/Stone/Tide etc.) are retired; informal zone typology must be re-authored against corridor cultural identities.

D-107: Trauma Events as EraModification Subtypes

  • Date: 2026-02-27
  • Decision: Trauma events are a subtype of EraModification with dual-track effects. Five subtypes: PhysicalDestruction, EconomicDisruption, PoliticalShock, ViolenceEvent, MigrationShock. Separate tracks: (1) structural damage via StructuralChange in ChunkMutations (applied as LocalOverlay per D-109); (2) cultural response via NPC weight distribution shift in DistrictRuntimeState.npc_pattern_weights. Decay rate seeded per-community with variation around heritage-root baseline (trauma_visual_decay_rate: slow | medium | fast, default medium). Design principle: Trauma intensifies culture, it does not transform it. A stressed community becomes a more concentrated version of itself — Frost communities close harder, Tide communities grief more publicly, Iron communities organize more collectively. Decay is toward the community's pre-trauma baseline, not toward a new equilibrium. Players who have learned a heritage root's trust model can predict community behavior in the aftermath.
  • Rationale: Cultural response must be legible — and predictable to a player who has invested in understanding the heritage root. Trauma as amplifier (not transformer) rewards prior observation.
  • Source: Generator Architecture Workshop (#562), 2026-02-27. docs/workshops/generator-architecture/workshop-outcomes.md §D-READY-12.
  • Raised by: Miri (trauma subtypes and heritage decay model, "trauma intensifies culture" principle added Round 5), Tyre (struct design and decay architecture). Full team sign-off.
  • Dissent: None.
  • Cross-reference: D-100 (DamageOverlay — structural track), D-104 (heritage grammar — cultural baseline), D-109 (LocalOverlay mandate)
  • Superseded (partial): Heritage-root-based decay model superseded by D-167 (2026-03-24). Trauma-intensifies-culture principle and structural track remain valid; heritage root baseline references must be re-interpreted via the corridor cultural system.

D-121: Voice is culture-driven — job as modifier

  • Date: 2026-03-05
  • Decision: NPC voice is authored at the culture level with job-specific modifiers layered on top. Culture is primary — a 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, not a generic tycoon. This is an inversion of the prior assumption that job drove voice with culture as modifier.
  • Rationale: Culture-primary voice produces characters that feel like they belong to a place. Job-primary voice produces archetypes. The life-sim vision requires characters legible as inhabitants of Van Maanen's Star, not as representatives of occupational categories.
  • Source: Where's the Fun? Workshop, Round 4 Interview, Decision 6
  • Raised by: Team Leader (Jeroen) — inversion of Mellanie's prior option C
  • Dissent: None
  • Cross-reference: D-128 (Van Maanen's Star culture as starting context)

D-122: All NPCs generated — no named hand-authored characters

  • Date: 2026-03-05
  • Decision: All NPCs in v0.2 are generated. There are no named, hand-authored characters. Kael Davan, Naia, Maret, and Sera Venn do not exist in v0.2. The generator produces NPCs that fit positions based on location characteristics. Limited vocabulary is acceptable at first. The FRIEND pattern (D-034) survives as a generator template, not an authoring assignment.
  • Rationale: Rimworld and The Sims are capable of generating characters that players form attachments to, even without dialogue or backstory. The generator-first approach (D-114) requires proving this foundation before hand-authored characters are layered on. Named NPCs and fixed triangles were a source of the rigidity that made v0.1 feel like a game level, not a place.
  • Source: Where's the Fun? Workshop, Round 4 Interview, Decision 7
  • Raised by: Team Leader (Jeroen)
  • Dissent: None
  • Supersedes: Named NPC assignments in D-034 (Kael/Sera as hand-authored characters — see amendment on D-034)
  • Cross-reference: D-123 (AI templating), D-129 (NPC personality model)

D-123: Generative AI for NPC content — build-time authoring tool and runtime voice pipeline

  • Date: 2026-03-05
  • Date (amended): 2026-03-07
  • Decision: The AI pipeline operates in two distinct modes with different safety profiles:
    • Build-time mode (authoring tool): Content generated at build time for baked hub zones. Subject to mandatory human review before shipping. AI as an accelerated authoring tool producing content humans review and approve.
    • Runtime mode (background enhancement): Content generated during gameplay for non-baked zones, via a background inference queue, when "AI-Enhanced Dialogue" is enabled. Not human-reviewed per line. Safety provided by three layers: (1) base-text-as-fallback — always present and complete; (2) build-time-validated injectors — only pre-validated prompts used, never ad-hoc; (3) runtime contamination filter — lightweight check before content is served.
    • Non-negotiable constraints (both modes): Culture vectors are the primary prompt constraint. The AI does not default to genre conventions. Authorial control governs what the LLM may and may not produce through injector clauses, negative constraints, and pipeline routing rules. The AI pipeline applies voice to authored semantic content; it does not generate narrative decisions, base text, tell behaviors, secret-tier dialogue (D-028 Layer 3), or anchor lines (D-092). These categories are always authored and always served as-authored.
  • Rationale: Full pipeline (behaviors + dialogue) is the correct scope. A system that voices observed behavior but not spoken dialogue creates register whiplash at the highest-investment moment of player engagement. Build-time mode preserves the human-review safety model. Runtime mode enables scaling to the generated world with base-text fallback as the permanent safety net.
  • Source: Where's the Fun? Workshop (original); LLM Voice Pipeline Workshop (amendment)
  • Raised by: Team Leader (Jeroen)
  • Dissent: None on amendment
  • Amendment attribution: The two-mode distinction (build-time authoring tool vs. runtime background enhancement) and the six dialogue re-voicing quality constraints are Paula's contribution from LLM Voice Pipeline Workshop Round 3. The two-mode framing is the organizing principle: build-time mode inherits the original D-123 safety model (human review); runtime mode operates under a different safety model (three-layer fallback) that was validated in Spikes 1 and 2.
  • Amended by: D-138 (LLM Voice Pipeline Workshop, 2026-03-07)
  • Cross-reference: D-121 (culture-primary voice), D-128 (culture profile as generator input), D-140 (dialogue re-voicing quality constraints)

D-124: In-game ollama for live NPC dialogue — deferred SUPERSEDED by D-138

  • Date: 2026-03-05
  • Date (superseded): 2026-03-07
  • Decision: Running a dressed-down version of ollama in-game for live NPC dialogue is possible and interesting, but deferred. Superseded by D-138. The in-game AI system uses llama-cpp-rs (not ollama) with GGUF Q4_K_M quantization, bundled with the game, running background inference via an isolated thread pool. The key constraint from D-124 remains binding through D-123 (amended): this system does not drive live narrative decisions. It applies voice to authored semantic content.
  • Rationale: The LLM Voice Pipeline Workshop (2026-03-07) walked through the door D-124 left open. The quality, performance, and determinism questions D-124 cited as blockers are addressed by cache-as-determinism, base-text fallback, and layered hardware detection.
  • Source: Where's the Fun? Workshop (original); LLM Voice Pipeline Workshop (supersession)
  • Raised by: Team Leader (Jeroen)
  • Dissent: None
  • Superseded by: D-138

D-125: World is quietly responsive — gradient of caring by social proximity

  • Date: 2026-03-05
  • Decision: The world does not care globally but notices locally. Primary social contacts (colleagues, neighbors) develop responsiveness over time. The gradient of caring is based on social proximity — the world is neither Kenshi-indifferent nor uniformly caring. The player should never encounter a truly indifferent world; even early builds will have localized responsiveness around primary contacts. Gore's concern about indifference is addressed by design — authored content will layer in before v1.0.
  • Rationale: True indifference breaks the life-sim emotional loop. Characters can't form attachments to a world that doesn't register their existence. The gradient model (socially close = responsive, globally = neutral) reflects realistic social structure and produces the "quietly alive" feel the workshop converged on.
  • Source: Where's the Fun? Workshop, Round 4 Interview, Decision 10
  • Raised by: Team Leader (Jeroen)
  • Dissent: None

D-126: Groundhog Day alarm clock homage — first game day only

  • Date: 2026-03-05
  • Decision: The first game day begins with an alarm clock that opens with the click pa-pa pa-pa opening from Groundhog Day, cut short. This happens on the first day of a new game only. The tone is a wink: "new day, new start, new chances." It sets the life-sim framing without exposition.
  • Rationale: A single tonal signal at game start establishes the day-cycle framing and communicates the game's tone — forward-moving, possibility-oriented, gently aware of its own conceits — without explicit explanation. First day only; repeating it would undermine the freshness.
  • Source: Where's the Fun? Workshop, Round 4 Interview, Decision 14
  • Raised by: Team Leader (Jeroen)
  • Dissent: None (legality of the reference to be verified)
  • Cross-reference: D-136 (first game moment design)

D-127: Player choices are the content — Rimworld model, job as rails

  • Date: 2026-03-05
  • Decision: Phase 1 of the game experience is not "an empty world before content arrives." It is "a world full of opportunity where the player's choices ARE the content." Rimworld model: one authored starting beat (the crash / the alarm clock + apartment wakeup), then agency and options. A job is rails to take off from, not a script to follow. The world provides opportunity and consequence; the player provides the story.
  • Rationale: The prior "no objectives" stance was a design stance, not a design solution. The Rimworld model is a design solution: curated starting beat, then genuine agency. Phase 1 is not empty — it is a full world of potential actions, economic choices, social encounters, and consequences. The player's story is the content.
  • Source: Where's the Fun? Workshop, Round 4 Interview, Decision 15
  • Raised by: Team Leader (Jeroen)
  • Dissent: None

D-128: Culture implicit in starting location — Van Maanen's Star equals Van Maanen's Star culture

  • Date: 2026-03-05
  • Decision: Culture is implicit in the starting bookmark location. The tycoon bookmark in Van Maanen's Star means Van Maanen's Star culture. The player does not select culture at character creation; it derives from where the bookmark places them. This resolves the culture-everywhere-but-nowhere tension: culture IS in the game from day one, it's just not a character creation slider. Van Maanen's Star provides the cultural context; NPC generation uses regional culture as the primary vector.
  • Rationale: Seven of nine workshop agents independently flagged the tension between D-115 (culture deferred from creation) and D-121 (culture primary for voice). Implicit culture unblocks five downstream pipelines simultaneously: voice cards (Mellanie), culture profiles (Miri), NpcBlueprint culture field (Tyre), cultural visual grammar (Araminta), systems integration (Gestalt).
  • Source: Where's the Fun? Workshop, Round 5 Interview, Decision 16
  • Raised by: Team Leader (Jeroen)
  • Dissent: None
  • Cross-reference: D-121 (culture-primary voice), D-036 (Van Maanen's Star canonical details)

D-129: NPC personality — traits + behavior first, relationships codified for systems

  • Date: 2026-03-05
  • Decision: NPC personality starts with traits and observable behavior. Relationships form through two channels: Sims-style accumulation through repeated interaction, and Rimworld-style bonding through shared adversity (surviving a crisis together, helping each other). The player's subjective feeling is the real metric, but relationships must be codified in the system so that game systems (storyteller, consequences, NPC behavior changes) can reference relationship state.
  • Rationale: All nine workshop agents identified NPC legibility as the universal gate. Generated NPCs must have sufficient personality surface area for emotional attachment. Without legible NPCs, the life-sim loop cannot fire. Codifying relationships for systems enables the storyteller to use them as triggers and the consequence model (D-132) to escalate through them.
  • Source: Where's the Fun? Workshop, Round 5 Interview, Decision 17 (resolves Q-WTF-034/035)
  • Raised by: Team Leader (Jeroen)
  • Dissent: None
  • Cross-reference: D-024 (NPC axes — see amendment), D-132 (consequence model)

D-130: Fully emergent moral arc for v0.2 — generator proves relationships readable first

  • Date: 2026-03-05
  • Decision: v0.2 ships a fully emergent moral arc — no authored arc structure. The tycoon bookmark has no pre-designed story arc. The explicit test before layering narrative depth: can the player tell "this is a relationship my character has" from generator output alone? Full flavor and generated content will be layered in later, but only after the relationship foundation is proven solid. This is a deliberate proof-of-concept sequence: generator proves relationships are readable → then add narrative depth.
  • Rationale: The full flavor and generated narrative content would get in the way of properly evaluating the generator's strength. The generator must be rock solid and usable before truly interesting threads are pulled. Fully emergent may feel artificial, but it is the right v0.2 test.
  • Source: Where's the Fun? Workshop, Round 5 Interview, Decision 18 (resolves Q-WTF-043)
  • Raised by: Team Leader (Jeroen)
  • Dissent: None
  • Cross-reference: D-129 (relationship legibility as test), D-119 (generator spike as prerequisite)

D-131: Broad economic verb vocabulary — life verbs, not tycoon-specific

  • Date: 2026-03-05
  • Decision: The verb vocabulary is broad and economic, serving all careers, not tycoon-specific. Life verbs: buy, sell, hire, rent, contract, inspect, negotiate, invest. A detective also uses contracts (hiring informants, renting surveillance equipment). Implementation follows the speed of the interpreting systems — each verb requires its backing system (ownership registration for buy/sell, contract tracking for hire/rent). This is a life-sim verb set, not a job-specific verb set.
  • Rationale: Tycoon-specific verbs would lock the gameplay loop to one archetype. Broad economic verbs serve the life-sim vision where "detective, smuggler, tycoon are jobs you can have, not the game's identity" (workshop executive summary). The verb map is the mechanical expression of that philosophy.
  • Source: Where's the Fun? Workshop, Round 5 Interview, Decision 19 (resolves Q-WTF-027)
  • Raised by: Team Leader (Jeroen)
  • Dissent: None

D-132: Dual-scale consequence model — Rimworld sharp events and DF slow accumulation

  • Date: 2026-03-05
  • Decision: The consequence model operates at two scales simultaneously. Rimworld-style sharp events (raids, crises, dramatic reversals) AND Dwarf Fortress-style slow accumulation (gradual relationship erosion, creeping debt, reputation shifts). Sharp events create drama; slow accumulation creates texture. Rimworld already manages both — sharp storyteller events on top of slow colony degradation. The Settled Reach follows the same dual-scale model.
  • Rationale: The dual-scale model produces both moment-to-moment drama and long-term narrative texture. A single-scale model either feels like it has no consequences (all slow) or like consequence happens arbitrarily (all sharp). Both are load-bearing.
  • Source: Where's the Fun? Workshop, Round 5 Interview, Decision 21 (resolves Q-WTF-037)
  • Raised by: Team Leader (Jeroen)
  • Dissent: None
  • Cross-reference: D-129 (relationships as consequence substrate)

D-138: LLM Re-voicing Pipeline for NPC Voice

  • Date: 2026-03-07
  • Decision: NPC observable behaviors and dialogue are processed through an LLM re-voicing pipeline that translates culture-neutral semantic base text into character-voiced output. The pipeline is a background runtime enhancement, not a live generation system. Tell behaviors are base-text passthrough — always. Active tell state influences the re-voicing prompt for surrounding content (tells are read-only inputs to the LLM, never LLM outputs). The game is complete and functional without the pipeline; it is an enhancement that elevates voice quality for players with sufficient hardware.
  • Architecture:
    • Model: Gemma 2 2B IT Q4_K_M (~1.6GB), bundled as server/models/gemma2.gguf. No fallback model. (Amended 2026-03-07: Phi-3 dropped entirely after Spike 1 — Gemma 2B produces superior culturally-differentiated output at the same quantization. Original GGUF: gemma-2-2b-it-Q4_K_M.gguf from Hugging Face bartowski/gemma-2-2b-it-GGUF.)
    • Runtime: llama-cpp-rs with GGUF format. Separate inference thread pool at below-normal priority. (Amended 2026-03-07, Spike 2: IPC is stdin/stdout JSONL pipes, not HTTP. Each worker owns a piped sr-voice child process — no network ports. This satisfies Gemma 2 Terms & Conditions: model is only reachable through the game server's queue, never exposed as a service.)
    • Content tiers: Baked (hub zones, build-time, human-reviewed) → Pre-voiced (background queue, priority-ordered) → Base text fallback (always present).
    • Tell treatment: Passthrough always. Tell state flows into re-voicing prompts as universal tone injectors. Cultural flavor is conditional and additive — humans are humans first; micro-expressions and body language must remain universally recognizable. Per-culture tell-tone tables are optional enrichment, not a launch requirement. (Amended 2026-03-07, Spike 2: Tell differentiation at 2B — 3/5 tells produce distinguishable output (Nervous, Guarded, Angry). Friendly and RoutineDeviation are inert at 2B capacity — model cannot reliably differentiate them from neutral. Deferred to post-ship or larger model. Angry tell requires length-aware injectors: short/medium content gets standard compression, long content (≥16 words) gets an explicit "keep full claim intact" instruction to prevent destructive information loss.)
    • Determinism: Cache-as-determinism. LLM generates once per seed; result cached. Cache lookup is deterministic.
    • Caching: Content-length-gated variants. Short lines (≤7 words): neutral only. Medium lines: 3 variants (neutral, high-affect, guarded). Long lines: up to 6 variants. Key: (npc_stable_id, line_id, tell_state, culture_id). (Amended 2026-03-07: Spike 1 confirmed 2B model cannot produce distinguishable tell-state variants on short lines — 5/5 states produced near-identical output for "Inspection's next week." Length-gated caching reduces wasted compute/storage.)
    • Hardware: "AI-Enhanced Dialogue" toggle. Layered detection: RAM check → TPT benchmark → recommendation. No hard minimum spec floor. Player can always override.
    • Distribution: Model bundled in game install (~1.5GB).
    • Protected categories (never re-voiced): Tell behaviors, secret-tier dialogue (D-028 Layer 3), anchor lines (D-092), relationship-specific lines naming third parties.
    • Composition engine: Occasional prompt injections (e.g. oath vocabulary, faith expressions) are controlled by the prompt generator at a configurable frequency (e.g. 1-in-4), not by the model. The model never decides injection frequency — it either receives the clause or doesn't. This is a systemic pattern applicable to any culture marker that should appear occasionally. (Added 2026-03-07: Spike 1 proved 2B models treat vocabulary lists as required markers. Composition-engine gating eliminates both over-use and under-use.) (Amended 2026-03-07, Spike 2: Prompt architecture uses a double-prompt technique — critical constraints are repeated in a REMEMBER block immediately before the OUTPUT: stop token to anchor them in the 2B model's attention window. Epistemic markers ("I heard", "apparently", "I think") are preserved via example-based integration, not keyword lists — keyword lists caused the model to emit comma-separated marker dumps. Injections use imperative framing: once fired by the composition engine, the model executes without discretion.)
    • Content classification: Base text should be classified by content type. Dialogue and Behavior pass through the LLM. A new Factual content type is recommended for lines bearing specific numbers, causal chains, or denial statements — these bypass the LLM entirely and serve base text, because 2B models cannot reliably preserve quantitative precision (e.g., "14 crates in bay seven" became "fourteen crates are missing"). (Added 2026-03-07, Spike 2: Paula endorsed ContentType::Factual over template-based approaches.)
    • Negative injectors: All negative injectors (NI-1 through NI-5) belong in per-culture voice personas, not in universal RULES. The universal RULES const contains only format constraints (one line, complete sentences, no invention). Worldbuilding constraints — military ranks, technology vocabulary, humor register, religious language, Earth references — vary by system/planet/location/culture and are authored per-culture in voice_persona. (Amended 2026-03-07, Spike 2: Jeroen directed removal of all worldbuilding from universal RULES. "Military ranks do exist in some parts of the settings." "Why all these assumptions." NI-2/NI-3/NI-4 removed from universal scope; all NIs are now culture-specific.)
  • Validation: Two-spike strategy. Spike 1: Rust sr-voice CLI + manual prompt testing (Jeroen/Mellanie/Paula). Spike 2: full pipeline integration (queue → worker pool → sr-voice child → cache → disk). (Amended 2026-03-07, Spike 2: Both spikes complete. 39 edge-case test prompts across 8 categories (length, tells, epistemic markers, injections, behaviors, named entities, causal chains, denials). Three rounds of iterative prompt refinement with Paula, Mellanie, and Gestalt reviewing output. Pipeline tested end-to-end with real Gemma 2B at ~16 t/s CPU.)
  • Rationale: D-122 (all NPCs generated) and D-128 (culture implicit in starting location) require NPC voice to scale across zones and cultures without O(R×Z×C) hand-authoring. The re-voicing model is the only architecture that scales while preserving content quality. Base-text fallback ensures the game is complete without the pipeline.
  • Source: LLM Voice Pipeline Workshop (2026-03-07)
  • Raised by: Team Leader (Jeroen), with Gestalt, Tyre, Paula, Mellanie, Ozzie, Miri, Troblum
  • Dissent: Miri flagged concern about cultural philosophy at 2B model size — addressed via hybrid injector format (instruction + example pairs) and spike validation.
  • Amends: D-123 (scope extended from authoring tool to authoring + runtime)
  • Supersedes: D-124 (in-game AI no longer deferred)
  • Resolves: Q-057 (composable behavior generation), Q-012 (generation expansion method)
  • Cross-reference: D-010 (information boundaries), D-121 (culture-primary voice), D-122 (all NPCs generated), D-128 (culture as generator input), D-029 (NPC tier model), D-092 (anchor lines), D-140 (dialogue re-voicing quality constraints)

D-139: Composable behavior primitives — three-layer assembly model

  • Date: 2026-03-13
  • Decision: Observable NPC behaviors are composed from three layers rather than authored as flat strings per culture×zone×role combination. The three layers are:
    1. BehaviorPrimitive (on RoleSpec): role-generic physical stage directions (e.g., "moves freight containers", "runs diagnostics on a terminal"). Tagged with a BehaviorContext (OnShift/OffDuty/Social/Any) that gates when the behavior is eligible. Optional modifier_hint for category matching.
    2. BehaviorModifier (on CultureProfile): culture-specific clauses appended to actions (e.g., "with mechanical efficiency", "with a watchful eye"). Categorized for matching (work_style, demeanor, social, etc.).
    3. Assembly function (assemble_behaviors): at NpcBlueprint instantiation time, filters primitives by context, selects a culture modifier per primitive (preferring hint matches, falling back to any), concatenates action + " " + modifier.clause. No modifier → action text used as-is.
  • Rationale: The current model has typical_behaviors: Vec<String> on RoleSpec — flat strings per culture×zone×role. At ~50 behaviors × 4 roles × N zones × M cultures, this is O(roles × zones × cultures) custom content. Decomposition to primitives + modifiers reduces to O(roles + cultures) authored content. Assembly is deterministic via SimRng, so behavior output is reproducible for a given seed. The three-layer model maps directly to the existing CultureProfile/RoleSpec/NpcBlueprint data flow — no new serialization formats or pipeline stages.
  • Implementation: server/src/npc/blueprint.rsBehaviorPrimitive, BehaviorContext, BehaviorModifier structs + assemble_behaviors() function. RoleSpec.behavior_primitives: Vec<BehaviorPrimitive> (serde default, backward-compatible). CultureProfile.behavior_modifiers: Vec<BehaviorModifier> (serde default). Legacy typical_behaviors field preserved until content migration complete.
  • Migration path: Copy team populates behavior_primitives on zone spec RON files and behavior_modifiers on culture RON files. Generator switches from typical_behaviors to assemble_behaviors() when primitives are present. Once verified equivalent for seed 42, legacy field can be removed.
  • Source: Sprint 26, ticket #633 (implements Q-057)
  • Raised by: Tyre (Technical Architect)
  • Dissent: None (design resolves the scaling problem identified in #630 sprint review)
  • Resolves: Q-057 (composable behavior generation — data structure definition)
  • Cross-reference: D-138 (resolved pipeline, this resolves data format), D-121 (culture-primary voice), D-122 (all NPCs generated)

D-140: Dialogue re-voicing quality constraints — Paula's six rules

  • Date: 2026-03-13
  • Decision: Six binding constraints govern the LLM re-voicing queue for all dialogue lines. These rules protect the information asymmetry mechanic (D-005), character voice integrity, and game narrative legibility. They are implemented in the prompt engineering layer and validated in baked content review.
    • D-140-R1 — Secret-tier passthrough: Lines tagged trust: secret (D-028 Layer 3) never enter the re-voicing queue. They are served as authored base text unconditionally. Re-voicing risks dramatization (inflating the disclosure) or trivialization (flattening the weight of the secret) — both failures corrupt the earned relationship payload.
    • D-140-R2 — Epistemic weight must not shift: Certainty level of factual claims must survive re-voicing unchanged. Hedge words ("I think," "I heard," "might be," "probably") and direct evidential markers ("I saw," "I was there," "he told me") must appear in re-voiced output with the same epistemic force as in the base text. Epistemic drift is the dialogue re-voicing failure mode most invisible to reviewers and most damaging to gameplay — the player reads voiced text and constructs a knowledge model. A shifted hedge changes what the player knows.
    • D-140-R3 — Access tier feel must be preserved: The social register appropriate to the D-028 access tier tag must survive re-voicing. public stays neutral-transactional; peer stays lateral-relaxed; insider stays familiar-complicit; authority stays institutional-asymmetric; hostile stays minimal-closed. The tag governs eligibility; the register governs feel. An insider line re-voiced into institutional language reads as authority to the player regardless of tag. Implementation: access tier injected as a constraint clause alongside the culture injector.
    • D-140-R4 — Named entities are passthrough within output: Any proper noun in the base text (NPC names, location names, faction names, technology terms) must appear verbatim in the re-voiced output. Named entities carry specific information — "Kael" and "that dock worker" are not interchangeable in an information-asymmetry game. Implementation: extraction step before re-voicing; protected entity list injected as a hard constraint. The extractor need not understand lore — capitalized terms are sufficient for identification.
    • D-140-R5 — Relationship-specific lines are passthrough: Any dialogue line naming a specific third-party NPC or describing a specific interpersonal event is not re-voiced. It is served as authored base text. These lines carry social information whose phrasing is load-bearing — the hesitation, the neutral delivery, the precise ambiguity are all authored intentionally. Re-voicing risks substituting the named NPC with a reference, dramatizing the event, or adding social judgment not in the original.
    • D-140-R6 — Tell-context modifier cannot override culture register: When a tell-context injector is active, it shapes emotional inflection within the culture register — it does not replace the register. A Van Maanen's Star NPC with a Nervous tell still speaks in Van Maanen's Star register (direct, minimal pleasantries, working-class pragmatic) while the content reflects nervous pressure. Culture is primary (D-121); tell-context is situational. Implementation: culture injector is always applied before tell-context modifier; tell-context is framed as inflection, not override.
  • Rationale: D-138 established the architecture; these rules operationalize the quality floor for dialogue content specifically. Dialogue re-voicing carries higher information risk than behavior re-voicing — dialogue is direct player-NPC exchange where epistemic signals and relationship registers matter most. These rules scale with the pipeline: at 300 systems and thousands of NPCs, the prompt engineering layer must enforce these constraints programmatically, not through per-line human review. The constraints are formalized here so server team, copy team, and QA can reference them independently.
  • Scaling note: R4 (named entity extraction) requires a proper noun tagger that works across all culture naming conventions — Van Maanen's Star names differ structurally from other cultures. The extractor approach (capitalized terms as proxy) is sufficient for the Van Maanen's Star launch system but must be culture-aware for systems with non-capitalized or logographic naming conventions. This is a DLC-scope concern, not a v0.2 blocker.
  • Source: LLM Voice Pipeline Workshop (2026-03-07), Paula Round 3 (docs/workshops/llm-voice-pipeline/paula-round3.md)
  • Raised by: Paula (LLM Voice Pipeline Workshop, Round 3)
  • Dissent: None
  • Cross-reference: D-123 (pipeline modes), D-138 (full architecture), D-028 (access tier model), D-005 (single character, information asymmetry as core), D-092 (anchor lines)

D-142: Zone-type template architecture for scalable NPC behavior

  • Date: 2026-03-13

  • Decision: Behavior primitives are zone-type-generic, not per-location. The content architecture for NPC behavior across 300+ systems is a three-layer composition model:

    Layer 1 — Zone-type primitives (what the body does): Universal physical stage directions per role, defined at the zone-type level. A farmer role in a rural_agricultural zone does the same base actions in any system. Primitives are authored once per role per zone type. They are context-tagged (OnShift, OffDuty, Social) and carry an optional modifier_hint for category-matched culture assembly.

    Layer 2 — Culture modifiers (how this culture does it): Clauses appended to primitives at assembly time, defined on CultureProfile. Seven categories: work_pace, physical_manner, social_signal, task_completion, environmental_scan, offduty_posture, authority_response. Culture modifiers are authored once per culture, work with all zone types immediately.

    Layer 3 — Gemma LLM flavor (what's happening here and now): Runtime enrichment only. Adds location-specific sensory and environmental detail: weather, time of day, lighting, ambient sound, physical environment state. Layer 3 is culture-neutral — it must not introduce cultural vocabulary, must not generate named entities, must not override culture register (D-140-R6), must not alter epistemic markers (D-140-R2). Layer 3 follows the pre-voiced three-layer safety model from D-138 (base-text fallback on failure, validated injector vocabulary, contamination filter for named entities). If Layer 3 fails or is unavailable, the Layer 1+2 assembly is served as-is.

    Standalone readability constraint: Layer 1+2 assembly (base text) must be playable and informative without the LLM. A player reading base text must be able to read what an NPC is doing. "Works a crop row, stopping to pull weeds, without wasted motion" is informative; "farms" is not. This constraint governs primitive authoring across all zone types.

    Location spec format: Location files (content/locations/{system}-{zone}.ron) declare a zone_type identifier and reference a culture. They carry metadata (economic_level, population_density, role weights, social sites) but contain no primitives. All behavior content lives at the zone-type and culture layers.

  • Zone-type taxonomy (31 types, v1.0): The following zone types constitute the canonical behavior template library. Each produces a distinct NPC behavior pool and distinct map generator layout template. Zone types sharing a group prefix differ enough in physical layout to require separate templates.

    Group Zone Types
    Rural rural_agricultural, rural_pastoral, rural_aquaculture, rural_orbital
    Industrial industrial_freight, industrial_manufacturing, industrial_processing
    Port port_space, port_surface, port_maritime, port_fishing
    Extraction extraction_space, extraction_surface, extraction_platform
    Commercial commercial_market, commercial_transit
    Administrative administrative_civil, administrative_judicial
    Single research_station, medical_facility, military_garrison, security_checkpoint, entertainment_hospitality, entertainment_venue, residential_station, residential_surface, residential_dispersed, detention_facility, archaeological_site, wilderness_frontier, diplomatic_elite

    Subtype distinctions within groups are map-generator-significant: a port_space (docking bays, airlocks, approach corridors) generates a physically different layout from port_maritime (piers, wharves, waterfront) or port_fishing (jetties, small craft, catch processing), and the NPC actions differ accordingly.

  • POI system (three-tier): Points of interest that create narrative destinations (monuments, gatebuilder ruins, prisons, pilgrimage sites, abandoned installations) are handled at three levels without requiring new zone types for each:

    Tier 1 — POI-as-zone-type: Sites large enough to have distinct layout, NPC population, and behavior pool are zone types. archaeological_site and detention_facility are in the canonical 31. Additional large POI zone types can be added as content permits.

    Tier 2 — abandoned flag: Any zone type can carry abandoned: true on its location spec. The map generator produces a decay variant of the base layout; the behavior pool switches to a cross-cutting scavenger/squatter/investigator primitive set. This generates abandoned station variants, ruined industrial facilities, collapsed residential blocks, and derelict extraction rigs without pre-authoring each as a separate zone type.

    Tier 3 — poi_overlay field: Small POIs (monuments, memorials, commemorative markers, shrines, public art) exist within an existing zone rather than as their own map. The location spec carries a poi_overlay list; the map generator places overlay elements within the zone layout. No new behavior pool required.

    The combination handles the full POI design space: gatebuilder_ruin = archaeological_site zone type; abandoned_station = any station zone type + abandoned: true; monument = poi_overlay on a commercial_transit or residential_surface zone; pilgrimage_site = poi_overlay cluster on appropriate base zone, or its own zone type if narrative scale warrants.

  • Scale math: 31 zone types × ~4 roles × ~15 primitives = ~1,860 authored primitive lines. 300+ cultures × ~12 modifiers = ~3,600+ modifier clauses. ~5,500 authored lines produce behavior across unlimited locations. Authoring cost is O(zone_types + cultures), not O(locations). New location: pick zone type + culture + metadata — zero behavior authoring. New culture: ~12 modifiers + voice persona — works with all 31 zone types immediately. New zone type: ~60 primitives — works with all cultures immediately.

  • File layout:

    • Zone-type templates: content/global/zone-types/{zone_type}.ron
    • Culture profiles: content/global/culture-{name}.ron (existing)
    • Location specs: content/locations/{system}-{zone}.ron (metadata only, no primitives)
  • Rationale: The per-location primitive model (current typical_behaviors and per-location behavior_primitives arrays) does not scale to 300 systems. A Van Maanen's Star farmer and a Vael farmer doing the same physical work in the same zone type are authoring the same primitives twice — the content that differs between them is the how (culture), not the what (the physical action). Separating these dimensions reduces authoring cost by an order of magnitude and ensures that adding a new system is a metadata operation, not a content sprint. The standalone readability constraint ensures the system degrades gracefully when the LLM is unavailable, which is a runtime reliability requirement for a 300-system game, not just a fallback policy.

  • Layer 3 grammar constraint: When Gemma appends environmental flavor to Layer 1+2 assembled text, the flavor clause must grammatically attach as a prepositional phrase or coordinating conjunction. Absolute and participial phrases (e.g., "tool already in hand") require a leading comma separator. Culture-specific modifier clauses that use absolute-phrase construction must include the separator (e.g., ", tool already in hand") or be rewritten as prepositional form ("with tool in hand") to ensure clean assembly. This constraint applies to all culture profile modifier authoring.

  • Source: Sprint 26 zone-type taxonomy discussion (2026-03-13); behavior review (#634); user requirements for 300-system scalability

  • Raised by: Paula (zone-type taxonomy and POI system); Gestalt (assembly engine); Mellanie (primitive content); Tyre (architectural review)

  • Dissent: None

  • Supersedes: Per-location behavior pool approach from current zone spec format (behavior_primitives arrays on location RON files). Location files retain metadata but behavior content migrates to zone-type template files.

  • Amends: D-139 — D-139 defined the assembly mechanics (BehaviorPrimitive, BehaviorModifier, assemble_behaviors); this decision defines the content architecture that feeds it. D-139 remains the implementation record; D-142 is the content architecture record.

  • Cross-reference: D-138 (LLM pipeline — Layer 3 safety model), D-140 (quality constraints — R4, R6 apply to Layer 3), D-139 (assembly mechanics), D-121 (culture-primary voice), D-036 (Van Maanen's Star setting origin of first zone specs), D-128 (culture implicit in location)


D-143: GD calendar epoch — Gate Discovery (2300 AD) as year 0

  • Date: 2026-03-14
  • Decision: The Settled Reach uses the Gate Discovery (GD) calendar. Year 0 GD = 2300 AD. The game present is ~600 GD (~2900 AD). The secession occurred ~300 GD (~2600 AD). The five settlement waves span 0600 GD. Earth dates (AD/BC) exist but are an Earth-internal reference most Reach residents wouldn't use. All age_years fields in the systems framework measure years before game present, not GD years directly.
  • Rationale: A civilization that seceded from Earth would not use an Earth religious calendar. The gate discovery is the founding event of the Reach — the moment human settlement beyond Sol became possible. 2300 AD provides enough time (~275 years from present day) for pre-gate spacefaring development including Mars terraforming (~2100-2200 AD, or roughly -200 to -100 GD).
  • Implications: Mars terraforming predates the gates — it's an Earth-only achievement, which adds to the "we built everything" obligation narrative. The ~12,900-year span of human civilization becomes a number only Earth institutions would cite. Reach residents measure history from the gates forward.
  • Reference timeline:
Event GD AD
Human civilization origin ~-10600 GD ~10,000 BC
Mars terraforming begins ~-200 GD ~2100 AD
Gate Discovery (epoch) 0 GD 2300 AD
Five settlement waves 0600 GD 23002900 AD
Secession ~300 GD ~2600 AD
Game present ~600 GD ~2900 AD
  • Cross-reference: D-036 (setting), Sol wiki page (GJ-0)

D-144: Sirius (GJ 244A / S-067) as Reach capital — seat of the Concord Assembly

  • Date: 2026-03-14
  • Decision: Sirius is the political capital of the Settled Reach and the seat of the Concord Assembly. It is a hub system (5 apertures, 5 gate connections) in the institutional core, settled in wave_1, 8.6 ly from Sol. Its real-world prominence (brightest star in Earth's sky) maps to its in-setting political centrality. Marked as generation_priority: campaign_anchor.
  • Rationale: The capital needs to be a recognizable name that players immediately associate with importance. Sirius's existing topology (hub, 5 connections) already makes it structurally central. Wave_1 settlement means it has the institutional depth to house the Assembly. The symbolic weight of the brightest star as the seat of power writes itself.
  • Cross-reference: D-143 (timeline), D-036 (v0.1 setting)

D-147: Aesthetic taste as character personality trait — shared root for cosmetic and environmental expression

  • Date: 2026-03-17
  • Decision: Characters have an aesthetic_taste personality trait (preferred palette, style leanings) that naturally expresses in both personal appearance and living space. This is NOT a cosmetic→apartment pipeline — hair color does not map to wall color. Instead, taste is a shared root: someone who gravitates toward teal will pick teal clothing AND own a teal vase. The apartment generator reads the character's taste trait (alongside economic position from #615 and cultural context from #679); the character customisation screen lets the player express that same taste through appearance choices. Neither system depends on the other — both read the same underlying trait.
  • Rationale: The naive approach (pipe cosmetic choices into apartment generator) creates a crude "team color" mapping that feels artificial. The elegant approach: taste is a personality attribute, like traits or skills. It manifests independently in multiple contexts. This keeps #619 (customisation) and #617 (apartment) architecturally independent while producing coherent identity expression. The taste trait is also reusable: NPC aesthetic preferences, gift preferences, "does this room feel like home" comfort checks, cultural style variations.
  • Dependency implication: #619 does NOT block #617. Both read the character's taste trait independently. The taste trait definition belongs to the character data model (server), not to either consuming system.
  • Information boundary (D-010): aesthetic_taste is a public trait — visible to other entities and the client. NPCs can observe the player's taste (e.g. gift relevance, comfort assessment). This is not private knowledge behind the information boundary.
  • Source: Sprint 27 planning pass — Q-WTF-040 resolution
  • Raised by: Project lead (taste-as-shared-root framing), Gestalt (ColorHint concept evolved into trait), Paula (culture + economics as primary apartment drivers)
  • Dissent: Ozzie argued for direct cosmetic→apartment pipeline. Tyre and Paula argued for no connection at all. The taste trait is the synthesis: connection through personality, not through data pipeline.
  • Cross-reference: D-125 (quiet responsiveness), D-134 (full character customisation), D-136 (first game moment), ticket #617 (auto-generated apartment), ticket #619 (full character customisation)
  • Resolves: Q-WTF-040


Content Pattern Note: Generator-compatible overheard conversation format (ticket #664)

  • Date: 2026-03-17
  • Status: Content pattern noted — pending formal D-record (check with Qatux before claiming ID)
  • Pattern: content/npc-conversations/overheard.ron introduces a new content type: a pool of NPC-to-NPC overheard conversations parameterized by role_pair and zone_types (matching zone-type template role IDs from D-142). No named NPC references. Culture-neutral text that accepts culture modifier at assembly time. Replaces overheard.yaml.deprecated (v0.1 hand-authored pool with named NPCs, superseded by D-122).
  • Format fields: id, zone_types[], role_pair(a, b), register (Work|Social|Gossip), relationship_context (Colleague|Acquaintance|Friend|Superior|Subordinate), topic, lines[(speaker:A|B, text)], knowledge_payload (Option<String>)
  • Occlusion authoring rules: D-078 rules apply unchanged — front-load key info, short declarative sentences, no pronoun-first openers, each turn self-contained.
  • Runtime resolution: Generator selects conversations where two nearby NPCs match role_pair and zone_types. Knowledge payload is exposed to player inference layer (partial occlusion reduces but cannot eliminate inference value of a fully-heard payload).
  • Schema location: server/src/npc/overheard.rs :: OverheardPool — TBD pending #663 struct changes.
  • Raised by: Paula (Sprint 27, ticket #664)
  • Decision needed: Whether to formalize this as D-NNN or treat as sub-pattern of D-142. Recommend D-record since it introduces the knowledge_payload field as a new ambient information delivery mechanism distinct from existing dialogue architecture (D-028).

D-167: Heritage Roots Superseded — Corridor Cultural System Replaces Abstract Roots

  • Date: 2026-03-24

  • Decision: The 7 abstract heritage roots (Frost / Stone / Tide / Vine / Dust / Iron / Salt) are retired. Clean break. The real-world cultural corridor system is canonical:

    • North Reach: Commonwealth (British / Australian / Canadian / South African / Indian / Nigerian)
    • South Reach: Iberian / Latin American + Southern African
    • East Reach: East Asian + South / Southeast Asian
    • West Reach: Northern / Central European + Central / Eastern European

    Cultural data is authored per-system in systems.db and the 301 wiki entries. The wiki IS the cultural register — the corridor framework from docs/design/cultural-migration-pressure.md was the input to wiki authoring, and now the wiki text is the input to generation and naming.

  • Rationale: The heritage root system was an abstract intermediate layer that never mapped cleanly onto the actual cultural material being authored. The corridor framework produced 301 grounded wiki entries with real cultural specificity. Retiring the abstract roots in favour of the concrete wiki-and-corridor system eliminates the translation step and keeps the cultural register in one canonical place.

  • Raised by: Jeroen, established 2026-03-24 during world generation workshop.

  • Dissent: None.

  • Supersedes: D-104 (heritage grammar overlay for non-urban palettes), D-105 (non-urban informal zone typology — heritage root correlations), D-101 axis A (ZonePalette modifier axis A = HeritageRoot, in decisions/architecture.md), D-107 (trauma events — heritage root baseline in cultural decay model).

  • Cross-reference: docs/design/cultural-migration-pressure.md, wiki/star-systems/ (301 entries), docs/workshops/world-generation/sw1-interview-answers.md


D-168: Iserlohn (GJ-532c) planet name — keep, real-city origin documented

  • Date: 2026-04-05
  • Decision: The planet name "Iserlohn" (GJ-532c, in the Kettenschmied system) is retained. The name derives from Iserlohn, a real industrial city in the Sauerland region of North Rhine-Westphalia, Germany — historically a centre of wire-drawing, chain manufacturing, and metal fabrication. This origin is directly coherent with Kettenschmied's identity as a west_reach German-heritage metalworking community. The real-city reading is the intended and primary reading.
  • IP note: Iserlohn Fortress is an iconic location in Legend of the Galactic Heroes (Ginga Eiyuu Densetsu). The name collision is acknowledged. The decision to retain is deliberate: the real-world German city predates the anime by centuries; real geographic names are not protectable; and the concept diverges fundamentally — a cold marginal mining/fabrication planet (1,000 population, component fabrication, asteroid mining) is the structural opposite of a strategic military megastructure. No reader can point at GJ-532c and say "that's the LoGH fortress" — the contexts share only a name.
  • Preferred alternative on record (if future team prefers a rename): Altena — a Sauerland city at the confluence of Lenne and Volme rivers, historically the actual birthplace of German wire-drawing and chain manufacture. The Altena castle became the site of the first industrial wire-drawing operation in the German states. Altena has no known SF franchise association and carries stronger historical precision for chain/cable fabrication. It would require an atlas rename of GJ532c and corresponding wiki edits.
  • Raised by: Miri (Sprint 31, ticket #773)
  • Dissent: None.

46 decisions. Last updated: 2026-04-05 (D-168 Iserlohn IP evaluation filed)