Keep a Literature Log That Stays Current
Only Google Drive sources re-sync in Gemini Notebook. Build the log there, feed it from Zotero, and re-check retractions on a monthly pass.
Most literature logs die the same way. You build a beautiful table in week two, stop updating it in week five, and by week twelve you are back to searching your own downloads folder for a filename you half remember. The log has to be somewhere that updates itself, or it will not stay current.
There is exactly one source type in Gemini Notebook, the tool Google renamed from NotebookLM on 16 July 2026, that Google documents as self-updating. Build the log there and the rest of the workflow follows from it.
The log lives in Google Drive, because Drive sources re-sync and uploads do not
Google's sources documentation is specific about Drive imports:
Sources imported from Google Drive are auto-updated and will sync every few minutes. Changes to your original document will automatically update when you open your Notebook. If needed, you can manually update a source by opening the source in Notebook and clicking "Click to sync with Google Drive."
No comparable sentence exists anywhere in the help centre for locally uploaded files. The docs describe upload as a one-time operation and document no re-sync, no version history, and no way to refresh an uploaded PDF in place. So a local upload is a snapshot, and a Drive file is a live document.
That single asymmetry decides the architecture. Write the log as a Google Doc, keep it in Drive, and import it into the notebook alongside your papers. Edit the Doc, and within a few minutes the notebook is answering from the current version. You never re-import anything.
Two limits to route around. Google Sheets sources are "limited to 100k tokens", which a long log will eventually exceed, so a Doc is the safer container even though a table feels like a spreadsheet job. And Gemini Notebook "does not import footnotes or comments from Google files", so anything you leave in a comment thread is invisible to the notebook. Put it in the body.
Eight columns, one of which is a date you have to keep touching
A log that only records what you read is an inventory. A log that records what you can defend is a working document. The difference is the last three columns.
| Column | What goes in it | Why it earns the space |
|---|---|---|
| Key | Author + year, e.g. Mehra 2020 | The name you will type into chat queries |
| DOI | 10.1038/nature12373 | The only identifier that survives across databases |
| Claim | One sentence, the claim you might cite | Forces you to decide what the paper is for |
| Location | Section or page where the claim sits | Turns re-checking from a re-read into a lookup |
| Scope | Population, conditions, sample size | The part a summary drops first |
| Status | verified / unverified / cut | Nothing reaches a draft from "unverified" |
| Retraction checked | Date of last check | A stale check is not a check |
| Contradicts | Keys of papers that disagree | Builds the disagreement map as you go |
Name each source in the notebook with the same key you use in the log. Google's guidance explains why that pays off: "When multiple sources are selected, mentioning source names in your query helps Gemini Notebook narrow its search." A log key that matches a source name lets you jump between the two without translating.
Notes look like the right home for the log and are the wrong one
Gemini Notebook has a notes system, it is convenient, and it is the wrong container for a log. Three documented reasons.
First, notes are conditional input. The FAQ spells out what reaches the model: "Notes: Only when you specifically select it. Sources: Always used in either the entire set or the subset you select." A log you forget to select is a log the notebook cannot see.
Second, there is no undo. Same FAQ, under recovering deleted notes: "Unfortunately, there's currently no way to recover deleted notes." Months of triage sitting behind a delete button with no recovery path is not a risk worth taking for the convenience.
Third, saved chat responses cannot be edited. The notes documentation states that "Saved response notes aren't editable once created", and a log is nothing but edits. The cap of 1,000 notes per notebook is generous and irrelevant next to those two.
Use notes for what they are good at, which is capturing a chat answer with its citations intact, then transcribe the durable line into the Drive log by hand.
Feed the log from Zotero instead of from your browser history
The log needs correct metadata arriving without effort, and that is a reference manager's job. Zotero's documentation describes the fastest path for a paper you already have an identifier for:
You can quickly add items to your library if you already know their ISBN, DOI, PubMed ID, arXiv ID, or ADS Bibcode. Click the Add Item by Identifier button in the toolbar, type or paste in the identifier, and press Enter/Return. To add more than one item, separate identifiers by spaces, commas, or line breaks.
Behind that button, Zotero resolves DOIs through Crossref, ISBNs through Library of Congress and WorldCat, PubMed IDs through NCBI PubMed, arXiv IDs through arXiv.org, and ADS Bibcodes through ADS. So the metadata in your log comes from the same registry you would use to verify a citation, which is the point.
Zotero also names a metadata-quality trap that catches a lot of people: "Metadata for the same item may vary in quality across sites providing it. For example, importing an item from the publisher's website will generally yield much better data than importing from Google Scholar." Save from the publisher page, not from the search results page.
One more habit worth forming. If you save a PDF directly and Zotero cannot identify it, "it will leave the PDF as a standalone attachment", and the fix is to "right-clicking on the PDF, choosing Create Parent Item, and entering an identifier such as a DOI or ISBN." A standalone PDF with no parent item is a paper with no DOI in your log, which is a paper you will not be able to verify later.
Zotero feeds keep new work arriving without a subscription
Staying current means new papers finding you. Zotero has an RSS reader built in, which most users never turn on. Click Add Library above the left pane, choose Add Feed, then From URL…, paste a journal or preprint-server feed URL, give it a title, and click Save.
Under Advanced Options you set how frequently the feed updates and how long read and unread items are kept before removal. When something in the feed matters, save it into your library with the Save to My Library button, or with Ctrl/Cmd-Shift-S.
Zotero's own framing of the feature is the correct expectation to have: "Feeds are a great way to discover new research. With feeds, you can subscribe to updates from a journal, website, publisher, institution, research group, or other source and quickly find new articles or works." Discovery, not filtering. The triage is still yours.
The monthly pass takes twenty minutes
Put it in the calendar, because it will not happen otherwise. Four moves, in order.
- Re-check retractions on everything marked verified. Crossref publishes retraction status in the
update-tofield of its REST API and says the Retraction Watch database "is updated once per working day", so a check from six weeks ago is genuinely out of date. Update the Retraction checked column with today's date, not with a tick. - Clear inactive sources. If a shared Drive file moved or was deleted, its source is dead but not free: "Inactive sources will count towards source limits but will not be referenced throughout your notebook." On a free account with 50 sources per notebook, dead slots are expensive.
- Empty the unverified rows. Every row still marked unverified after a month either gets verified or gets cut. Rows that sit in limbo migrate into drafts.
- Re-read the Contradicts column. It is the only part of the log that gets more useful the longer you keep it, and it is the part a generated summary will never build for you.
Two things Google does not give you, so keep the log outside the notebook
There is no notebook duplication. The FAQ answers the question in five words: "This feature isn't supported yet." And the help centre documents export at the level of individual notes, via Export to Docs and Export to Sheets, with a warning attached: "Any modifications made within the newly created Docs or Sheets file will not synchronize with your original Gemini Notebook note, and sharing permissions will not carry over."
Nowhere does Google document exporting a whole notebook, backing one up, or moving one between accounts. Free accounts get 100 notebooks with up to 50 sources each, and no documented way to copy any of them.
So the notebook is a reading surface, and the Drive log is the thing you actually own. If Google renames the product again, changes the limits, or retires a feature, the log survives it, because it is a Google Doc with DOIs in it. That is the whole reason to keep it there rather than inside the tool that is convenient this quarter.
Changelog (1)
- July 31, 2026 — First published.