Story continuity

Character Consistency Across Chapters: An AI Continuity Ledger

Track knowledge, injuries, relationships, and objects between chapters with a practical continuity ledger and a worked three-chapter example.

Character consistency across chapters requires a record of what changed and when. A character sheet explains who Mara is; a continuity ledger explains what Mara knows at the end of chapter three. When using AI to draft a long story, pass that current state into the next chapter and update it only after reviewing the new prose.

Track state at chapter boundaries

Create one row for each consequential change. Include a source location so that you can check the prose instead of trusting a summary.

Chapter Character State after chapter Evidence Next constraint
1 Mara Has the brass key; does not know its door Workshop scene Cannot name the door yet
2 Mara Left hand cut; key given to Ivo Floodgate scene Avoid two-handed climbing
3 Ivo Knows the map is incomplete Tower conversation May reveal this only on purpose

This is an illustrative ledger for an invented story. The “next constraint” column is useful because it translates a fact into a drafting consequence. A summary saying “Mara was injured” is less actionable than specifying which hand and which actions are affected.

Separate knowledge by character

The reader may know more than the viewpoint character. Track three levels separately: what happened in the world, what the reader has seen, and what each character believes. A mistaken belief is not a continuity error if the story supports it.

For example, Ivo may believe Mara kept the key even after the reader sees her hide it. If you overwrite his belief with the objective truth, the next conversation loses its tension. Add a “belief” label when a fact is uncertain or misleading.

Extract changes before drafting again

After accepting a chapter, ask an assistant to propose ledger updates. Require quotations or paragraph references from the accepted text. Then inspect every proposed row yourself.

Compare the accepted chapter with the starting ledger.
List only changed knowledge, injuries, possessions, promises, and relationships.
For each change, provide the supporting sentence and affected character.
Mark inference as inference. Do not invent off-page events.
Do not update the approved ledger until I accept the changes.

This two-step review keeps a plausible but incorrect summary from becoming the next chapter's authority.

Resolve contradictory rows

Imagine chapter four says Mara turns the brass key while climbing a ladder with both hands. There are two separate questions: how did the key return to her, and has her injury healed enough? Search the accepted chapters for evidence. If neither transition exists, add a scene-supported transfer and recovery, or change the action.

Do not solve every conflict by adding explanatory sentences. A quieter repair may be to let Ivo unlock the door while Mara holds the light. That preserves the established state and creates a useful dependency between them.

Keep the context packet small

For the next chapter, supply the relevant current rows, the chapter goal, and unresolved promises. Archive the historical ledger separately. A complete history is useful for review, but past and present versions mixed together can confuse a drafting request.

Download the chapter state CSV. Start with three chapters and five state categories. If the ledger takes longer to maintain than the prose, remove decorative details and keep only facts that could change a scene's logic.

FROM THE PAGE TO THE FRAME

Have a story in mind?

Shape a concept in the local Ficlora workbench. Save it in your browser or export it as text.

Explore the workbench