Decision: Mem0 Memory and Deterministic Combat Boundary
Lorewright will use Mem0 for campaign memory while keeping combat legality and resolution deterministic in engine code.
Decision: Mem0 Memory and Deterministic Combat Boundary
Context
The prototype goal is a persistent-memory Dungeon Master that can run a 5e SRD-based tabletop game. The current codebase already contains mem0ai in pyproject.toml, a placeholder DM orchestration shell in engine/dm/, deterministic SRD 2014 level-up logic in engine/srd_level_up/engine.py, and character persistence in engine/characters/store.py.
The system needs two different kinds of intelligence:
- Long-lived recall of campaign facts, world state, NPCs, quests, and prior session details.
- Rules-correct combat behavior that follows 5e mechanics and does not drift based on model prose.
Those concerns should not be collapsed into a single LLM prompt. Memory retrieval can be probabilistic and relevance-ranked, but combat legality, dice, resources, hit points, action economy, and conditions need deterministic ownership.
Decision
Lorewright will use Mem0 as the campaign/world memory solution for the prototype. Mem0 will own semantic memory storage and retrieval for campaign facts, NPC facts, locations, quests, session recaps, and other long-lived context.
Lorewright's app database will still persist campaign/session identity, raw turns, model responses, tool calls, combat state snapshots, and memory operation audit rows. This keeps the prototype recoverable and inspectable even when Mem0 is the primary memory retrieval layer.
Combat will be implemented as a deterministic engine subsystem based on 5e SRD rules. The LLM may choose or propose NPC moves, but only through a structured output contract. The deterministic combat engine validates proposed moves against current combat state and rules, rejects illegal proposals, rolls or accepts dice through an engine-owned dice interface, applies HP/resource/condition changes, and emits an audit record.
The LLM must not be the source of truth for:
- Whether an action is legal.
- Whether an attack hits.
- How much damage is applied.
- Whether a spell slot or limited-use feature is available.
- Whether concentration, conditions, death saves, or initiative order change.
- What the canonical combat state becomes after a move.
The model's combat role is tactical and narrative: choose an NPC's intent, select from available legal options, explain behavior in character, and produce structured move requests for the engine to validate and resolve.
Consequences
This creates three explicit boundaries:
- Memory boundary: Mem0 retrieves relevant long-lived campaign context. App-db stores audit/history and can replay what happened.
- Rules boundary: deterministic engine code owns 5e mechanics, including combat state transitions.
- Model boundary: the LLM proposes structured actions and narrative framing, but does not mutate canonical game state directly.
The prototype backlog must prioritize a Mem0 adapter, memory namespaces, and memory audit rows before custom memory retrieval heuristics. The earlier deterministic text-match memory task is superseded by Mem0-backed retrieval, though local search may still be useful for audit/history views.
The combat backlog must be split into a rules resolver and an NPC move proposal contract. GRPO combat data remains useful later for improving NPC action choice quality, but it should train or evaluate the model's proposal behavior, not replace deterministic rules resolution.