A single source of truth is not one enormous file. It is an agreement about where each kind of current information lives, plus the habit of putting things back there. Manuscripts fork during revision rather than during drafting, because revision is when several people change the same pages and nobody wants to lose their version.
- Declare one canonical draft in writing and name the person who owns it.
- Give the outline, sources, cut passages, and decisions separate homes.
- Keep a cut file so removing a paragraph stops feeling irreversible.
- Use named versions inside one document rather than duplicate files.
- Reconcile offline edits and open threads before every stage handoff.
Manuscripts fork during revision, not drafting
While one person is writing, there is only one draft. The copies appear the moment the piece goes out for review: a downloaded file for the reviewer who reads offline, a pasted excerpt in a message thread, a duplicate made before somebody attempts a risky restructure.
None of those is a mistake on its own. The failure is leaving them alive with nothing to mark which one is current. Two weeks later somebody edits the wrong copy carefully and well, and that work has to be thrown away or merged back by hand.
Declare the canonical draft in writing
Pick one location and state it at the top of the project. Everything else is a copy, a snapshot, or an export. This sounds too obvious to need saying until you count how many long projects have never recorded which file is the real one.
Put the declaration where collaborators arrive rather than inside a message. If a reviewer has to ask which version to open, your source of truth exists only in your head. Add the owner's name beside the link, so there is somebody to ask when the answer is ambiguous.
Every duplicate of a draft is a decision you will have to make again later.
Give each kind of material one home
A long project holds at least five kinds of material: the current draft, the working outline, the source notebook, the decision log, and the cut file. Each needs one place. Mixing them is what makes a manuscript file grow to twice the length of the piece.
Keep research out of the draft. Notes pasted into the body as reminders become published text more often than anybody expects, especially in the final week. Link the source note to the claim instead, so verification stays one click away and the prose stays clean.
Keep a real cut file
Writers resist deletion because the material took work. Give it somewhere to go. A cut file inside the project holds every passage removed during revision, each with one line recording which section it came from and why it left. Nothing in there needs to be tidy.
This habit changes revision behaviour more than anything else on this page. Cutting becomes reversible, so people actually cut. It also removes the main reason for duplicating a whole document, which was usually the wish to preserve one paragraph nobody was ready to lose.
Make status labels mean something
Labels such as drafting, structural review, line edit, approved, and published should each describe a state somebody can verify. Write down what has to be true to enter each one. A status that reflects hope rather than fact is worse than no status at all.
Show the owner and the date of the last meaningful change beside the label. A project sitting in review with no date attached is the most common way a manuscript stalls quietly for a month while everyone assumes somebody else is currently reading it.
Use version history instead of copies
Named versions inside one document give you what duplicates were meant to give you: a recoverable earlier state with no competing current file. Save a named version before each restructure and before each round goes out, naming it for the change rather than a number.
If you must branch the manuscript to develop a different structure in parallel, mark it clearly as an experiment, give it an owner, and give it an end date. When that date arrives, merge it or delete it. An unfinished experiment is how the second final appears.
Reconcile before every handoff
Before the draft moves to a new stage, spend ten minutes reconciling it. Fold in offline edits, close the remaining comment threads, update the outline so it matches the sections that now exist, and archive anything that has stopped being current.
Do the same when the piece publishes. Record the live URL on the project, mark the manuscript as published, and set a date to review it. A finished draft with no link to its published version is how corrections get made in the wrong place months later.
A project folder, before and after reconciliation
Shared folder, week six of a report project: report-draft.docx (last edited 12 days ago) report-draft-v2.docx report-draft-v2-JM-comments.docx report-FINAL.docx report-FINAL-use-this-one.docx notes and links.docx Copy of report-draft-v2 (1).docx Tracker status: "In review" Nobody can say which file the copy editor should open. Two of them hold edits that exist nowhere else, and the tracker has said the same thing since week three, when the first review round opened.
Project home: Current manuscript: Report, working draft (link). Owner: Maya. Status: line edit, entered 4 March. Outline: section plan (link), matching the sections that exist today. Sources: research notebook (link), 31 notes each linked to the claim it supports. Cut file: removed passages (link), 9 entries with reasons. Decision log: 6 entries, most recent 2 March. Snapshots: "before restructure, 18 Feb" saved in the manuscript's version history. Everything else archived. The offline comments were folded in on 1 March.
The first list is not disorganised so much as undecided. Every copy was a reasonable act at the time and none was ever retired. The second version uses no extra tools. It names one current file, gives the other material somewhere to live, and says who to ask.
Common mistakes
| The mistake | Why it costs you, and what to do instead |
|---|---|
| The second final | A file named final needs one more change, and rather than overwrite it somebody creates a second one. Never encode status in a filename. Put it on the project home instead. |
| Research living inside the draft | Pasting a quotation into the body is faster than filing it, so the manuscript becomes a mixture of prose and reminders. Keep sources in a notebook and link them to the sentence they support. |
| Offline review with no return path | A reviewer downloads the document, comments carefully, emails it back, and those edits live in an attachment nobody reopens. Agree before the round that one named person owns folding them back in. |
| Status labels nobody defined | The tracker has said in review for six weeks because nobody wrote down what leaving that state requires. Define the exit condition for each label, and show the date it was entered. |
Your checklist
- Write the canonical draft's location and owner at the top of the project.
- Create separate homes for the outline, sources, cut passages, and decisions.
- Save a named version before each restructure and each review round.
- Archive or delete every duplicate that is no longer current.
- Define the exit condition for each status label you use.
- Record the published URL back on the project and set a review date.
Key terms
- Canonical draft
- The single document declared to be the current manuscript. Every other file is a copy, snapshot, or export, and none may be edited as though it were the original.
- Cut file
- A place in the project holding passages removed during revision, each with a note on where it came from and why. It makes deletion reversible, and therefore likelier.
- Decision log
- A short running list of editorial choices and the reasoning behind them, kept beside the project so that a settled question is not reopened by every new reader.
Getting a draft read by someone else?
Frequently asked questions
Is a shared drive a source of truth?
+
Storage is only half of it. A source of truth also needs a declared current file, a named owner, a status with a written definition, and links that people genuinely use. Without those, a shared drive is a faster way to accumulate copies of the same manuscript.
What if a reviewer insists on working offline?
+
Let them, and decide in advance who transfers their comments back into the manuscript and by when. The offline copy is never the real problem. The problem is the copy that comes back and waits in an inbox while the draft keeps moving without it.
How long should the cut file be kept?
+
Until the piece publishes, at the very least. Most cut material is never restored, but the file's value is behavioural rather than archival: knowing it exists is what makes a writer willing to remove a paragraph they spent an afternoon on.
Should each review round be a new document?
+
No. Use named versions inside one document for rounds. Create a separate document only for a real structural experiment, and give that experiment an owner and a date by which it is either merged into the manuscript or dropped without ceremony.
Where do AI suggestions fit into this?
+
Treat them like any other proposal. Accept them into the canonical draft or leave them out, but do not keep a parallel document of suggested rewrites. Strut AI working against the current manuscript is safer than a rewrite sitting somewhere with no owner.
Who is responsible for updating the status?
+
Whoever owns the stage the piece is in right now. Handing over the stage means handing over the status with it. If nobody owns the current stage, that gap is the real problem, and the stale label is only the symptom you noticed.