We Ran an AI Consistency Scan on Dracula — Here's What It Found

We ran our AI consistency engine over the full text of Bram Stoker's Dracula — about 160,000 words — and it extracted 4,738 factual claims. The surprising result: almost every "contradiction" a blunt check flags is the story working as intended. A character who dies and rises as the Un-Dead isn't an error — and telling that apart from a real mistake turned out to be the whole point.

Dracula has a reputation. For a novel this beloved, it is also famously tangled — readers and scholars have argued for a century about when, exactly, its events take place. So it seemed like the perfect first subject for a simple experiment: point an AI consistency engine at all 27 chapters and see how many contradictions fall out. We expected a pile. What we got taught us more about checking consistency than about Stoker.

Key takeaways

• We scanned every chapter of Dracula and extracted 4,738 checkable facts — real data from a real run, not opinion.
• A blunt "any changed value is a contradiction" check flagged 164 conflicts. Almost every one was the plot, not a mistake.
• The engine's real job isn't finding contradictions — it's not crying wolf about a character who is supposed to change: to die, to age, to transform.
• After we taught it to tell a time-varying state from a fixed fact, genuine flags collapsed to three — and even those aren't the errors you'd expect.
• The one problem Dracula is genuinely known for — its muddled 1893 timeline — is a different kind of error (chronology), which a fact-contradiction pass doesn't catch. We're honest about that boundary.
• Trustworthy consistency is about precision. Here's how the engine decides what's an error and what's the story.

What did an AI consistency scan of Dracula actually find?

It found 4,738 factual claims across the book — and almost no genuine fact-contradictions. That second part surprised us, so let's be precise about what happened.

The engine reads each scene and extracts the concrete assertions it makes — a character's appearance, where they are, whether they're alive, what they now know — into a registry. Over Dracula that came to 4,738 tracked facts. Then it cross-references every claim against every other for the same subject: if "Elena's eyes" are green in one place and brown in another, that's a contradiction.

Run naively — flag any case where the same subject has two different values for the same property — and Dracula lights up with 164 conflicts. That number is the trap. Because when we actually read them, they weren't errors. They were the novel doing exactly what novels do.

The scan, in three numbers	Count
Facts extracted from the full text	4,738
"Conflicts" a naive check would flag	164
Genuine flags after the engine tells state from fact	3

The gap between 164 and 3 is the entire story.

Why were 164 "contradictions" not errors?

Because a novel is built on change, and a blunt checker can't tell change from a mistake. This is the single most important thing we learned, and it's easy to miss.

Consider Lucy Westenra. Early in the book she is alive and well. Then she sickens and dies. Then — this being Dracula — she rises as the Un-Dead and walks Hampstead Heath. To a naive fact-checker, that is a screaming contradiction: the subject "Lucy" has an alive_status of alive, then dead, then active again. Flag it. But it isn't an error. It's the most important event in the book.

Multiply that across a whole novel and you get the 164. A character is described as calm in one scene and furious in the next — not a contradiction, a mood. Renfield is "restrained in a strait-waistcoat," then "chained to the wall" — not a contradiction, an escalation. Two different aspects of the same castle get recorded under one loose label. None of these are mistakes; they're the story progressing. A tool that flags all 164 doesn't make you a better writer — it trains you to ignore it, and then you miss the one that matters.

So the useful engine has to draw a line that sounds obvious and is surprisingly hard:

• Some facts are fixed — eye colour, a birthplace, a species. If those change, it's almost always an error.
• Some facts are state — health, location, mood, whether you're alive. Those are supposed to change over time. A later value simply supersedes the earlier one; it isn't a contradiction with it.

Teach the engine that difference — that alive_status progresses along a timeline while eye_color does not — and the 164 false alarms fall away. What's left is genuinely worth a writer's attention.

What were the three genuine flags — and are they even mistakes?

After the fix, the engine surfaced three candidates — and on inspection, the clearest one is the plot itself. That's not a failure of the scan; it's the scan being honest.

