jpmschweitzerandClaude Opus 4.6
1920f002a1
Workshop briefs for the larger spikes identified by the architecture review audit: knowledge graph & information boundaries, observer snapshot pipeline, NPC AI state machines, save/load architecture, and map authoring pipeline. Each includes participants, key questions, input documents, and expected outputs. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
4.1 KiB
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
- What does "entity A knows about entity B" look like as a Rust struct?
- How is knowledge confidence tracked? (Q-016: hierarchy levels)
- How does knowledge decay over time? (D-011: "fog returns when you leave")
- How are non-entity facts tracked? (locations, events, relationships between others)
Knowledge Flow
- How does knowledge enter the graph? (Direct observation, told by NPC, inferred)
- How does the
KnowledgeSourceaffect confidence? - Can knowledge be wrong? (Misinformation, outdated information)
- How do NPCs share knowledge with each other? (Gossip, reports, investigations)
Performance
- At 80 Active NPCs, each knowing about ~50 entities, what's the memory budget?
- How is the knowledge graph queried efficiently for observer snapshot generation?
- Does knowledge graph update need spatial partitioning? (Only update knowledge for nearby entities)
Game Mechanics Integration
- How does the knowledge graph drive monologue triggers? (D-019, tickets #119-122)
- How does knowledge state affect dialogue access tiers? (D-028)
- 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
- Decision: D-0XX — Knowledge Graph Data Model — Rust struct definitions for
KnowledgeGraph,EntityKnowledge,KnowledgeConfidence,KnowledgeSource - Decision: Resolution of Q-016 — Knowledge hierarchy levels with concrete enum values
- Design document: Knowledge flow specification (how knowledge enters, propagates, decays)
- Tickets: Implementation tasks broken down from the design
- 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