Google put Deep Review in public hands. The reviewer needs a review trail

THE SIGNAL IN ONE SENTENCE

A reviewer who never gets tired sounds wonderful right up until the reviewer is confidently wrong on page 37. Google Research made Deep Review publicly available on October 14. The agentic system accepts a technical document, divides it into logical sections, assigns more computing effort to dense parts, sends specialized reasoning agents across those sections and synthesizes a final report with additional consistency and grounding checks. That is the machinery Google describes. The useful product is simpler: a second reader that can keep looking when the first reader's eyes have turned into soup. Google says Deep Review checks logical consistency and mathematical statements, grounds factual claims, compares a document with related work and suggests improvements. The company positions it for scientific papers, design documents, presentations, legal agreements and financial material. Public access begins with PDFs and plain text. Multi-file review is planned, not available yet. Every user gets two complimentary reviews per week. Higher-volume users can connect a Gemini API key and use an API. Google says uploaded documents are not used to train, fine-tune or improve its models, but public-release uploads are stored for one year so users can see them in the interface. Those details make Deep Review more than a lab demo. They also create a much more ordinary question than whether an AI can critique a paper. Can the person receiving the critique inspect how it was made? The plain signal is that automated review needs a review trail. A useful finding should identify the exact passage it evaluates, the claim it believes that passage makes, the evidence it checked, the test it ran, the uncertainty it carries and what would change the conclusion. If another reviewer disagrees, the system should preserve that disagreement. If the author corrects the text, the next report should say which finding closed and why. Without that trail, a long report can create the atmosphere of rigor without the inconvenience of being auditable. Deep Review arrives with more field experience than most new document tools. Google developed it from the Paper Assistant Tool, or PAT, and offered private pre-submission feedback to authors who opted in at STOC 2026, ICML 2026, NeurIPS 2026 and ICLR 2027. Google says the pilots covered more than 16,000 manuscripts. The distinction between pre-submission help and official peer review matters. Google says PAT feedback was separated from conference review decisions. Authors could use it to stress-test a paper before submission, while human conference reviewers retained control over acceptance. Pilot papers were not collected for training and were deleted after each program, according to Google. The new public service has a different one-year storage policy. Google's June preprint reports that PAT improved recall on mathematical errors in the SPOT benchmark by 34 percent over a zero-shot baseline. It also describes author feedback and conference pilots. That is promising company-authored evidence about a particular benchmark and workflow. It is not proof that the service catches every important error, avoids every false accusation or transfers cleanly into law, finance and other domains. Recall has a cost. A system that flags more real mistakes can also flag more things that are not mistakes. In research, a plausible false alarm can consume hours of author and reviewer time. In a legal agreement, it can send a team chasing a contradiction that disappears when jurisdiction or defined terms are considered. In finance, it can confuse an unusual but valid accounting treatment with an inconsistency. This is why the report should show both the alarm and the path to it. Start with source anchoring. Every finding should link to the relevant sentence, equation, table cell or figure. A factual challenge should link to the external source used for grounding, with access date and a short explanation of what that source supports. A mathematical objection should show the assumptions and the smallest counterexample or failed step the system can identify. A cross-section conflict should display both passages side by side. Next, separate observation from judgment. The observation might be that Table 4 reports 72 samples while the methods section reports 70. The judgment might be that the experiment is invalid. Those are not the same statement. A two-sample discrepancy could come from a typo, an exclusion rule or a serious data problem. The report should mark which part is visible in the document and which part is an inference. Then expose uncertainty. Not a decorative confidence percentage. Give users the reasons for doubt. Perhaps the cited paper was unavailable. Perhaps an equation uses uncommon notation. Perhaps the result depends on a definition from a missing appendix. Perhaps two review agents disagreed and the synthesis agent chose one reading. That disagreement is valuable information. Hiding it inside a polished final paragraph is not synthesis. It is laundering uncertainty. The product also needs a correction loop. An author should be able to mark a finding as accepted, disputed, resolved by revision or unresolved. A dispute should allow a short reason and supporting source. The next run should not simply rediscover the same issue as if nobody had answered. It should compare versions, retain the earlier record and explain whether the new text changed the result. This is especially important when Deep Review enters continuous workflows through the API. A research group could run it before every manuscript submission. An engineering team could attach it to design-document review. A publisher could use it as an additional check on long technical reports. A compliance team could compare clauses and tables before a human signs off. All of those are sensible experiments if the output remains advice rather than hidden authority. The dangerous shortcut is to convert a report into a gate. Do not reject a paper because the automated reviewer found three major issues. Do not block a contract because the report is red. Do not give a student a grade because the system produced reviewer-like prose. Each setting needs a named human decision-maker, a process for contesting findings and a record of how the automated review influenced the outcome. That record should include non-use too. If a reviewer ignores a warning because it is unsupported, log that. If a warning catches a real error, log the repair. If the tool misses a problem a human later finds, add it to a local evaluation set. Over time, the team should know whether Deep Review saves attention or merely moves attention into a different inbox. Google's four-stage architecture is a thoughtful response to long-document failure. First, a segmenter covers the document with logical, sometimes overlapping sections. Second, the system assigns different compute budgets based on information density. Third, specialized agents review sections in parallel while retaining access to the whole document. Fourth, a synthesis agent checks cross-section consistency, reruns logical checks when needed and uses external tools for grounding. The architecture makes several failure points easier to name. The segmenter can split a dependency from the passage that explains it. Adaptive budgeting can spend too little effort on a short but decisive footnote. Parallel agents can repeat the same assumption. The synthesizer can smooth disagreement into one confident conclusion. External grounding can retrieve the wrong source or a newer source that does not reflect what the author could have known. None of those possibilities make the system useless. They define the tests it needs. Build a small evaluation set from documents your organization understands well. Include obvious errors, subtle errors, valid oddities and clean passages likely to trigger false alarms. Measure whether the tool finds the planted problems, how often it invents a concern, whether citations support the stated finding and how much human time each report takes to resolve. Test version changes too. Google says the public system adds Gemini 4 Argon support beyond the older PAT iterations described in the paper. That means benchmark and pilot evidence about PAT should not be treated as a permanent score for every future Deep Review configuration. A model change, prompt change, retrieval change or synthesis change can alter both successes and mistakes. Every report should therefore carry a system version, run date and input hash. If a later run changes its mind, users should be able to see what changed besides the answer. Privacy deserves the same precision. Google clearly states that uploads are not used to train, fine-tune or improve its models. It also states that public-service uploads are stored for one year for display in the interface. Research groups handling unpublished results, companies reviewing confidential designs and lawyers working with privileged material need to decide whether that retention period and the surrounding terms fit their obligations. They should not infer that no training means no risk. Before uploading, teams should classify the document, remove secrets that are not needed, confirm who can access the resulting report, understand deletion controls and decide whether API use changes storage or administrative options. Highly sensitive work may require an approved environment or no external upload at all. There is a real access benefit here. Experienced human feedback is unevenly distributed. A researcher at a large laboratory can ask senior colleagues to interrogate a proof or experimental design. An independent scholar, student or small team may have no comparable network. A competent automated critic can help them find a missing baseline, an unsupported leap or an unclear method before scarce human review begins. That benefit is strongest when the tool teaches rather than pronounces. Show the passage. Show the reason. Show the source. Show the uncertainty. Let the author answer. Keep the human reviewer free to disagree. Deep Review should become a magnifying glass, not a rubber stamp with a very long report attached. The public release gives researchers and other knowledge workers something worth testing. The next useful release should give them a standard review trail: passage-level anchors, evidence links, reasoning labels, disagreement records, version history, corrections, retention controls and a clear declaration that final decisions belong to people. A machine can read every line without getting tired. Accountability begins when a person can retrace what it thought it saw.