Edit a Series Bible for the Collaborator Who Has to Build From It
Edit a Series Bible for the Collaborator Who Has to Build From It
A development bible usually fails its collaborator in the same place: it never says which sentences are rules.
Page 6 holds a settled decision. Page 22 holds a sample scene that quietly breaks it. A note halfway down another list asks whether the breaking should be allowed. Nothing in the document separates the three, so the incoming writer does the only thing the document permits — guesses — and builds an episode on the guess. Two weeks later the creator reads it and says no. Both people did their jobs. The bible is why they disagree.
The repair is mostly not a rewrite. For a document that will be handed to another writer or director, the work that pays is a status pass. Every claim in a bible is doing one of three jobs: it governs the work, it illustrates a possibility, or it is waiting on a decision. A collaborator can act confidently on all three. They cannot act confidently on a pile where the three are indistinguishable.
Identify which kind of bible the collaborator needs
Three different documents get called the bible, and they are edited three different ways.
A pitch bible exists to get the show evaluated. It argues. Its reader is deciding whether to say yes, and it is allowed to be persuasive — often it presents one possible version of the series as if it were the plan, because a pitch is a bid, not a contract.
Development material exists to explore the show while it is still being discovered. This is the document you hand to an incoming writer or director. Its reader is deciding what to make.
A production reference carries settled continuity for people already making the show: how a name is spelled, what the building looks like from the street, what happened in episode four. Its reader is deciding what may not change.
Screen Australia's guidance on drama story documents keeps the pitch-facing account and the production-facing reference as separate jobs — in its 2018 edition, that distinction sits on the page headed "The bible." That guidance is Australian, it is about drama development, and it is not a page-count rule; it doesn't settle how long anything should be. The distinction travels even where the vocabulary doesn't.
This article edits the middle document. A pitch deck usually needs cutting; a production database needs discipline; a development handoff needs something else — enough shared decisions to support new work without pretending every idea is settled. When one file is made to do all three jobs, you get the mess in the opening: an argument, an exploration, and an instruction manual in a single binder, with no way for a stranger to tell which is which.
Begin with the collaborator's actual question
Before moving a page, write down what the person has been asked to make. Not the show — the task. One episode set on the night the manager is away. A recurring location designed to hold three different kinds of scene. A character's first real scene after a season of being talked about.
That sentence decides the route through the document. For any single task, a development bible holds three kinds of useful content: the world rules that constrain what can happen, the state of the relationships at this point in the story, and where the show currently stands in its progression. Everything else is either inspiration or noise, and it pays to be honest about which you're keeping.
The test is not whether a passage is interesting. It's whether the collaborator needs it to answer the question in front of them, or would make something better for having read it. Inspiration earns its place the same way a constraint does: a vivid detail about how the house sounds at 3 a.m. might be exactly the thing that produces the shot a director was hired to find. What doesn't earn its place is lore the collaborator must carry without using — the second cousin's history, the town's politics, the joke that only lands if you've read the pilot three times.
Note the trap. Relevance is not the same as brevity. If you cut the passages about how the boardinghouse makes its money because they seem unglamorous, you may remove the reason a room cannot simply be handed to someone — and then your collaborator writes a scene the show can't afford. Trim by task, not by taste.
If you're editing for more than one person, add a short routing note near the front: a few lines, one per reader, naming the pages that person needs first and the pages they can postpone. Two routes and a heading beat a forty-page document that everyone reads in the wrong order.
Give fixed decisions, examples, and questions different status
Three labels do most of the work.
Governing. A settled choice. A proposal either follows it or asks to change it. This is where the show's real rules live: authorization, chronology, who knows what, what the premise forbids.
Illustrative. A demonstration of a possibility. It shows one way a story could go. A collaborator may diverge from it without asking permission, unless the divergence contradicts something governing. Marking a sample story illustrative is what turns it from a precedent into a resource.
Open. A question the show has not answered. Proposals may explore it; they may not assume an outcome. Open is not the same as forbidden, and it is not the same as settled. It's a third thing, and most bibles only have room for two.
Two rules keep the conflict cases honest.
First, you cannot resolve a contradiction by merging the passages. A compromise sentence is a new decision, and the person editing the bible is usually not the person allowed to make it. Turn the conflict into a visible choice instead, with a name on it.
Second, that name has to be real. "Owner: to confirm" is a better entry than an invented authority, and it is a better entry than guessing. Find out who actually holds the call — creator, showrunner, the network, the director with a hold on the material — and write down what you know, including the fact that you don't know. A document that assigns authority it doesn't have is worse than one with a gap in it.
Then add the half-page key: three lines telling the collaborator what each label confers. Say plainly that illustrative grants permission to diverge. A label the reader has to interpret is only half a label.
Finally, give each governing decision a short "if this changes, check:" list. Three or four lines at most, naming the passages that would need a second look. This is not a continuity database and shouldn't try to be one. It's a note to your future self about which other pages lean on this one.
Answer one worked continuity query
Here is a constructed example, invented for this article and used through the rest of it.
A boardinghouse comedy's development bible contains three relevant passages. One states a rule: only the manager can authorize a guest's stay. One is an unlabeled sample episode in which the caretaker offers a vacant room to somebody while the manager is away. One, buried in a list of notes, asks whether an emergency discretion clause should exist.
An incoming writer has been asked to develop tonight's story, and the manager is away. The query is one line: Can the caretaker offer this room tonight?
The question is answerable, but only after the passages get status. The edit produces three entries.
Settled — governing. Only the manager authorizes a guest's stay. State who the manager is, whether the rule comes from the house, the law, or the manager's own temperament, and what counts as authorization — a signature, a phone call, a note under a door. A rule with no texture is a rule nobody can dramatize.
Illustrative — dependent. The sample episode in which the caretaker offers the room. Label it for what it is: one version of what an emergency-discretion story could look like. It presumes an exception the show has not adopted. It depends on open question 1. Note that the episode demonstrates that someone imagined the exception working; it does not establish that the house permits it, or ever has.
Open — decision needed. Should the caretaker hold emergency discretion to authorize a stay while the manager is away? Undecided. Owner: to confirm.
Now the query has an answer. Not tonight — not as the bible currently reads. Authorization runs through the manager, the manager is away, and the emergency discretion the sample leans on is a question, not a rule. The caretaker may not offer the room.
Two routes are permissible for the writer's proposal, and they are different kinds of thing.
The first stays inside the settled rule. The scene becomes what the caretaker does instead of offering the room: tries to reach the manager, stalls the guest, refuses and lives with the cost of refusing. This is ordinary development work, and the bible already supports it.
The second explores the open question directly. The caretaker offers the room, the story is about what that costs her, and the proposal is flagged as a bid on the undecided question — a scene written to help the show decide, not a depiction of how the house works. The writer isn't taking the decision. They're asking for it in the only language a writers' room fully reads, which is a scene.
What cannot be assumed is the third thing: that the exception exists. If the new episode shows the caretaker granting the room and every character treats it as normal, the episode has quietly decided a question the show hasn't. That is how an illustration becomes law — not by anyone choosing it, but by nobody noticing it.
Now run the decision both ways, because that's the part a collaborator needs most.
If the discretion is granted, with limits. The governing entry gains an exception: who may use it, under what condition, what the manager can undo on return. The sample episode is relabeled as conforming. And every passage that assumes the manager is the only gatekeeper needs review — any scene where a stay is granted or refused, any plot that runs on the manager's absence being absolute.
If the discretion is refused. The sample episode is relabeled as a counterfactual, or cut. The true illustration becomes a scene where the caretaker withholds the room. The open question closes and moves into the governing column with an answer attached.
Notice that the sample scene might survive either way. What changes is what it is an example of. That is the whole point of the pass: not to delete the ideas, but to stop them from voting.
And then stop. You have answered one query about one decision. A bible that tries to pre-answer every query becomes the production database you weren't editing.
Check that the handoff permits new work
When the pass is done, ask the collaborator for one short new scene or episode beat — something the bible doesn't already contain. Then read it against two questions. Does it belong to this show without copying an existing example? And if it follows a rule, is the rule a governing one; if it diverges, is the divergence in territory you labeled illustrative or open?
The failure modes are recognizable.
If the only correct scene the collaborator can produce is a retelling of your sample episode, the sample has become a constraint, whatever label you gave it. If every new idea needs a permission check before it can be written, you have turned open questions into approval gates and taught the writer to wait. And if the collaborator can't tell whether they're following a rule, using an example, or opening a question without asking you, the status pass isn't finished.
Run this as work, not as an exam. Hand the scene over as something you want, and mean it — a document that grades its reader stops being a resource the moment the grade lands.
Testing the edited material with an actual collaborator, under an agreed scope and with a note of what they had to infer, is the check that tells you whether the labels hold. That check hasn't happened for the example above; the boardinghouse and its query are constructed for the exercise, and the honest version of this step is still in front of you.
What the document has to say out loud
A development bible earns its keep when it lets someone else ask a question you haven't answered yet and still make something.
That means leaving room on both sides. Not every possibility should harden into a rule, and not every open question should become another thing to be approved. The document's job is narrower and more useful than either: to say which claims govern, which demonstrate, and which are still yours to decide.
In the boardinghouse, the caretaker's offer might turn out to be the best scene the show ever has. That's an argument for writing it — and for deciding first, or at least for writing it down as undecided while it's still undecided. The bible's job, in the meantime, is to say so out loud, so the next person doesn't have to guess.
Frequently asked questions
Why does a development bible often fail its collaborator, and what is the main repair?
It never says which sentences are rules. A settled decision, a sample scene that quietly breaks it, and a note asking whether the breaking is allowed can all look alike, so the incoming writer guesses. The main repair is mostly not a rewrite: do a status pass, marking every claim as governing, illustrative, or open.
What are the three kinds of bible, and which one does this editing pass address?
A pitch bible argues to get the show evaluated, and its reader is deciding whether to say yes. Development material explores the show while it is still being discovered, and its reader is deciding what to make. A production reference carries settled continuity for people already making the show, and its reader is deciding what may not change. The editing pass addresses the development handoff: enough shared decisions to support new work without pretending every idea is settled. A pitch deck usually needs cutting, and a production database needs discipline.
How should governing, illustrative, and open claims be treated?
Governing means a settled choice: a proposal either follows it or asks to change it. Illustrative means a demonstration of a possibility: a collaborator may diverge without asking permission unless the divergence contradicts something governing. Open means a question the show has not answered: proposals may explore it but may not assume an outcome. Add a half-page key saying what each label confers, and state plainly that illustrative grants permission to diverge.
In the boardinghouse query, can the caretaker offer the room tonight, and why?
Not as the bible currently reads. Only the manager authorizes a guest's stay, the manager is away, and the sample episode in which the caretaker offers the room is illustrative—it presumes an emergency-discretion exception that is still open and undecided. The caretaker may not offer the room. The writer can either stay inside the settled rule, making the scene about what the caretaker does instead of offering the room, or explore the open question directly and flag the proposal as a bid on the undecided question. What cannot be assumed is that the exception exists.
What are the failure modes after a status pass, and how should the handoff be tested?
If the only correct scene a collaborator can produce is a retelling of the sample episode, the sample has become a constraint whatever label it carries. If every new idea needs a permission check, open questions have become approval gates. If the collaborator cannot tell whether they are following a rule, using an example, or opening a question without asking, the status pass is not finished. Test by asking for one short new scene or beat the bible does not already contain, then read it against whether it belongs without copying an existing example and whether any divergence sits in territory labeled illustrative or open. Do that as work, not as an exam; testing with an actual collaborator under an agreed scope and a note of what they had to infer is the check that tells you whether the labels hold. That check has not happened for the constructed boardinghouse example.