chore(meta): Sprint 17 planning — briefings, workshop brief, close Q-025
- Write sprint 17 briefings for server, client, copy, visual, joint - Add Knowledge Flow & NPC Boundaries workshop brief - Close Q-025 (KG cap/eviction not needed at current scale) - Assign 9 tickets to Sprint 17: Tell Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
@@ -139,11 +139,10 @@ Tracked questions awaiting discussion or resolution.
|
||||
- **Source:** Knowledge Graph & Information Boundaries Workshop (Gestalt Round 1)
|
||||
|
||||
### Q-025: Knowledge graph cap and eviction strategy
|
||||
- **Status:** Open
|
||||
- **Question:** At what point does an NPC's knowledge graph need entry eviction? What is the eviction policy? Options: MAX_ENTITY_KNOWLEDGE constant (e.g., 100 entities), LRU by `last_observed_tick`, lowest confidence first, hybrid approach. How are evicted entries handled — complete removal, or archival to "forgotten" state that can be refreshed?
|
||||
- **Context:** Memory budget analysis shows ~14 KB per NPC with 50 entities + 20 facts. At 80 Active NPCs this is ~1.1 MB, well within budget. However, long-running sessions or NPCs with high interaction rates could accumulate entries. Eviction policy affects gameplay: forgetting low-confidence rumors creates natural information decay; forgetting old observations simulates memory limits.
|
||||
- **Assigned to:** Tyre, Dudley
|
||||
- **Source:** Knowledge Graph & Information Boundaries Workshop (Dudley Round 1, section 8.3)
|
||||
- **Status:** Resolved — not needed for v0.1/v0.2. Revisit if gossip propagation (Q-024) causes unbounded growth.
|
||||
- **Question:** At what point does an NPC's knowledge graph need entry eviction? What is the eviction policy?
|
||||
- **Resolution (2026-02-23):** The v0.1 Gauntlet has ~16 NPCs. At worst case (every NPC knows every other NPC + 50 facts), total KG memory is ~30 KB. The D-041 workshop estimate of ~1.1 MB for 80 Active NPCs still holds. `ToldBy` source (the only mechanism that could cause unbounded growth via gossip chains) is not yet implemented — NPC-to-NPC knowledge transfer does not exist. The existing decay system (`decay_knowledge` in `knowledge/events.rs`) downgrades confidence and marks entries `Stale` but does not remove them, which is correct behavior (preserves "I used to know X" for narrative). No cap or eviction is needed at current or projected v0.1 scale. If gossip propagation ships (Q-024) and causes growth concerns, the simplest eviction policy is: on each decay pass, if `entities.len() > MAX_ENTITIES`, remove `Stale` entries with lowest `last_updated_tick`. The BTreeMap makes this a clean O(N) scan.
|
||||
- **Source:** Knowledge Graph & Information Boundaries Workshop (Dudley Round 1, section 8.3). Closed by architecture audit 2026-02-23.
|
||||
|
||||
### Q-026: Contradiction detection algorithm
|
||||
- **Status:** Open
|
||||
|
||||
Reference in New Issue
Block a user