Track a Claim Back to the Original Source

A research workflow that cannot walk a sentence back to a real page in a real paper is not a research workflow. It is a plausible-text generator with a bibliography stapled on. Everything else in this series exists to make the walk-back possible, and this is the walk.

There are four checkpoints, and they rule out four different failures. Skipping any of them leaves a specific hole, so it is worth knowing which hole you are choosing to live with.

Checkpoint one: the citation locates a passage, and that is all it does

Start inside the notebook. Gemini Notebook, renamed from NotebookLM on 16 July 2026, attaches citations to chat answers, and Google's chat documentation describes the mechanism:

Gemini Notebook uses direct quotes, text, and images straight from your sources as citations to answer your questions and perform actions. These citations help you check the accuracy of the response. You can hover over any citation to get the full quoted text right away. If you select a citation, Gemini Notebook automatically navigates to the location of the quote, so you can easily view it in context.

Hover, then click. Do both, every time, on any sentence going into a draft. Hovering shows the quote. Clicking puts you at the location in the source viewer, which is where you find out whether the surrounding paragraph reverses the sentence you were about to cite.

Now the limit, stated plainly because Google does not state it for you. A working citation proves that a passage exists at that spot in a document you uploaded. It does not prove the passage supports the model's sentence, it does not prove the document is what it claims to be, and it does not prove the claim is still true. Google documents nothing about how a citation span is selected, so you cannot know whether the quote was retrieved first and written around, or attached to a sentence afterwards.

One documented case produces no usable location at all. From the FAQ: "If your source content is too short, Gemini Notebook references the entire document without a cited individual text from your source." A short abstract can yield a whole-document reference that looks like a citation and points nowhere in particular.

Checkpoint two: resolve the DOI at the registry, not by matching the title

The paper in your notebook has a title, and the temptation is to search that title elsewhere and call it verified. Titles are unreliable keys across databases, and there is an easy demonstration.

Take the DOI 10.1038/nature12373. Queried on 31 July 2026, the Crossref REST API returns the title Nanometre-scale thermometry in a living cell. The Semantic Scholar Academic Graph API, for the same DOI, returns Nanometer scale thermometry in a living cell. British spelling in one index, American in the other, and a hyphen that appears in one and not the other. A title string-match fails. A DOI match cannot.

The Crossref REST API needs no account. Its documentation says to "Use https://api.crossref.org/ as your base URL", that "No sign-up is required to use the REST API", and asks that you identify yourself for the polite pool by appending mailto= to your request:

https://api.crossref.org/works/10.1038/nature12373?mailto=you@example.org

Crossref is the registration agency, so its record is the publisher's own deposited metadata. That makes it the right place to settle a journal name, a publication date, or whether a DOI exists at all. A DOI that does not resolve at Crossref is the single loudest signal that a citation was invented.

The Semantic Scholar Academic Graph API accepts the same identifier with a prefix, and its base URL is https://api.semanticscholar.org/graph/v1, with a paper endpoint at /paper/{paper_id} and a fields parameter described in its tutorial as "a string of comma-separated field names, which tell the API what information to return":

https://api.semanticscholar.org/graph/v1/paper/DOI:10.1038/nature12373?fields=title,year,citationCount,openAccessPdf

That openAccessPdf field is the practical payoff. It returns a legal full-text link when one exists, which is how you get from a claim to the actual PDF without going through a paywall or a pirate site.

Semantic Scholar's tutorial documents the rate limits too. Unauthenticated callers "are affected by the traffic from all other unauthenticated users, who share a single API key", while an individual API key "automatically gives a user a 1 request per second rate". Verify a claim at a time, not a bibliography at a time.

Checkpoint three: two databases disagree about the same paper, so name yours

Citation counts feel like facts. They are database artifacts, and the same DOI gives different answers depending on who you ask.

Four citations apart is not a scandal. Writing "cited over 1,800 times" without naming which index produced the number is, because the next person to check will get a different figure and will not know whether you were wrong or whether the corpus moved. Cite the count with the source and the date attached, or leave the count out.

Checkpoint four: check the retraction record before the claim ships

This is the checkpoint most workflows skip, and it is the one that produces the worst outcomes. A retracted paper does not disappear from your PDF folder, and it does not stop being fluent.

Crossref bought the infrastructure to make this checkable. Its Retraction Watch documentation states: "In September 2023, we acquired the Retraction Watch database from the Center of Scientific Integrity and have made it publicly available." The data reaches you two ways. "Retractions are included in the update-to field of json files in the REST API", and the whole database is downloadable in CSV from a git repository. Crossref says it "is updated once per working day", and that other update types "such as expressions of concern and corrections, are also included in the data."

What that looks like on a real record. The DOI 10.1016/S0140-6736(20)31180-6 is the 2020 Lancet hydroxychloroquine registry analysis that was retracted after its underlying data could not be verified. Queried on 31 July 2026, Crossref returns a title that begins RETRACTED: and an update-to array carrying four entries of "type": "retraction", each dated 2020-05-22, plus an updated-by entry of type expression_of_concern. The retraction is machine-readable, and a script can catch it.

The same DOI at Semantic Scholar returns the same RETRACTED: title prefix and a citationCount of 734. Seven hundred and thirty-four papers point at a retracted study. Any of them can end up in your notebook, and none of them will announce it.

Search tools differ on how they handle this, and the difference is worth checking in each tool's documentation rather than assuming. Elicit's API documentation exposes a retracted filter with three values, "exclude_retracted", "include_retracted" and "only_retracted", and states that it "Defaults to exclude_retracted." That is a sensible default and a documented one. The useful inference runs the other way: a tool whose documentation says nothing about retractions almost certainly has no policy on them, and Google's Gemini Notebook help centre says nothing about retractions anywhere.

What each checkpoint rules out, and what it leaves standing

Nothing in that column on the right is solved by a tool. It is solved by reading the paper at the location the citation pointed to.

The rule that makes the rest of it work

A claim that survives all four checks goes in the draft with its DOI recorded. A claim that fails any of them does not go in, and does not get softened into a hedged version of itself either, because a hedge attached to an unverifiable source is still an unverifiable source with better manners.

The failure mode to guard hardest against is the one where a claim is nearly verified. The DOI resolves, the paper is real, the topic is right, and the specific sentence you wanted turns out to be a paraphrase of a paraphrase that nobody in the chain quite wrote. That claim reads well and cannot be defended. Cut it, or go find the sentence.