Lorekeeper
Every fiction project with a worldbuilding database eventually hits the same problem. You’ve been writing for months. The Legendry has grown. Your prose has grown. And the two have quietly stopped matching each other in places you can’t quite remember. Maybe a character’s eye color drifted between chapters four and eight. Maybe a city’s founding date is inconsistent across two mentions. Maybe you gave a faction a leader in the Legendry and then in a scene you wrote “nobody had ever led them.” These are the kind of contradictions that haunt the revision pass — the ones a careful beta reader will catch and flag as “wait, what?” — and the only way to catch them yourself is to hold the entire project in your head at once, which nobody can do.
The Lorekeeper is the agent that holds the whole project for you. You hand him a document; he reads it against your Legendry; he flags every place where the two don’t match. The output is a scored consistency report with a list of issues, each with a severity level, a location, and a suggested fix. The agent catches the kind of exhaustive contradictions only a computer can check for, which means the real editor you eventually hire spends their time on things the agent can’t see.
How a check runs
Section titled “How a check runs”You open a document (or a lore entry — the Lorekeeper can check either), open the Lorekeeper panel, pick a depth level, click Run Check. The analysis starts, and it streams back to you as it works. You don’t wait for a final result in silence — you watch the panel fill in with progress messages, entity chips, and issues as the agent finds them. You can cancel any time.
Under the hood, the agent does four things in sequence. It loads the lore entries relevant to the document. It extracts entities from the document’s text. It cross-references the detected entities against the lore database. Then it sends the text, the entities, and the lore context to the LLM, which produces the actual consistency analysis. The streaming comes from each of those stages publishing intermediate results as they complete.
Analysis depth
Section titled “Analysis depth”Four levels, each trading speed for thoroughness:
- Minor. Quick scan. Catches obvious contradictions — wrong name, wrong age, wrong faction affiliation. Fast, cheap, useful for in-progress drafts where you just want a sanity check.
- Moderate. The default. Standard analysis. Catches most real issues including some subtle ones. Use this for a chapter review after you’ve finished drafting it.
- Strict. Thorough check. Catches more subtle inconsistencies — narrative drift, implied contradictions, chronology issues. Slower, more expensive in tokens.
- Deep. Comprehensive analysis. The most thorough option, and the slowest. Use this for pre-submission passes on chapters that have to be tight.
Pick the depth based on what the check is for. A mid-draft sanity check is Minor. A post-chapter review is Moderate. A pre-submission pass is Strict or Deep. Running Deep on every chapter would be overkill — and expensive — but running Minor on a chapter you’re about to submit would miss too much.
Cross-reference mode
Section titled “Cross-reference mode”A toggle that expands the check to compare entity references across multiple documents, not just within the current one. When it’s off, the check only looks at the document in your hand. When it’s on, the check also pulls in every other document in your project that references the same entities and checks consistency across all of them.
Cross-reference mode is slower — it has to load more context — but it’s the only way to catch contradictions between chapters. A character described one way in chapter three and a different way in chapter eight is invisible to a per-chapter check. Turn on cross-reference to catch it.
What the results look like
Section titled “What the results look like”Every issue the Lorekeeper surfaces has a consistent shape:
- Category. What kind of entity or concept the issue is about — character, location, event, faction, item, concept.
- Severity. Critical, major, moderate, or minor. Critical and major issues are hard contradictions that need attention; moderate and minor are softer and sometimes intentional.
- Description. The agent’s explanation of what’s wrong.
- Location. A pointer to where in the document the issue was found — paragraph and character offset, so you can jump straight to the text.
- Affected entities. Which Legendry entries are involved.
- Suggestion. A proposed fix from the agent.
- Confidence. How sure the agent is. High confidence means the contradiction is clear; low confidence means the agent is flagging something that might or might not be a problem.
The panel displays issues sorted by severity, with critical and major at the top. Right-click any issue for actions: mark acknowledged, mark resolved, mark false positive, jump to the location in the editor, or view the affected entities in the Legendry.
Consistency score
Section titled “Consistency score”Every check produces a consistency score from 0 to 100. The score starts at 100 and subtracts points for each issue — 15 per critical or major, 5 per moderate or minor. A document with zero issues gets 100. A document with two critical issues gets 70. A document with one critical and three moderate gets 70 as well.
The score sorts into three bands:
- Good (80-100). Few or no issues detected. The document is probably fine as-is.
- Moderate (60-79). Some issues need attention. The document is usable but has real problems.
- Poor (0-59). Significant consistency problems. Don’t ship until you’ve worked through the issues.
The score is a rough diagnostic, not a grade. Don’t take it too seriously — one chapter with two critical false positives will look “poor” even though it’s actually clean. Use the score as a first-pass indicator and the full issue list as the authoritative output.
Issue lifecycle
Section titled “Issue lifecycle”Every issue has a four-state lifecycle that persists across runs:
- Open — newly detected, unreviewed. The default for any new issue.
- Acknowledged — you’ve seen it and are aware, but haven’t fixed it yet. Useful when you’re doing a review pass and want to come back to specific issues later.
- Resolved — you’ve fixed the source. The issue is closed.
- False positive — the agent was wrong. The prose is actually consistent, the agent misread something.
The states persist. Next time you run a check on the same document, previously-resolved and previously-false-positive issues don’t re-surface. You don’t have to re-triage the same list every time. This is the thing that makes the Lorekeeper practical for real workflows — a consistency checker that forgets what you already reviewed would be miserable to use.
Open issues dashboard
Section titled “Open issues dashboard”A project-wide view showing every open issue across every document in your project, sorted by severity. Critical open issues are displayed prominently. Issues you’ve resolved or marked false positive drop out of the view automatically.
This is where you go when you want to see the health of your whole project at once. “How many unresolved contradictions do I have across this book?” — the dashboard tells you. It’s the equivalent of the Desktop Attention Queue but specifically for lore issues rather than general project state.
Check history
Section titled “Check history”Every check is saved with its timestamp, score, issue list, and the full state of the document at the time of the check. You can scroll back through previous checks, click any of them, and see the exact results as they were when you ran them. Useful when you want to compare before-and-after after doing revision work — “I ran a Deep check last week, I just did an editing pass, let me re-run and see what’s different.”
File monitoring
Section titled “File monitoring”The Lorekeeper can watch a directory (usually your data/documents folder) for file changes and automatically trigger a re-analysis when a monitored file changes. Toggle monitoring from the panel with a status indicator. When monitoring is on, any save to a monitored document kicks off a background consistency check and updates the stale state.
Most authors leave this off and run checks manually. The monitoring feature exists for workflows where you want real-time feedback as you write — type a sentence that contradicts the Legendry, see the Lorekeeper flag it a few seconds later. It’s more expensive (more LLM tokens) and it can be distracting, but it catches issues at the moment you write them instead of at the end.
Staleness detection
Section titled “Staleness detection”The Lorekeeper tracks whether the last check is stale relative to the current state of the document. If you run a check, then edit the document, then look at the panel again, the “Run Check” button changes to “Re-check” and the previous results are marked stale. You can still see the stale results, but the UI is telling you they no longer reflect the current text.
Staleness is computed from whether the document’s content has changed since the last check. A whitespace change doesn’t trigger staleness; a paragraph edit does. The idea is that the panel should never show you outdated issues as if they were current.
Entity extraction side benefit
Section titled “Entity extraction side benefit”As the Lorekeeper runs a check, it extracts every entity mentioned in the text and tags each one as either “lore” (found in your Legendry) or “new” (not yet in the database). The extraction shows up as entity chips in the panel during the streaming phase.
This is a side benefit of how the check works, but it’s genuinely useful. Running a Lorekeeper check on a chapter also tells you every entity you mentioned but never added to the Legendry — which is exactly the kind of gap the Legendry is designed to catch. Click any “new” chip and you can create a stub entry for that entity on the spot.
What the Lorekeeper is not
Section titled “What the Lorekeeper is not”A few deliberate limits:
- He’s not a grammar checker. The Lorekeeper cares about canonical consistency, not grammatical correctness. Bad grammar doesn’t show up in his reports. For grammar work, use Hawken’s style analysis or ProseGuard.
- He’s not a fact-checker. If your prose says something that’s wrong about the real world (“the character loaded 20 rounds into the revolver”), the Lorekeeper doesn’t catch it — that’s WorldKnowledge’s job. The Lorekeeper only checks against your own Legendry.
- He’s not a story critic. If a scene is paced badly or a character motivation doesn’t make sense, the Lorekeeper doesn’t care. He only checks facts, not craft. For craft-level critique, use Hawken’s developmental edit passes.
- He’s not a real-time annotation layer. The Lorekeeper runs explicit checks on explicit documents. There’s no continuous background analysis that highlights problems as you type (except via the optional file monitoring feature, which is more of a periodic re-check than a real-time layer).