Most nonfiction authors have a reference library. Fewer have source tracking. The difference matters most in the middle of a revision, when the prose is moving and the citations are the last thing anyone wants to re-open.
A library answers “what did I read?” Source tracking answers a harder question: “which source supports this sentence, what does it actually do for the claim, and is that link still true after I moved the paragraph?” Those are different data structures, and confusing them is one reason careful drafts still ship with unsupported claims.
1. Citations are not source tracking
A bibliography is a list of sources. It does not know which claim each source supports. It cannot tell you that chapter four and chapter seven make incompatible assertions from two different studies. It cannot tell you that a quotation was trimmed after the source check, so the sentence no longer matches the passage it cites.
Source tracking is the layer above the bibliography. It links sources to claims, records what each source does, and keeps a pointer into the manuscript so the link can be re-checked when the text moves.
2. The four fields every tracked claim needs
You do not need a complex database. You need four fields per claim, applied consistently:
- Claim — the assertion as the manuscript words it, in one sentence.
- Sources — the specific documents, datasets, interviews, or pages, each with a role.
- Evidence status — what the sources do for the claim, not merely that they exist.
- Manuscript anchor — the passage the claim supports, precise enough to find again.
If a claim has no source field, it is a gap. If it has a source but no status, you have not decided anything. If it has a status but no anchor, you cannot tell whether the check still applies after an edit.
3. Separate the library from the ledger
The library and the ledger do different jobs, and merging them creates the usual mess.
- The library holds sources: title, author, date, publisher, URL or file, and whatever metadata you need to find it again.
- The ledger holds claims and their dependencies: which source supports which claim, in what role, at what point in the text.
One source can support many claims. One claim can need several sources. A library cannot express that many-to-many relationship, which is why a bibliography alone can lose the thread of a long argument.
4. Track evidence status, not just presence
“Cited” is not an evidence status. It says a pointer exists; it says nothing about what the pointer does. A useful status set distinguishes at least these roles:
- Supports — the source directly backs the claim as worded.
- Weakly supports — the source is relevant but partial, indirect, or low-confidence.
- Disputes — credible sources disagree, and the disagreement belongs in the text.
- Contradicts — the source conflicts with the claim; the claim needs revision or the conflict needs acknowledgment.
- Mentions — the source refers to the topic but does not establish the claim.
- Background / method / limitation — the source informs context, method, or caveats rather than the headline assertion.
The point of the status is to stop a common substitution: a real source attached to a claim it does not support. Status makes that visible before an editor does.
5. Anchors make the link re-checkable
An anchor is a pointer from the claim back to the passage it supports. A quote plus a stable location is enough; offsets or a passage marker help. The anchor does two jobs:
- It tells the next reader exactly where the claim lives in the manuscript.
- It detects when the passage has changed, so the source check can be re-run.
A stale anchor is not a failure of the system. It is the system working: it tells you that the text moved and the old check no longer applies to the new sentence. The alternative — a silent mismatch between a claim and a source — is the failure.
6. Contradictions are a first-class output
Long manuscripts contradict themselves in ways a chapter-by-chapter read can miss. Chapter four cites one study; chapter seven cites another; the two findings cannot both be true as stated. Each chapter looks fine alone.
A source-tracking system should surface those conflicts as an explicit exception list, not bury them in a bibliography. The author then decides: reconcile the claims, qualify one of them, or explain the disagreement in the text. Any of those is better than shipping an argument that contradicts itself.
7. When a source changes your mind
Sources change. A correction appears, a retraction lands, a newer study supersedes the one you relied on. The temptation is to quietly edit the sentence and move on. The better move is to record what changed and which claims are affected, then update their status.
That record is what lets you tell an editor, a fact-checker, or a reader why the book says what it says. It also stops the same stale source from reappearing in a later chapter that was drafted before the change.
8. A weekly maintenance loop
Source tracking is not a one-time pass. A workable loop looks like this:
- As you draft, add the claim and attach the source at the moment you write it. Retrospective source hunting is where claims get lost.
- Before an editor sees a chapter, run the exception list: claims with no source, weakly supported claims, and contradictions.
- After a structural edit, re-check the stale anchors. The text moved; the links need to move with it.
- When a source changes, update the status and the affected claims in the same pass.
The loop is deliberately small. A system you will actually run beats a perfect taxonomy you abandon after two chapters.
9. Start with five claims
If you want to see the gap-finding half before you commit to a full ledger, try the free five-claim source-gap check. It shows which claims name no source and which numbers, causal claims, and universals are unsupported. It is a gap check, not a fact-check; the source still has to be opened and read.
The Claim Ledger is the full version: every claim with its sources, evidence status, and manuscript anchor, plus the whole-manuscript exceptions that a single read misses.