All notes

    Continuity

    Why your story bible gets ignored

    You filled in every character, every rule, every timeline entry — and the AI still gave your bald character hair. This is not a bug in your bible. It is what a story bible actually is underneath, and why the interface implies something the model never promised.

    Josep11 min read

    The complaint is remarkably consistent, and if you have made it you are in large company. Writers report spending hours filling in a story bible — character descriptions, world rules, what happens when — and then watching the AI introduce a character described as bald with a full head of hair, put a character into chapter one who is explicitly marked as not appearing until chapter three, or change someone's gender partway through a scene. Others report the opposite failure: the bible is not contradicted so much as simply unused, with the generated text bearing no discernible relationship to the outline they spent a weekend building.

    The natural conclusion is that you filled it in wrong. You did not. The behaviour is a predictable consequence of how these features work, and once you can see the mechanism you can both work around it and evaluate tools much more sharply.

    What a story bible is, underneath

    A language model has no memory between requests. Every time it generates text, it receives one block of input, produces output, and retains nothing. There is no database it consults, no file it opens, no persistent knowledge of your novel.

    So when a tool shows you a structured story bible with fields and entries, that structure exists for you and for the tool's own code. To reach the model at all, some portion of it has to be copied into the block of text sent with your request. The interface implies a reference work the model can look things up in. What is actually happening is that some selection of your entries gets pasted above your prompt, every single time, and the model reads it as one continuous stretch of text alongside everything else.

    Which raises the question that explains almost every failure people report: which entries?

    The selection problem

    Your bible does not fit. A serious one for a novel runs to tens of thousands of words; add the relevant previous chapters and your actual instruction, and you exceed what can be sent — or what can be sent affordably, since you are usually billed per word of input.

    So the tool must choose a subset. It typically does this by matching your current scene against your entries and including the ones that look relevant. That retrieval step is invisible, is not something you control, and is where your bald character gets his hair: the entry describing him was not selected, because nothing in the scene you were writing looked lexically like his description.

    This also explains the second failure mode, the one where a character appears three chapters early. Nothing enforced that rule. The constraint lived in an entry that either was not selected or was selected and treated as background colour. Which brings us to the more uncomfortable half.

    Even when it is included, it is not a rule

    Suppose the retrieval works perfectly and every relevant entry lands in the context. Your bible still is not a constraint. It is more text in a block of text, and the model is doing one thing: continuing plausibly.

    Nothing checks the output against your entries. If the generated paragraph contradicts line 4,000 of the input, no error is raised, because no component is comparing them. Plausible continuation is the only objective, and a bald man with hair is entirely plausible prose.

    This is why "put it in the story bible" and "say it again in the prompt" often produce different results. Instructions near the end of the input tend to carry more weight than material buried in the middle of a long block — a well-documented weakness with long inputs, where information in the middle is used less reliably than information at either end. Your carefully structured bible is, structurally, the middle.

    And when a rule is stated as a negative — "does not appear until chapter three", "never mentions the war" — it fares worse still. The name is present in the input, the surrounding text makes them contextually relevant, and the prohibition is a single clause competing against every other signal.

    What this means practically

    Four things follow, and none of them require a different tool.

    Put load-bearing facts in the prompt, not only the bible. If a detail must survive this scene, restate it in the instruction for this scene. Redundancy is not a failure of your organisation.

    Phrase rules positively. "Marcus is bald" beats "do not give Marcus hair". "This scene contains only Ana and Ines" beats "Tomas does not appear".

    Expect to verify, not to trust. The generation step cannot enforce continuity, so the checking has to happen after. That is not a workaround; it is the correct division of labour.

    Judge tools by what they check, not by what they store. A richer bible does not help if nothing compares the output to it. When evaluating a tool, the question is not how detailed its bible can get — it is whether anything validates finished text against it, and what happens when the two disagree.

    The design conclusion we drew

    We think the framing is backwards in most tools, and it shows up in the complaints. A story bible presented as an input to generation is asking the least reliable part of the system to do the enforcing. The same information used as a checking instrument works, because comparing a finished paragraph against a set of recorded facts is a task with a right answer.

    Generation is where models are strong and unreliable. Comparison is where they are boring and dependable. Continuity is a comparison problem that has been handed to the generator, and that is why writers keep having this exact argument with their tools.

    It is also why the two tools we run today analyse text rather than produce it, and why we published the test where our own generation-side product lost. The pattern is not a coincidence.

    The short version

    Your story bible is not a database the AI consults. It is text that may or may not get copied in beside your request, and which functions as suggestion rather than rule even when it does. Nothing is checking the output against it. Restate what matters, phrase rules positively, and treat continuity as something to verify after generation rather than something you can configure before it.

    We are building the version that checks instead of generates

    A story bible that reads your finished chapter and tells you it contradicts entry 47, rather than one that hopes the model reads it first. It is built and running, and we are working out what it should be before opening it up.

    One email when there is something to try — not a schedule. We store your address, which list you joined and where you signed up from, and nothing else. Privacy.