settled-reach/docs/workshops/content-gap-analysis_v0_1/round2-gestalt.md

Round 2: Gestalt (Systems Design) - Synthesis

Workshop: v0.1 Content Gap Analysis Date: 2026-02-11 Scope: Mechanical convergence across all Round 1 outputs + Jeroen's Round 2 directives

---

0. Directives Acknowledged

Before I get into synthesis, let me confirm the constraints from Jeroen's Round 2 direction. These are locked. No further debate:

Directive	Status	Mechanical Implication
Separate monologue pools per character	Confirmed, non-negotiable	Two parallel content trees. character is a hard partition tag, not a filter.
Color = relationship to player	Approved	Entity color is a client-side derivation from RelationshipState component + knowledge state. Not an NPC property.
Audio included in v0.1	Confirmed	6-8 AI-generated files. Sound event system architecture must support this. Visual fallback for everything beyond those files.
One NPC per character = THE FRIEND	Confirmed	Two production-level NPCs. Full pipeline depth test. All systems exercised on these two.
Wiki structure for taxonomy	Non-negotiable	Miri handling. Tag taxonomy I define here must integrate with wiki structure.
Line pool format (YAML)	Needs validation	Mellanie and Paula must sign off. That's what this section does.

---

1. Converged Line Pool Format

Let me break down what this actually means mechanically. Three people proposed tag schemas in Round 1. Let me reconcile them.

Schema Comparison

