A story bible for AI writing should tell an assistant which facts are approved, which facts are uncertain, and what it is allowed to invent. Its most useful form is a compact context packet you can attach to a specific scene. A beautiful encyclopedia does little for continuity if the drafting tool never receives the relevant entries.
Download the editable Markdown template. It works as a plain text document; it does not depend on a Ficlora account or a particular writing model.
The six parts of a useful packet
1. Scope. Name the story, version, current chapter, viewpoint, tense, and task. “Revise chapter four's dialogue” is a different assignment from “invent an alternative ending.”
2. Approved canon. Include only facts relevant to the scene. Label stable facts explicitly. A magical mechanism's limitation belongs here if the scene tries to use it.
3. Current state. List location, possessions, injuries, knowledge, and relationships at the scene's start. Link each important fact to an accepted chapter or note.
4. Open questions. Keep unresolved ideas separate. “Maybe Ivo is the missing cartographer” must not be promoted into a revelation by accident.
5. Invention boundaries. State what may be added. Minor weather details might be open; a new magic ability or family relationship may require approval.
6. Output and review. Ask for the scene plus a short list of proposed new facts. Accept or reject those facts before updating the bible.
A filled example
Story: The Orchard at Low Tide / approved notes v0.3
Task: outline chapter 4, not prose
Viewpoint: Mara, close third person, past tense
Fixed: tide clocks can predict water, never control it
Current: Mara's left hand is injured; Ivo holds the brass key
Knowledge: Mara has not learned that the map is incomplete
Unresolved: why the orchard appears only during the lowest tide
Allowed invention: small physical obstacles in the tower
Requires approval: new magic, relatives, hidden knowledge
Return: 5 scene beats + any proposed canon changes
This invented example demonstrates the structure. It is not a claim that any particular model will obey every instruction.
Reduce the bible for each scene
Keep a master bible for yourself and assemble a shorter packet for each request. The tower scene does not need the entire royal genealogy. It does need the clock's limitation and who currently holds the key.
If the tool retrieves context automatically, inspect what it actually includes when that is possible. A feature called “memory” may store information without supplying the right information to a particular request. Our memory evaluation guide gives you a small test you can run with your own material.
Make updates a review step
Never replace your approved bible with an unreviewed model summary. Save the current version first, compare proposed changes with the accepted text, and record the source of each new fact. A short change log is enough: version, changed field, reason, source chapter.
When a draft and the bible disagree, decide which one you want to preserve. You may prefer the new scene. If so, revise the bible and affected earlier scenes deliberately instead of treating the contradiction as solved by renaming it.
For a broader planning document before you start drafting, use the novel story bible. That companion covers theme, setting, and arcs; this packet covers what an assistant needs for one controlled writing task.
