Nothing gets lost: the conservation ledger

The scariest moment with any citation checker is not a bad verdict. It is a number that doesn't add up: your document plainly has more references than the screen is showing, and the tool offers no account of the difference. An audit trail — every line kept, matched, or set aside, none silently dropped — is the difference between a checker you consult and a checker you trust.

This post explains a rule we build the whole product around. We call it conservation, and it is exactly what an accountant means by the word: everything that enters must appear on one side of the ledger or the other, at every step, and the totals must reconcile to the line.

The rule: what goes in must be accountable coming out

When CitationLab reads your document, every citation-shaped thing it finds gets an identity — the in-text citations, the bibliography entries, and the lines that merely look like one of those but aren't. From that moment the rule holds: each of those identities lives in exactly one named place at all times. Not zero places, which would be loss; not two, which would be double counting. One.

Every screen you move through — extraction, review, cross-check, export — is a boundary where the books are balanced. The number that entered a stage must equal the number the stage can show you, summed across everything it holds: the citations on screen, the entries matched to your bibliography, and the material you or the tool set aside. If the arithmetic ever failed to reconcile, that would be a defect in the checker — not a detail of your thesis.

read from the document          412

  in-text citations             268
  bibliography entries          121
  set aside as non-citations     23
                              ─────
  accounted                     412   ✓ balances to the line

counts are illustrative — the rule, not the totals, is the point

"Set aside" is a place, not a verdict — and never a deletion

Real documents are full of things that look like citations and are not: figure labels, section cross-references, a date in running prose. We collect these as chaff — and the important word in that sentence is collect. Chaff is a drawer you can open, not a bin that empties itself. The same is true of everything you dismiss or delete by hand while reviewing: the action moves the item to a named place and writes down that it happened. Undo is possible precisely because nothing was destroyed.

A checker earns trust not by what it shows you, but by being able to account for what it doesn't.

This has a user-interface consequence we treat as law: absence from the screen must never mean absence from the ledger. A panel with nothing left to show tells you it is empty — it does not quietly vanish, because a vanished panel and a lost item look identical from where you sit. Zero is a count we display, not a reason to hide.

Why tools lose things — and why silence is the real failure

Losing citations is not exotic. It is what naturally happens when software filters what it isn't sure about: a confidence threshold here, a "minimum plausible entry" rule there, a de-duplication step that collapses two records into one and forgets the second existed. Each filter is individually reasonable. Together they produce the worst possible behaviour: a clean-looking result with an unexplained hole in it — the exact failure that convinced one student 90% of her citations had failed when nearly all of them were fine.

So we hold two lines. First, extraction is deliberately generous: we never add a filter that finds fewer things — doubt routes an item into chaff, where you can see it, rather than out of existence, where you can't. Second, every transformation that changes the count is recorded as a movement between places. When two records merge as duplicates, the ledger shows two arrivals and one survivor with its history attached — the arithmetic still balances, and you can still answer "where did the other one go?"

What conservation looks like on your screen

• Every stage shows its own books. Extraction tells you what it read and where each line went. Review shows what moved, and lets you move things back. Cross-check accounts for every pairing it proposes.
• Totals travel with you. The counts you accepted at one stage are the counts the next stage starts from — visibly, so a change is something you did, never something that happened.
• The export carries the full accounting. What you download reports matched, missing, orphaned and set-aside material in one place — the same ledger, closed out. Your Ref[In] Report is credible to a supervisor for exactly this reason: its numbers reconcile.
• Starting over is explicit. Re-extracting opens a fresh ledger and says so. It never silently rewrites the one you were working from.

The question you should put to any checker

Not "how many did you find?" — any tool answers that. Ask instead: "there were 412 reference-shaped lines in my document; show me all 412." A checker built on conservation can answer with a screen for every one of them. A checker built on filters answers with the ones it kept, and the difference between those two answers is precisely the part of your bibliography you needed to know about.

The same discipline applies beyond checking, incidentally. When our sister tool proposes newer sources for an ageing reference list, it validates the references you already had before it suggests touching anything — accounting first, improvement second.