Tag	Gestalt R1	Mellanie R1	Paula R1 (implied)	Converged
id	{template}_{type}_{###}	{template}-{role}-{situation}-{##}	Not specified	Keep Gestalt format — machine-parseable, stable
text	string	string	string	Keep
role / speaker	role (enum per template)	speaker (enum per template)	Implied by NPC profile	role — the template role, not the NPC name. NPC assignment is runtime.
character	N/A (on monologue only)	character (smuggler/detective/any)	Implied	character — but ONLY on monologue lines. Dialogue lines are character-agnostic; the access tier handles filtering.
access	list<enum>	single enum	Per-line, hard filter	list<enum> — a line can be eligible for multiple access tiers
trust	enum (surface/real/secret)	enum (same)	Three disclosure tiers, progressive	Aligned. No change.
situation	list<enum>	list<enum>	Relationship history + context	list<enum> — see converged situation taxonomy below
topic	list<enum>	single enum	Mood + topic for Layer 4	list<enum> — lines can cover multiple topics
mood	list<enum>	single enum	Mood for weighted selection	list<enum>
location	N/A (implicit from file)	enum	N/A	Drop from line-level. Location is implicit from the file's directory. Adding it per-line is redundant and an error source.
type	N/A (implicit from file)	type (dialogue/monologue/env/ticker)	N/A	Drop from line-level. Content type is implicit from file name (dialogue.yaml vs monologue.yaml).
tags	list<string> freeform	N/A	N/A	Keep — escape hatch for author intent that doesn't fit taxonomy
dual_lens	map (per-character notes)	N/A	Critical for authoring	Keep — authoring-only, not consumed by engine
notes	string	N/A	N/A	Keep — authoring-only
trigger	On monologue only	N/A	N/A	Keep for monologue — the observation event that fires the line
prerequisite	On monologue only	N/A	N/A	Keep for monologue — knowledge state gate

Converged Tag Taxonomy — FINAL (pending Mellanie/Paula sign-off)

Structural tags (required on every dialogue line):

Tag	Type	Values	Maps to D-028 Layer
id	string	{template}_{d|m|e}_{###}	N/A (indexing)
text	string	The authored line	N/A (content)
role	enum	Template-defined roles	N/A (speaker assignment)
access	list<enum>	public, insider, authority, peer, hostile	Layer 1 (hard filter)
trust	enum	surface, real, secret	Layer 3 (hard filter)
situation	list<enum>	See taxonomy below	Layer 2 (context filter)

Selection tags (recommended, fallback to defaults if empty):

Tag	Type	Values	Maps to D-028 Layer	Default
topic	list<enum>	See taxonomy below	Layer 4 (weighted selection)	[general]
mood	list<enum>	See taxonomy below	Layer 4 (weighted selection)	[neutral]
tags	list<string>	Freeform	N/A (author use)	[]

Authoring-only tags (not consumed by engine):

Tag	Type	Purpose
dual_lens	map	Per-character interpretation notes
notes	string	Author intent, dependencies, context

Monologue-specific tags (in addition to above):

Tag	Type	Values	Purpose
character	enum	smuggler, detective	Hard partition. Separate pools per Jeroen's directive.
trigger	enum	See trigger taxonomy below	Observation event that fires this line
prerequisite	map or null	Knowledge state conditions	Gate: line only eligible if character knows X

Alignment with Paula's Four Layers

This is the critical validation. Does the converged schema express all four D-028 layers?

D-028 Layer	How It's Expressed	Tag(s)	Filter Type
Layer 1: Access tier	access tag on every line. Engine checks player character's current access tier at the NPC's social site.	access	Hard filter. Line invisible if access doesn't match.
Layer 2: Relationship history	situation tag + engine-tracked interaction state. Engine maintains per-NPC counters (interaction_count, last_interaction_time, notable_events). These counters activate/deactivate situation eligibility. first_meeting is true once. repeated_visit activates after 3+ visits. greeted_before is tracked by engine, not tagged per-line.	situation + engine state	Context filter. Narrows eligible pool based on relationship progression.
Layer 3: Trust-gated gossip	trust tag on every line. Engine tracks trust progression per NPC (starts at surface, can reach real/secret through repeated positive interactions).	trust	Hard filter. Line invisible if current trust level is below line's trust tier.
Layer 4: Unprompted disclosure	topic + mood tags. Engine selects from eligible lines (post-Layer 1/2/3 filtering) weighted by match between NPC's current mood state and line's mood tag, and between NPC's current concern topics and line's topic tag.	topic + mood + engine state	Weighted selection. Soft ranking, not hard filter. Neutral mood always available as fallback.

Verdict: The converged schema fully expresses all four layers. Layers 1 and 3 are hard filters (binary tag match). Layer 2 is engine-state-to-situation mapping. Layer 4 is weighted selection across two tag dimensions.

Paula's concern about greeted_before:true — this is NOT a per-line tag. It's engine state. The engine tracks whether these characters have met before and activates the first_meeting or repeated_visit situation accordingly. The content author doesn't tag individual lines with interaction history — they tag situations, and the engine decides which situations are active.

Key Changes from My Round 1 Proposal

1. Dropped location from line-level tags — location is directory-level. This removes a redundancy Mellanie flagged.
2. Dropped type from line-level tags — content type is file-level. This reduces Mellanie's 8 tags to 6 structural + 2 selection = 8 total, but 2 fewer per-line.
3. Added character as monologue-only hard partition — confirms Jeroen's directive mechanically.
4. Clarified that access is list, not single — a line can be eligible for both insider and peer.
5. Made topic and mood list types — a line can cover multiple topics and be appropriate for multiple moods.

Situation Taxonomy v0.1 (Converged)

Merged from my Round 1 list + Mellanie's proposal:

Situation	Description	Activation
greeting	First interaction this game-day	Engine: no interaction logged today
first_meeting	Characters have never interacted	Engine: interaction_count == 0
routine	Normal daily activity	Engine: NPC in scheduled routine state
morning / afternoon / evening / night	Day phase (D-031)	Engine: current SimulationTime phase
repeated_visit	Player has visited this NPC 3+ times	Engine: interaction_count >= 3
interrogation	Player is asking pointed questions	Engine: dialogue topic escalation detected
witnessed_secret	Player has observed something they shouldn't	Engine: KnowledgeInventory contains secret-tagged fact about this NPC
idle	NPC is between scheduled activities	Engine: NPC routine state = idle
working	NPC is performing job routine	Engine: NPC routine state = job
social	NPC is in social activity (bar, break)	Engine: NPC routine state = social
confrontation	Triangle tension has escalated	Engine: triangle pressure threshold exceeded
post_event	Responding to a recent simulation event	Engine: event log contains recent entry for this NPC
absence_noticed	An expected NPC is missing	Engine: NPC not in expected location during expected time

13 situations for v0.1. Mellanie's gossip and observed_anomaly situations are covered by social + topic filtering and post_event respectively. I'm not adding them as separate situations because they're better expressed as topic + mood combinations.

Topic Taxonomy v0.1

Topic	Description
work	Job-related: tasks, schedules, complaints
social	Relationships, personal life, family
cargo	Freight, manifests, shipments — setting-specific
money	Finances, costs, spending
rumors	Gossip, hearsay, speculation
identity	Who someone is, where they're from, what they do
deflection	Avoiding a topic, changing subject
complaint	Grievances, frustrations
general	Weather, food, neutral small talk

9 topics for v0.1. Mellanie's crime topic is deliberately excluded — NPCs don't think of what they do as "crime." It's cargo or money from their perspective. The dual-lens interpretation is what makes those topics crime-adjacent for the detective.

Mood Taxonomy v0.1

Mood	Description
neutral	Default state. Calm, unremarkable.
happy	Positive, upbeat, satisfied
tired	Low energy, going through motions
annoyed	Irritated, short-tempered
nervous	Anxious, fidgety, checking surroundings
defensive	Guarded, deflecting, walls up
friendly	Warm, open, welcoming
cautious	Careful, measuring words

8 moods for v0.1. Mellanie's tense, relaxed, and suspicious map to nervous, happy/neutral, and cautious respectively. I'm consolidating to prevent near-duplicate moods that make authoring harder without adding selection granularity.

Monologue Trigger Taxonomy v0.1

Unchanged from Round 1. 9 triggers:

Trigger	Description
enter_location	Player enters a new area
observe_npc	Player sees NPC doing something notable
hear_sound	Sound event from fog edge
observe_anomaly	NPC deviates from known routine
post_conversation	After dialogue ends
discover_evidence	Player examines an informational object
witness_interaction	Player sees two NPCs interacting
time_idle	Player hasn't acted for a while
return_visit	Player returns to a previously visited area

---

2. Mellanie's Tag Proposal vs. Mine — Convergence

Mellanie proposed 8 tags. I proposed a more granular set. Here's where we landed:

Mellanie's Tag	My Tag	Resolution
character	character (monologue only)	Aligned. Monologue-only, hard partition. Not on dialogue lines.
access	access	Aligned. I upgraded to list<enum>; she had single. List is correct.
trust	trust	Aligned. Identical.
location	(directory-level)	Dropped from per-line. Directory structure handles this. Mellanie agreed provisional format is fine.
situation	situation	Aligned. Her values are a subset of mine. Using the full 13-situation taxonomy.
mood	mood	Aligned. Consolidated to 8 moods.
topic	topic	Aligned. Expanded to 9 topics.
type	(file-level)	Dropped from per-line. File naming convention handles this.

Net result: 6 per-line structural tags + 3 per-line selection/freeform tags = 9 tags per dialogue line. For monologue lines: +3 monologue-specific tags = 12 tags per monologue line.

Mellanie's "tag smoke test" request is smart. Before she writes 165 lines for the workplace, she writes 20, tags them, and I validate the filtering behavior. This should happen as the first line previewer test case.

---

3. THE FRIEND: Production-Level NPC Specification

Okay, let me map this to mechanics. Jeroen says THE FRIEND is a production-level complex NPC — one per character, full pipeline depth test. Ozzie defined the emotional design in Round 1. Let me define what "production-level" means for the ECS and content pipeline.

What "Production-Level" Means Mechanically

THE FRIEND exercises every system we're building. It's the NPC that proves the pipeline works end-to-end:

System	What THE FRIEND Tests	Minimum Requirement
10-axis model (D-024)	All 10 axes populated with meaningful values that change during play	Axes must shift in response to simulation events
Access tiers (D-028 L1)	THE FRIEND has different access tiers per character	Smuggler: insider+peer. Detective: varies (starts public, can reach peer)
Relationship history (D-028 L2)	Interaction count tracked, situation progression works	first_meeting -> greeting -> repeated_visit must trigger different lines
Trust progression (D-028 L3)	Trust level advances through positive interactions	Surface -> Real progression visible in dialogue depth change
Unprompted disclosure (D-028 L4)	THE FRIEND volunteers information when mood + topic align	At least 3 unprompted lines that fire based on NPC mood state
Tell system	Observable behavioral markers for internal state	All 5 tell categories must be demonstrable on THE FRIEND
Routine system	Predictable daily schedule with deviations	Morning/afternoon/evening locations defined. At least 1 deviation event
Triangle membership	Belongs to at least 1 triangle	Triangle pressure must affect THE FRIEND's behavior observably
Contradiction arc (Ozzie)	Discoverable through observation, not dialogue	The contradiction must emerge from routine deviation + tell, then be confirmed/complicated by dialogue
Monologue integration	Player character comments on THE FRIEND specifically	Named monologue lines referencing THE FRIEND's behavior, not generic role observations
Dual-lens divergence	Same NPC, fundamentally different relationship per character	THE FRIEND is a different person emotionally to the smuggler vs. detective

THE FRIEND: ECS Component Profile

Each FRIEND NPC needs these components at minimum:

Entity: THE_FRIEND_smuggler / THE_FRIEND_detective

Components:
  - NpcIdentity { name, role, home_template, reference_templates[] }
  - Want { current_want, intensity, blocked_by }
  - Secret { content, known_by[], exposure_risk }
  - Relationships[3] { target_entity, valence, trust_level, interaction_count, last_interaction }
  - ToleranceThreshold { current_value, max_value, triggers[] }
  - DailyRoutine { schedule: Map<DayPhase, Location>, deviations[] }
  - InformationInventory { known_facts[], rumors[], secrets_held[] }
  - Contentment { value, trend, causes[] }
  - PersonalityTraits { trait_a, trait_b, trait_c }
  - TellState { active_tells: Map<TellCategory, Intensity> }
  - SkillSet { skills[], combat_trained: bool }
  - AccessTierMap { Map<Entity, AccessTier> }  // per-observer access
  - TriangleMembership { triangle_ids[], role_in_triangle: Map<TriangleId, Role> }
  - MoodState { current_mood, trend, causes[] }

THE FRIEND: Content Requirements

Per FRIEND NPC, Mellanie needs to author:

Content Type	Volume	Notes
Dialogue lines (all access tiers)	25-35 lines	Must cover public, insider, peer, hostile. More lines than any other NPC.
Trust-gated dialogue (surface/real/secret)	15-20 lines	Including at least 3 secret-tier lines that reveal the contradiction
Unprompted disclosure lines	5-8 lines	Mood-triggered, topic-relevant. THE FRIEND initiates conversation.
Monologue lines (smuggler reacting to FRIEND)	10-15 lines	Named references. "There goes Kael." Not "That dock worker."
Monologue lines (detective reacting to FRIEND)	10-15 lines	Different framing. Analytical, not personal.
Tell observation monologue	5-8 lines per character	"Kael's tapping his foot again." / "Subject displays stress indicators."
Contradiction discovery monologue	3-5 lines per character	The moment the player realizes THE FRIEND isn't what they seemed

Total per FRIEND: ~70-100 authored lines (including both character perspectives). This is roughly half the content budget of an entire template's dialogue pool — for one NPC. That's the cost of production-level. It's worth it because this NPC carries D-027 success criterion #3.

THE FRIEND: Mapping to Paula's NPCs

Looking at Paula's Round 1 relationship web:

Character	THE FRIEND candidate	Why
Smuggler	NPC-B (Logistics Worker 1 / Kael Davan)	Smuggler's closest colleague. Ring member. Works together daily. Trust + shared risk = deepest pre-existing bond. Contradiction: Kael is reliable to the smuggler, but is cracking under pressure / making mistakes / possibly considering turning.
Detective	NPC-D (Dock Inspector) or NPC-G (Security Officer)	The detective needs a contact who becomes a relationship. NPC-D has the gambling debt (exploitable, sympathetic). NPC-G has institutional proximity (a peer the detective trusts professionally). Recommendation: NPC-D — the gambling debt creates the contradiction (seems corrupt, might just be desperate) and connects to Triangle B (Card Game Debt).

Paula should confirm these assignments in her Round 2. The FRIEND NPCs are the first profiles she should write at Tier 1 depth.

---

4. Missing Tickets for Systems/Mechanical Work

I've cross-referenced all Round 1 outputs against the existing ticket pool. Here are the systems tickets that should exist but don't (or need upgrading):

New Tickets Needed

Title	Type	Priority	Rationale	Depends On
Dialogue selection pipeline implementation	Feature	Critical	The 4-layer filtering engine: access -> situation -> trust -> weighted(mood, topic). This is the core runtime system that makes content playable. Nothing in the existing tickets covers the actual selection algorithm.	Line pool format (this document), NPC component architecture
Monologue trigger system	Feature	Critical	Engine component that fires monologue events based on observation triggers (enter_location, observe_npc, etc.). Must select from character-specific pool, apply prerequisite gates, track variety (no repeats).	Perception system (#124), Character knowledge state
NPC mood state machine	Feature	High	NPCs need a mood component that changes based on simulation events (triangle pressure, time of day, recent interactions). Mood drives Layer 4 selection + tell system.	10-axis NPC components
Trust progression system	Feature	High	Engine tracks trust level per player-NPC pair. Progresses through surface -> real -> secret based on interaction quality and frequency. Must be observable (player can sense trust improving).	Relationship tracking, dialogue system
Interaction tracking component	Feature	High	Per-NPC-pair counter: interaction_count, last_interaction_time, notable_events log. Drives Layer 2 situation activation.	NPC component architecture
Tell state derivation system	Feature	Medium	System that reads NPC axis values (Secret + Tolerance = nervous, Contentment low = frustrated, etc.) and outputs observable tell states consumed by monologue trigger system.	10-axis NPC components, monologue trigger system
Sound event system architecture	Feature	High	Event emitter for sound occurrences. Emits typed events (footsteps, voices, machinery, alarm) with position, intensity, and range. Client renders as audio file OR visual indicator + monologue, depending on available assets.	Perception system (#124)
YAML content loader	Feature	High	Rust system that parses content YAML files into indexed, queryable line pools at startup. Must support hot-reload for previewer/authoring workflow.	Line pool format (this document)
Line variety tracker	Feature	Medium	Prevents the same line from firing repeatedly. Tracks recently-used line IDs per NPC per session. Selects from eligible pool excluding recent history.	Dialogue selection pipeline
Knowledge state component	Feature	High	Per-character component tracking known facts, tagged by source, confidence, and emotional weight. Gates monologue prerequisites and informs situation activation. Paula's KnowledgeInventory proposal.	NPC component architecture
Observation event generator	Feature	Critical	System that detects observable NPC behaviors (routine deviation, interaction between NPCs, absence from expected location) and generates events consumed by monologue trigger system. This is the bridge between simulation and player perception.	NPC routine system, perception system
Tag taxonomy wiki page	Documentation	High	The converged taxonomy from this document, formatted for the wiki structure Miri is building. Reference document for all content authors.	This document, Miri's wiki structure
THE FRIEND: Smuggler's NPC profile	Story	Critical	Full Tier 1 profile for the smuggler's FRIEND (NPC-B / Kael Davan). All 10 axes, voice paragraph, triangle positions, contradiction arc.	Dual Lens Guide (#261)
THE FRIEND: Detective's NPC profile	Story	Critical	Full Tier 1 profile for the detective's FRIEND (NPC-D / Dock Inspector). Same depth.	Dual Lens Guide (#261)

Existing Tickets That Need Scope Updates

Ticket	Current Scope	Needed Addition
#90 (Tell system)	Unclear	Scope to 5 tell categories (nervous, angry, friendly, guarded, routine deviation). Text-via-monologue as v0.1 renderer, not visual animation.
#124 (Sound system)	Unclear	Must include sound event emitter architecture supporting both audio playback AND visual indicator fallback. See Section 6 below.
#193 (Line previewer)	"Authoring tool"	Concrete MVP scope defined. See Section 7 below.
#168 (Tag taxonomy)	"Agreement needed"	This document IS the agreement. Ticket should be updated to reference this converged taxonomy.

---

5. How Mechanical Systems Support Content Needs

Let me map every content need from Round 1 to a mechanical system. This is the crosswalk that ensures nothing falls through the cracks.

Content Need -> System Mapping

Content Need (from Round 1)	Required System	Status	Gap?
Dialogue lines filtered by access tier	Dialogue selection pipeline (Layer 1)	Not built	YES - needs ticket
Dialogue changes based on relationship history	Interaction tracking + situation activation (Layer 2)	Not built	YES - needs ticket
Trust-gated disclosure	Trust progression system (Layer 3)	Not built	YES - needs ticket
NPCs volunteer information based on mood	NPC mood state machine + weighted selection (Layer 4)	Not built	YES - needs ticket
Monologue fires on observation events	Observation event generator + monologue trigger system	Not built	YES - needs ticket
Separate monologue per character	Character-partitioned content pools	Not built	Covered by YAML loader + character tag
Tells observable through monologue	Tell state derivation + monologue integration	Not built	YES - needs ticket
NPC routine creates observable patterns	NPC routine system (D-024 Daily routine axis)	Partially ticketed	Needs scope for deviations and absence detection
Dual-lens interpretation of same event	Per-character monologue pools + knowledge prerequisites	Not built	Covered by monologue trigger system + prerequisite field
Mirror moments on replay	Same trigger, different character pool	Architectural	Covered by design — separate pools keyed to same triggers
Flat NPCs don't feel flat	Routine system + 1 memorable trait + role voice pool	Not built	Personality trait modifier in dialogue selection
THE FRIEND contradiction arc	Triangle pressure + tell escalation + routine deviation	Not built	Composition of several systems (triangle, tell, routine)
Environmental text readable in world	Environmental text rendering in Godot client	Not built	Needs client-side ticket
News ticker / Meridian feed	Ticker content system + time-based rotation	Not built	Needs ticket for both content + rendering
Audio atmosphere (6-8 files)	Sound event system + audio playback	Not built	YES - see Section 6
Diegetic tutorial via monologue	Opening hook monologue + trigger on first-time events	Not built	Covered by monologue trigger system + first_meeting / first-visit gates

Summary: 17 content needs, 0 fully built, 12 need new tickets, 5 covered by existing ticket scope updates.

The critical path for systems is:

NPC Component Architecture (10 axes)
  |
  +-> NPC Routine System
  |     |
  |     +-> Observation Event Generator
  |           |
  |           +-> Monologue Trigger System
  |
  +-> NPC Mood State Machine
  |     |
  |     +-> Tell State Derivation
  |
  +-> Interaction Tracking
  |     |
  |     +-> Trust Progression
  |
  +-> YAML Content Loader
        |
        +-> Dialogue Selection Pipeline (4 layers)
              |
              +-> Line Variety Tracker

Everything fans out from the NPC component architecture. That's Sprint 1 server work. The YAML loader and dialogue pipeline can be developed in parallel once the component schema is stable.

---

6. Audio Event System: Minimal Architecture

Jeroen confirmed audio in v0.1: 6-8 AI-generated files. Ozzie's minimum viable list from Round 1:

1. Station ambient loop (1 file)
2. Location variants: workplace, bar, corridors (3 files)
3. Footsteps — walk/run (2 files)
4. Monologue appearance chime (1 file)
5. (Optional) UI interaction sound (1 file)

That's 7-8 files. Here's the minimal architecture that supports them while remaining extensible:

Sound Event System Architecture

[Simulation Server]
  SoundEventEmitter
    - emits: SoundEvent { type, position, intensity, range_category }
    - types: Footstep, Voice, Machinery, Alert, Ambient
    - range_category: Close, Medium, Long (D-018)
    |
    v
[ObserverSnapshot]
  sound_events: Vec<SoundEvent>  // only events within perception range
    |
    v
[Godot Client]
  SoundRenderer
    - receives SoundEvents from snapshot
    - looks up audio asset for event type
    - if asset exists: play audio (with distance attenuation + stereo panning)
    - if asset missing: render visual indicator + fire monologue trigger
    |
    +-> AudioAssetRegistry
    |     Maps SoundEvent.type -> audio file path (or null)
    |     v0.1 registry:
    |       Footstep -> footstep_walk.ogg, footstep_run.ogg
    |       Ambient(workplace) -> ambient_workplace.ogg
    |       Ambient(bar) -> ambient_bar.ogg
    |       Ambient(corridor) -> ambient_corridor.ogg
    |       Alert(monologue) -> monologue_chime.ogg
    |       * -> null (visual fallback)
    |
    +-> VisualSoundIndicator
    |     Renders fog-edge ripple/pulse for events without audio
    |     Color-coded per Araminta's spec:
    |       neutral (#c8d0e0), voices (#e8c547), danger (#d45d5d)
    |
    +-> AmbientManager
          Manages location-based ambient loops
          Crossfades between ambient tracks on location transition
          The span gate hum (Miri's suggestion) is the base layer

Key Design Principles

1. Events first, assets second. The simulation always emits sound events. The client decides how to render them. Zero audio files = everything renders as visual + monologue. 8 files = partial audio with visual fallback for the rest. Full audio suite = rich soundscape. The architecture doesn't change.

2. The ambient manager is separate from event-driven sounds. Ambient loops play continuously based on location. Sound events are discrete occurrences (footsteps, voices, alerts). These are two different subsystems that share the audio output.

3. Monologue chime is a UI sound, not a simulation sound. It's triggered by the client when monologue text appears, not by the simulation. It doesn't go through the SoundEvent system.

4. Distance attenuation is simple for v0.1. Close range = full volume. Medium range = 50% volume + slight muffle. Long range = no direct audio (insert notification only). Three tiers, not continuous falloff.

What This Requires from Implementation

• Server side: SoundEventEmitter system that checks entity actions each tick and emits typed events. Perception filter includes events within hearing range in ObserverSnapshot.sound_events.
• Client side: SoundRenderer node in Godot that processes snapshot sound events. AudioAssetRegistry as a simple dictionary. VisualSoundIndicator for fog-edge rendering. AmbientManager for location loops.
• Asset pipeline: 7-8 .ogg files, generated or sourced. Integrated into Godot project's audio resources.

This is a small architecture for a large capability surface. It handles v0.1's 8 files and scales to hundreds without structural changes.

---

7. Line Previewer (#193): Concrete MVP Scope

The line previewer was flagged by me, Mellanie, and Ozzie in Round 1 as critical. Let me scope the MVP concretely.

What the Previewer Does

The previewer answers one question: "Given this NPC state and this player state, what line fires?"

It's the authoring equivalent of a compiler — it tells the content author whether their tags produce the intended behavior before the line is integrated into the game.

MVP Feature Set

Feature	Description	Priority
Load YAML	Parse a content YAML file (dialogue or monologue) into indexed pool	Must have
Set filter context	CLI arguments or interactive prompts for: access tier, trust level, active situations, NPC mood, topic filter, character (for monologue)	Must have
Show matching lines	Display all lines that pass the 4-layer filter with the given context	Must have
Show selected line	Apply weighted selection to show which single line would fire	Must have
Explain selection	Show WHY each line was included/excluded (which filter passed/failed)	Must have
Sequence mode	Play N lines in order simulating a walk-through (Ozzie's "preview sequence" request)	Should have
Coverage report	Show which access/trust/situation combinations have zero eligible lines (dead conversation detection)	Should have
Hot reload	Watch YAML file for changes, re-run filter on save	Nice to have
Batch validation	Run all YAML files through a consistency checker (missing required tags, invalid enum values, duplicate IDs)	Should have

Implementation

Language: Rust. The previewer should use the same YAML parser and selection logic that the game server will use. This means the previewer IS a test harness for the dialogue pipeline — if the previewer selects correctly, the game will select correctly.

Interface: CLI. No GUI needed. Terminal output with color-coded pass/fail on filters.

# Show what the detective hears from a dock_worker at insider access, surface trust,
# morning routine, neutral mood
$ cargo run --bin previewer -- \
    --file content/templates/logistics-hub/dialogue.yaml \
    --role dock_worker \
    --access authority \
    --trust surface \
    --situation greeting,morning,routine \
    --mood neutral \
    --verbose

[PASS] access=authority  [PASS] trust=surface  [PASS] situation=greeting
  -> lh_d_002: "You're new around here? Or just... visiting?"
     topic=[social, identity]  mood=[cautious, neutral]  weight=0.85

[PASS] access=authority  [PASS] trust=surface  [FAIL] situation=first_meeting (requires interaction_count==0)
  -> lh_d_005: "Morning. Can I help you with something?"
     (excluded: situation mismatch)

Selected: lh_d_002 (weight: 0.85, variety_penalty: 0.0)

Sequence Mode (Ozzie's Request)

$ cargo run --bin previewer -- \
    --file content/templates/bar/monologue.yaml \
    --character smuggler \
    --sequence enter_bar \
    --mood neutral

[Sequence: enter_bar — smuggler]
1. (enter_location) "The Last Shift. Lera's already got my usual poured."
2. (observe_npc) "Kael's at the corner booth. He looks rough tonight."
3. (observe_npc) "Drin's telling the same story again. Third time this week."
4. (time_idle) "Should probably check in with Kael. He doesn't usually drink alone."

This gives Mellanie and Ozzie a way to "feel" the content flow without running the full game. It's the emotional smoke test.

Effort Estimate

The previewer shares 80% of its code with the dialogue pipeline implementation. Building it first means the pipeline is already tested when it's integrated into the server. The unique work is the CLI interface, the verbose explain mode, and the sequence playback — maybe 2-3 days of Dudley/Tyre's time on top of the pipeline work they'd do anyway.

Recommendation: Build the previewer AS the first implementation of the dialogue pipeline. Don't build them separately. The previewer is the pipeline running in standalone mode with verbose output.

---

8. Cross-Agent Synthesis: Convergence Map

Here's where every Round 1 contributor's proposals landed after synthesis:

Fully Aligned (no further discussion needed)

Topic	Status	Contributors Aligned
Separate monologue pools per character	Locked (Jeroen directive)	All
Color = relationship to player	Locked (Jeroen directive)	Araminta (proposed), Gestalt (endorsed)
YAML as authoring format	Aligned	Gestalt (proposed), Mellanie (accepted with conditions)
5 tell categories for v0.1	Aligned	Gestalt (proposed), Araminta (visual notes), Ozzie (emotional validation)
Diegetic tutorial via monologue	Aligned	Gestalt (mechanical), Mellanie (content), Paula (narrative)
30/50/20 entanglement ratio	Aligned (D-029 confirmed)	All
Monologue is v0.1 tell renderer	Aligned	Gestalt, Araminta, Mellanie

Converged in This Document

Topic	Resolution	Key Decision
Tag taxonomy	Converged 8-tag system (6 structural + 2 selection + freeform)	See Section 1
Situation taxonomy	13 situations from Gestalt + Mellanie merge	See Section 1
Access tier model	list<enum> with 5 values	Gestalt's model, Paula's content, aligned
Line pool file structure	Directory = template/location, file = content type	Dropped per-line location and type tags
THE FRIEND mechanical spec	Full pipeline depth test with ~70-100 authored lines per NPC	See Section 3
Audio architecture	Event-driven with asset registry + visual fallback	See Section 6
Line previewer MVP	Rust CLI sharing pipeline code, 7 must-have features	See Section 7

Needs Round 2 Confirmation from Others

Topic	Who Needs to Confirm	What I Need
Converged tag taxonomy	Mellanie	Can you author with 6+3 tags per line? Is the mood/topic consolidation workable?
Converged tag taxonomy	Paula	Does the Layer 2 approach (engine-state-to-situation mapping, not per-line relationship tags) satisfy your 4-layer requirements?
THE FRIEND NPC assignments	Paula	Confirm NPC-B (Kael) for smuggler, NPC-D for detective. Or propose alternatives.
Miri's setting tags	Miri	Your proposed lattice_tier, shift_phase, district_familiarity, institutional_context — these should be engine-state context, not per-line tags. The engine knows the player is a newcomer; it activates first_meeting situations. Do you agree?
Spatial layout timing	Araminta	Your spatial layouts are needed before or in parallel with content packs. Confirmed? Can they be done independently of content?
Audio asset creation	Ozzie	7-8 AI-generated files. Who generates them? What's the quality bar? Do we need a ticket for audio asset generation?

---

9. Emergent Interactions: Where Systems Collide

This is my favorite part. Let me map the places where independently designed systems will interact to produce emergent gameplay — the stuff nobody scripted.

Interaction Map

System A	System B	Emergent Result
NPC Routine + Observation Events	Player sees NPC in unexpected place at unexpected time	Monologue fires: "That's not where they usually go." Player decides to follow or ignore. Neither designer planned the specific moment.
Trust Progression + Triangle Pressure	NPC's trust in player increases while triangle pressure increases	NPC discloses something they shouldn't under pressure. The disclosure is selected by the dialogue pipeline combining high trust + high stress mood. Not scripted — emergent from system state.
Access Tier Shift + Monologue Dual-Lens	Player's access tier changes at a social site (e.g., detective becomes a bar regular)	New dialogue lines become available AND the monologue reflects the shift ("They're starting to warm up to me"). The player FEELS the social change through two channels simultaneously.
Sound Events + Fog of Perception + Monologue	Player hears voices through a wall they can't see past	Sound event at fog edge -> visual indicator -> monologue interprets ("Sounds like an argument. Can't make out the words.") Player decides to move closer or not. The three systems produce a decision point.
THE FRIEND Contradiction + Tell System + Monologue	THE FRIEND's tell state escalates (nervous) while their dialogue stays friendly	The player gets conflicting signals: dialogue says "everything's fine," monologue says "they keep checking the door." The player must decide which signal to trust. Asymmetric information within a single NPC.
NPC Mood + Time Phase + Unprompted Disclosure	An NPC's mood worsens over the course of a day; by evening at the bar, they're drunk and frustrated	Layer 4 selects from mood: [annoyed, tired] + trust: real pool. The NPC says something they wouldn't have said that morning. Time + mood + alcohol = emergent information leak.

This is why systems-first design works. None of these moments are scripted events. They're collisions between independently designed systems operating on shared state. The content authors write the individual lines; the systems decide when and how those lines combine. The result is stories the designers didn't anticipate.

---

10. Open Questions for Round 3 / Sprint Planning

Question	Owner	Context
Does the 4x generation expansion apply to THE FRIEND's custom lines? Or are all 70-100 hand-authored?	Mellanie + Gestalt	Generation expansion on high-specificity NPC lines risks losing the hand-crafted voice. Recommend: no expansion on FRIEND lines. Every line hand-authored.
Who creates the 7-8 audio files?	Ozzie + Justine	AI-generated is confirmed, but the pipeline needs defining. Which AI tool? What format? Who evaluates quality?
Should the line previewer be a sprint deliverable or a tooling side-project?	Tyre + Dudley	I recommend sprint deliverable — it's the dialogue pipeline in standalone mode. Building it IS building the pipeline.
How does the knowledge prerequisite system handle "partial knowledge"?	Gestalt + Paula	A monologue line gated on knows: smuggling_operation — does the player need to know the full operation, or just that something suspicious is happening? Need a knowledge hierarchy: suspects < knows_of < knows_details.
Triangle pressure threshold — what triggers escalation?	Gestalt + Paula	Triangles need a numeric pressure value that increases based on events. When it crosses a threshold, confrontation situation activates. Need to define the events that increase pressure.

---

Gestalt out. The taxonomy is converged. The FRIEND is specified. The audio architecture is minimal and extensible. The previewer is scoped. Now we need Mellanie and Paula to validate the tag schema, and Dudley to start building the NPC component architecture. The systems are ready to support the content. Let's build.