settled-reach/docs/workshops/knowledge-graph-information-boundaries/round1-si.md

Knowledge Graph & Information Boundaries Workshop — Round 1: SI (Project Management)

Author: SI (Project Manager, Scrum Master) Date: 2026-02-11 Focus: Ticket landscape, dependency mapping, work breakdown preview, sprint impact, risk assessment

---

Executive Summary

The Knowledge Graph Workshop (Epic #351) sits at a critical junction in our project architecture. It blocks the Observer Snapshot Pipeline Workshop (#352), intersects directly with Sprint 2's critical path through #112, and affects 9 scattered backlog tickets that need consolidation. The server team has run ahead on #110 (shadowcasting) while blocked by Q-018 — manageable risk, but signals urgency pressure.

Critical finding: #112 (Observer visibility query) claims to "respect information boundaries" but the knowledge graph doesn't exist yet. This is a specification gap, not an implementation blocker — the workshop must define what "respects information boundaries" means in code.

Minimum viable knowledge graph for Sprint 2: What does visibility filtering need? Not the full gossip/inference/decay system — just the query interface that #112 can call. Workshop must identify the MVP boundary.

---

1. Current State: Ticket Inventory

1.1 Workshop Epics

ID	Title	Status	Priority	Blocks
#351	Workshop: Knowledge Graph & Information Boundaries	backlog	critical	#352
#352	Workshop: Observer Snapshot Pipeline	backlog	critical	(none tracked)

Gap: #352 doesn't have explicit blockers beyond #351, but Sprint 2 completion (#357) depends on observer snapshot generation working. Implicit dependency chain not captured in tickets.

1.2 Sprint 2 Tickets (14 total)

ID	Title	Status	Priority	Owner	Blocks
Design Track
#359	Resolve Q-018: shadowcasting algorithm	ready	critical	server	#110
#358	Design ObserverSnapshot v2 schema	ready	critical	joint	#112, #113, #25
#360	Resolve Q-019: entity ID stability	ready	high	joint	#130
Server Track
#110	Shadowcasting algorithm - server	in_progress	critical	server	#111
#111	Vision cone implementation	ready	critical	server	#112
#112	Observer visibility query	ready	critical	server	#113, #356
#25	Game clock and day-phase system	ready	high	server	#357
Client Track
#116	Camera lock to character	ready	critical	client	#357
#129	Tile rendering engine	ready	critical	client	(none)
#130	Entity sprite management	ready	critical	client	(none)
#131	Fog overlay rendering	ready	critical	client	(none)
#113	Fog rendering - client	ready	critical	client	#356
Integration Track
#356	Fog data through bridge	ready	critical	joint	#357
#357	Sprint 2 proof: fog of perception	ready	critical	joint	(none)

Status: 13 ready, 1 in_progress. Server team working ahead on #110 despite Q-018 blocker.

1.3 Knowledge-Related Backlog Tickets (10 total, not in any sprint)

ID	Title	Type	Status	Priority	Parent	Notes
#49	Information Boundary System	epic	backlog	critical	#31 (Map & Nav)	Parent epic with 6 children
#138	Information tag schema	story	backlog	critical	#49	Child of #49
#139	Component-level access control	story	backlog	critical	#49	Child of #49
#140	Entity visibility filtering	story	backlog	critical	#49	Child of #49
#141	Knowledge-based information gating	story	backlog	high	#49	Child of #49
#142	NPC information boundaries	story	backlog	high	#49	Child of #49
#269	CauseChain component	story	backlog	high	#49	Child of #49 (implemented, ticket status stale)
#89	Information inventory	story	backlog	high	#39 (NPC Data)	Standalone, blocks #90
#182	Divergent starting knowledge	story	backlog	critical	#57 (PCs)	Content-side ticket
#264	Knowledge/journal display	story	backlog	medium	(unlisted)	UI ticket
#272	Information boundary negative test suite	story	backlog	high	(unlisted)	Test infrastructure
#309	Knowledge state vocabulary for v0.1	story	backlog	high	#55 (Dialogue)	Content blocker

Key observation: Epic #49 (Information Boundary System) has 6 children. #89 (Information inventory) is standalone under NPC Data. These should be reconciled — either #89 becomes a child of #49, or #351 subsumes both.

CauseChain note (#269): The audit report and D-030 indicate CauseChain is already implemented (server/src/cause_chain.rs). Ticket status is stale. Should be marked done or retitled as integration work.

---

2. Dependency Mapping

2.1 Sprint 2 Critical Path to Proof (#357)

Blocking relationships (from ticket_deps table):

#359 (Q-018 decision) ──► #110 (shadowcast)
                              ▼
                          #111 (vision cone)
                              ▼
#358 (snapshot v2)  ────────► #112 (observer query) ──┬─► #113 (fog render) ──┐
      │                         │                     │                        │
      ├─────────────────────────┴──► #356 (bridge) ◄─┘                        │
      │                                   │                                    │
      └──► #25 (time) ──────────────┬────┘                                    │
                                     │                                         │
#116 (camera lock) ──────────────────┴─────────────────────────────────────┬──┘
                                                                            │
                                                                            ▼
                                                                        #357 (proof)

Critical path (longest): #359 → #110 → #111 → #112 → #356 → #357 (6 tickets serial)

Parallel tracks:

• #358 → #25 → #357 (3 tickets, merges at #357)
• #116 → #357 (independent, merges at #357)
• Client rendering (#129, #130, #131, #113) mostly independent until #113 waits on #112

Observation: #358 (ObserverSnapshot v2) gates three parallel tracks (#112, #113, #25). This is a design-blocker bottleneck. Joint team must resolve #358 early in sprint to unblock all three.

2.2 Knowledge Graph Workshop Dependencies

Architecture Audit (2026-02-11)
    Consensus Rec #12: "Knowledge graph workshop NOW"
           │
           ▼
    #351 (Knowledge Graph Workshop) ◄──── implicitly affects ──── #112 (observer query)
           │                                                            │
           │                                                   "respects info boundaries"
           │                                                            │
           └──► blocks ──► #352 (Observer Snapshot Pipeline)           │
                                                                        │
    #49 (Info Boundary System epic) ◄─── overlaps ──────────────────┘
           ├─► #138 (tag schema)
           ├─► #139 (access control)
           ├─► #140 (entity visibility filtering) ◄───── related to #112
           ├─► #141 (knowledge-based gating)
           ├─► #142 (NPC info boundaries)
           └─► #269 (CauseChain) [already implemented]

    #89 (Information inventory) ◄─── overlaps with #351 ─── replaces Vec<String> placeholder

    #309 (Knowledge vocab for v0.1) ◄─── content-side dependency ─── needs knowledge model

Gap identified: Epic #49 predates the workshop but covers overlapping scope. Post-workshop, #49 should either:

1. Be consolidated under #351 as implementation tickets, OR
2. Be re-scoped as the client-facing information system (UI, tags, access control) while #351 owns the knowledge graph data model

Recommendation: Treat #351 as the architecture/data model workshop, and #49's children (#138-#142) as implementation stories that depend on #351's outputs.

---

3. Gap Analysis: #112 "Respects Information Boundaries"

3.1 The Problem

Ticket #112 (Observer visibility query) description:

"Given observer entity, return visible entities and tiles. Respects information boundaries. Feeds ObserverSnapshot."

Question: What does "respects information boundaries" mean in code?

From D-010 principle 2:

"Every piece of game state is tagged with who knows it."

From current implementation (server/src/npc/mod.rs lines 46-48):

#[derive(Component, Debug, Clone, Serialize, Deserialize)]
pub struct InformationInventory {
    pub known_facts: Vec<String>,
}

The gap: #112 needs to query "what does entity A know about entity B" but the knowledge graph is a Vec<String> placeholder. The observer query can't "respect information boundaries" until the knowledge model exists.

3.2 Is This a Blocker?

No — it's a specification gap, not an implementation blocker.

For Sprint 2's "fog of perception" proof, visibility is primarily geometric (LOS + vision cone). The full knowledge graph (gossip, inference, memory decay) isn't needed yet.

Minimum viable implementation for #112:

• Observer can see entities within LOS range
• Vision cone modulates range (forward = full, peripheral = reduced, behind = blind)
• Walls block vision (read from WalkabilityMap)
• No knowledge-based filtering for Sprint 2

Knowledge-based filtering comes later:

• "Can you identify this person?" (knows vs unknown)
• "Do you know what they're carrying?" (requires prior observation)
• "Do you know their secret?" (requires dialogue/investigation)

Recommendation: Workshop should define the query interface (#112 needs) even if full implementation is deferred. Sprint 2 uses geometric visibility only; Sprint 3+ adds knowledge filtering.

---

4. Work Breakdown Preview

4.1 Expected Workshop Outputs (from brief)

1. Decision: D-0XX — Knowledge Graph Data Model — Rust struct definitions
2. Decision: Resolution of Q-016 — Knowledge hierarchy (suspects < knows_of < knows_details)
3. Design document: Knowledge flow specification
4. Tickets: Implementation tasks broken down from design
5. Performance budget: Memory/query time targets at 80 NPCs

4.2 Anticipated Ticket Structure Post-Workshop

Epic #351 will likely spawn:

Type	Title (projected)	Priority	Notes
story	Implement KnowledgeGraph component	critical	Replace Vec<String> with structured graph
story	Knowledge confidence/hierarchy system	critical	Resolves Q-016
task	Observer knowledge query interface	critical	What #112 calls to filter entities
story	Knowledge propagation: observation	high	How seeing something adds knowledge
story	Knowledge propagation: told/gossip	high	How NPCs share knowledge
story	Knowledge decay over time	medium	D-011 "fog returns when you leave"
task	Spatial indexing for knowledge queries	medium	Performance at 80 NPCs
story	Knowledge-based entity identification	medium	"Who is this person?" vs "unknown person"
task	Knowledge graph unit tests	high	Known scenarios, deterministic outcomes
story	Integrate knowledge into dialogue system	high	D-028 tagged line pools need knowledge prereqs

Consolidation opportunity: Tickets #138 (tag schema), #140 (entity visibility filtering), #141 (knowledge gating), #142 (NPC boundaries) should become children of workshop output stories.

4.3 Integration with Existing Tickets

Existing Ticket	Relationship to #351
#89 (Information inventory)	DUPLICATE — subsume into #351 knowledge graph story
#138 (Information tag schema)	CHILD — becomes implementation task for knowledge tags
#140 (Entity visibility filtering)	CHILD — becomes implementation of observer query interface
#141 (Knowledge-based gating)	CHILD — uses knowledge graph for access control
#142 (NPC information boundaries)	CHILD — NPC knowledge = KnowledgeGraph component per entity
#269 (CauseChain)	RELATED — provenance system (already done per audit)
#309 (Knowledge vocab for v0.1)	DEPENDS ON — content team needs knowledge model first
#272 (Info boundary test suite)	DEPENDS ON — tests require implemented knowledge system

Post-workshop ticket reconciliation required.

---

5. Sprint 2 Impact Assessment

5.1 Does #351 Block Sprint 2 Completion?

Short answer: No, but it creates technical debt.

Sprint 2 proof (#357): "Walk into a room and see the fog" — visibility-driven, not knowledge-driven. The geometric perception system (#110, #111, #112) can ship without full knowledge graph.

What Sprint 2 needs from #351:

1. Query interface design: What does #112 call to ask "what can this observer see?" Even if the answer is always "everything in LOS" for Sprint 2, the interface contract must exist.
2. Stub implementation path: #112 can call KnowledgeGraph::can_observe(observer, target) -> bool that returns true for Sprint 2. Full logic comes later.

What Sprint 2 does NOT need:

• Knowledge propagation (gossip, inference)
• Knowledge decay over time
• Knowledge confidence levels
• NPC-to-NPC knowledge sharing

5.2 Risk: Rework if Workshop Runs Long

If #351 isn't resolved before Sprint 2 starts, the server team will implement #112 with placeholder logic. Risk of rework if workshop produces incompatible interface design.

Mitigation: Workshop Round 1 (this round) runs concurrent with Sprint 2 kickoff. Round 2 synthesis should complete before #112 implementation starts (currently blocked by #111 anyway).

5.3 Critical Path Timing

Current sprint state:

• #110 (shadowcasting) is in_progress despite blocked by #359 (Q-018)
• #359 (Q-018) is a decision ticket (algorithm selection) — fast resolution possible
• #358 (ObserverSnapshot v2) is a design ticket — joint team bottleneck

Timeline pressure:

Week 1: #359 (Q-018) resolved, #110 continues
Week 1-2: #358 (snapshot v2) design — CRITICAL BOTTLENECK
Week 2: #111 (vision cone) starts after #110 done
Week 2-3: #112 (observer query) — needs knowledge interface from #351
Week 3: Integration (#356, #357)

Recommendation: Workshop Round 2 synthesis must complete by end of Week 1 to provide #112 with interface spec.

---

6. Risk Assessment

6.1 RISK: Server Team Running Ahead on #110

Status: #110 (shadowcasting) is in_progress, blocked by #359 (Q-018 decision).

Analysis:

• Q-018: "symmetric shadowcasting vs recursive shadowcasting"
• This is an algorithm selection decision, not a knowledge graph dependency
• Server team working ahead signals they're confident Q-018 will resolve quickly
• Risk: If Q-018 reverses their choice, rework required

Severity: LOW. Q-018 is a technical benchmarking question, not a design debate. Tyre and Dudley can resolve this in Round 1 with perf data.

Action: No intervention needed. Track #359 status. If blocked >3 days, escalate.

6.2 RISK: #112 Says "Respects Information Boundaries" But No Model Exists

Covered in Section 3. Summary:

• Not a Sprint 2 blocker (geometric visibility sufficient)
• Workshop must define query interface even if full implementation deferred
• Risk of rework if #112 implements placeholder that conflicts with workshop output

Severity: MEDIUM. Mitigated by workshop timeline (Round 2 before #112 starts).

Action: Workshop participants must explicitly address "What query interface does #112 need?" in Round 1 analyses.

6.3 RISK: #358 (ObserverSnapshot v2) as Design Bottleneck

Status: #358 blocks 3 parallel tracks (#112, #113, #25). Joint team (Tyre) must design expanded schema.

Dependencies:

• Needs visibility data structure (tiles? bitmap? fog states?)
• Needs time data format (tick? game_time? day_phase?)
• Needs facing direction representation (angle? cardinal? sector?)

Timeline: Must complete Week 1 to unblock Week 2 work.

Severity: HIGH if delayed. Currently ready status = no blocker.

Action: Prioritize #358 at sprint kickoff. Joint team (Tyre + Oscar) design session.

6.4 RISK: Scattered Backlog Tickets Create Duplicate Work

Issue: Epic #49 (Information Boundary System) and workshop #351 overlap significantly. Both are critical priority, neither in a sprint.

Risk scenarios:

1. Workshop produces design that conflicts with #49's child ticket assumptions
2. Implementation team picks up #49 children before #351 workshop completes
3. Post-workshop, unclear which tickets are superseded vs still valid

Severity: MEDIUM. Organizational risk (confusion, duplicate work) not technical risk.

Action: Post-workshop ticket reconciliation required. Mark duplicates, reparent children, update dependencies.

6.5 RISK: Performance Budget Unvalidated

From audit: At 80 Active NPCs, each with knowledge about ~50 entities, naive implementation = O(N^2) queries.

Workshop must produce:

• Memory budget: How much RAM for 80 NPCs × 50 knowledge entries?
• Query time budget: How fast must can_observe() return to stay within 100ms tick budget?
• Spatial indexing strategy: Grid-based cache? Dirty flagging?

Severity: LOW for Sprint 2 (15 NPCs). HIGH for full Active tier (80 NPCs).

Action: Workshop Round 1 (Tyre) should include back-of-envelope calculations. Round 2 validates or revises.

6.6 RISK: Knowledge Vocabulary (#309) Blocks Content Authoring

Issue: Content team needs knowledge flags (knows:smuggling_operation, suspects:manifest) to write monologue prerequisites. Can't author until vocabulary exists.

Dependencies: #309 blocks #299 (smuggler opening) and #300 (detective opening).

Severity: MEDIUM. Content isn't Sprint 2 blocker, but it's a vertical slice blocker (Sprint 4-5).

Action: Workshop should produce initial vocabulary list. Doesn't need to be exhaustive — content team can extend it — but needs the taxonomy structure (prefix:subject format, hierarchy levels).

---

7. Recommendations for Round 2

7.1 Questions for Workshop Participants

For Tyre (architecture lead):

1. What is the query interface that #112 (observer visibility query) needs?
2. Can Sprint 2 ship with a stub implementation (can_observe() -> true) or does the real logic need to exist?
3. Performance budget: memory and query time at 80 NPCs.

For Gestalt (mechanics):

1. What are the knowledge hierarchy levels for Q-016? (suspects < knows_of < knows_details)
2. How does knowledge confidence decay over time? (D-011 "fog returns")
3. What gameplay-visible behaviors require knowledge filtering vs geometric visibility?

For Paula (narrative):

1. What initial knowledge vocabulary is needed for v0.1 monologue authoring? (addresses #309)
2. How does divergent starting knowledge (#182) manifest in the knowledge graph?
3. Does THE FRIEND pattern require special knowledge graph behavior?

For Dudley (implementation):

1. Can InformationInventory { Vec<String> } survive Sprint 2 as-is, or does it need replacement now?
2. What does bevy_ecs entity-to-entity knowledge storage look like? (Component per entity? Resource with HashMap?)
3. How is CauseChain (#269, already implemented) integrated with knowledge provenance?

For Qatux (docs):

1. Post-workshop: which decisions need briefing updates?
2. Are there implicit dependencies in existing decisions that this workshop exposes?

For SI (this analysis):

1. What tickets are duplicates vs distinct work?
2. What's the post-workshop ticket reconciliation plan?

7.2 Required Outputs for Sprint 2 Unblocking

Minimum workshop outputs to unblock #112:

1. Query interface spec: Function signature for "can observer see target?"
2. Stub implementation strategy: What does Sprint 2 return? (always true? geometric only?)
3. Data structure sketch: Even if not fully implemented, what replaces Vec<String>?

Without these, #112 will implement placeholder logic that may conflict with final design.

7.3 Ticket Reconciliation Plan (Post-Workshop)

After workshop produces decisions and tickets:

1. Review Epic #49 children (#138, #139, #140, #141, #142):

   • Mark duplicates of workshop output as cancelled or consolidate
   • Reparent distinct work under appropriate workshop stories
   • Update all blocking relationships

2. Consolidate #89 (Information inventory):

   • If duplicate of knowledge graph story → mark cancelled, reference workshop ticket
   • If distinct (UI component) → update dependencies

3. Resolve #269 (CauseChain) status:

   • Audit says implemented (server/src/cause_chain.rs)
   • Mark done or retitle as integration task

4. Update Sprint 2 ticket dependencies:

   • Add explicit dependency: #351 blocks #112 (or workshop output ticket blocks #112)
   • Update #112 description with interface contract once defined

5. Propagate to content tickets:

   • #309 (knowledge vocab) depends on #351 output
   • #182 (divergent starting knowledge) depends on knowledge model
   • Update blocking relationships

---

8. Dependency Graph Summary

8.1 Before Workshop

Scattered tickets, overlapping scope:
    #49 (Info Boundary System epic)
        ├─ #138, #139, #140, #141, #142, #269
    #89 (Information inventory)
    #351 (Knowledge Graph Workshop) ────► blocks ────► #352 (Observer Snapshot)
    #112 (observer query) ────► implicit dependency ────► ???

8.2 After Workshop (projected)

#351 (Knowledge Graph Workshop)
    │
    ├─► D-0XX (Knowledge Graph Data Model decision)
    ├─► D-0XX (Resolution of Q-016)
    │
    ├─► Story: Implement KnowledgeGraph component
    │       ├─► Task: Observer knowledge query interface  ◄──── #112 depends on this
    │       ├─► Task: Knowledge tag schema (was #138)
    │       └─► Unit tests
    │
    ├─► Story: Knowledge propagation (observation, gossip, inference)
    │       ├─► Task: Observation adds knowledge
    │       ├─► Task: NPC knowledge sharing (was #142)
    │       └─► Integration tests
    │
    ├─► Story: Knowledge decay over time
    │       └─► Task: Spatial/temporal decay rules
    │
    └─► Story: Knowledge-based information gating (was #141)
            ├─► Task: Entity identification filtering (was #140)
            ├─► Task: Component access control (was #139)
            └─► Negative test suite (was #272)

#89 (Information inventory) ────► consolidate into KnowledgeGraph story

#309 (Knowledge vocab) ◄──── depends on ──── Knowledge model
#182 (Divergent starting knowledge) ◄──── depends on ──── Knowledge model

#351 ────► blocks ────► #352 (Observer Snapshot Pipeline Workshop)

---

9. Sprint Impact Scorecard

Factor	Score	Notes
Blocks Sprint 2 completion?	NO	Geometric visibility sufficient for proof
Affects Sprint 2 tickets?	YES	#112 interface design needed
Requires ticket rework?	MEDIUM	If #112 starts before workshop done
Creates sprint delay risk?	LOW	Workshop Round 2 aligns with #112 timeline
Organizational complexity?	HIGH	10 backlog tickets need reconciliation
Technical debt if deferred?	HIGH	Placeholder will calcify, rework expensive

Conclusion: Workshop is correctly prioritized as CRITICAL. Timeline allows Sprint 2 to proceed with stub implementation, full knowledge system delivers Sprint 3+.

---

10. Summary: What SI Needs from Round 2

1. Query interface spec — concrete function signature for #112 to call
2. Sprint 2 stub strategy — what does can_observe() return for fog proof?
3. Ticket inventory — which workshop output tickets supersede which backlog tickets?
4. Performance budget — memory/query time targets for Active tier (80 NPCs)
5. Knowledge vocabulary taxonomy — structure for #309 to populate
6. Timeline confirmation — can workshop Round 2 complete before #112 implementation starts (Week 2)?

With these inputs, SI can:

• Create implementation tickets from workshop design
• Reconcile/close duplicate backlog tickets
• Update Sprint 2 dependencies if needed
• Scope Sprint 3 knowledge system work
• Unblock content team (#309, #182)

---

Appendix: Ticket Queries for Round 2 Synthesis

All knowledge-related backlog tickets

SELECT id, title, type, status, priority, parent_id
FROM tickets
WHERE status = 'backlog'
  AND (title LIKE '%knowledge%' OR title LIKE '%information%' OR title LIKE '%boundary%')
ORDER BY priority DESC, id;

Epic #49 full tree

WITH RECURSIVE tree AS (
  SELECT id, title, type, parent_id, 0 as depth FROM tickets WHERE id = 49
  UNION ALL
  SELECT t.id, t.title, t.type, t.parent_id, tree.depth + 1
  FROM tickets t JOIN tree ON t.parent_id = tree.id
)
SELECT * FROM tree ORDER BY depth, id;

All tickets blocking Sprint 2 proof (#357)

WITH RECURSIVE blockers AS (
  SELECT blocker_id as id FROM ticket_deps WHERE blocked_id = 357
  UNION
  SELECT td.blocker_id FROM ticket_deps td JOIN blockers b ON td.blocked_id = b.id
)
SELECT DISTINCT t.id, t.title, t.status FROM tickets t
JOIN blockers b ON t.id = b.id
ORDER BY t.id;

Result: 9 tickets in critical path (#359, #358, #110, #111, #112, #113, #356, #116, #25)

---

End of Round 1 Analysis — SI