How to Build an AI Worldbuilding Bible Without Losing Story Continuity
Build an AI worldbuilding bible by giving every established fact a stable ID, a human decision owner, a source, and a defined scope. Track when it is true, where it applies, and which characters know it. Ask AI to propose additions and flag conflicts; require an explicit editorial decision before those proposals become canon. This guide is for fiction and game writers building a working reference for their next chapter, scene, or quest. The task is to create a bible you can consult and revise without accidentally changing the story’s rules. The reusable continuity ledger below connects facts to the scenes that depend on them.
What should your AI worldbuilding bible contain?
Start with a small reference system that answers practical drafting questions. Can this character reach the observatory before sunset? Have they learned how its door opens? Does that answer change on another story branch?
Organize the bible into six connected sections:
Use a spreadsheet, linked documents, or a database you can maintain comfortably. Give entities stable IDs such as LOC-01 and CHAR-02; keep display names and aliases in separate fields. Renaming “Glass Observatory” should not break every reference to its location record.
Treat narrative summaries as convenient views of the ledger. When a summary disagrees with an underlying record, inspect the source and resolve the conflict before drafting from either version.
Who owns a fact, and what makes it canon?
For this workflow, fact ownership has two parts: one authoritative record holds the statement, and one person is responsible for accepting changes. A solo writer fills that role. A team might assign location decisions to a world designer and character revelations to a narrative lead, with one designated resolver for overlapping decisions.
Record provenance alongside ownership. The W3C’s PROV overview (https://www.w3.org/TR/prov-overview/) describes provenance as information about the entities, activities, and people involved in producing something. Applied to a story bible, that means preserving where a statement originated, how it changed, and who accepted it. The ledger here adapts that principle; it is not a formal PROV implementation.
Give each record an explicit status:
When importing an existing manuscript, let AI extract candidate facts with exact scene references and short supporting quotations. Check the references yourself. A character saying “the observatory is always locked” establishes that statement was made; it does not automatically establish an objective rule.
Write down your project’s authority policy. For example: an accepted retcon decision overrides the previous canon entry; accepted source scenes establish facts; working drafts and brainstorming remain provisional. If two accepted scenes disagree, mark the conflict unresolved until you decide which one changes.
How do you track timelines and locations together?
Record story time separately from revision time. “The bridge closes on Day 6” describes an event. “The writer changed the bridge’s closing date in revision 4” describes an editorial decision. Mixing these creates ambiguity about whether the world changed or its description was corrected.
For each event, capture its earliest and latest possible time, location, participants, prerequisites, and resulting state. Use ranges when precision is unnecessary: “after the morning delivery, before sunset” can be more useful than an invented minute. Define calendar units if your setting uses unfamiliar days or seasons.
For each route, record origin, destination, travel mode, duration or range, and availability conditions. State whether travel works in both directions. A map can show two places close together while your established route still requires a long detour.
Consider this explicitly illustrative continuity check: a courier leaves the orchard at 09:00, needs three hours to reach the observatory, and spends another 30 minutes collecting a lens. The earliest arrival is 12:30. A scene placing the courier there at noon conflicts with those inputs unless an accepted exception applies.
Resolve the conflict by changing a supported input: departure time, route, delay, or meeting time. If travel takes two to four hours, arrival is a range instead. Preserve that uncertainty rather than reporting a definite contradiction.
How do you separate world truth from character knowledge?
Keep knowledge records separate from objective facts. For every significant revelation, record the character, the fact or belief, the acquisition event, the time, and any branch condition. Distinguish “knows,” “suspects,” “believes incorrectly,” and “has not learned.” An absent record means knowledge is unrecorded; it does not prove ignorance.
This has a direct counterpart in interactive narrative. Inkle’s official ink tutorial (https://www.inklestudios.com/ink/web-tutorial/) demonstrates conditional text and choices based on previously visited story sections. It also describes custom variables. Those mechanisms can represent access to information, although writers must still decide whether visiting a scene actually teaches the character a particular fact.
For example, the observatory door may open when a copper disc is aligned with a mark. That is a world fact. Mira learning the procedure during a demonstration is a separate event. Another character reading an incomplete note may only suspect how it works.
For a branching game, attach the learning event to the relevant path or state condition. Test both a route where the character learned the procedure and one where they skipped it. For a novel, check that explanation and dialogue occur after the learning event in story time, even when chapters appear out of chronological order.
A reusable continuity ledger
Use the following fields as spreadsheet columns or as a repeatable record in your notes. Keep one independently revisable claim per record. The examples are invented solely to demonstrate the workflow.
Here is a compact view of three connected records. The full ledger would retain the evidence and ownership fields above for each row.
Do not let “unresolved” silently become “no.” Question Q-003 leaves the substitute-disc option undecided. It neither allows nor forbids it. A scene requiring an answer should trigger a decision request.
Give each open question an owner and a decision point: “Resolve before drafting S-15.” If the answer is deliberately withheld from readers, record whether the writer already knows it. An author-held answer and an undecided design choice need different treatment.
How should AI use the bible during drafting?
Prepare a scene packet containing the target scene’s time, place, viewpoint, branch, relevant canon records, and unresolved dependencies. Include linked prerequisites, not just entries sharing the scene’s keywords. A door scene may depend on an earlier demonstration in another location.
Use a prompt such as this reusable instruction:
Review the supplied scene against the attached continuity records and their stated revision. For each potential conflict, quote the scene passage and identify the relevant record ID. Classify it as a contradiction, missing information, or a proposed addition. Check chronology, travel, location access, character knowledge, and branch conditions. Preserve unresolved questions. Suggest repairs separately; do not change canon or invent source references. State which checks could not be completed from the supplied material.
For generative work, ask for alternatives within explicit constraints: “Suggest three ways to delay Mira without changing F-014 or granting her knowledge before E-008.” Describe the desired atmosphere, pacing, and setting features in your own terms.
Review the output in two passes. First check whether its cited records support its findings. Then decide which suggestions serve the story. Only accepted changes enter the ledger. If a necessary source is missing, retrieve it or leave the finding unresolved.
How do you handle retcons without erasing history?
Distinguish an ordinary event from a retcon. If the door receives a new mechanism on Day 11, add a transition event and a new time-bounded rule. If you decide it always used a different mechanism, revise the earlier canon and examine every dependent scene.
Version history makes earlier states recoverable. The official Git book’s introduction to version control (https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control) explains how version control records changes, supports comparisons, and allows previous versions to be recalled. Git is one option; choose a document system with usable history if that better fits your work. Separately record why a narrative decision changed.
For each proposed retcon:
A reusable change-log entry should contain change ID, revision date, decision owner, reason, old record, replacement record, affected material, and verification status. For example: “CH-006 proposes requiring two aligned discs; affects F-014, E-008, K-009, and S-12; decision pending.” Approval alone would not mean those dependent scenes had already been repaired.
What should you check before accepting a scene?
Read the scene once for continuity after its creative revision. Verify that required events have happened, travel and access conditions hold, characters possess the information they use, and branch-specific facts remain within their branches. Check that new details have either been accepted into canon or remain visibly provisional.
Record the bible revision used for that check. If a later change touches one of the scene’s dependencies, reopen the scene for review. You can begin with one location, one character, and the next scene’s essential facts, expanding the ledger whenever a new detail constrains what can happen later.