# 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):
```rust
#[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
```sql
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
```sql
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)
```sql
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**