Drop a language model into your game and it will, sooner or later, tell a player that the king is alive three scenes after you killed him. Large language models are fluent, not faithful. They generate what sounds right, not what is true in your world, and left unchecked they will contradict your lore, break character, and invent canon that was never yours.
The fix is not a better model. It is a validation layer between the model and the game: a gate that checks every generated decision against your rules and refuses anything that violates them. This article explains why the problem happens, the patterns that solve it, and how to put one in place, whether you build it or buy it.
Why AI breaks lore
Three facts about language models explain most of the trouble:
- They predict plausible text, not canonical fact. Plausible and correct are not the same thing, and the model optimizes for the first.
- Context is finite. The model only knows what you fed it this turn. Anything outside that window, it guesses.
- Fluency hides error. The output reads confidently even when it is wrong, so mistakes ship.
That produces four failure modes:
- Contradiction: it states something that conflicts with established facts (the dead king speaks).
- Out of character: the shy scholar suddenly threatens violence.
- Rule-breaking: it grants an item, opens a locked door, or changes a stat it was never allowed to touch.
- Invented canon: it introduces a god, a war, or a faction that does not exist in your world.
The patterns that fix it
Four layers, strongest when combined:
- Retrieval grounding. Before the model answers, fetch the facts that apply (this NPC's memory, the current world state, the relevant rules) and put them in the prompt. The model can only stay consistent with what it can see.
- Constrained output. Do not ask for free prose. Ask for structured output: typed fields, enumerated actions, values inside allowed ranges. A model that can only choose from valid moves cannot make an invalid one.
- Validation and rejection. After the model responds, check the output against your rules. If it violates a constraint, reject it and retry, or fall back to a safe default. Nothing reaches the game until it passes.
- Scoped authority. Decide, per field, what the model may change and what is immutable. Personality is locked; mood can shift. A quest can advance; a completed quest cannot un-complete.
The principle underneath all four: the model proposes, your rules dispose. The AI is a source of suggestions, never the final authority.
How constraint validation works in practice
Concretely, you describe your game state as parameters, each with a type, a range, and a mutability flag. The model returns a proposed change, and a validator checks it before anything happens:
- Is this field allowed to change at all?
- Is the new value the right type and inside the allowed range?
- Does it satisfy the conditions you set, such as "this can only happen if the player has the key"?
If any check fails, the change is rejected before it touches the game. The player never sees the broken output, because it never becomes real. This is exactly how LoreWeaver Director operates: every decision it generates is validated against the constraints you define in Architect, and invalid decisions are rejected and retried. The pattern is general, though, and you can build it yourself.
Build or buy
If you are running your own local or cloud model, you will build this layer yourself: define the schema, write the validator, wire up retrieval, and maintain it as your world grows. It is very doable, and it is the most important part of the system, so budget for it. Our guide to running a local LLM for game NPCs covers the surrounding stack.
If you would rather not, a runtime that ships with validation built in does this for you. LoreWeaver Director is one, it runs on-device, and it is in beta today. Either way, the rule stands: never let a raw model output reach your game unchecked.
FAQ
Why does AI contradict my game's story? Because a language model generates plausible text from the context it was given, not verified facts. If a fact is outside its context window, it guesses, and a fluent guess reads like truth.
Can you stop an LLM from hallucinating in a game? You cannot make a model perfect, but you can make its mistakes harmless. A validation layer checks every output against your rules and rejects anything invalid before it reaches the player, so a hallucination never becomes canon.
What is constrained generation? Asking the model for structured output within fixed options, such as typed fields, enumerated actions, and allowed ranges, rather than free text. It shrinks the space of possible errors to near zero.
Do I need a validation layer with a small local model? Yes, and arguably more so. Model size does not remove the failure modes; validation does. The layer matters regardless of where the model runs.
Does constraint validation slow the game down? The check is cheap compared to generation. It runs after the model responds and before the game applies the result, and it can fall back to a safe default if a retry would take too long.
The short version
AI-driven narrative is only as good as the guardrails around it. Build the validation layer, or use a runtime that already has one. Director validates every decision on-device against the rules you set in Architect, which is free to try. The model proposes; your rules decide.