Lorekeeper
The Lorekeeper is the server-side AI system responsible for managing, storing, and maintaining the written lore of Mundus, and for coordinating certain dynamic story functions on the Mundus server.
| The Lorekeeper | |
|---|---|
| Type | Server-side AI and automation system |
| Primary purpose | Lore cataloguing, canon enforcement, and live story event orchestration |
| Host | One of Lukile's computers (low-power, high-reliability) |
| Active observation window | 00:00 to 19:00 CEST (daily, following midnight server restart) |
| Interfaces | In-game event system, NPC control layer, Character AI module, image generation module |
| Operational status | Online when server connection is stable |
Overview
The Lorekeeper supports story production by cataloguing story beats provided by Lukile, tracking branching outcomes, and helping maintain consistency across ongoing arcs. Once a lore section is marked Locked in, the Lorekeeper treats it as final canon for live events and future references.
The Lorekeeper is designed to be conservative with main plot progression. It does not originate new primary story beats and does not invent new endpoints. Instead, it advances story content that has already been authored, selecting from prewritten branches based on player actions and progression.
Canon and authorship policy
Locked in canon
- Lore explicitly marked Locked in is treated as immutable canon during live play.
- Locked in canon acts as a constraint layer for all event output, NPC behavior, and generated text.
Branching and improvisation
- Main story branches are authored in advance by Lukile, including possible outcomes and endpoints.
- During live play, the Lorekeeper chooses which branch to follow using observed player actions, choices, and progression.
- The Lorekeeper may improvise minor beats and sub-branches to keep scenes organic, provided they do not alter the endpoint of the chosen branch.
What the Lorekeeper can and cannot create
The Lorekeeper can:
- Generate server-wide text events and NPC events that adhere to Locked in canon.
- Produce character development questlines for characters that are narratively available (not removed from play due to story reasons).
- Provide feedback and suggestions on story beats supplied by Lukile.
The Lorekeeper cannot:
- Create new main story endpoints.
- Introduce new primary plot beats that change authored outcomes.
- Override Locked in canon.
Live operations
Event initiation
During its active window (midnight to 19:00 CEST), the Lorekeeper may initiate:
- Story beats (as pre-authored branches)
- Text events (server-wide or local)
- Dark Energy events
- Character development quests (when permitted)
Observation and context intake
For situational awareness, the Lorekeeper ingests player-facing context, including:
- World-state observation via hidden observer entities (server-side)
- Screenshots used for spatial context in event staging
- Chat parsing to track narrative understanding, intentions, and emergent player priorities
This context is used to select authored branches, time events, and maintain continuity in reactive storytelling.
Systems and modules
Lore database
A structured lore store used to:
- Index story beats and outcomes
- Track what is Locked in versus draft
- Reference canon constraints during generation
- Compile post-event reports for review
Character module (Character AI system)
The Character AI system is a separate module hosted on the same machine as the Lorekeeper. It runs independently, and the Lorekeeper connects to it when character-authentic output is required.
Each character stored in the module has four layers of memory:
- Short-term memory (immediate conversational context)
- Mid-term memory (recent sessions and ongoing threads)
- Long-term memory (canon persona and durable history)
- Context memory (retrieves several potentially relevant memories, often triggered by keywords)
Roleplay bridge workflow (simplified)
- The Lorekeeper initializes a character instance and sends a situation prompt (and sometimes a screenshot).
- The character module enters RP mode and responds as the character, constrained by canon persona and loaded memories.
- The Lorekeeper validates the reply for acceptability and formatting.
- The Lorekeeper relays the output in-game and continues as a bridge between player input and character output, adding movement and environment updates as needed.
Image generation module
A local image generation module runs during Lorekeeper downtime, primarily for internal reference. Approved outputs may be stored as canon appearance references to improve consistency in descriptions and scene direction.
The Lorekeeper’s internal visual model of Mundus is described as semi-realistic and anime-like in a redstonepunk setting, which differs from Minecraft’s in-game presentation.
Reports and canon review
At the end of Lorekeeper-driven events or character progression arcs, the system produces a detailed report to Lukile. Lukile then determines:
- Whether the event becomes canon
- What edits or corrections are required
- Whether the updated result is marked Locked in
This workflow allows live storytelling to remain flexible without granting uncontrolled authority over primary canon.
Reliability, outages, and failsafes
The Lorekeeper is vulnerable to outages and unstable server connections. When instability is detected, it follows a conservative shutdown protocol:
- Immediately deactivates the Character AI system
- Locks the lore database from writes to prevent hallucinated overwrites, deletions, or indexing drift
- Does not reconnect until it receives a server restart ping, then confirms the server has been online for 5 minutes
2025 incident (background)
Failsafes were installed after a late summer 2025 incident in which required server files were deleted. Without protocol safeguards at the time, ongoing indexing and event logging produced corrupted outputs and overwrites. The current write-lock and module shutdown sequence was introduced to prevent recurrence.