The standout is Lucy again: her alive_status runs dead → Un-Dead, an "impossible reversal" the engine flags because, in any ordinary novel, a character returning from death would be a continuity error. In Dracula it's intentional — so the correct action isn't "fix it," it's "confirm it's deliberate and move on." That is exactly how the engine treats it: it surfaces the reversal for you to bless, rather than silently deciding Stoker made a mistake.

The other two are instructive precisely because they're not clean errors:

• Jonathan Harker's hair shifts from brown to white — a real change, but the right kind. His hair turns white from terror during his escape. That's character development written into a physical detail, and the engine's language step recognises it as an evolution, not a blunder.
• "A dog" appears as dead in one place and alive in another — but "a dog" isn't a named character. It's a generic reference the extractor couldn't tie to a single animal, so two different dogs collapsed into one phantom subject. That's not a Stoker error; it's a reminder of why the engine lets you name and alias the entities you care about, so a vague noun doesn't manufacture a conflict.

What the writer actually sees: flagged items to review — accept a real fix, or mark an intentional change (a resurrection, a dye job) so it never nags again.

Notice what did not happen: the engine did not produce a triumphant list of "23 mistakes Bram Stoker made." We could have written that headline. It just wouldn't have been true — and a consistency tool that fabricates errors on a book everyone can read is worse than useless. The honest finding is the interesting one: Dracula's apparent inconsistencies are overwhelmingly the supernatural machinery of the story, not lapses in it.

So does Dracula have real continuity errors?

Yes — but they live in a dimension a fact-contradiction scan doesn't reach: time. This is the honest boundary of what we tested, and it's worth stating plainly.

The thing Dracula is genuinely, provably muddled about is its calendar. The text points to 1893 — it name-drops the death of the French neurologist Charcot, the founding of the Westminster Gazette, the phrase "New Woman" — and Stoker's own notes used an 1893 diary so the weekdays line up. Yet an addendum has Harker recall events "seven years ago," which pulls the timeline back toward 1890, and an earlier manuscript said "eleven years ago." Scholars have spent decades reconciling it (the Wikipedia entry on Dracula summarises the debate). There's also the vampire's own rulebook: the "must be invited across a threshold" law that isn't applied with perfect consistency.

Our fact-contradiction pass doesn't catch those, and we won't pretend it does. A wrong year isn't two different values for one property — it's an arithmetic and chronology problem, a different class of check entirely (the kind that reasons over a timeline and world rules, not a fact registry). Naming that limit is part of the point. A checker you can trust is one that's clear about what it does and doesn't see — which is also why our own contradiction tier and a timeline/rules pass are separate jobs, not one magic button.

You can read the primary source yourself: the full text lives on Project Gutenberg, which is exactly what we fed the engine.

What scanning Dracula taught us about AI consistency checking

The hard part of consistency isn't finding contradictions. It's not producing false ones. That sounds backwards until you watch a naive checker flag a beloved novel 164 times for the crime of having a plot.

Anyone can build a tool that compares values and shouts when they differ. It will be technically correct and practically worthless, because a story is a controlled sequence of changes and the tool can't tell an intended one from a mistake. The engineering that matters — the part we spent real effort on — is precision: modelling which facts are allowed to move, recognising a natural evolution, letting the writer confirm an intentional reversal, and linking vague references to real characters so a stray "a dog" doesn't invent a conflict. Get that right and the handful of flags you're left with are ones you'll actually act on.

That's the difference between a spell-checker for facts and a tool you trust across a hundred thousand words. If you want the mechanics behind the line we drew between state and fact, that's in how the Consistency Engine works; for the craft side — telling a continuity error from a plot hole from a character simply changing — start with the complete guide to story consistency and how to find and fix plot holes.

Dracula was the ideal first subject not because it's riddled with errors, but because it's riddled with change — death, transformation, resurrection — the exact thing a lazy checker mistakes for error. The engine's job was to look at all of it and, correctly, stay quiet. You can point the same scan at your own manuscript with NovelCanon — and find out how much of what looks like a contradiction is really just your story doing its work.