settled-reach/docs/design/interaction-verbs-v0.1.md

title, description, type, status, ticket, decision_refs, author, created, updated, superseded_by

title	description	type	status	ticket	decision_refs	author	created	updated	superseded_by
Interaction Verb Specification v0.1	Seven interaction verbs, single context-sensitive action button, and verbs[] architecture for player-world interaction	design	superseded	#402	D-005 D-011 D-015 D-027 D-028 D-032 D-035 D-041 D-044 D-051 D-054 D-060		2026-02-12	2026-02-12	D-166

SUPERSEDED (2026-06-12, cascade-refocus sweep): superseded by D-166 (player interaction is Phase 5 work on the generated world). Kept as historical record; do not build against it.

Interaction Verb Specification v0.1

Ticket: #402 Status: v0.1 design spec Source: Workshop output A-04 (D-044), D-INTERACT lead decision (D-051), D-060 (verbs[] rename) Soft dependency: NEW-9 (server InteractionOptions component)

---

1. Overview

The interaction verb system is how the player interfaces with the simulation. Every interaction between the player character and the world is expressed as a verb -- a discrete, typed action that triggers server-side processing and produces client-side feedback.

v0.1 uses a single context-sensitive action button. When the player presses [E] near an interactable entity, the system selects the highest-priority available verb and executes it. The player does not choose between verbs in v0.1 -- the system picks.

Underneath, the architecture supports N verbs per entity via the verbs[] array. The server computes all available verbs for every entity in the player's perception range on every tick. The v0.1 client reads only verbs[0] (the highest-priority option). The v0.2 client will present the full list as a verb wheel or horizontal label row. No server changes are required for this transition.

There are 7 interaction verbs in v0.1:

#	Verb	Type	Player Input
1	Move	Active	WASD keys
2	Look	Passive	Automatic (perception system)
3	Monologue	Reactive	Automatic (server-triggered)
4	Examine Object	Active	Context key on environment
5	Examine NPC	Active	Context key on NPC
6	Talk	Active	Context key on NPC
7	Overhear	Passive	Automatic (proximity-based)

Cross-references:

• Game concept and vertical slice: D-005, D-027
• Perception and fog: D-011, D-015
• Dialogue architecture: D-028
• Monologue pools: D-032
• Tag taxonomy: D-035
• Knowledge graph: D-041
• ObserverSnapshot v3: D-054

---

2. Terminology

verbs[] -- the canonical term

A verb is a player-initiated or system-triggered interaction with the world. Each entity in the player's perception has a verbs[] array listing available interactions, computed by the server every tick.

The term verbs[] replaces all prior references to actions[], AvailableActions, EntityInteractions, and ActionOption. This rename was confirmed in the closing round of the v0.1 Content Scoping Workshop (D-060) and applies across:

• Server code (Rust structs and enums)
• Client code (GDScript)
• YAML content files
• Wiki documentation
• Decision files

Key definitions

Term	Definition
Verb	A typed interaction between the player character and an entity or the environment.
verbs[]	Per-entity array of available verbs, sorted by priority (index 0 = highest priority). Embedded in ObserverSnapshot.nearby_interactions.
Active verb	Requires player input to execute (Move, Examine Object, Examine NPC, Talk).
Passive verb	Fires automatically when conditions are met (Look, Overhear).
Reactive verb	Triggered by the server in response to game events, not by direct player action (Monologue).
Context key	The single action button ([E] in v0.1) that executes the highest-priority available verb on the targeted entity.
Verb priority	Numeric rank determining which verb the context key executes when multiple are available. Lower number = higher priority. See Section 4.

---

3. Per-Verb Specifications

3.1 Move

The player moves to a tile or location.

Move is the foundational verb. Physical presence in the world determines what the player can perceive, who they can interact with, and what information they have access to. Movement is not just locomotion -- it is a commitment of time and attention that creates observable behavior for NPCs.

