Building a Lore Bible for LLMs: Canon Rules, Style, and Consistency

A “lore bible” is the single source of truth your model should follow. For LLM-driven writing (NPC dialogue, quest logs, recaps, patch notes), the lore bible isn’t just worldbuilding—it’s a constraint system: what’s true, what’s allowed to change, and how the voice should sound.

What a lore bible must do for an LLM

• Define canon: facts that cannot be contradicted (timeline, geography, factions, names).
• Define style: tone, register, taboo phrases, and formatting conventions.
• Define authority: what to do when sources conflict (hierarchy + tie-break rules).
• Define change: what can evolve (seasonal events, league results) and how updates are recorded.

1) Canon rules: the “physics engine” of your setting

Write canon rules as explicit, testable statements. Avoid paragraphs of lore that bury constraints. Prefer short rules with unique IDs so you can cite them in prompts, evaluations, and bug reports.

2) A compact schema beats a beautiful document

LLMs are sensitive to context size and retrieval quality. Instead of one huge PDF, store lore as structured entries (YAML/JSON/Markdown with frontmatter) so you can retrieve only what’s relevant.

{
  "entity": "Faction",
  "id": "faction-amber-cabinet",
  "names": ["Amber Cabinet"],
  "summary": "Merchant-arbiters who control canal tolls.",
  "canon": {
    "founded_year": 812,
    "colors": ["amber", "ink"],
    "oath": "Contracts outrank favors."
  },
  "constraints": [
    {"rule_id": "R-FAC-001", "text": "Cabinet members never reveal prices in public."}
  ],
  "voice_notes": "Formal, ledger metaphors, no slang."
}

3) Style guide: make “good output” measurable

A style section should be short, specific, and include “do/don’t” examples. Useful dimensions:

• Narrative distance (close/neutral/omniscient) and tense.
• Lexicon: approved terms, forbidden terms, spelling rules, naming patterns.
• Formatting: headings, bullets, stat blocks, recap templates.
• Safety/ratings: content limits and how to fade-to-black.

Tip: treat style drift like a bug. If you can’t write a failing test for it (or a reviewer can’t point to a rule), it’s not a rule yet.

4) Consistency workflows: prevention, detection, correction

1. Prevention: retrieval-first prompting (only the needed entries) and “cite rule IDs” instructions.
2. Detection: automated checks for names, dates, ranks, and forbidden phrases.
3. Correction: write a new rule or patch the entry; don’t “handwave” in the prompt forever.

5) Prompt packaging: keep the contract readable

When you inject lore, separate it into: facts (retrieved entries), rules (constraints), and task (what to write). This reduces accidental blending and makes failures explainable.

6) Keep it alive: versioning and change logs

Canon evolves—especially for league recaps, seasonal events, and recurring meetups. Add a change log and require a “why” note for each update. If you publish articles, align the lore bible’s version to the content you produced so you can reproduce outputs later.

A quick checklist before you ship

• Every major entity has an ID, canonical name(s), and disallowed variants.
• Every constraint is a one-liner with a rule ID.
• Conflicts have a source hierarchy (e.g., “published recaps > notes > drafts”).
• Your prompts require rule citations for sensitive facts.
• You can run a small test set (10–30 prompts) and record failures as rule/entry issues.

If you’re also refining your prompt structure, pair this with Prompt Engineering for Game Worlds: Writing Prompts That Stay In-Lore and Reducing Hallucinations in Game Content: Guardrails, RAG, and Validation.