Files
settled-reach/docs/workshops/knowledge-graph-information-boundaries/round1-paula.md
T
jpmschweitzerandClaude Opus 4.6 93abd9b9d0 docs(workshops): complete Knowledge Graph & Information Boundaries workshop
Two-round workshop producing D-041 (Knowledge Graph Data Model):
- Round 1: independent analyses from Dudley, Gestalt, SI, Tyre, Paula
- Round 2: synthesis resolving debates + Gestalt mechanics validation

Key decisions:
- 4-level confidence hierarchy (Suspects < KnowsOf < KnowsDetails < Direct)
- BTreeMap for deterministic iteration (D-010 principle 4)
- Per-entity Component model, not centralized Resource
- StableEntityId + EntityRegistry for save/load stability (partial Q-019)
- Sprint 2 stub: structs + direct observation + basic decay (~6.5 dev-days)

Resolved Q-016 (knowledge hierarchy), raised Q-024/Q-025/Q-026.
Created tickets #361-#368 under epic #351, reconciled #49 children.
Updated sprint 2 briefings, agent briefings, and decision files.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-02-11 23:24:37 +01:00

37 KiB

Knowledge Graph & Information Boundaries — Round 1 (Paula)

Role: Narrative & Political Depth Specialist Focus: How knowledge creates story, how relationships generate meaning, how the graph makes mystery playable Date: 2026-02-11


Executive Summary

The knowledge graph is not a database problem. It's a narrative problem disguised as a data structure.

Here's what actually matters: knowledge is the currency of relationships. NPCs don't just know facts — they know facts about each other, and their willingness to share those facts is the entire social gameplay loop. The knowledge graph must track not just "what does entity A know" but "what does entity A know about entity B, and who told them, and what does that reveal about their relationship?"

The aha moments this system must support:

  1. Discovering that THE FRIEND lied to you (contradictory knowledge from different sources)
  2. Realizing two NPCs know something you just learned (they've been talking behind your back)
  3. Exploiting an NPC's ignorance (they don't know you know)
  4. Watching knowledge propagate through a social network (gossip as observable mechanic)
  5. The moment when your character's internal monologue flags a contradiction your player missed

