How Guardian works.

The obvious way to build a consistency checker is to hand the manuscript to a model and ask it to find the problems. This works impressively on a short story and degrades on a novel, for a reason that isn’t a temporary model limitation: recall over long contexts thins out as the material grows, and it thins out unevenly. The middle of a long input is where things go quiet.

A novel is the worst possible shape for this. The contradiction you care about is almost never local — it’s between a detail in chapter two and a sentence in chapter forty, separated by ninety thousand words the model is also trying to hold. By book three of a series, the fact being contradicted isn’t even in the file you have open.

There is a second problem, quieter and worse: a naive checker is unfalsifiable. Ask a model for plot holes and it will return plot holes, because that is what you asked for. Some will be real. Nothing in the design distinguishes the real ones from the fluent ones, and nothing tells you what it missed.

Guardian doesn’t check your chapter against your manuscript. It checks it against a structured record of what your story has established: characters and their traits, locations, timeline events with timestamps, and — the part that does the real work — typed relationships between them. Parent of. Located in. Ally of. Ruler of.

This is the difference between a story bible and a checkable one. A wiki stores facts for you to consult. A typed graph stores facts a machine can reason over. When you write that Mara is Aleth’s daughter, that isn’t a note — it’s an edge, and edges have consequences.

Prose that hasn’t been captured as structure still matters, so a second path indexes your chapters as embeddings and retrieves semantically related passages when a check needs them. Structure handles what is decidable; retrieval handles what is merely relevant. Both feed the same pipeline.

A large class of continuity errors doesn’t require reading comprehension at all. It requires arithmetic and bookkeeping — exactly what humans are bad at across a hundred thousand words, and what software has been good at since forever.

So Guardian runs a symbolic inference engine over your relationship graph before any model is involved. It computes a bounded closure: it derives the facts that follow from the facts you authored — your character’s parent’s parent is their grandparent — and stops at a fixed depth, so the derived set stays small, fast, and predictable rather than exploding across the graph.

Then it looks for contradictions in the combined set. Among them:

• Kinship and age — cycles in descent, a parent younger than their child, ages that can’t coexist with the timeline.
• Containment — a place inside a place inside the first one. Geography that closes a loop.
• Residence — a character established as living in two mutually exclusive homes.
• Status — a character recorded as dead still holding a role that asserts a present state.
• Timeline — a chapter naming a dated event and stating a year that contradicts the record, or ordering two dated events against their own timestamps.

None of this involves a language model. That matters for three reasons: it is reproducible — the same graph always yields the same findings; it is testable, because a deterministic function has a correct answer; and it is cheap, so it can run constantly instead of when you remember to ask.

Plenty of real problems aren’t decidable from structure. Whether a character’s arc actually turns, whether a scene’s causality holds, whether your prose slid out of its own register — these need reading. Here Guardian uses a language model, under two constraints.

It is grounded, not asked. Detectors run against retrieved, relevant material rather than a general request to find problems. The model is given the passage, the canon it must be consistent with, and one narrow question.

It has to show its work. A proposed finding passes through an evidence gate, and the gate’s default is to drop. Anything the model cannot ground in quoted text from your manuscript doesn’t reach you. This deliberately costs us recall — some real problems get dropped — because we think a checker that cries wolf is worse than one that occasionally stays quiet. You are trying to write. Every false alarm spends your attention, and attention is the thing the tool exists to protect.

The checks are organised in layers by nature and cost — consistency, style and prose, deeper narrative analysis, chapter craft, plot structure — so that the cheap deterministic work can run continuously while the expensive interpretive work runs when you ask for it. Keeping them separate also keeps us honest: the layers do not perform equally, and averaging a strong check with a weak one into a single confidence score would hide exactly the information you need.

The most requested check we have declined to build: flagging a chapter that references an event the timeline places later. The data is right there. It would have been a morning’s work.

We didn’t build it because that pattern is also the definition of foreshadowing — one of the core techniques of the craft, and something Creader ships a dedicated feature for. Separating “you contradicted yourself” from “you set something up” requires reading intent, and we don’t believe a checker should guess at intent and then present the guess as an error. Guardian would have spent its credibility fighting your technique.

The general rule: when a signal is genuinely ambiguous, we would rather stay silent than be confidently wrong. Every false positive teaches you to ignore the panel, and a panel you ignore is worth nothing no matter what it catches.

A consistency engine makes a testable claim, so we test it. Clean fiction fixtures are corrupted with known, catalogued errors — a changed eye colour, a broken timeline, a contradicted rule — and the engine is scored on how much of the damage it recovers, and how precisely.

The suite also carries trap fixtures: passages that are entirely correct and must come back clean. These matter more than the positives. Recall is easy to buy by lowering thresholds until everything trips; the traps are what stop us buying it.

Results are compared against a committed baseline, and the comparison runs in continuous integration as a merge gate. A change that degrades detection, loses coverage, or trips more traps fails the build — which means it can’t quietly ship because a demo still looked fine.

We’re not publishing scores here, and we’d rather say why than pretend the omission is modesty: our layers do not perform equally. The deterministic consistency work is strong. Some of the interpretive analysis is early, and we know which parts. Publishing a single flattering headline number would misrepresent that spread, and publishing the full table invites comparison against benchmarks that don’t measure the same thing. What we will commit to is the shape of the thing: every layer is measured, the measurements gate our releases, and the weak ones are known to us and being worked on.

If you want to see it against your own manuscript rather than ours, that’s the honest test — here’s how the writing side fits together.