Evidence · mechanism
How canon is maintained.
A story bible is only worth checking against if it is structured, and only trustworthy if each fact in it can be traced back to the passage that established it. This page describes how that actually works in the product — the shapes the data takes, what ties a fact to your prose, and what the checker reads at each scale. It is written so you can open the studio and match it against what you see.
Structure
Entries, links, and an index of names.
Canon lives in your project’s own store — a Durable Object with its own SQLite database, one per project, not a shared table with a project column. Three shapes carry it.
- Entries. One row per canon fact-holder — a character, a location, a rule, a piece of history. Each has a section and an optional subsection, a slug, a title, a body, and structured frontmatter. The section/subsection/slug triple is unique, so there is exactly one entry per path and a second one cannot quietly appear alongside it.
- Links. Typed edges between entries — this character belongs to that organisation, this location sits inside that region. Directed, with a kind, and cascading: delete an entry and its edges go with it rather than dangling.
- An index of terms. A term-to-entry table, which is what lets a name in your prose resolve to the entry it refers to without you tagging it by hand.
Provenance
Every fact records what established it.
This is the part that makes canon checkable rather than merely stored. When a fact is accepted into an entry, the product writes a provenance row beside it: the paragraph it came from, the excerpt itself, what kind of fact it is, and why it was proposed — with a timestamp.
- It is the “established by” ledger. An entry does not just assert that a character has green eyes; it carries the passage where that became true, so the claim can be checked against the manuscript rather than taken on trust.
- It is append-only. Rows are added, never rewritten. Accepting a fact, reverting it, and accepting it again does not produce three contradictory histories — the ledger de-duplicates on the entry and source paragraph, so the record stays one row per passage.
- It is what a contradiction is measured against. A finding that says two passages disagree is only useful if it can name both. The excerpt is what lets it.
Scale
Three scales, because three different questions.
Checking a scene and checking a trilogy are not the same operation, and pretending otherwise is how a checker becomes either too slow to use or too shallow to trust.
- One chapter. Analysis and checks take a chapter and a focus — structure, style, logic — and read that chapter against canon. This is the scale you use while drafting, because it is the one whose answer arrives while you still remember what you were trying to do.
- The whole manuscript. Validation takes the project and reads all of it at once. It is the only scale that can find a contradiction between chapter three and chapter thirty, because it is the only one that has both in view.
- Across volumes. A series check reads canon and prose across the books in a project, which is the scale at which rereading to verify stops being something anyone actually does.
What this page does not tell you is how often the checker is right. That figure would depend on your manuscript, and any number quoted here would be one we could not stand behind for your book. What we can show you is the output of a real run, findings and misses together — see worked examples, and what Loreon does not do.