The Ten-Page Lore Bible: Canon Tiers, Naming Systems and a Contradiction Pass

Three weeks before your vertical slice is due, your environment artist asks a simple question: "Is the harbour district under imperial control or not? I need to know whether to model banners." Nobody knows. The narrative designer says yes, the level designer built the district as a smuggler's haven, and the quest writer already wrote a line where a guard captain complains that he has no jurisdiction there. Someone has to lose two days of work.

That is what a missing lore bible costs. Not a thinner world — a stalled one. The purpose of a lore bible is not to impress anyone with the depth of your setting. It is to answer production questions in under a minute so nobody has to guess, and so two people guessing differently never reaches the build.

Ten pages beats a hundred

Most first-time lore bibles fail in the same way: they grow into a 90-page novel nobody reads, then quietly stop being updated, and the team goes back to asking each other in chat. A bible that is out of date is worse than no bible, because it produces confident wrong answers.

Aim for something a new contractor can read in twenty minutes. A workable budget for a first pass on a small game:

Section	Pages	What it must answer
Premise and tone	0.5	What kind of story is this, and what would feel out of place?
The world in one page	1	Geography, who holds power, what the conflict is
Factions	2	Who wants what, who hates whom, what each one controls
Timeline	1	Dated events the team may reference
Rules of the world	1.5	Magic/tech limits, costs, what is impossible
Naming systems	1	How to invent a name that fits
Places	2	Only locations that appear in the build
Open questions	1	Deliberately undecided things, with owners

That is ten pages. Everything else — the third-age succession crisis, the etymology of a dead language — is optional colour you write when a scene actually needs it. If you keep your setting in the GameDesignerX lore bible module, resist the urge to create an entry per idea; create entries per question your team keeps asking. Cross-link the ones that already live in Locations and Characters instead of restating them, so a fact has exactly one home.

Canon tiers: decide what is actually locked

The single most useful structure I know for a bible is marking every fact with how firm it is. Three tiers is enough:

• Hard canon — locked. Changing it breaks shipped content, art, or VO. Example: "The Ashfall happened 40 years ago and the protagonist's mother survived it." Changing this invalidates dialogue.
• Soft canon — the current answer, changeable with a heads-up. Example: "The harbour district pays protection money to the Gull Syndicate." A designer can propose a change; the narrative owner approves it.
• Open — deliberately undecided, with a named owner and a deadline. Example: "Do the imperial legions use firearms? — owner: Priya, decide before combat vertical slice."

The tier tells a reader what they are allowed to do. Without it, everyone treats everything as either gospel or a suggestion, and both are wrong. A one-line annotation is enough: [HARD], [SOFT], [OPEN — Priya, by M3].

The tier also tells you where to record the reasoning. When a soft fact gets promoted to hard, or an open question is closed, write the why in your decision log, not in the bible. The bible should say what is true; the decision log says why you chose it and what you rejected. That is what stops the same argument from restarting in four months.

Keep the open questions visible

Resist the instinct to hide undecided things. A bible with a visible Open Questions list is a bible people trust, because it tells them exactly where the soft ground is. Ten open questions with owners is a healthy sign. Zero usually means they are open anyway, just undocumented.

Naming systems, not name lists

A list of 200 invented names is a dead artifact — nobody searches it, and the moment someone needs a name that is not on it, they invent one in the wrong register. A naming system is three or four lines per culture and it scales forever.

Something as small as this is enough:

• Imperial (Vantic) — Latinate, two syllables, hard consonants, -us/-a endings. Castus, Verra, Oldric. Places take -um: Praetorum.
• Coastal (Gull Coast) — trade-pidgin, occupation-based surnames, apostrophes never. Mira Netter, Hal Saltwright. Places are plain descriptive compounds: Longpier, Blackmouth.
• The Deep Order — no personal names in public; titles only. The Third Reader, Warden of Ninths.

Now anyone on the team can name an NPC at 2am and it lands. Add a short banned list: sounds you have decided are out of register (X, Z, Qu for coastal names), plus names too close to existing ones. Marek and Marec in the same build will confuse your QA notes, your VO director, and your players.

Write entries that answer questions, not entries that describe

Compare two versions of the same location entry.

Prose version: "Blackmouth is a grim, rain-lashed port whose crooked alleys have witnessed centuries of quiet violence..."

Usable version:

• What it is: working port, ~8,000 people, under nominal imperial rule
• Who controls it: Gull Syndicate in practice [SOFT]
• Visual keys: tar, wet rope, imperial banners left to rot, no clean stone
• Sounds like: gulls, hull creak, no music in public
• Do not: show imperial soldiers patrolling in force — the point is absence of authority
• Appears in: Chapter 2, side quest "Salt Debt"
• Open: does the Syndicate know about the player's cargo? [OPEN — Sam, by M2]

The second version is shorter and answers the banner question in one line. The Do not field is the highest-value part of any entry; it is the one thing you cannot reconstruct from concept art. Keep the prose — one evocative paragraph per major place is genuinely useful for art and audio briefs — but put it after the facts, not instead of them.

The contradiction pass

Bibles rot at the seams, where a fact is referenced in dialogue, item text, and a quest log. Once a milestone, run a 30-minute pass. It is boring and it catches real bugs.

Checklist:

1. Dates. Every "X years ago" in dialogue, resolved against the timeline. Character ages are the usual failure: someone who fought in a war 40 years ago cannot be 35.
2. Names. Search the build's text for each proper noun. Count spellings. Any noun with two spellings is a bug.
3. Power and geography. For each faction, does every scene agree on who controls what?
4. Rules of the world. Find each use of your magic or tech system and check it against the stated cost. Free healing in one side quest undoes the scarcity your whole plot rests on.
5. Dead links. Any entry referencing a character or location that was cut.
6. Open questions past their deadline. Close them or re-own them.

If your dialogue and item text live in the same workspace as your lore bible, steps 2 and 4 become a search rather than an archaeology project — that is the practical argument for keeping lore next to Dialogue Trees, Items and Timeline instead of in a separate document. The GameDesignerX REST API also makes step 2 scriptable: pull your proper-noun list, pull your dialogue text, and diff them in a few lines of Python as part of your milestone checklist.

What to do this week

If you have no bible at all, do not start with history. Start with the questions your team asked in chat over the last month, because those are provably the ones that block work. Write one entry per question, tier each fact, name an owner for the unknowns. You will likely have five pages by Friday, and it will already be more useful than the 90-page version you were dreading.

Then give it one rule to stay alive: any answer given in chat gets written into the bible the same day, or it did not happen.