The failure modes to avoid:

  1. Knowledge as Pokemon collection (gather all the facts)
  2. Perfect memory with no decay (no tension)
  3. Binary knowledge states (you either know or you don't — no suspicion, no partial information)
  4. NPC knowledge invisible to the player (can't read the room)
  5. Knowledge without emotional weight (facts that don't connect to relationships)

The content team dependency (#309): We need a knowledge vocabulary for v0.1 monologue authoring — the canonical list of knowledge flags that monologue lines can reference as prerequisites. Without this, Mellanie can't write "Character knows X" trigger conditions.


1. Narrative Foundations: What Is Knowledge?

1.1 What Does "Knowledge" Mean Narratively?

Knowledge is not objective truth stored in a mind. Knowledge is:

  1. An interpretation — what the character BELIEVES based on incomplete evidence
  2. A relationship artifact — most knowledge comes from other people, and the source shapes the meaning
  3. An emotional stake — knowledge about people you care about weighs more than knowledge about strangers
  4. A liability — knowing something can be dangerous, and NPCs know this

Example from the v0.1 scenario:

The smuggler knows Kael (their colleague and THE FRIEND) has been meeting someone in the restricted corridor. This knowledge is:

  • An interpretation: "Kael is compromised" or "Kael is trying to exit the ring" (both possible)
  • A relationship artifact: The smuggler learned this through direct observation, not rumor — high confidence
  • An emotional stake: Kael is trusted, so this knowledge creates internal conflict
  • A liability: If the ring leader asks "Do you know where Kael was?" the smuggler must choose: lie (protect Kael), tell truth (protect the operation), or deflect (buy time)

This is what the knowledge graph must support. Not "entity A knows fact X" but "entity A believes interpretation Y based on source Z, which creates emotional state W and decision pressure P."

1.2 How Does the Player CHARACTER Know Things?

Critical distinction: the PLAYER might notice something in the viewport, but the CHARACTER might not. The knowledge graph tracks what the CHARACTER knows, not what the player has seen.

Four ways the character gains knowledge:

Method Trust Level Monologue Behavior Example
Direct observation HIGH (but interpretation can be wrong) Immediate monologue: "Kael's in the corridor. He shouldn't be there." You watch Kael enter a restricted area
Told by trusted NPC VARIABLE (depends on relationship + situation) Delayed reflection: "Sera said Kael was at the dock... but I just saw him here. Why did she lie?" Sera tells you Kael's location
Told by untrusted NPC LOW (flagged as suspicious) Immediate skepticism: "He's lying. But why?" A hostile NPC makes a claim
Physical evidence MEDIUM-HIGH (can be forged) Analytical monologue: "Manifest says 40 units. I count 37. Where are the other three?" You access a terminal

Key narrative mechanic: The monologue system reveals the CHARACTER's confidence level. The player learns what their character thinks, not ground truth. This is the unreliable narrator pattern (D-016) applied to information.

1.3 Knowledge Hierarchy: From Suspicion to Certainty

Q-016 asks for a knowledge hierarchy. From a narrative perspective, there are five levels:

1. Unaware         — "Who's Hael?"
2. Suspects        — "I think something is wrong with Kael"
3. Knows_of        — "Kael has been meeting someone"
4. Knows_details   — "Kael met Hael in corridor B-7 at 22:40"
5. Understands     — "Kael is trying to exit the ring to protect Hael"

Why five levels, not three?

  • Unaware -> Suspects is the first monologue trigger. Character's gut feeling before evidence. This is "character is smarter than player" moment (D-039 wow moment #2).
  • Suspects -> Knows_of is the observation confirmation. Suspicion becomes fact.
  • Knows_of -> Knows_details is the investigative depth. General knowledge becomes actionable.
  • Knows_details -> Understands is the emotional/contextual revelation. Facts become narrative meaning.

Content authoring implication: Monologue lines need to reference specific levels:

- id: monologue_kael_suspicion
  text: "Kael's been distant lately. Three late arrivals this week. That's not like him."
  trigger: observe_npc
  prerequisite:
    knowledge:
      - subject: kael_davan
        level: suspects
        topic: behavior_change

The level gates which lines play. A knows_details monologue shouldn't fire if you're still at suspects.


2. Key Aha Moments the System Must Support

2.1 THE FRIEND Contradiction Discovery

The emotional centerpiece of v0.1 (D-034, D-039 wow moment #3). Here's the knowledge graph sequence:

Timeline:

  1. Session start — Character knows: kael_davan: trusted, colleague, ring_member (high relationship, insider access)
  2. Minute 20 — Direct observation: Kael enters restricted corridor during off-shift hours
  3. Knowledge update — Character now knows: kael_davan: observed_in_restricted_area, timestamp: 1200, source: direct_observation
  4. Monologue trigger — Urgent chime: "Kael? What's he doing in B-7? That corridor's off-limits during second shift."
  5. Player follows — Observes Kael meeting unknown NPC (Hael)
  6. Knowledge update — Character now knows: kael_davan: meeting_unknown_contact, location: corridor_b7
  7. Relationship state changekael_davan: relationship_tier shifts from trusted > flagged
  8. Entity color shift — Green -> Amber (D-033)
  9. Next conversation with Kael — Dialogue tree unlocks confrontation option

What the knowledge graph must support:

  • Observation generates knowledge nodes
  • Knowledge contradicts prior beliefs (Kael is supposed to be on dock, but you saw him in corridor)
  • Contradiction triggers monologue + relationship state shift
  • Relationship state affects dialogue access tiers (new lines unlock)
  • Subsequent observations add detail (meeting someone -> meeting Hael specifically)

2.2 Discovering Shared Knowledge (Gossip Observation)

Scenario: The smuggler overhears two NPCs (Torek and Lera) discussing Kael's strange behavior. Both NPCs reference details the smuggler also knows.

What this reveals:

  1. Kael's behavior is public knowledge (multiple observers)
  2. Torek and Lera have been talking (relationship between them)
  3. The situation is escalating (if people are gossiping, it's becoming a problem)

Monologue: "Torek and Lera are talking about Kael. They've noticed too. This is getting messy."

Knowledge graph implication: NPCs must have their own knowledge graphs that the player can partially observe. When you overhear a conversation, you learn:

  • What the NPCs know (adds to your graph)
  • That the NPCs know it (meta-knowledge about their knowledge)
  • That they're sharing it with each other (relationship inference)

This is load-bearing for political intrigue. In a conspiracy game, WHO KNOWS WHAT is as important as what they know.

2.3 Exploiting Information Asymmetry

Scenario: The detective learns (via evidence) that Voss (hub supervisor) has been filing false manifests. The detective knows. Voss doesn't know the detective knows.

Gameplay opportunity: The detective can:

  1. Confront Voss directly (uses knowledge to force disclosure)
  2. Observe Voss to gather more evidence (exploit ignorance to catch him in the act)
  3. Bluff to Voss ("I know what you've been doing") even if evidence is incomplete

Dialogue system integration (D-028): Confrontation dialogue unlocks when:

  • Player has knows_details level knowledge about Voss's activity
  • Voss relationship state includes has_secret flag
  • Player initiates dialogue and selects confrontation topic

Example dialogue tree:

- id: voss_confrontation_manifest
  role: hub_supervisor
  access: [authority, hostile]  # Changes when confronted
  trust: secret  # This was hidden information
  situation: confrontation
  topic: cargo_discrepancy
  prerequisite:
    knowledge:
      - subject: voss
        flag: false_manifests
        level: knows_details
  text: "[Present evidence] I pulled the cargo logs for the last three weeks. The numbers don't match."
  response_branches:
    - deny: [voss_deny_weak, voss_deny_strong]  # Depends on Voss's tolerance
    - deflect: [voss_deflect_authority, voss_deflect_personal]
    - confess: [voss_confess_partial]  # Only if tolerance threshold crossed

The knowledge level gates the option. You can't confront without knows_details.

2.4 Knowledge Decay and the Return

Scenario (D-011): The smuggler visits the bar, then leaves the district for several game-hours. When they return, the bar's social configuration has changed — different NPCs present, different conversations happening.

Knowledge decay:

  • location_state: last_bar timestamp is old
  • Character knows: "The bar was quiet when I left. Let's see who's here now."
  • Player expects the same scene. Character knows better.

Monologue on return: "Bar's louder now. End of shift crowd. Torek's here — wasn't earlier."

This creates micro-mystery. What happened while you were gone? Who talked to whom? The fog returns not just visually but informationally.


3. Content Authoring: The v0.1 Knowledge Vocabulary

Critical dependency: ticket #309 (knowledge state vocabulary for monologue authoring).

Mellanie needs a canonical list of knowledge flags to write monologue prerequisites. Here's my proposal for v0.1:

3.1 Entity Knowledge Categories

Knowledge about NPCs, structured by category:

Category Example Flags Content Use
Identity knows_name, knows_role, knows_background Greeting monologue, name vs "the dock worker"
Location last_seen_location, expected_location, observed_out_of_place Deviation detection monologue
Behavior observed_nervous, observed_lying, behavior_change Character assessment monologue
Relationships knows_relationship_to_X, observed_meeting_X, knows_triangle Social dynamics monologue
Secrets suspects_secret, knows_secret_partial, knows_secret_full Progressive revelation monologue
Contraband knows_ring_exists, knows_ring_member, knows_smuggling_operation Conspiracy monologue

3.2 World Knowledge Categories

Knowledge about places, events, systems:

Category Example Flags Content Use
Locations knows_restricted_area, knows_dead_drop, mapped_corridor_b7 Navigation monologue
Events witnessed_meeting, heard_argument, discovered_evidence Event reaction monologue
Systems knows_shift_schedule, knows_security_gaps, knows_manifest_process Operational knowledge monologue
Factions knows_commission_presence, knows_ring_structure Political assessment monologue

3.3 Confidence Levels (Q-016 Resolution)

Each knowledge flag has a confidence level:

knowledge:
  - subject: kael_davan
    category: behavior
    flag: observed_out_of_place
    level: knows_details  # One of: suspects, knows_of, knows_details, understands
    source: direct_observation
    timestamp: 1200
    location: corridor_b7

Monologue authoring example:

# Early suspicion line
- id: mon_kael_suspicion_001
  character: smuggler
  trigger: observe_npc
  prerequisite:
    knowledge:
      - subject: kael_davan
        flag: behavior_change
        level: suspects  # Fires when suspicion forms
  text: "Kael's been off lately. Can't put my finger on it, but something's different."

# Confirmed observation line
- id: mon_kael_observation_001
  character: smuggler
  trigger: observe_npc
  prerequisite:
    knowledge:
      - subject: kael_davan
        flag: observed_out_of_place
        level: knows_of  # Fires after you see him somewhere wrong
  text: "Kael, in the restricted corridor. He's not scheduled for that area."

# Detailed understanding line
- id: mon_kael_understanding_001
  character: smuggler
  trigger: post_conversation
  prerequisite:
    knowledge:
      - subject: kael_davan
        flag: trying_to_exit_ring
        level: understands  # Fires after you piece together the why
  text: "He's trying to get out. For Hael. Damn it, Kael, you should have talked to me first."

This is the vocabulary content team needs. A structured taxonomy, not free-form strings.


4. Dialogue System Integration (D-028)

4.1 Access Tiers and Knowledge

The four access tiers (public/peer/insider/secret) interact with knowledge state:

Public tier — anyone can say these lines, regardless of relationship:

  • Greetings
  • Surface-level small talk
  • Officially public information

Peer tier — requires neutral-to-positive relationship:

  • Casual conversation
  • Workplace chat
  • Shared experiences

Insider tier — requires trust relationship + shared context:

  • Personal information
  • Informal knowledge
  • Community secrets (not individual secrets)

Secret tier — requires high trust + specific knowledge trigger:

  • Individual secrets
  • Criminal activity
  • Vulnerability disclosure

Knowledge gates the secret tier. An NPC won't disclose secret-tier information unless:

  1. You have sufficient trust relationship
  2. You ALREADY know part of the secret (partial knowledge proves you're safe to tell)
  3. The NPC is under pressure (tolerance threshold crossed, triangle pressure high)

Example:

# Surface gossip (insider tier, no knowledge prerequisite)
- id: lera_gossip_kael_001
  role: bar_owner
  access: [insider]  # Must be a bar regular
  trust: surface
  situation: casual_conversation
  topic: coworker_gossip
  text: "Kael's been a bit quiet lately. Everything okay with him?"

# Real disclosure (insider tier, requires partial knowledge)
- id: lera_disclosure_kael_001
  role: bar_owner
  access: [insider]
  trust: real
  situation: private_conversation
  topic: kael_situation
  prerequisite:
    knowledge:
      - subject: kael_davan
        flag: behavior_change
        level: knows_of  # You've noticed, so Lera can confirm
  text: "Yeah, I've noticed too. He's been meeting someone. Don't know who, but it's not ring business."

# Secret admission (insider tier, high trust, detailed knowledge)
- id: lera_admission_kael_001
  role: bar_owner
  access: [insider]
  trust: secret
  situation: confrontation
  topic: kael_exit_attempt
  prerequisite:
    knowledge:
      - subject: kael_davan
        flag: trying_to_exit_ring
        level: knows_details  # You know enough to be dangerous
    relationship:
      trust_level: high
  text: "Look, Kael came to me asking how to get out clean. I told him there's no such thing. You planning to turn him in, or help him?"

The knowledge prerequisite controls disclosure progression. NPCs don't volunteer secrets — you unlock them by demonstrating you already know enough to be trusted.

4.2 Fishing for Information (Player Doesn't Know Yet)

Question from workshop brief: What happens when the player asks about something they don't know about yet?

Answer: You can't ask about what you don't know exists.

The dialogue system should only present topics the character has at least suspects level knowledge about. If you've never heard of Hael, you can't select "Ask about Hael" as a dialogue option.

BUT: You CAN ask open-ended questions that might reveal new knowledge:

# Open-ended probe (always available in peer+ conversations)
- id: dialogue_probe_general_001
  role: any
  access: [peer, insider]
  trust: surface
  topic: general_probe
  text: "Anything interesting happening around here lately?"
  # NPC response depends on their mood, trust, and what THEY know

The NPC might volunteer knowledge, weighted by:

  • Their mood (stressed NPCs overshare)
  • Their trust in you
  • Triangle pressure (gossip escalates conflicts)
  • Recent events

This is D-028 Layer 4 (unprompted disclosure). NPCs have agency — they choose to tell you things based on their state, not just your questions.

4.3 Confrontation Mechanics

Confrontation is a special situation (D-035 situation taxonomy) that activates when:

  1. You have knows_details level knowledge about an NPC's secret/vulnerability
  2. You initiate conversation with confrontation intent (player choice)
  3. OR triangle pressure crosses threshold (Q-017)

Confrontation dialogue uses knowledge as evidence:

- id: dialogue_confront_voss_manifest
  role: hub_supervisor
  access: [authority]
  trust: secret
  situation: confrontation
  topic: manifest_discrepancy
  prerequisite:
    knowledge:
      - subject: voss
        flag: false_manifests
        level: knows_details
  text: "[Present evidence] I pulled the cargo logs for the last three weeks. The numbers don't match."
  # Voss's response depends on his tolerance threshold

NPC response is NOT dialogue branches. It's systemic:

  • Low tolerance -> confess, cooperate
  • Medium tolerance -> deflect, stall
  • High tolerance -> deny, become hostile

The knowledge system creates the confrontation opportunity. The NPC's axes (D-024) determine the outcome.


5. Political & Social Dynamics

5.1 Knowledge Propagation (Gossip as Mechanic)

NPCs share knowledge with each other. This is D-010 principle 2 in action — NPCs have information boundaries just like the player.

Gossip propagation rules:

  1. NPCs share knowledge during conversations (visible to player if in earshot, invisible if not)
  2. What gets shared depends on:
    • Relationship between the NPCs (trust level)
    • Personality (some NPCs are gossips, some are discreet)
    • Tolerance threshold (stressed NPCs overshare)
    • Triangle pressure (gossip escalates triangle conflicts)

Example propagation chain:

T=100:  Smuggler observes Kael in restricted corridor
        Smuggler knowledge: kael_observed_out_of_place (level: knows_of)

T=150:  Smuggler mentions this to Lera (bar owner) in casual conversation
        Lera knowledge: kael_observed_out_of_place (level: knows_of, source: told_by_smuggler)

T=200:  Torek (security officer) visits bar, talks to Lera
        Lera shares gossip about Kael (her personality: gossip=high)
        Torek knowledge: kael_observed_out_of_place (level: knows_of, source: told_by_lera)

T=250:  Voss (hub supervisor, ring leader) talks to Torek
        Torek casually mentions Kael's odd behavior
        Voss knowledge: kael_behavior_suspicious (level: suspects, source: told_by_torek)

T=300:  Voss confronts Kael
        Ring pressure increases
        Kael's tolerance threshold approaches breaking point

The player can observe parts of this chain:

  • Overhear Lera and Torek gossiping (direct observation)
  • Notice Voss and Kael having a tense conversation (indirect observation)
  • Kael becomes more nervous in subsequent interactions (behavioral tell)

Monologue commentary: "Everyone's talking about Kael now. This is how people get caught."

This is emergent political intrigue. The knowledge graph + NPC conversations create information flow that the player can observe, exploit, or try to suppress.

5.2 Social Triangles and Knowledge (D-024, Q-017)

Triangles are the atomic unit of social intrigue. Knowledge about triangles changes gameplay.

Triangle 4 (Worried Partner) from canonical web: Hael — Kael — Sera

Knowledge progression:

Phase Character Knowledge Gameplay Impact
Unaware Character doesn't know triangle exists No special options
Suspects "Kael's been acting strange. Sera seems worried about something." Monologue flags pattern
Knows_of "Kael and Sera have been meeting. Hael is involved somehow." Can ask NPCs about relationships
Knows_details "Hael is Kael's partner. Kael is trying to exit the ring to protect Hael. Sera is covering for both of them." Confrontation unlocks, triangle pressure visible
Understands "This is why Sera lied to me. She's protecting Hael as a friend." Emotional context, forgiveness option

Triangle pressure (Q-017 question): As knowledge spreads, triangle pressure increases. When it crosses threshold, confrontation situation activates automatically (not player-initiated).

Pressure increase events:

  • Player observes triangle interaction (+10 pressure)
  • Player asks NPC about triangle member (+15 pressure)
  • Gossip spreads to additional NPCs (+20 pressure per NPC)
  • Player confronts one triangle member about another (+30 pressure)
  • External event (ring leader suspicious, Commission investigation progresses) (+25 pressure)

Threshold: ~75-100 pressure. When crossed, next interaction with any triangle member triggers confrontation dialogue automatically.

Content implication: Each triangle needs confrontation dialogue for each member, with knowledge prerequisites.

5.3 Information Asymmetry Between Player and NPCs

The most interesting moments are when:

  1. You know something an NPC doesn't (exploit their ignorance)
  2. An NPC knows something you don't (you're being played)
  3. You both know something but pretend you don't (social dance)

Example 1: You know, they don't

The smuggler knows Voss has been skimming from the ring's profits (discovered via evidence). Voss doesn't know the smuggler knows.

Gameplay: You can watch Voss to gather more evidence, confront him when you have enough, or use the information as leverage.

Monologue: "Voss thinks he's being clever. But I've seen the discrepancies."

Example 2: They know, you don't

THE FRIEND (Kael) knows the smuggler has been asking questions about him. The smuggler doesn't realize Kael knows.

Gameplay: Kael becomes evasive, changes behavior, might confront the smuggler first.

Dialogue shift:

# Before Kael knows you're investigating
- id: kael_casual_001
  access: [insider, peer]
  trust: surface
  text: "Hey. Usual shift chaos today."

# After Kael knows (relationship state includes 'aware_of_investigation')
- id: kael_guarded_001
  access: [insider, peer]
  trust: surface
  prerequisite:
    relationship:
      flags: [aware_of_investigation]
  text: "Hey. [pause] Everything okay with you?"

Monologue: "Kael's acting strange. Did someone tip him off?"

Example 3: Mutual knowledge, mutual pretense

Both you and an NPC know the ring exists. Neither has acknowledged it explicitly. You're dancing around the truth.

Dialogue uses coded language:

- id: voss_coded_001
  role: hub_supervisor
  access: [insider]
  trust: real
  situation: private_conversation
  prerequisite:
    knowledge:
      - subject: voss
        flag: ring_leader
        level: knows_of  # You suspect, but haven't confirmed
  text: "Some cargo needs... special handling. You understand."
  # Player response options include: play along, press for details, refuse

This is the social gameplay. Not just "know X to unlock Y" but "what you know changes how you interact."

5.4 Can NPCs Lie? (Misinformation)

Yes. Load-bearing mechanic.

NPCs lie when:

  1. Protecting a secret (themselves or someone they care about)
  2. Under pressure (tolerance threshold low, desperate)
  3. Testing you (seeing if you already know the truth)
  4. Manipulating you (advancing their own agenda)

How lies work in the knowledge graph:

When an NPC tells you something false, it enters your knowledge graph as TRUE (with source: told_by_X). The lie is indistinguishable from truth until you have contradictory knowledge.

Example:

T=100:  Sera (detective's FRIEND) tells you: "Kael was at the dock during second shift."
        Detective knowledge: kael_location_second_shift = dock (level: knows_of, source: told_by_sera, confidence: high)

T=200:  Detective directly observes Kael in corridor B-7 during second shift
        Detective knowledge: kael_location_second_shift = corridor_b7 (level: knows_details, source: direct_observation, confidence: very_high)

T=201:  Knowledge system detects contradiction
        Both nodes remain in graph, flagged as conflicting
        Relationship state updated: sera_lied = true

T=202:  Monologue trigger (urgent chime): "Sera told me Kael was at the dock. But I just saw him in the corridor. Why did she lie?"

T=203:  Entity color shift: Sera changes from green (trusted) to amber (flagged)

T=210:  Next conversation with Sera unlocks confrontation option

This is THE FRIEND's arc (D-034). The contradiction is discoverable through observation. The lie isn't revealed through dialogue — it's revealed through the knowledge graph detecting the conflict.

Content implication: NPCs need both truthful and false dialogue lines for key topics. The NPC's decision to lie depends on:

  • Relationship trust (low trust = more likely to lie)
  • Secret/vulnerability pressure (protecting something = lie)
  • Situation (confrontation = less likely to lie, casual = easier to lie)

Misinformation vulnerability: A clever player could spread false information to NPCs, then observe how it propagates. This creates disinformation gameplay.


6. Character Perspective and Monologue Integration

6.1 Single-Character Perspective Constraint (D-001, D-005)

The knowledge graph must reflect CHARACTER knowledge, not player knowledge.

The split between player and character:

  • Player sees: Entities in viewport, visual tells, spatial relationships
  • Character knows: Interpreted meaning of what they see, context from past experience, emotional weight

Example:

Player sees: Two NPCs having a conversation in the corner of the bar.

Character knows (if smuggler, insider access): "That's Voss and Nils. Probably ring business. They don't usually meet here."

Character knows (if detective, outsider): "Two men in the corner. Hushed conversation. Worth noting."

The monologue bridges the gap. It translates visual observations into knowledge entries, filtered through character perspective.

Monologue trigger sequence:

1. Player viewport: Kael enters restricted corridor
2. Perception system: Character has LOS to Kael
3. Knowledge system: Does character recognize Kael? (yes, knows_name + knows_role)
4. Knowledge system: Is this location notable? (yes, restricted_area)
5. Knowledge update: kael_observed_out_of_place = true, level: knows_of
6. Monologue trigger: Character commentary on the observation
7. Monologue rendering: "Kael? What's he doing in B-7?"

If the character DIDN'T recognize Kael: Monologue would be generic: "Someone in the corridor. Odd time for that area to be active."

Knowledge level determines monologue specificity.

6.2 Internal Monologue and Knowledge State

The monologue system (D-016) must reveal the character's knowledge state to the player.

Monologue functions:

  1. Perception bridge — translate visual observation into narrative meaning
  2. Knowledge commentary — reveal what the character knows about what they see
  3. Confidence indicator — show whether character is certain or uncertain
  4. Emotional reaction — show how the character FEELS about what they know
  5. Contradiction detection — flag when new knowledge conflicts with prior beliefs

Monologue examples by knowledge level:

# Unaware (no knowledge about Hael)
- text: "Someone I don't recognize. New face at the hub."

# Suspects (beginning of knowledge)
- text: "I think I've seen them before. Can't place where."

# Knows_of (confirmed but vague)
- text: "That's Hael. Works in maintenance, I think. Keeps to themselves."

# Knows_details (specific knowledge)
- text: "Hael Miran, maintenance second shift. Kael's partner. Started three months ago."

# Understands (contextual meaning)
- text: "Hael. So that's who Kael is risking everything for."

Each level unlocks more detailed monologue. The player learns what their character knows through the specificity of the commentary.

6.3 Different Archetypes Experience Knowledge Differently

Smuggler (operator archetype):

  • Knowledge focus: threat assessment, operational security, loyalty network
  • Monologue style: terse, practical, paranoid
  • Knowledge interpretation: "Is this a threat? Can I trust them? What's the risk?"

Detective (investigator archetype):

  • Knowledge focus: pattern recognition, evidence correlation, procedural gaps
  • Monologue style: analytical, methodical, distant
  • Knowledge interpretation: "Does this fit the pattern? What's the evidence? What's the procedure?"

Same observation, different knowledge entry:

Event: Kael arrives 15 minutes late to shift

Smuggler knowledge:

subject: kael_davan
flag: behavior_change
level: suspects
emotional_weight: concern  # Kael is a friend
monologue: "Kael's late again. Third time this week. If he's getting sloppy, the whole operation is at risk."

Detective knowledge:

subject: kael_davan
flag: routine_deviation
level: knows_of
emotional_weight: neutral  # Professional interest only
monologue: "Dock worker, second shift. Third late arrival this week. Noted."

Same fact, different interpretation, different emotional weight. This IS the dual-lens experience.


7. Risks: What Makes the Knowledge System Feel Cold?

The knowledge graph could feel like a spreadsheet instead of a story. Here's what would kill the narrative:

7.1 Knowledge as Checklist

Risk: Player treats knowledge like collectibles. "I need to unlock 'knows_details' about Kael to proceed."

Mitigation:

  1. No UI display of knowledge flags. Player never sees "Kael: suspects (2/5 levels)". They experience it through monologue.
  2. Multiple paths to the same information. You can learn about Kael's situation through observation, through gossip, through evidence. No single required path.
  3. Knowledge doesn't gate story progress, it gates understanding. You can finish the vertical slice without knowing THE FRIEND's full story. But if you DO know, it means more.

7.2 Perfect Memory

Risk: Player character remembers everything forever with perfect clarity. No tension, no challenge.

Mitigation:

  1. Knowledge decay (D-011 fog returns). Information about NPC locations becomes stale. "Kael was at the dock" is only true at that timestamp.
  2. Confidence degradation. Knowledge learned through rumor has lower confidence than direct observation. Over time, confidence decays unless refreshed.
  3. Journal as crutch, not backup brain. Player can review the journal, but the CHARACTER doesn't consult it constantly. Monologue reflects what the character actively remembers.

7.3 Binary Knowledge States

Risk: You either know or you don't. No nuance, no investigation feel.

Mitigation:

  1. Five-level hierarchy (suspects > knows_of > knows_details > understands). Gradual revelation.
  2. Partial knowledge is useful knowledge. Even at suspects level, monologue fires. Even at knows_of level, new dialogue unlocks. You're playing with incomplete information, which is the point.

7.4 NPC Knowledge Invisible

Risk: NPCs have knowledge graphs, but player can't read them. The social dynamics are invisible.

Mitigation:

  1. Observable tells (D-034). NPCs change behavior based on their knowledge state. If an NPC knows you're investigating, they act guarded.
  2. Overhearing gossip. When NPCs share knowledge, you can witness it (if in earshot). This reveals both the information and the social relationship.
  3. Relationship color coding (D-033). Entity color reflects relationship state, which is partially driven by what the NPC knows about you.

7.5 Knowledge Without Stakes

Risk: Facts accumulate, but they don't matter emotionally.

Mitigation:

  1. Every piece of knowledge about THE FRIEND has emotional weight. Learning Kael is compromised HURTS because you trusted them.
  2. Knowledge creates obligation. If you know Kael is trying to exit the ring, you must choose: help them, turn them in, or pretend you don't know. Knowledge is liability.
  3. NPCs react to your knowledge. If they know you know their secret, the relationship changes. Knowledge has social consequences.

8.1 Resolve Q-016 (Knowledge Hierarchy)

Proposal: Five-level hierarchy (unaware, suspects, knows_of, knows_details, understands) with narrative definitions for each level.

Needs: Gestalt validation (does this map to mechanics?) and Dudley validation (is this implementable?).

8.2 Define v0.1 Knowledge Vocabulary (#309)

Proposal: Section 3 of this document provides the taxonomy. Content team needs this to write monologue prerequisites.

Deliverable: Formal knowledge vocabulary document with:

  • Entity knowledge categories (identity, location, behavior, relationships, secrets, contraband)
  • World knowledge categories (locations, events, systems, factions)
  • Confidence level schema
  • Example monologue prerequisites

Owner: Paula (narrative spec) + Gestalt (mechanical validation) + Mellanie (authoring validation)

8.3 Design Knowledge-to-Monologue Pipeline

Question: How does knowledge state trigger monologue?

Current gap: We know monologue has 9 trigger types (D-035). One is observe_npc. But how does the knowledge graph interact with the trigger system?

Proposal:

  1. Observation triggers perception query
  2. Perception query checks knowledge graph: "Do I know this entity?"
  3. If yes, retrieve knowledge level and recent changes
  4. Select monologue from pool filtered by: character, trigger type, knowledge level, emotional state
  5. Render monologue with character voice

Needs: Gestalt (pipeline design) + Dudley (perception integration)

8.4 Prototype THE FRIEND Contradiction Arc

Critical test case: The knowledge graph must support THE FRIEND's arc. If it can't handle:

  • Kael tells you X
  • You observe not-X
  • Graph detects contradiction
  • Monologue fires (urgent chime)
  • Relationship state shifts (color change)
  • Dialogue unlocks (confrontation)

...then the system isn't ready.

Recommendation: Prototype this sequence as a proof-of-concept. If the knowledge graph can handle THE FRIEND, it can handle the whole game.

8.5 Define Gossip Propagation Rules

Question: How do NPCs share knowledge?

Proposal:

  • NPCs have conversation system (not detailed in current architecture)
  • During conversation, NPCs can share knowledge based on: relationship trust, personality (gossip tendency), tolerance state, triangle pressure
  • Shared knowledge enters recipient's graph with source: told_by_X
  • Player can observe gossip if in earshot (overhearing mechanic)

Needs: Gestalt (conversation system design) + Tyre (performance implications of NPC-to-NPC knowledge transfer)

8.6 Integrate Knowledge with Dialogue Access Tiers

Current state: D-028 defines four relational layers. D-035 defines tag taxonomy including access and trust filters.

Missing piece: How does knowledge state affect access tier eligibility?

Proposal:

  • Secret-tier dialogue requires knowledge prerequisite (you must know part of the secret)
  • Confrontation dialogue requires knows_details level
  • NPCs can volunteer information (unprompted disclosure) based on their knowledge of YOUR knowledge ("I heard you were asking about Kael...")

Needs: Dialogue system specification update integrating knowledge prerequisites.


9. Files Referenced

Decision Files

  • decisions/content.md — D-023, D-024, D-025, D-028, D-029, D-032, D-034, D-035
  • decisions/perception.md — D-011, D-015, D-016, D-017, D-018, D-019, D-033
  • decisions/architecture.md — D-010
  • decisions/scope.md — D-001, D-005, D-006, D-027, D-039
  • decisions/questions.md — Q-016, Q-017

Workshop Files

  • docs/workshops/knowledge-graph-information-boundaries/workshop-brief.md

Briefing Files

  • docs/briefings/paula.md

End of Round 1 Analysis

The honest truth is this: the knowledge graph is where mechanics and narrative either fuse into something greater, or fail to connect at all. Get this right, and every observation means something. Every conversation has stakes. Every betrayal lands. Get this wrong, and it's just bookkeeping.

What SUSTAINS knowledge as a mechanic across hours of play is that knowledge creates OBLIGATION. Knowing something means you must choose what to do with it. And in a conspiracy story, that choice is never clean.