How to Track Continuity Across a Long Series

Why memory fails at series scale

Early in a series you can hold the world in your head. The trap is that it feels like that will continue, so no system gets built — and by the time it obviously does not scale, there are already hundreds of facts that disagree in ways nobody has checked.

The failure is structural, not personal. The number of facts you have to keep straight does not grow in a line; the number of pairs of facts that have to agree grows roughly with the square of it. Forty characters, a dozen rules, and a hundred events is not a hundred and fifty-two things to remember — it is thousands of pairwise relationships, every one of which has to hold. No memory does thousands of pairwise checks, which is why the breaks creep in at the edges no matter how sharp the author is.

So plan for the series you will have in book five, not the one you have in chapter three. The four moves below are what a memory does for a small world, externalized so they keep working when the world is too large for any memory at all.

Move one: build one source of truth

Pick one place where canon lives and make everything else defer to it. The most common cause of continuity drift is parallel copies — a doc, a wiki, and a collaborator's notes that slowly disagree. One current record everyone reads from and writes to eliminates that entirely, because there is no longer a second version for the first to contradict.

It has to be the place decisions are made, not a transcription you update later. The instant you decide a character's brother survived the fire after all, that decision lands in the canon — not in a notebook, not in your memory, not in a comment on chapter nine. A canon that trails the actual decisions is always one step behind the work, and the gap between the decision and the record is exactly where contradictions are born.

Move two: make every fact atomic and dated

Break facts down to one checkable statement each, and attach a timeframe to anything that changes. Take "Maren leads the rebellion." As written, it is a trap — a flashback or a later coup can contradict it and nothing flags the clash, because the fact has no time attached. Rewrite it as "as of volume two, Maren leads the rebellion" and it becomes verifiable against every scene set before and after.

The reason this matters is that a consistency check operates on atomic, dated facts as its unit. A paragraph of character description cannot be checked with any precision — the machine, or the editor, has no idea which clause is a load-bearing fact and which is color. A set of discrete, dated statements can be checked, one against another, which is the entire point of recording them this way.

Date the things that change — status, location, knowledge, rank, the cost of a power after a rule is revised — and leave the permanent things undated. The discipline is not to date everything; it is to never leave a changing fact looking permanent.

Move three: check before each installment ships

Run a full pass over the world before each book, season, or volume goes out — and again at the major internal handoffs, like the move from outline to draft. The cost of a contradiction climbs steeply the later you find it: a note-stage fix is one edit; a draft-stage fix is a revision; a post-publication fix is a retcon you now have to manage forever, honoring the mistake in every book that follows.

Make the check a routine gate, not a heroic effort. A gate is something the installment simply does not pass through until the pass is clean; a heroic effort is something that happens when someone has time, which in a serialized schedule is never. When the check runs every installment as a matter of course, continuity stops being something you lose and notice three books later, and becomes something you maintain on a schedule.

Move four: track relationships, not just entries

The fourth move is the one most systems miss. It is not enough to have an entry per character and an entry per rule; the continuity errors live in how those entries relate. A character's knowledge depends on which events they were present for. A power's behavior in a scene depends on the rule that governs it. A journey's duration depends on the distance between two locations. The facts that break are relational, so the record has to hold the relationships, not just the nouns.

Practically, this means your system should let you ask connected questions — what does this character know as of this event, which scenes invoke this rule, what is still unresolved in this thread — and get answers without re-reading the series. A flat list of entries cannot answer those; a connected, typed record can. This is the move that turns a pile of notes into something you can actually check.

Where CanonBoard fits

CanonBoard is this system, built. Your series lives on one open canvas as connected, typed cards — characters with status over time, world rules with their costs, a real timeline, open threads — which is moves one, two, and four in a single structure: one source of truth, atomic dated facts, and the relationships between them all held together.

Then it runs move three for you. CanonBoard scans the whole board on demand and surfaces continuity breaks with both sides quoted and the conflict named, so the pass before each installment is a button rather than a re-read of five books. Build the system early, keep it current as you serialize, and let the check catch what memory cannot.

Frequently asked questions

How do you keep a long series consistent?

Keep one shared source of truth, record every fact atomically and with a timeframe, and run a full consistency check before each installment ships rather than relying on memory.

What is the best way to track continuity?

A structured, queryable record where each fact knows what it is (character, rule, event) — not a flat document. Structure is what lets you, or a tool, check the whole world against itself.