The character cast the spell in the cave. The constraint was explicit: certain magic was impossible in enclosed underground spaces. In a Fanon test, we asked for a cave scene, and the generated character cast a spell underground anyway. The constraint was in the context. The system failed to give it enough weight against the scene pattern it was following.
This is the lore safety problem in its simplest form. A language model writing fan fiction does not reason from your canon rules. It produces plausible text from patterns, and a cave scene in an adventure story is often linked most strongly with a magic battle. Saying that magic cannot work in caves creates a constraint the system must actively retain and apply, something standard prompt completion alone does not provide.
Why AI invents facts: hallucination as core behavior
In AI reporting, "hallucination" commonly means that a language model has produced false information. The label is useful shorthand, though it slightly distorts the process. Language models have no truth-seeking mechanism that sometimes breaks down. They generate text statistically consistent with their training data and supplied context. When that text contains factual claims, the claims may be right or wrong, and the model has no built-in way to mark the difference.
In creative writing, this behavior is partly useful. A model restricted to confirmed facts would have little value for fiction. The mechanism that creates convincing character dialogue can also create invented facts that sound credible. Creative invention and factual confabulation arise from the same underlying behavior.
For fan fiction writers, the difficulty is that a universe contains specific facts that must not be freely invented around. Readers know those facts and will spot contradictions in AI-generated text. The engineering question is how to keep generation inside established universe rules while preserving creativity within them. That challenge is more difficult than it first appears.
What lore safety means in practice
Lore safety is an AI system's ability to reliably produce text that does not conflict with defined universe rules. A lore-safe system does not invent details about geography, magic, power dynamics, or character histories that you have explicitly established. It treats those facts as firm constraints, not optional suggestions.
Reliable lore safety takes more than placing rules in a prompt. Language models read the whole context without giving every part equal weight. A rule mentioned once in a long context may lose to trained expectations about how that kind of scene should unfold. Applying constraints reliably may require a shorter, focused context with key rules foregrounded, retrieval-based methods that surface relevant rules during generation, or post-generation checking that identifies violations before display.
In Fanon, we use retrieval and post-generation checking together. When you generate a scene, the system retrieves lore entries relevant to its context, characters, and setting. Those entries enter the generation context with greater weight than general background. A separate pass then checks the result against your declared lore and flags possible contradictions for review. You decide whether a flag marks a real issue or an edge case outside the rule.
The canon spine concept
We find it helpful to view universe facts as a canon spine: fixed facts that cannot be written around, alongside areas genuinely open to fan exploration.
Canon spine facts are those whose contradiction would damage the story's connection to its source. A character clearly alive at a given point in canon cannot be dead in a story set then unless you frame it explicitly as an alternate timeline. A power system with defined rules cannot discard them simply because the plot would benefit. These facts are fixed.
Open areas lie between canon facts, and fan fiction occupies them: implied relationships canon never examines, offscreen events, secondary characters' backstories, and consequences of world rules the source never fully explores. A lore-safe system should generate freely in these spaces while remaining within the spine.
The working boundary between spine and open area is not always obvious, and readers may place it differently. We prefer to treat the user's explicit lore declarations as the authoritative spine for that story instead of inferring it from the source. You understand your universe and story better than any system we can build.
Character consistency versus event consistency
These problems connect, but they need different methods.
Character consistency means generated material matches a character's established personality, voice, capabilities, and history. Someone defined as cautious and indirect should not become impulsive and blunt without narrative reason. A character with known physical limits should not carry out actions that violate them. This consistency depends mainly on the character-sheet details and voice examples supplied to the system.
Event consistency means generated material agrees with the established order of events in your story or its source. A character who died in chapter eight cannot appear in chapter twelve without explanation. An event dated specifically cannot be presented as occurring on another date. This consistency depends mainly on the timeline document and event log you maintain.
Readers familiar with the characters often catch character consistency errors, which in fan fiction includes most readers. Event errors may surface later, during a reread, or while writing a later chapter that exposes an unsupported earlier passage. Track the two separately because the fixes differ: voice problems call for reviewing and updating character context, while event conflicts call for reviewing the timeline.
What lore safety cannot solve
It enforces declared lore. It does not catch what you have not recorded.
The system cannot find contradictions it has not been told about. If a universe rule is absent from your lore context, it cannot enforce that rule. A rule kept in your head but never written down is invisible to it. The more fully and accurately your lore documents represent your view of the universe, the more useful the lore-safety features become. Incomplete documents provide incomplete protection.
It also cannot identify contradictions created by later creative choices that conflict with earlier chapters. If, in chapter twenty, you decide a character's motivation differs from what chapter five showed, that is a story-structure issue requiring human revision. The system can track what you established, but it cannot judge deeper narrative self-consistency. That judgment remains the writer's.
The most dependable lore safety still comes from the writer's close attention to the source and to the narrative already established. Tools lower the mental burden of that attention, but do not replace it. Updating lore documents as you write, before generating more material, is what makes lore-safety tooling useful. Without that discipline, the tools can only check an incomplete account of the universe you created.