AI Series Bible: Keeping Book 3 True to Book 1
Book three is 61,000 words in and your beta reader sends back one line: wait, didn't Sela's brother die?
You go looking. Chapter nineteen. Tobiah is on the page, alive, arguing with her about harbor tariffs. He died at the end of book two, chapter thirty-one — you wrote the scene, you cried a little, your newsletter subscribers cried a little. And the model that helped you draft chapter nineteen had no idea, because as far as it could tell Tobiah was simply a character who exists in your notes. Nothing in those notes said until.
This is the part nobody warns you about when you move from writing a novel to writing a series. Single-book continuity is a memory problem. Series continuity is a bookkeeping problem, and the fix is different.
Why series continuity breaks differently than chapter continuity
Within one manuscript, continuity drifts because the model forgets — it loses a detail from chapter three by the time it's writing chapter thirty. Across books, continuity breaks for the opposite reason: the model remembers your notes perfectly, and your notes are wrong. They describe a world state that was true two books ago and isn't anymore.
That distinction matters because it changes the fix. Single-manuscript drift is solved by getting the right details back in front of the model. Series drift is solved by making your reference document capable of expressing time — because a flat character sheet that says Tobiah: Sela's older brother, harbormaster, gruff is not a fact. It's a fact with an expiry date, and nothing in the file records it.
The obvious workaround — paste the previous books in — collapses fast. A three-book series at 90,000 words apiece is roughly 360,000 tokens of manuscript. Current frontier models will physically accept that; the trouble is what happens to recall inside it. In Lost in the Middle (Liu et al., TACL 2024), the researchers found that performance "is often highest when relevant information occurs at the beginning or end of the input context, and significantly degrades when models must access relevant information in the middle of long contexts, even for explicitly long-context models." Book two, chapter thirty-one is the exact middle of your pile. That's where you buried the death.
If you're running a local model, the ceiling arrives sooner and more quietly. Ollama's documentation sets the default context by available VRAM: under 24 GiB you get 4k tokens, which is about twelve pages. Your series bible has to fit in that, and so does the scene you're writing.
Your series bible needs a column your story bible doesn't
A series bible is, as Laterpress puts it, "a collection of notes and descriptions [used] to ensure that their stories are consistent across multiple installments." Every good one tracks characters, places, timelines, and objects. Sarra Cannon — a self-published author with over half a million books sold — organizes hers into nine categories: characters, story arcs and summaries, places, organizations and government, magic system and technology, objects of significance, language, timelines, and a style guide.
Keep all of that. Then add the field that makes it survive AI drafting: which book each fact became true in.
A fact in a series isn't true. It's true as of book two, chapter twelve. A series bible without a book number attached to its mutable facts is just a very confident lie, and the model will repeat it back to you in polished prose forty times before your beta reader catches it.
The two-tier split: write-once facts and versioned facts
Sort every entry into one of two tiers before you write another word.
Write-once facts never change for the life of the series. Eye color. Height. The scar and how it got there. Birth order. A character's native accent. The rules of your magic system. Once you commit these in book one, they are load-bearing — a reader who notices Sela's eyes go from brown to grey in book three will not finish book three.
Versioned facts are supposed to change, and every one of them carries a book number. Alive or dead. Rank and title. Who they're married to, estranged from, sleeping with. Where they live. What they own. And the one that catches the most writers: what they know. Sela cannot read in book one, chapter four. She learns from the archivist in book two, chapter twelve. Both are true. A flashback scene in book three set before that lesson, in which she skims a shipping manifest, is a continuity error that no spell-check will ever flag.
Write the two tiers as two visibly separate sections in your file, not two columns in one table. The point of the separation is that when you're editing at 2am you should be able to see that you've wandered into the write-once section, and stop.
Keep this in whatever holds it — a spreadsheet is genuinely fine, and better than a wiki you'll spend three weekends decorating. What changes with an AI-assisted workflow is the reading, not the writing: if your reference lives somewhere the model consults on its own — NovelMage's Codex works like a lorebook the model pulls from automatically while drafting — you maintain the split once instead of re-pasting it into every prompt and hoping you grabbed the current version.
A worked series: 245,000 words, one four-page file
Call the author Priya. Three-book harbor-fantasy series: book one published at 96,000 words, book two published at 88,000, book three drafting at 61,000. That's 245,000 words of established canon, roughly 325,000 tokens — and she is not feeding any of it to a model.
Her series bible is about 4,000 words. Write-once section: eleven characters with physical anchors and voice notes, the four rules of tidewater binding, the geography of the harbor district. Versioned section: a status line per character per book, a chronological timeline of beats with dates, and a "who knows what, from when" block that is currently the longest thing in the file.
That block is where the work is. It has entries like Sela — literate from B2 c12 and Marisol — knows Tobiah is her father from B2 c27; Sela does not know as of B3 c19. Nine entries. It took Priya an afternoon to reconstruct from the published books, and it is the reason she caught the flashback problem herself instead of hearing about it in a review.
Every drafting session, she feeds the model three things: the write-once section (unchanged, ~1,200 words), the versioned state as of the current chapter only (~600 words — not the history, just the present), and a one-page "story so far." Under 3,000 tokens, every time. It fits in a 4k local context with room for the scene.
The 2,000 words of version history she never sends. That's for her, for the audit, and for book four.
Update after the book, or as you go?
Practitioners genuinely disagree here, and the disagreement is worth understanding rather than splitting.
Cannon updates "after each book is totally complete and ready to be published," on the logic that mid-draft changes pollute the record — you don't want a fact in your bible that came from a scene you cut in revision. Laterpress treats the bible as a "living document," updated continuously during writing.
Both are right about different halves of the file. Update your versioned section continuously, because that's the half the model reads tomorrow morning and a stale status line is exactly what produces a resurrected brother. Update your write-once section only at publication, because a physical detail invented in a draft scene shouldn't become canon until the scene survives revision. One half is a working state; the other half is a contract with your readers.
And update it the day you write the scene, not the week you finish the book. Most continuity breaks aren't a tooling failure, they're a bible that fell four chapters behind and nobody noticed.
The pre-launch continuity audit
Before book three goes to your editor, run one dedicated pass — separate from line editing, and not while you're drafting.
- Reconcile every versioned entry against the actual manuscript. Not against your memory of it. Open the chapter, confirm the status line, and note the chapter number where each change happens.
- Trace deaths and departures forward. For every character who exits, search the following manuscript for their name and confirm each hit is memory, letter, or ghost.
- Trace knowledge forward. For each entry in your who-knows-what block, find the scene where it's learned and confirm nobody acts on it earlier — flashbacks and interleaved timelines included.
- Check the write-once list against book one. Eye color, scars, ages, birth order. If book one is published, book one wins. Change the bible, not the published novel.
- Rebuild the timeline as dates, not beats. Character ages drift when your books span years; a birthday nobody tracked will put a fourteen-year-old in a tavern.
Steps two and three catch the errors that lose readers. Step five catches the ones that lose reviewers.
If a book in the series is under contract and unpublished, the audit is also the moment the manuscript gets copied around most — pasted into a chat window, uploaded to a web tool, mailed to yourself. Running the pass in a desktop app against a local model through Ollama or LM Studio, as NovelMage does, keeps the unpublished draft on your own disk while you do it.
Frequently Asked Questions
Do I need a series bible if I'm only writing a trilogy?
Yes, and it's cheaper to start now than to reconstruct it later. Cannon's own guidance scales the complexity to the series — a trilogy doesn't need what a twelve-book saga needs — but the versioned section is the part that pays for itself immediately, and a trilogy has exactly the same resurrection problem as a saga. If you're writing a standalone, skip all of this; one manuscript doesn't need versioned canon.
Can't I just let the AI read my published books and build the bible?
You can generate a first draft that way, and it will save you the afternoon. Review every line before it becomes canon. An extracted fact that's subtly wrong is worse than no fact at all, because it poisons every chapter written after it — the model has no way to distinguish a fact you confirmed from one it inferred, and it will defend both with equal confidence.
How long should a series bible be?
Short enough to fit in context alongside the scene you're writing. In practice that's 3,000 to 5,000 words for the sections the model actually reads, with version history kept separately for your own audits. If your bible has grown past the point where you can send it whole, split the state from the history rather than summarizing the state.
What about a character who genuinely changes physically — an injury, aging, a transformation?
Then it was never a write-once fact. Move it to the versioned section with the book and chapter where it changes, and leave a pointer in the write-once entry so future-you doesn't re-file it wrong. The tiers are about stability, not about body versus biography.
Where to keep it
The method above is the whole product; software only changes how many times a day you have to think about it. If your reference lives in a Codex the model reads on its own while it drafts, the versioned state reaches the page without you assembling a prompt every session — and if you're running local models, none of those 245,000 words are leaving your desk. NovelMage is a Windows and macOS desktop app built that way: local models through Ollama or LM Studio, or your own Claude, GPT, or Gemini keys, at $99.99 once for up to three devices rather than a subscription that outlives the series.
You can try it free for seven days and see whether book three starts behaving.
Whatever you use, the rule survives the tooling: put a book number on every fact that can change, and stop asking the model to remember what you never told it.