AI Continuity Checking: How It Actually Works

An AI continuity checker works by giving the model two things at the same time: a structured record of what’s true in your story, and the prose to check it against. That pairing is the whole trick. It converts an open-ended “read my book and find problems” request, which language models are unreliable at, into a bounded “here are the facts, here is the text, show me where they disagree” task, which they’re good at. Here’s what’s actually happening under the hood.

The naive version, and why it underdelivers

Paste your manuscript into a general chatbot, ask for continuity errors, and you’ll get a confident list that’s part real and part invented. The reason is simple: the chatbot has no source of truth. It’s comparing your book to its own fuzzy memory of your book, formed as it read. Across a long manuscript that memory blurs, so it misremembers details, hedges with vague notes, and flags your unreliable narrator’s deliberate contradiction as a mistake. (We covered exactly where this holds and where it fails in can AI catch plot holes and continuity errors?)

A real continuity checker removes the guessing by supplying the source of truth explicitly. That takes a few pieces.

Step 1: a structured world model, not prose notes

The foundation is a machine-readable record of your world, not a folder of description. Instead of a paragraph about Elena, you have structured facts:

• Entities: every character, location, object, faction, and rule.
• Attributes: short factual pairs (eyes: grey, status: alive, allegiance: Ironhold).
• Relationships: Elena serves the Order, the Relic is held in the Citadel.

Structure matters because a fact buried in a prose paragraph is invisible to a checker, while a fact stored as a value is something it can test. This is the same world-graph idea behind the manual continuity system, made explicit enough for software to use.

Step 2: linking facts to the manuscript

A world model floating beside the text isn’t enough; the checker needs to know where each fact could be contradicted. That means connecting entities to the places they appear in the prose. In practice this is done with mentions: tagging where a character or object shows up, so the system can map each entity to its chapters.

The payoff is that checking becomes bounded. Instead of “reread the whole book for Elena problems,” the checker looks only at the chapters Elena actually appears in. It also lets the output point at a specific sentence rather than a general worry.

Step 3: state over story time

The upgrade that separates a real checker from a fact sheet is tracking when facts change. A static record can say Elena is alive; it can’t say she’s alive until chapter 12. So the system records change points against story time: status: alive to dead (chapter 12).

This needs a story-time index, a numbering of scenes by when they happen in the story rather than where they sit in the manuscript, so flashbacks and non-linear structures don’t fool it. With state over time in place, “Elena speaks in chapter 15” is checkably wrong while “Elena speaks in chapter 9” is correctly fine. That single capability is what lets a checker catch the state and timeline errors most tools miss entirely.

Step 4: the scan, world and prose sent together

Now the actual check. For a given chapter (or the whole manuscript), the system sends the model both the relevant slice of the world model and the prose, in one request, with a clear instruction: find the places where the text contradicts the recorded facts.

Two things make this reliable where the naive approach isn’t:

• It’s a checking task, not a judgment task. The model isn’t asked to remember or infer what’s true; it’s told, and asked only to compare. Comparison against given facts is squarely in what these models do well.
• The output is anchored. Each flag points at a specific sentence and the specific recorded fact it contradicts, so you can verify it in seconds instead of taking the model’s word for it.

Why this beats “just paste it in”

Everything above exists to fix one weakness: a general chatbot has to guess what your story’s facts are, and it guesses worse the longer the book. By supplying the facts, linking them to the text, and stamping them with story time, a purpose-built checker turns a vibes-based read into a mechanical cross-reference. False positives still happen (treat every flag as a question, not a verdict), and intentional contradictions like a lying narrator will get flagged correctly, so a good tool lets you mark those as known so they stop resurfacing.

What it still can’t do

Being honest about the ceiling: this approach catches contradictions of recorded fact, not failures of plausibility. It won’t tell you the villain’s plan makes no sense, or that a character’s motivation doesn’t hold, because those have no ground truth to check against. It only knows the facts you’ve recorded, so a detail that lives only in prose isn’t checkable until it’s in the model. Human readers still own judgment. The full version of that boundary is in can AI catch plot holes and continuity errors?

Seeing it in practice

This is exactly the pipeline StoryGuard runs: a structured world graph, @mentions that link it to your chapters, entity state tracked against story time, and a scan that reads world and manuscript together and returns anchored, sentence-level flags. A new account opens into a sample project with real issues already flagged, so you can see the output rather than take the explanation on faith. The mechanism isn’t magic. It’s just the difference between asking a model to remember your book and giving it the facts to check against.