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

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

title	description	type	status	workshop	agent	round	created
Knowledge Graph & Information Boundaries Workshop Brief	Workshop brief defining goals, context, and deliverables for the knowledge graph design workshop	workshop	archived	knowledge-graph-information-boundaries		0	2026-02-11

Knowledge Graph & Information Boundaries Workshop Brief

Goal: Design the knowledge data structure that replaces InformationInventory { known_facts: Vec<String> } — the pillar-1 mechanic foundation for asymmetric information. Ticket: #351 (epic) Priority: CRITICAL — Sprint 2 blocker Participants: Tyre (architecture lead), Gestalt (mechanics), Paula (narrative), Dudley (implementation), Qatux (docs), Si (tickets) Source: Architecture Review Audit 2026-02-11, Consensus Recommendation #12

Context

The architecture audit independently identified the knowledge graph as the most important and least specified critical system. Both Tyre and Troblum rated it CRITICAL.

D-010 principle 2 says: "every piece of game state is tagged with who knows it." The current implementation in server/src/npc/mod.rs has InformationInventory { known_facts: Vec<String> } — a placeholder that cannot support observation, monologue, dialogue, or success criteria.

This system is load-bearing for:

• D-010: Multiplayer-ready information boundaries
• D-011: Fog of perception (what returns when you leave)
• D-017: Perception modes (what different modes reveal)
• D-028: Tagged line pools (access-tier dialogue)
• D-033: Entity color from relationship state
• Q-016: Knowledge hierarchy (suspects < knows_of < knows_details)

Key Questions to Resolve

Data Structure

1. What does "entity A knows about entity B" look like as a Rust struct?
2. How is knowledge confidence tracked? (Q-016: hierarchy levels)
3. How does knowledge decay over time? (D-011: "fog returns when you leave")
4. How are non-entity facts tracked? (locations, events, relationships between others)

Knowledge Flow

5. How does knowledge enter the graph? (Direct observation, told by NPC, inferred)
6. How does the KnowledgeSource affect confidence?
7. Can knowledge be wrong? (Misinformation, outdated information)
8. How do NPCs share knowledge with each other? (Gossip, reports, investigations)

Performance

9. At 80 Active NPCs, each knowing about ~50 entities, what's the memory budget?
10. How is the knowledge graph queried efficiently for observer snapshot generation?
11. Does knowledge graph update need spatial partitioning? (Only update knowledge for nearby entities)

Game Mechanics Integration

12. How does the knowledge graph drive monologue triggers? (D-019, tickets #119-122)
13. How does knowledge state affect dialogue access tiers? (D-028)
14. How do social triangles interact with knowledge? (Does knowing about a triangle change behavior?)

Input Documents

Document	What to read	Why
decisions/perception.md	D-011, D-015-D-019	Perception system requirements
decisions/architecture.md	D-010 (principles), D-024 (NPC model), D-026 (simulation tiers)	Architecture constraints
decisions/content.md	D-028 (tagged line pools), D-033 (entity color)	Content system dependencies
decisions/questions.md	Q-016 (knowledge hierarchy), Q-017 (triangle pressure)	Open questions this workshop should resolve
server/src/npc/mod.rs	Current NPC component model	What exists today
server/src/perception/mod.rs	Perception plugin stub	Where this code will live
docs/audits/architecture-review-2026-02-11.md	Tyre R-01, Troblum section 4	Detailed analysis and proposals

Expected Outputs

1. Decision: D-0XX — Knowledge Graph Data Model — Rust struct definitions for KnowledgeGraph, EntityKnowledge, KnowledgeConfidence, KnowledgeSource
2. Decision: Resolution of Q-016 — Knowledge hierarchy levels with concrete enum values
3. Design document: Knowledge flow specification (how knowledge enters, propagates, decays)
4. Tickets: Implementation tasks broken down from the design
5. Performance budget: Memory and query time targets at 80 NPCs

Workshop Format

Two rounds, following project convention:

• Round 1: Each participant independently analyzes the questions from their domain perspective
• Round 2: Cross-review, debate, and synthesis into concrete decisions