Aspect	Specification
Trigger	WASD key input (continuous while held).
UI need	Character sprite moves on tilemap. Camera follows (locked to character per D-015). Footstep audio triggers (D-038: sfx_footstep_metal.ogg / sfx_footstep_metal_run.ogg).
Server event	PlayerAction::Move(direction). Server validates against collision map, updates player entity position, recalculates LOS (symmetric shadowcasting per D-035/perception), updates ObserverSnapshot with new visible entities and fog state.
Content requirement	Collision map per social site. Tile walkability data. No authored text content.
Knowledge impact	Indirect. Moving into LOS range of an entity may trigger DirectObservation knowledge source updates. Moving into proximity range of NPC conversations enables Overhear. Moving to a new location may trigger enter_location monologue.
v0.1 scope	Full implementation. WASD movement, collision, LOS recalculation. Walk speed only (no run toggle in v0.1).

---

3.2 Look

The player observes the environment through their character's perception.

Look is the passive observation verb. It fires continuously as long as the player has line-of-sight to entities. The player does not press a button to Look -- the perception system handles it. Look is how the player gains spatial awareness: who is where, what they are doing, and how entities relate to each other in space.

Aspect	Specification
Trigger	Automatic. Fires every tick for all entities within the player's LOS (shadowcasting per D-011). No player input required.
UI need	Entities rendered on tilemap within LOS. Entity color reflects relationship state (D-033: teal for unknown, green for friendly, amber for person of interest, red for hostile). Fog of perception obscures entities outside LOS. Vision cone renders forward/peripheral/blind zones (D-015).
Server event	Not a discrete event. The perception system continuously evaluates which entities fall within the player's LOS and populates ObserverSnapshot.visible_entities. Entity visibility triggers KnowledgeEvent updates for position and last_observed_tick.
Content requirement	None directly. Entities must have visual representations (sprite/placeholder). Entity color palette defined in D-033.
Knowledge impact	Updates location key for observed entities (Direct confidence). Updates last_observed_tick. If an NPC is observed performing a routine deviation (tell), may set behavior_flags and trigger Monologue via observe_npc or observe_anomaly.
v0.1 scope	Full implementation. Natural vision cone + fog of perception. No additional perception modes (thermal, camera feeds, etc. are deferred per D-017).

---

3.3 Monologue

The player character's internal voice reacts to observations and events.

Monologue is the player character's inner narrator. It is reactive -- triggered by the server based on game events, not by player input. Monologue bridges the gap between the top-down camera and the character's subjective experience (D-016). It is the primary vehicle for character voice, anomaly flagging, atmospheric commentary, and diegetic hints.

Monologue is character-specific. The smuggler and detective have completely separate monologue pools (D-032). Same trigger, different pool, different voice.

