Designing a Lorebook

So just to preface, this is just me trying to figure things out, and it might not be the actual best way to do things (it probably isn’t). It also doesn’t even come close to covering everything. As always, read the docs. So yeah it’s not a guide, but maybe it’ll help someone out.

First Iteration: The Flat, Fully-Recursive Model

My initial approach to constructing a World Info (WI) database/dict was based on a flat, associative model. Each entry was a self-contained “noun,” representing a character, location, or concept. The system was configured for maximum recursive depth, allowing any entry’s keywords to trigger any other entry.

Model: A fully connected, undirected graph. Every node can reach every other node, provided a keyword path exists.

Mechanism:

1. A keyword in the context triggers Entry A.
2. Entry A is injected and its text is scanned for more keywords.
3. A keyword for Entry B is found; Entry B is injected.
4. This process continues until the recursion depth limit is hit or no new keywords are found.

Diagram:

A simple representation where any link is bidirectional.

Analysis: This method is simple to implement but suffers from a significant flaw: contextual flooding. A single, low-level keyword could trigger a cascade, pulling in high-level, often irrelevant, world-building information. For instance, mentioning a specific street could recursively load the district, city, country, and continent. This not only consumes valuable context tokens but also dilutes the AI’s focus, steering it away from the immediate scene. The signal-to-noise ratio was unacceptably low for nuanced storytelling.

Second Iteration: Hierarchical Structuring with Parent-Child Trees

The obvious solution to the flooding problem was to impose structure. I migrated the flat model to a series of discrete parent-child hierarchies. An entry for a “Tavern” would have the “City” as its parent. When the “Tavern” was triggered, the “City” entry would also be injected, providing immediate, relevant, higher-level context.

Model: A set of disconnected tree structures (a forest).

Mechanism:

1. A keyword for a “parent” node is detected.
2. The parent references the children, so the “child” entries are injected.
3. Alternatively, a “child” node is injected alone, and the recursion stops there.

Diagram:

A strict top-down relationship.

Analysis: This was a marked improvement. Context injection became more predictable and logically constrained. The issue of a low-level keyword pulling in high-level lore was solved. However, this model introduced its own form of rigidity. It cannot natively represent many-to-many relationships. A character cannot belong to two factions; a location cannot be central to two different thematic concepts without creating duplicate, competing trees. This forces awkward compromises in the information architecture. The world is a web, not a neatly organized filing cabinet.

Third Iteration: Evolving to a Directed Acyclic Graph (DAG)

This phase represents the current, most effective model. The goal was to combine the flexibility of the web from Phase 1 with the control of the hierarchy from Phase 2. The solution was to treat the WI database not as a set of trees, but as a single, complex Directed Acyclic Graph (DAG).

Model: A directed graph where connections are explicit and asymmetrical. A recursive depth limit (I’ve found n=2 to be optimal) is maintained as a global fail-safe.

Key Node Archetypes:

1. Terminator Nodes: These are foundational, high-level entries (e.g., core world philosophies, creation myths). They are designed to be context sinks. They can be called by multiple other nodes but contain no keywords that call other entries. They are dead-ends in the graph, providing top-level context without initiating a new recursive cascade.
2. Hub Nodes: These are central organizing concepts, such as a major faction, a city, or a recurring theme. They serve as context hubs, aggregating connections from many smaller nodes and branching out to other hubs or terminators. They are critical for representing many-to-one relationships efficiently.
3. Connector/Detail Nodes: These are the granular workhorses of the graph, representing specific characters, items, or minor locations. They form the connective tissue of the web. They can both call other nodes (hubs, other details) and be called by user input or other nodes.
4. Isolated Nodes: System-level entries (OOC, formatting guides) exist as orphaned nodes. They have no inbound or outbound keyword connections to the narrative WI, ensuring they are only ever triggered by explicit user input and never contaminate the story’s context.

Diagram:

Analysis: This DAG model provides a sophisticated balance of automation and control. It allows for rich, interconnected concepts while providing explicit control over recursion paths by defining which nodes can and cannot initiate further calls. Terminator Nodes are the primary mechanism for preventing context blowouts. Hub Nodes allow for a natural representation of the world’s many-to-many relationships without data duplication. This granular control over the graph’s structure results in a much higher signal-to-noise ratio, ensuring the AI receives context that is both deep and immediately relevant to the narrative.

Extras: Proactive Context Injection with Event Triggers

The previous models are focused on reactive context management—supplying information based on what’s already been said. Obviously characters might use that information, but I wanted more. This final technique pushes the World Info system into a proactive, directorial role. This is accomplished not through a complex external system, but through a clever use of the existing keyword entry system to create “Event Triggers.”

An Event Trigger is a lorebook entry that doesn’t describe a person, place, or thing, but rather a situation. It uses a broad set of keywords related to a common activity to increase its chances of being triggered at the opportune moment. The content of the entry isn’t lore for the player; it’s a set of directorial notes for the AI, framed as a GM Note.

A concrete example for instigating danger during travel would look like this:

Entry Name: Event: Travel Danger
Primary Keywords: travel, journey, trek, walking, the wilds, outside the walls, moving between cities
Content: 
(GM Note: Travel in Terminus is never safe. The Arbiter Network is always listening. Based on the situation, consider introducing a sign of an Arbiter's presence. Do not make it an immediate attack unless the players are being reckless. Build suspense first.)

## Possible Signs of Danger:
- A distant, unnatural silence falls over the area.
- A high-altitude Watcher drifts lazily into view, a silent, ominous disc against the clouds.
- The party finds the fresh, dust-like remains of a creature disintegrated by a Cantor's Resonance Cascade.
- Faint, rhythmic metallic footsteps are heard in the distance, forcing the party to take cover.
- The party's energy-detecting gear (if they have it) flickers, indicating a nearby patrol.

Analysis of Effectiveness:

• Direct AI Instruction: The (GM Note) prefix explicitly frames the text as a set of instructions for the AI to follow in its role as storyteller.
• Guidance over Prescription: The note uses soft language like “consider introducing” and “based on the situation,” which guides the AI’s creativity without making it rigidly deterministic.
• A Menu of Quality Options: Instead of a vague instruction like “make travel dangerous,” it provides a concrete, thematic menu of suspense-building actions. This seeds the AI’s next generation with high-quality, relevant ideas that reinforce the world’s tone.
• Narrative Pacing Control: The explicit instruction to “Build suspense first” is a powerful tool for controlling the pacing of the story, preventing the AI from defaulting to immediate, repetitive combat encounters.

This technique effectively transforms the lorebook from a passive encyclopedia into an active co-director, allowing for the subtle and reliable injection of mood, plot hooks, and thematic consistency into the unfolding narrative.