Merge Parallel Series-Bible Edits Without Losing Either Writer's Changes
Merge Parallel Series-Bible Edits Without Losing Either Writer’s Changes
Two writers hand back the same series bible, each carrying a season's worth of decisions in the margins and a few new ones in the body text. The fastest move is also the one that quietly erases a colleague's work: find the file with the later timestamp and keep drafting from that. Don't.
The two returns are evidence, not competing candidates. Your job is to recover both sets of changes, keep each one attached to the person who made it, and surface the places where they disagree before anyone writes the successor. Combining preserves alternatives for judgment. It cannot perform the judgment, and a combine that runs cleanly tells you nothing about whether the writers agree. A series bible is a set of claims about a world, and two editors can produce individually sensible claims that cannot both be true.
So the work has a shape. Preserve the returns untouched. Establish what each writer actually started from. Combine only when the starting points match. Then read the combined story for contradictions that no software flags. When the starting points diverge, reconstruct narrowly instead of forcing a merge. Everything unresolved goes on a decision list, not into the review document as though it were settled.
Preserve the returns and identify their starting points
Before you open anything, copy both attachments into a folder and mark them read-only. Keep the originals bit-identical; every operation from here runs on a copy. When something goes wrong three steps later, you want the untouched file to fall back to.
Then answer one narrow question: did these two writers edit the same document version, or did one of them begin from something older? Filenames will lie to you — both returns are probably named after the show, with a stray "final" or a person's initials attached. A recent modification date tells you when someone last saved, not what they started from. The evidence you want is inside the documents.
Compare each return against the candidate baseline and read whether the differences look like editorial revisions or like a different starting point. A handful of changed lines, each attributable to a writer's intent, suggests a shared ancestor. A whole section present in your distributed copy and simply gone from a return is ambiguous: it could be a deliberate cut, or a writer who never had that section to cut. Which one it is decides everything downstream, so don't guess. Find the file you actually distributed, note its saved date, and check what was added to the bible between drafts — you may discover the Rules section arrived after one writer had already received their copy.
Accepted changes are a related trap. A writer who worked with tracked changes on, then accepted them all and saved, returns a file that looks clean. That is not a problem by itself: as long as you still have the baseline the writer started from, you can recover what changed by comparing the two. Losing the baseline is the problem. So verify it before you combine, and when a shared starting point cannot be established, say so. Whatever you do, don't nominate one returned copy as authoritative just to manufacture a common ancestor you never confirmed. That move makes the file look mergeable while quietly overwriting the other writer's base text.
Combine into a review document, with contributors identified
The example running through the rest of this piece is invented, and its files and edits stay fixed from here on. It is a fictional six-episode limited series called Foxglove. The combine behavior I describe is the documented behavior of Word's Combine command, not a run performed on these particular files.
The baseline, foxglove_bible_v0.docx, went to both writers. Two sections matter. In §2 (Setting): "The Bellamy Institute has stood on the same foundation since 1871." In §3 (Rules of the Institute): "The sub-basement vault cannot be forced. It opens only by its own mechanism."
Writer A returned foxglove_bible_A.docx with three changes. Writer B returned foxglove_bible_B.docx with two.
| # | Where | Writer | Change |
|---|---|---|---|
| 1 | §2 | A and B | both rewrite the founding year — A to 1859, B to 1904 |
| 2 | §4 | A | inserts a paragraph: the registrar, Bea Okonkwo, keeps every access order in a paper ledger |
| 3 | §3 | A | adds: the vault threshold is keyed to Ines alone; anyone else is turned back at the door below |
| 4 | §5 | B | adds: Ruiz descends the vault stair alone and reads the ledgers by her flashlight |
For a verified shared baseline, the documented route is Review > Compare > Combine in a desktop Word version that offers it. The command produces a new comparison document rather than overwriting either input, and it labels revisions by the file they came from, which is what puts a contributor's name on an edit that no longer carries visible tracked markup. When you fold in the second return, run it as a further combine into that review document, and then check that the first contributor's alternatives are still represented. Preserve a snapshot of the review document between combines so you can see what each step added.
Two habits keep this honest. Work on copies, always, so a mis-click cannot touch the received files. And write down the platform and settings you used — Combine is a desktop feature, its labels and its handling of certain revision types have shifted between editions, and it is not the same tool on the web app. Recording what you actually ran beats asserting that it behaves identically everywhere.
Keep the nature of the operation in view. Combine attributes changes and lays them out side by side. It does not accept them, and it does not decide which are correct.
Review textual overlap and semantic contradiction separately
Run two distinct passes over the review document, because they catch different failures.
The first pass is textual. Read the competing replacements, insertions, deletions, and comments against both returned copies. In the example, edit #1 is a genuine overlap: both writers rewrote the same clause of §2, so the comparison document shows the baseline text struck through and both replacements present, each tagged with its source. That is a testable conflict — one year, two claims — and you resolve it by choosing one or writing a third. Edit #2, the registrar paragraph, has no competing edit and simply survives; nothing needs deciding. Editing, the levers here are ordinary: inspect each attributed change, confirm nothing was attributed to the wrong file, and check the comments as carefully as the visible text, since a comment can carry a decision that the body text does not.
The second pass is different in kind. Read the combined story as a story and ask whether its facts can coexist. Edits #3 and #4 differ from #1 in every way that matters. They sit in different sections, §3 and §5, and they share no sentence. The comparison document prints both as clean insertions and flags nothing, because nothing textual overlaps — the contradiction lives at the level of world facts. A's rule says the vault threshold admits Ines and turns everyone else back. B's scene puts Ruiz inside that vault, alone, reading its ledgers by flashlight. If A's rule is true, B's scene cannot happen as written. No combine command will tell you this, because no combine command reasons about your show.
This is the pass that pays for the whole method, and it is the one an editor working from a single tidy file will skip. Each writer's addition is defensible alone. Writer A is building a rule that gives Ines a unique relationship to the vault; Writer B is building a plot beat where the detective gets one unsupervised look. Neither is wrong in isolation. Together they describe two incompatible vaults.
Once you have both passes in front of you, move the unresolved items onto a decision list rather than into the review document. Give each row the disputed point, the source passage in each return, the competing alternatives, who owns the call, and its status. The list is where canon gets settled; the review document is where material gets preserved. Keeping them separate is the difference between "we decided B's scene wins and A's rule needs a rewrite" and "the review document has both, so it must be fine."
Reconstruct cautiously when baselines differ
Now change one fact and hold the rest. Suppose Writer A had opened an earlier file — foxglove_bible_early.docx, the draft that circulated before the Rules section existed — and edited that instead. Everything else is as before, except A's return contains no §3 at all, because the file A started from had none. The vault rule isn't part of this version of events; A never had a section to add it to. A's real changes are the founding year and the registrar paragraph.
Combine A and B directly and the review document fills with noise. §3 shows up whole from B's file and appears as though A had done nothing with it, or worse, as though A had deleted it. The differences you are looking at now mix genuine edits with baseline drift, and nothing in the automatic output tells you which is which.
The disciplined alternative is bounded reconstruction. Compare each return against its own known baseline where you can — A against the early draft, B against foxglove_bible_v0.docx — which separates earlier settled text from the new contribution and yields two small, attributable change sets. Lay those two sets beside each other in the review document by hand. You are no longer asking a tool to relabel a century of ignored text as revisions; you are placing edits next to edits. Where the history stays unclear, keep it unclear on paper: write down that A's baseline is unconfirmed and why, and carry that uncertainty forward instead of resolving it by fiat.
The failure case worth naming is the inference that looks decisive. A's file lacks §3, so someone rules that A "rejected the Rules section" and drops it. But A never had §3 to reject — the earlier draft predates it, and absence is not a decision. The same error shows up in the shared-baseline case: A's vault rule sits in the review document, B never comments on it, and the team records "B approved it." Silence is not approval either. Both inferences feel like conclusions and are neither.
Reconcile the successor against the evidence
After the authorized decisions are made — by whoever owns canon, not by whoever ran the merge — build a fresh successor document rather than continuing to edit the review copy. Then reconcile its wording against both returns and against the decision list. Every deliberate change should trace to a decision and to the source passage that prompted it. Retain the review copy, the baseline or baselines, the intermediate snapshots, the decision list, and the finished successor as one evidence chain. If a question resurfaces in six months, that chain answers it without re-reading two bibles from scratch.
End with both writers' changes accounted for and every choice in the successor traceable to a person. The test is not whether the merge finished. It is whether you can point to each change from each writer and say what became of it and who decided. Present in the review document is not the same as accepted. Absent is not the same as rejected. The tool preserved the alternatives; people chose among them. That division of labor is the whole point: software can hold two versions of the vault in one document, but it cannot tell you which vault the show is in.
Frequently asked questions
Why not just keep drafting from the series bible returned with the later timestamp?
That move quietly erases a colleague's work. The two returns are evidence, not competing candidates. The job is to recover both sets of changes, keep each attached to the person who made it, and surface places where they disagree before anyone writes the successor. Combining preserves alternatives for judgment; it cannot perform the judgment.
How can you establish whether two writers edited the same series-bible version?
Filenames and modification dates do not prove a starting point. Compare each return against the candidate baseline and read whether differences look like editorial revisions or a different starting point. A handful of changed lines attributable to writer intent suggests a shared ancestor. A whole section present in the distributed copy but absent from a return is ambiguous: it could be a deliberate cut or a writer who never had it. Verify the shared baseline before combining, and do not nominate one returned copy as authoritative just to manufacture a common ancestor.
What does Word's Combine command do, and what does it not do?
In a desktop Word version that offers it, Review > Compare > Combine produces a new comparison document rather than overwriting either input, and it labels revisions by the file they came from. Fold in the second return as a further combine into that review document, then check that the first contributor's alternatives are still represented. Combine attributes changes and lays them out side by side; it does not accept them or decide which are correct.
What is the difference between the textual pass and the semantic pass over the review document?
The textual pass reads competing replacements, insertions, deletions, and comments against both returned copies; it catches genuine overlaps like both writers rewriting the founding year. The semantic pass reads the combined story as a story and asks whether its facts can coexist. A's rule that the vault admits Ines alone and B's scene of Ruiz inside the vault share no sentence but contradict at the level of world facts, and no combine command flags that because it does not reason about the show.
What should happen when the writers' starting points differ?
Use bounded reconstruction: compare each return against its own known baseline where possible, producing two small attributable change sets, then lay those sets beside each other in the review document by hand. Keep uncertainty on paper rather than resolving it by fiat. Do not infer that an absent section was rejected or that silence on an edit was approval. After authorized decisions, build a fresh successor and reconcile it against both returns and the decision list, keeping an evidence chain.