Aspect	Specification
Trigger	Server-initiated. The monologue system evaluates triggers every tick against the player character's current state. 9 trigger types defined in D-035: enter_location, observe_npc, hear_sound, observe_anomaly, post_conversation, discover_evidence, witness_interaction, time_idle, return_visit. Each monologue line has a prerequisite map (AND-only) that gates on knowledge state.
UI need	Monologue text rendered in world-space layer (not HUD). Character-tinted text (smuggler: amber-white #f0e0c8, detective: blue-white #c8d8f0). Max 160 characters, max 2 visual lines. Display time 3-6 seconds (length-adjusted). Fade in 0.3s, fade out 0.5s. Monologue chime audio (D-038: sfx_monologue_chime.ogg, or sfx_monologue_chime_urgent.ogg for anomaly/contradiction triggers). Queue depth 1 (drop lower priority). Cooldown 2s between lines. Priority ordering per D-059.
Server event	Monologue system selects the highest-priority eligible line from the active character's monologue pool. Sends MonologueDisplay { id, text, priority, trigger_type } in ObserverSnapshot.monologue. Client renders.
Content requirement	Separate monologue pool files per character per location (e.g., monologue-smuggler.yaml, monologue-detective.yaml). Each line tagged per D-035: character, trigger, prerequisite, priority, cooldown. Estimated volume: ~200 authored monologue lines across both characters for v0.1 (per workshop budget).
Knowledge impact	Monologue does not directly update the knowledge graph -- it reflects it. However, the trigger that caused the monologue (e.g., observe_anomaly) may have already updated knowledge. Some monologue lines serve as player-facing confirmation that a knowledge update occurred (e.g., "He checked his lattice again. Third time." confirms behavior_flags update).
v0.1 scope	Full implementation. All 9 trigger types. Prerequisite evaluation against knowledge graph. Priority-based queue. Fires during dialogue (for wow moment #3 -- FRIEND contradiction triggers monologue while the player is in conversation).

Priority ordering (highest to lowest):

Rank	Trigger Type	Rationale
1	observe_anomaly	Anomalies are rare and time-critical.
2	witness_interaction	NPC-to-NPC events the player should notice.
3	discover_evidence	Direct investigation payoff.
4	post_conversation	Reflection on just-completed dialogue.
5	hear_sound	Sensory input from outside LOS.
6	observe_npc	Commentary on observed NPC behavior.
7	enter_location	Arrival at a new area.
8	return_visit	Revisiting a known area.
9	time_idle	Unprompted reflective thought (wow moment #6).

---

3.4 Examine Object

The player examines a specific object in the environment.

Examine Object is how the player investigates environmental elements: terminals, manifests, cargo containers, notices, equipment. It produces descriptive text and may update the knowledge graph with FactId entries.

Aspect	Specification
Trigger	Player presses context key ([E]) while targeting an examinable object within interaction range. Object must be in LOS and within close range.
UI need	Context prompt appears when player is in range: [E] Examine. On execution, description text displayed in HUD panel (or inline). Text sourced from server (client does not load content files per D-048).
Server event	PlayerAction::InteractPrimary(target_stable_id). Server resolves verb as VerbKind::ExamineObject. Retrieves examine description for the target object. May evaluate knowledge prerequisites (some objects reveal different information based on what the player already knows). Returns ExamineResult { target_id, description, knowledge_grants } in ObserverSnapshot.examine_result.
Content requirement	Examine descriptions per examinable object. Detective and smuggler may receive different descriptions for the same object (filtered by access tier per D-028). Environmental objects in the 3 social sites: cargo terminals, manifests, shift schedules, bar fixtures, maintenance panels, door locks. Estimated: ~30-50 examine descriptions across all locations.
Knowledge impact	May grant new FactId entries (e.g., examining a manifest reveals fact:shift_schedule_discrepancy). May update existing EntityKnowledge if the object references an NPC (e.g., examining a terminal shows Kael's access log, updating routine_pattern for Kael). Knowledge grants are specified per examine description in the content YAML via knowledge_grants field.
v0.1 scope	Full implementation. Static examine descriptions with access-tier filtering. No multi-step examination (examine once, get the full description). No item pickup (evidence is knowledge, not inventory per D-046).

---

3.5 Examine NPC

The player observes a specific NPC without initiating contact.

Examine NPC is passive intelligence gathering. The player studies an NPC from a distance -- watching their behavior, reading body language, noting patterns. This is the detective's primary loop entry point and the smuggler's surveillance mode. Critically, Examine NPC does not alert the target NPC. The player gathers information without social cost.

The separation between Examine NPC and Talk is load-bearing for the investigation loop:

• The detective's loop: Examine first (accumulate tells across multiple observations) then Talk later (use evidence in confrontation).
• The smuggler's loop: Talk first (social, operational, casual) then Examine when suspicious ("something's off, let me watch them").

Collapsing Examine and Talk into a single "Interact" verb would break both loops.

Aspect	Specification
Trigger	Player presses context key ([E]) while targeting an NPC within mid-to-close range and in LOS. Only available when Talk is not the higher-priority verb (see Section 4 for priority resolution).
UI need	Context prompt: [E] Observe. On execution, observation text displayed (behavioral description, tell observations, appearance notes). Text sourced from server. No dialogue UI opens.
Server event	PlayerAction::InteractPrimary(target_stable_id). Server resolves verb as VerbKind::ExamineNpc. Server evaluates target NPC's current behavioral state, active tells, and the observing character's knowledge level. Returns observation description. May trigger observe_npc monologue. Updates InteractionLog (tracks observation count per target).
Content requirement	Observation descriptions per NPC, tiered by knowledge state. At Suspects confidence: surface-level observations ("Dock worker. Focused on the manifest."). At KnowsOf+: behavioral observations ("He's checked his lattice three times this shift. That's not routine."). Tell observation lines per NPC (D-034 specifies 5-8 per FRIEND NPC). Estimated: ~5-10 observation lines per T1/T2 NPC, ~2-3 per T3 NPC.
Knowledge impact	May update behavior_flags (tell observations: "nervous", "schedule_changes", "evasive"). May update routine_pattern if the NPC is observed deviating from their known routine. May increment tell observation counter (tracked in behavior_flags per D-055). Confidence level may advance from Suspects to KnowsOf through repeated observation (gated by InteractionLog count).
v0.1 scope	Full implementation. Knowledge-tiered observation descriptions. Tell detection system (NPC behavioral flags mapped to observable tells). No "analyze" sub-verb (lattice-assisted analysis deferred to v0.2).

---

3.6 Talk

The player initiates conversation with an NPC.

Talk is active information exchange. The player approaches an NPC and begins a dialogue. This is the primary verb for social gameplay: building trust, gathering information, confronting contradictions, and maintaining cover. Talk has a social cost -- the NPC knows you engaged, and other NPCs may observe the interaction.

Dialogue uses tagged line pools with systemic selection (D-028), not branching trees. Lines are filtered by access tier, trust level, situation, and topic. The server selects and serves dialogue lines; the client displays them.

Aspect	Specification
Trigger	Player presses context key ([E]) while targeting an NPC within close range and in LOS. Talk takes priority over Examine NPC for most NPCs (see Section 4).
UI need	Context prompt: [E] Talk. On execution, dialogue panel opens (HUD layer). Displays NPC dialogue lines with player response options (selected from eligible pool). Sim speed drops to 50% during dialogue (D-052). Dialogue panel is one of the P0 UI scenes (1 scene, 1 script). Monologue can fire simultaneously in the world layer during dialogue (separate visual layer).
Server event	PlayerAction::InteractPrimary(target_stable_id). Server resolves verb as VerbKind::Talk. Server opens a dialogue session: evaluates access tiers (D-028 Layer 1: insider/outsider/authority/peer/hostile), filters by trust level (D-028 Layer 3: surface/real/secret), applies situation context (D-028 Layer 2), selects eligible lines. Returns ActiveDialogue { partner_id, lines, response_options } in ObserverSnapshot.active_dialogue. Player selects a response; server processes PlayerAction::DialogueResponse(choice).
Content requirement	Dialogue pools per template role and location (D-028). ~165-210 authored lines per Tier 2 template, generation-expanded 4x. Four relational layers all present from v0.1: access tiers, relationship history, trust-gated gossip, unprompted disclosure. FRIEND NPCs require ~25-35 dialogue lines + 15-20 trust-gated + 5-8 unprompted (D-034).
Knowledge impact	Dialogue can grant knowledge through knowledge_grants tags on lines. Trust level may advance or degrade based on dialogue choices (relationship history, D-028 Layer 2). RelationshipState may transition (Unknown to Known on first conversation, Known to Friendly through repeated positive interaction). Gossip lines may reveal information about third parties (updating EntityKnowledge for NPCs not present in the conversation).
v0.1 scope	Full implementation of all four dialogue layers. Tagged line pool selection. Access-tier filtering. Trust-gated disclosure. NPC-initiated unprompted disclosure (weighted by trust and mood). Post-contradiction confrontation dialogue (FRIEND arc Phase 4).

---

3.7 Overhear

The player overhears NPC-to-NPC conversation based on proximity.

Overhear is environmental intelligence. When the player is within earshot of two or more NPCs having a conversation, fragments of that conversation are presented to the player. Overhear is passive -- the player does not press a button. The player merely needs to be close enough, and the server delivers fragments.

Overhear is the primary mechanism for the player to learn about NPC relationships, concerns, and secrets without direct engagement. It rewards spatial awareness and patience. The quality and completeness of overheard information depends on proximity (D-018: close range = high accuracy, medium range = imprecise).

Aspect	Specification
Trigger	Automatic. The server detects when the player character is within hearing range of an active NPC-to-NPC conversation. No player input required. Proximity thresholds follow D-018 three-range sound model: close range (full content, high trust), medium range (fragments, directional, imprecise).
UI need	Overheard text rendered as fragments -- partial lines, attributed to speakers if in LOS, unattributed if only audible. Visual indicators at fog edge for medium-range overhearing (D-018). Overheard text styled distinctly from monologue and dialogue (italicized or bracketed, lower opacity). No dialogue panel opens.
Server event	NPC conversation system runs independently of player action. When the player entity is within hearing range, the server includes relevant fragments in ObserverSnapshot.overheard as Vec<OverheardFragment>. Each fragment contains: speaker_id (if visible), text, audibility (clear/muffled/indistinct), topic_hint.
Content requirement	NPC-to-NPC conversation scripts. These are short, repeating exchanges that NPCs perform as part of their routines. Bar chatter, workplace complaints, shift handover talk, gossip. Key scripted conversations: Kael and colleague discussing schedules (innocuous surface, routine deviation subtext), bar regulars discussing Torek's spending, maintenance workers referencing Drin's absences. Estimated: ~40-60 overheard lines across all social sites.
Knowledge impact	Overheard content may update known_associates (hearing two NPCs talk confirms they interact). May update behavior_flags (hearing an NPC complain about schedule changes). May trigger hear_sound or witness_interaction monologue. Critical for wow moment #3 setup: overhearing references to NPC behavior that the player later observes directly. Knowledge source tagged as Heard (D-041), which carries lower confidence than DirectObservation.
v0.1 scope	Full implementation. Proximity-based fragment delivery. Close-range = clear text with speaker attribution. Medium-range = muffled fragments with directional indicator. NPC-to-NPC conversations run on schedule (not dynamically generated). Long-range insert alerts deferred (D-018 stretch goal).

---

4. v0.1 Priority Resolution

v0.1 uses a single context-sensitive action button ([E]). When multiple verbs are available on a target, the system selects the highest-priority verb. The player does not choose.

Priority order

Priority	Verb	Condition
1 (highest)	Talk	Target is NPC, in close range, NPC has available dialogue, NPC is not flagged as PersonOfInterest with unresolved contradiction
2	Examine NPC	Target is NPC, in mid-to-close range, NPC IS flagged as PersonOfInterest with unresolved contradiction (post-contradiction, observation becomes primary)
3	Examine NPC	Target is NPC, in mid range only (too far for Talk)
4	Examine Object	Target is examinable environment object, in close range
5	Talk	Target is NPC, in close range, but NPC has limited/exhausted dialogue pool for current situation

Context-sensitive priority shifts

The priority order is not static. It shifts based on game state:

Default state (pre-contradiction):

• NPC in close range: [E] Talk (Talk > Examine NPC)
• NPC in mid range: [E] Observe (Examine NPC, Talk unavailable at this distance)
• Object in close range: [E] Examine

Post-contradiction state (NPC flagged as PersonOfInterest):

• NPC in close range: [E] Observe (Examine NPC > Talk)
• This represents the detective shifting from social mode to surveillance mode, or the smuggler shifting from trust to suspicion
• Talk remains available in v0.2 as a secondary verb ([F] Talk)

Post-confrontation state (after confrontation dialogue):

• NPC in close range: [E] Talk returns to primary (conversation continues, relationship has shifted)

Resolution rules

1. Only one verb executes per input. The context key triggers exactly one verb.
2. Server computes all available verbs. The full verbs[] array is populated every tick per entity.
3. Client reads verbs[0]. The v0.1 client displays and executes only the first (highest-priority) verb.
4. Passive/reactive verbs are not in verbs[]. Look, Monologue, and Overhear are not player-activated and do not appear in the verb array. They fire independently.
5. verbs[] contains only active verbs. Move, Examine Object, Examine NPC, and Talk are the verbs that can populate verbs[]. Move is handled by WASD (not context key), so in practice verbs[] contains Examine Object, Examine NPC, and Talk.

---

5. Architecture Notes

How verbs[] works at the server level

The server populates verbs[] per entity every tick. The computation follows this pipeline:

Per-entity verb evaluation (runs in perception phase):

1. Entity type check
   - NPC -> eligible for: Examine NPC, Talk
   - Object -> eligible for: Examine Object
   - Environment -> eligible for: Examine Object (if tagged examinable)

2. Distance check
   - Close range -> all eligible verbs available
   - Mid range -> Talk removed (requires close range)
   - Far range / out of LOS -> no verbs (entity not interactable)

3. Sightline check
   - Entity must be in player's LOS (shadowcasting result)
   - No interaction through walls or fog

4. Relationship state check
   - PersonOfInterest + unresolved contradiction -> Examine NPC priority rises above Talk
   - Hostile -> Talk may be removed (NPC refuses engagement)

5. Conversation state check
   - NPC in active conversation with another NPC -> Talk unavailable (NPC is busy), Overhear activates passively
   - NPC in active dialogue with player -> only DialogueResponse verbs available

6. Dialogue availability check
   - NPC with exhausted dialogue for current situation -> Talk priority drops
   - NPC with high-priority disclosure queued -> Talk priority rises

7. Priority sort
   - Available verbs sorted by priority (see Section 4)
   - Result written to verbs[] array on the entity's nearby_interaction entry

Data structures

The verbs[] array is embedded in the ObserverSnapshot within nearby_interactions:

ObserverSnapshot {
    ...
    nearby_interactions: Vec<NearbyInteraction>,
    ...
}

NearbyInteraction {
    entity_id: StableId,
    entity_type: EntityType,
    distance: f32,
    verbs: Vec<VerbOption>,       // <-- the verbs[] array
}

VerbOption {
    kind: VerbKind,               // ExamineObject, ExamineNpc, Talk
    label: String,                // "Examine", "Observe", "Talk"
    priority: u8,                 // lower = higher priority
    available: bool,              // false if conditions not met (greyed out in v0.2)
}

enum VerbKind {
    ExamineObject,
    ExamineNpc,
    Talk,
}

The VerbKind enum does not include Move (handled by WASD input), Look (passive perception), Monologue (server-triggered), or Overhear (passive proximity). These verbs operate outside the verbs[] system.

Client reads, server decides

The client is a dumb renderer (D-048, D-052). It does not evaluate content files, compute verb availability, or resolve priorities. The client:

1. Reads nearby_interactions from ObserverSnapshot
2. For the entity nearest to the cursor/facing direction, reads verbs[0]
3. Displays the label as the context prompt: [E] {verbs[0].label}
4. On [E] press, sends PlayerAction::InteractPrimary(entity_id) to the server
5. The server resolves which verb was meant (it already knows -- it computed the array)

Future extension (v0.2+)

The v0.2 client reads the full verbs[] array and presents multiple options:

v0.1: [E] Talk
v0.2: [E] Talk  [F] Observe

No server changes required. The protocol already carries the full verb list. The client simply renders more of it.

Further future: a verb wheel or radial menu for entities with 3+ available verbs (e.g., an NPC near an examinable object -- Talk, Observe, Examine nearby object).

---

6. Content Authoring Implications

The verb system defines what content must exist for each interaction type. Content authors need to produce material for each verb that fires on their NPCs, objects, and locations.

Per-verb content requirements

Verb	Content Type	Author Responsibility	Estimated Volume (v0.1)
Move	Collision maps, walkability	Level design (not prose authoring)	3 social site maps
Look	Entity sprites/placeholders, color palette	Visual design	17 NPC representations + objects
Monologue	Monologue pool YAML files	Mellanie (prose), Gestalt (triggers/prerequisites)	~200 authored lines, partitioned by character (D-032)
Examine Object	Examine descriptions per object	Content authors	~30-50 descriptions across all locations
Examine NPC	Observation descriptions per NPC, tiered by knowledge	Content authors	~5-10 lines per T1/T2 NPC, ~2-3 per T3 NPC
Talk	Dialogue pool YAML files per role and location	Mellanie (prose), content team (tagging)	~165-210 authored lines per template, 4x generation-expanded (D-028)
Overhear	NPC-to-NPC conversation scripts	Content authors	~40-60 overheard lines across all social sites

Content file structure

Per the content directory design (D-057):

content/districts/sova-transit/
  dialogue/
    hub-dock-worker.yaml        # Talk content: dock worker role at Terminal
    hub-supervisor.yaml         # Talk content: supervisor role at Terminal
    bar-owner.yaml              # Talk content: bar owner role at Last Shift
    bar-regular.yaml            # Talk content: regular role at Last Shift
    ...
  monologue/
    monologue-smuggler.yaml     # Monologue: all smuggler lines for this district
    monologue-detective.yaml    # Monologue: all detective lines for this district
  examines/
    hub-objects.yaml            # Examine Object: Terminal equipment, manifests
    bar-objects.yaml            # Examine Object: bar fixtures, notices
    corridor-objects.yaml       # Examine Object: maintenance panels, doors
  observations/
    npc-observations.yaml       # Examine NPC: observation descriptions by NPC + knowledge tier
  overheard/
    hub-conversations.yaml      # Overhear: Terminal NPC-to-NPC exchanges
    bar-conversations.yaml      # Overhear: Last Shift NPC-to-NPC exchanges
    corridor-conversations.yaml # Overhear: corridor NPC-to-NPC exchanges

Key authoring rules

1. Talk requires dialogue pools. Every NPC the player can Talk to needs dialogue lines tagged with access tier, trust level, and situation. FRIEND NPCs need the full 4-layer treatment (D-028). T3 NPCs need at minimum a greeting pool.

2. Examine NPC requires observation descriptions. Every NPC observable at mid range needs at least a surface-level observation description. T1/T2 NPCs need knowledge-tiered descriptions that reveal more as the player's confidence level increases.

3. Overhear requires NPC-to-NPC conversation scripts. These are independent of player dialogue pools. They fire when NPCs are near each other on their routines. Content must be written as fragmentary, overheardable exchanges -- not full conversations.

4. Monologue is triggered by server events, not player choice. Authors write monologue lines against specific triggers and prerequisites. The server decides when to fire them. Authors cannot assume the player will see monologue in any particular order -- prerequisite gates ensure logical sequencing.

5. Examine Object descriptions should be character-aware. The same terminal may show different information to the smuggler (cargo routing details) and the detective (access logs, anomaly flags). Use access tier tags to differentiate.

6. All text comes from the server. The client never loads or evaluates content files (D-048). Authors write content that the server selects and serves. The client renders what it receives.

---

v0.1 specification. 7 verbs, single context-sensitive action, verbs[] architecture ready for N-verb expansion. Last updated: 2026-02-12.