A solo author's story bible is a reference they keep for themselves. A team's story bible is infrastructure — the thing that decides whether five people are building one world or five overlapping ones. They look similar and they are not the same tool.
The difference is not size. A team bible could have the exact same sections as a solo one — characters, rules, timeline, threads — and still fail, because the hard part of a shared bible is not what is in it but how the team relates to it: whether everyone reads the same copy, whether it is current, who is allowed to change it, and whether a newcomer can trust it. Those are properties of the bible as a shared object, and they are exactly the properties a solo author never has to think about.
If you already know what goes into a story bible, this is the next question: how do you run one so a whole team actually shares it, instead of each person quietly keeping their own?
Why private bibles drift apart
The default failure is not having no bible — it is having several. One writer keeps notes in a doc, another in their head, a third in the margins of a script, a fourth in a Notion page nobody else has the link to. Each is internally consistent and they disagree with each other, and because no two people ever read the same one, the disagreement stays invisible until it ships.
This is the multi-copy problem, and it is the root cause of nearly every team continuity break. Two contributors make locally reasonable decisions against their own copies — one writes the artifact as destroyed, the other as merely hidden — and neither is wrong inside their own bible. The contradiction does not live in either person's work. It lives in the gap between two copies that no one is comparing.
A shared bible exists to collapse those copies into one. Its first job is not completeness; it is singularity. There should be exactly one place the team agrees the truth lives, and everything else — a writer's outline, a margin note, a draft — is understood to be a draft on the way into it, not a competing version of it.
It has to be live, not launch-day
The most common way a shared bible dies is that it freezes. Someone writes a thorough bible at the start of a project, the team refers to it for a month, and then the work moves on without it — decisions get made in meetings and drafts, the bible falls behind, and within a season it describes a world that no longer exists. People keep half-trusting it, which is the worst state of all: they cite a record that is partly wrong and cannot tell which parts.
A shared bible has to be the place decisions are made, not a transcription updated later if someone remembers. The instant the team rules that a character's brother is alive after all, that ruling lands in the bible the same day, in the one place everyone already reads from. A bible that trails the real decisions by even a week is a bible the team has quietly stopped believing.
Structure it for sharing, not just storing
A team bible has to be readable by people who did not write it. That means facts kept atomic and findable — "as of season two, she leads the council" rather than a paragraph only its author can parse — and a structure where anyone can locate a character, rule, or thread without asking the person who added it. The test is simple: if finding a fact requires knowing who wrote it down, the bible is organized for its authors, not for the team.
It also means the bible carries the kind of facts teams break on, not just the easy ones. Anyone can record that a character exists; what gets left out is what they know and when, what the world's rules cost, what the timeline asserts, and which threads are still open. Those time-dependent, relational facts are precisely the ones a team contradicts, and they are precisely the ones a shared bible has to make explicit so a contributor can check their work against the world before adding to it.
The test: could a newcomer write a scene?
The cleanest way to know whether your shared bible is actually working is the onboarding test. Hand it to a brand-new collaborator and ask them to write a scene that does not break the world. If they can — if the bible answers their questions about who knows what, what the rules are, and where the open threads stand without them having to interview the team — the bible is doing its job.
If instead they come back with a list of questions only a veteran could answer, every gap in that list is a place your canon currently lives in someone's head rather than in the shared record. Teams change; people leave a room, a co-author joins mid-series, a new narrative designer inherits the world. The shared bible is what survives that turnover, and the onboarding test is how you find its holes before the turnover does.
Permissions and history keep it trustworthy
For a shared bible to stay the source of truth, the team has to trust it — which means controlling who can change canon and recording every change. A wide group should be able to read and propose; a smaller group ratifies. That separation is not bureaucracy; it is what keeps the canon from being quietly overwritten by whoever edited last, and it gives the team a single answer to "is this actually canon now?"
Every change should leave a trail: what shifted, when, and by whom. That history is what lets a team trace a contradiction back to the decision that caused it, and what lets a new contributor trust that the record reflects ratified canon rather than someone's unreviewed edit. A shared bible without permissions and history is just a faster way to overwrite each other.
Where CanonBoard fits
CanonBoard is a shared story bible built for these properties from the start. The world lives on one open canvas as connected, typed cards — characters, world rules, plot threads, lore, a real timeline — with shared editing, role permissions, and change history, so a team gets one live copy instead of five drifting ones, current as of the last decision and traceable to who made it.
And because the bible is structured rather than prose, it can check itself. CanonBoard scans the whole board on demand and surfaces the contradictions that hide in the gaps between contributors — both sides quoted, the conflict named — so the team settles them while the world is still cheap to change. One bible the whole team shares, that argues back when the team disagrees with itself.
Frequently asked questions
- What is a shared story bible?
- A shared story bible is one canonical record of a story world that an entire team reads from and writes to — as opposed to a solo author's private bible. Its job is to be the single source of truth so the team never works from conflicting copies.
- How is a team story bible different from a solo one?
- A solo bible mainly has to be complete. A team bible also has to be live, shared, permissioned, and traceable — current the moment canon changes, readable by everyone, editable by the right people, with a history of what changed and why.
- How do you keep a shared story bible from going stale?
- Make updating it part of the moment a decision is made, not a separate chore. When canon changes in a meeting or a draft, it should land in the shared bible the same day, in one place everyone already reads from.
CanonBoard scans your whole world and tells you where it disagrees with itself.
Start free