Skip to content
Markdown

Auditing autonomous research agents

Scope: how to tell whether an autonomous research system's output is true, when the output is a professional-looking paper plus code plus a score. This page covers the four forensic integrity checks that apply to any system's artifacts, the architectural choices that determine whether a system passes them, what a 15-paper-per-system sample can and cannot establish, and the specific ways verification and generation come apart. The solver-side counterpart is Frontis-MA1 and OpenMLE; the loop that produces these artifacts is autonomous experimentation loops; the reward-hacking analogue is evaluation integrity and anti-gaming.

Primary source: Meng, Dalvi Mishra, Chen, Li, Goyal, Parmar, Song, Song, Sinha, Ranganathan, Gokturk, Yoon, Pfister (Google Cloud AI Research), "ScientistOne: Towards Human-Level Autonomous Research via Chain-of-Evidence", arXiv:2605.26340v1, 25 May 2026. Benchmark: ADRS. Project site: https://scientist-one.github.io/.

What this page adds. The Python block is executed and asserted (Python 3.11, numpy 2.x). It converts the audit table to rates, computes exact Fisher tests on the published counts to establish which orderings the sample size supports, and checks two of the paper's summary sentences against its own tables. No system was run and no paper was re-audited; every count is the paper's.

The reviewer is not independent. Paper quality is scored by ScholarPeer (arXiv:2601.22638), whose six authors include five of this paper's thirteen: Palash Goyal, Mihir Parmar, Yiwen Song, Tomas Pfister, and Jinsung Yoon. Both are Google research artifacts and both run on Gemini 3.x Pro, which is also the backbone of every system under test. The integrity checks (Section 6.1) do not depend on that reviewer; the review-score results (Section 6.3) do.

What it is

The framing is an analogy to ACID, and it is a good one. ACID does not say how to build a database; it says what properties a database must have for its results to be trustworthy. Chain-of-Evidence (CoE) plays the same role for research artifacts: every claim must trace, through a recorded chain, to a grounding source. It defines four claim types and the evidence shape each requires.

Claim type Example Must resolve to
Citation "Smith et al. showed X" A work that exists in a scholarly database, described consistently
Numerical "achieves 87.3% on Prism" A recorded output: log line, measurement, simulation result
Methodological "we use a 3-layer MLP" The corresponding implementation
Conclusion "outperforms baseline by 5%" Supporting numerical or methodological claims, through verifiable reasoning

The CoE Integrity Audit is the part that transfers to any system, because it is forensic: it runs on submitted artifacts alone, through an adapter that normalises each system's deliverables into a common bundle of paper.tex, solution code, and references.bib.

  • I1 Score Verification. Extract the reported score from the TeX and the PDF, re-run the submitted solution on the golden evaluator, and compare within an adaptive tolerance of max(1%, 3 sigma / |mean score|) computed over five evaluator runs.
  • I2 Specification Violation. LLM inspection of solution code against the evaluator and task spec, majority vote over multiple runs, looking for evaluator reverse-engineering and hardcoded answers.
  • I3 Reference Verification. Resolve every bibliography entry against Semantic Scholar, arXiv, OpenAlex, and CrossRef by arXiv ID, DOI, and title, with an LLM cross-check for near-misses and for a real DOI attached to a fabricated description.
  • I4 Method-Code Alignment. LLM reads the method section beside the code and judges whether the paper describes what the code does. Acceptable simplification counts as aligned; only a fundamentally different algorithm counts as misaligned. Majority vote.

Why use it

Because every baseline system in the audit fails at least one check, and none of the failures is visible from the paper.

System I1 score verified I2 spec violations I3 hallucinated refs I4 method-code aligned
Sakana AI-Scientist v2 5/12 (41.7%) 10/15 0/159 (0.0%) 5/15 (33.3%)
AutoResearchClaw 5/12 (41.7%) 0/15 3/196 (1.5%) 3/15 (20.0%)
DeepScientist 11/12 (91.7%) 0/15 42/201 (20.9%) 5/15 (33.3%)
AI-Researcher 9/12 (75.0%) 1/15 21/222 (9.5%) 12/15 (80.0%)
ScientistOne 12/12 (100%) 0/15 0/337 (0.0%) 14/15 (93.3%)

The failure mechanisms are more instructive than the counts, because each traces to an architecture:

  • Cross-stage score cherry-picking. In 4 of 7 Sakana failures, the writeup model receives summaries from all four search stages and picks the most favourable number rather than the one belonging to the node whose code was submitted. One example: the selected node scores 22.79, the paper reports 25.39, and that number is traceable to ablation node 6 in ablation_summary.json.
  • Environment-dependent tuning. A solver contains a hyperparameter loop gated on an environment variable set differently during canonical re-evaluation, so the paper's number came from the tuned path and the re-run uses defaults. One case is 26.26 tuned against 22.34 default, a 15% gap.
  • Disconnected pipeline stages. AutoResearchClaw's 23-stage waterfall runs code generation in stages 10-13 and paper writing in stages 16-23 with no shared intermediate representation, so the writer invents algorithm names from experiment metadata. Its 20% method-code alignment is the direct consequence, and the failures are algorithm-class mismatches, not paraphrase.
  • Bibliographies from parametric memory. DeepScientist and AI-Researcher generate references from the model rather than from retrieval, at 20.9% and 9.5% hallucination.
  • A poisoned seed library. AutoResearchClaw's three bad references are one entry from a hand-curated YAML file shipped with the framework, which gives a real paper an informal title and is injected deterministically into every paper whose topic touches optimisation. One curation error, reproduced across three papers, with no model hallucination involved.

That last one is the most transferable finding on this page: a fabricated citation can be a static-asset bug, and no amount of model improvement fixes it.

When to use it (and when not)

Run I1 and I3 on anything you plan to act on. They are cheap, deterministic enough to automate, and they catch the failures that cost the most downstream. I3 in particular needs no LLM judgment for the common case: an entry either resolves against four scholarly APIs or it does not.

Treat I2 and I4 as advisory, and record the vote margin. Both are majority-vote LLM judgments, and the paper's own footnote shows the threshold doing real work: DeepScientist's LLM-SQL solver contains the same evaluator-exploiting column permutation that AI-Researcher was flagged for, but only 2 of 5 judges caught it, so it is not counted. The published I2 counts are threshold-dependent, and the paper says so.

Do not compare systems on I2 or I4 when a harness mismatch confounds them. The paper excludes Sakana from cross-system I2 and I4 comparison because its four-stage search design causes both effects: the stage-2 goal encourages intra-iteration parameter sweeps, which produces evaluator imports in 10 of 15 runs, and the submitted files carry tuning and tracking code alongside the solver, which I4 judges flag. That exclusion is correct and should be copied whenever a system was adapted rather than designed for the benchmark.

Do not use this audit outside domains with deterministic evaluators. I1 and I2 exist because ADRS ships golden evaluators. In biology, materials science, or theoretical work, the equivalent checks require wet-lab protocol verification, simulation reproducibility, or proof checking. The claim taxonomy transfers; the checks do not.

Do not read I3 as citation support. It checks existence, which is a necessary condition. A real paper cited for a claim it never made passes. The paper names this as an open problem in scholarly natural-language inference and leaves it to future work.

Architecture

flowchart TB
  subgraph PIPE["Evidence-preserving pipeline"]
    PI["Problem Investigator<br/>citation graph from scholarly APIs<br/>up to 100 full-text PDFs per topic<br/>provenance metadata per reference"]
    DISC["Discovery: Ideator + parallel explore-exploit<br/>B branches, I iterations, E versions per node<br/>best-run selector drops spec-violating solutions"]
    WRITE["Paper Writer: Conceive, Ground, Critic, Resolve, Compose<br/>every factual claim carries an inline evidence tag"]
    CV["Claim Verifier<br/>numerical vs evaluator logs<br/>citation vs bibliography, abstract entailment<br/>methodological vs experimental logs"]
    PI --> DISC --> WRITE --> CV --> OUT["Final LaTeX, evidence tags stripped"]
    CV -->|"flagged sentences"| WRITE
  end
  subgraph AUDIT["CoE Integrity Audit, forensic, applies to any system"]
    AD["Adapter: paper.tex + code + references.bib"]
    AD --> I1["I1 re-run on golden evaluator<br/>tolerance max(1%, 3 sigma / mean)"]
    AD --> I2["I2 spec violation, majority vote"]
    AD --> I3["I3 resolve refs against 4 APIs"]
    AD --> I4["I4 method vs code, majority vote"]
  end
  OUT --> AD

The load-bearing asymmetry is in the write path. Conceive emits a narrative in which every factual claim carries an inline tag binding it to a workspace artifact (a log line number, a score-file entry, a citation key). Ground validates each tag deterministically. Critic handles what deterministic checks cannot. Resolve rewrites against both. Only then does Compose render LaTeX, section by section, with verified numbers already in hand, so each section writer "writes prose around established facts rather than generating claims that must be sourced after the fact".

That ordering is the entire architectural claim, and the audit supports it: the systems that write first and ground afterwards are the ones with 20-33% method-code alignment.

How to use it

Executed audit of the published counts

import math

I1 = {"Sakana": (5, 12), "ARC": (5, 12), "DS": (11, 12), "AIR": (9, 12), "S1": (12, 12)}
I3 = {"Sakana": (0, 159), "ARC": (3, 196), "DS": (42, 201), "AIR": (21, 222), "S1": (0, 337)}
I4 = {"Sakana": (5, 15), "ARC": (3, 15), "DS": (5, 15), "AIR": (12, 15), "S1": (14, 15)}

# 1. The abstract's headline rates reproduce from the counts.
assert abs(100 * 42 / 201 - 20.9) < 0.1        # "hallucinated reference rates reach 21%"
assert abs(100 * 5 / 12 - 41.7) < 0.1          # "passes in as few as 42% of papers"
base_i4 = [100 * k / n for s, (k, n) in I4.items() if s != "S1"]
assert abs(min(base_i4) - 20) < 0.1 and abs(max(base_i4) - 80) < 0.1

# 2. Two systems reach zero hallucinated references, not one.
assert [s for s, (k, _) in I3.items() if k == 0] == ["Sakana", "S1"]

# 3. What 15 papers per system can separate. Exact two-sided Fisher.
def fisher(a, b, c, d):
    tot, s = b + d, a + c
    obs = math.comb(b, a) * math.comb(d, c) / math.comb(tot, s)
    return sum(math.comb(b, i) * math.comb(d, s - i) / math.comb(tot, s)
               for i in range(max(0, s - d), min(b, s) + 1)
               if math.comb(b, i) * math.comb(d, s - i) / math.comb(tot, s) <= obs * (1 + 1e-9))

assert fisher(*I4["S1"], *I4["AIR"]) > 0.3      # 14/15 vs 12/15: p = 0.598, separates nothing
assert fisher(*I1["S1"], *I1["DS"]) > 0.9       # 12/12 vs 11/12: p = 1.000
assert fisher(*I3["S1"], *I3["DS"]) < 1e-10     # 0/337 vs 42/201: p = 5.6e-20

def wilson(k, n, z=1.96):
    p, d = k / n, 1 + z * z / n
    c = p + z * z / (2 * n)
    h = z * math.sqrt(p * (1 - p) / n + z * z / (4 * n * n))
    return (c - h) / d, (c + h) / d

assert wilson(*I4["S1"])[0] < wilson(*I4["AIR"])[1]   # I4 intervals overlap heavily

# 4. "All systems match or exceed the human expert baseline on all five tasks" (Section 6.4).
TASKS = {"Prism": ("max", 21.89, {"Sakana": 26.26, "ARC": 26.25, "AIR": 26.26, "DS": 26.26, "S1": 26.26}),
         "Cloudcast": ("min", 626.24, {"Sakana": 627.11, "ARC": 690.37, "AIR": 734.28,
                                       "DS": 620.09, "S1": 618.08}),
         "EPLB": ("max", 0.1265, {"Sakana": 0.1270, "ARC": 0.1266, "AIR": 0.1449,
                                  "DS": 0.1284, "S1": 0.1459}),
         "LLM-SQL": ("max", 0.6920, {"Sakana": 0.7320, "ARC": 0.6757, "AIR": 0.7148,
                                     "DS": 0.7307, "S1": 0.7222}),
         "TXN": ("max", 2724.8, {"Sakana": 4184, "ARC": 3247, "AIR": 4311, "DS": 4286, "S1": 3906})}
losers = [(t, s, v, h) for t, (d, h, sc) in TASKS.items() for s, v in sc.items()
          if (v < h if d == "max" else v > h)]
assert len(losers) == 4                                   # not zero
assert sum(1 for t, *_ in losers if t == "Cloudcast") == 3
assert TASKS["Cloudcast"][2]["S1"] < TASKS["Cloudcast"][1]  # the paper's own system does pass

# 5. Solver placement of the verifiable system, where it is not first.
assert TASKS["TXN"][2]["S1"] / 4311 < 0.92      # 3906 vs the best entry: -9.4%
assert TASKS["LLM-SQL"][2]["S1"] / 0.7520 < 0.97

# 6. Native claim provenance, and the sensitivity of its correction.
claims, passed = 639, 627
assert abs(100 * passed / claims - 98.1) < 0.1
assert 99.3 < 100 * (claims - 4) / claims < 99.5   # the '~99%' corrected figure is the pessimistic end

# 7. Review scores: soundness is every system's floor, clarity every system's ceiling.
SOUND = {"Sakana": 1.5, "ARC": 1.1, "DS": 1.7, "AIR": 1.9, "S1": 2.3}
CLAR = {"Sakana": 3.1, "ARC": 2.5, "DS": 3.1, "AIR": 3.1, "S1": 3.0}
assert max(SOUND.values()) < min(CLAR.values())
assert 0.05 < fisher(6, 15, 2, 15) < 0.25       # 6/15 vs 2/15 accepts: p = 0.215

print("all assertions passed")

Five results.

Only the reference check carries its own conclusion. At 337 versus 201 bibliography entries, ScientistOne's 0 against DeepScientist's 42 is p = 5.6e-20. At 15 papers per system, the method-code ordering of 14/15 against 12/15 is p = 0.598 and the Wilson intervals are [70.2, 98.8] and [54.8, 93.0], overlapping almost entirely. The score-verification ordering of 12/12 against 11/12 is p = 1.000. The audit's findings about failure are robust because the failing rates are far from the passing ones; the audit's ranking among the good systems is not, and the paper's own framing ("the gap is largest in reference integrity and method-code alignment") points at the one check where the sample supports the gap.

The abstract's uniqueness claim is only true as a conjunction. Read distributively, "the only system to achieve zero hallucinated references" is contradicted by the body, which reports Sakana AI-Scientist v2 at 0/159 through its own cached citation retrieval. The unique thing is passing all three checks at once. This matters practically: retrieval-grounded citation is not exotic, and a system with an otherwise poor integrity profile already has it.

Section 6.4's human-baseline sentence is contradicted by Table 3. "All systems match or exceed the human expert baseline on all five tasks" has four counterexamples in the same table. Cloudcast is a minimisation task with a human baseline of 626.24, and Sakana (627.11), AutoResearchClaw (690.37), and AI-Researcher (734.28) are all worse; AutoResearchClaw is also below the human on LLM-SQL. ScientistOne itself does beat the human on all five, so the paper's abstract-level claim about its own system holds. The over-general sentence is about the field.

Verifiability has an opportunity cost that the tables show and the abstract does not. ScientistOne is 9.4% below the best entry on TXN and 4.0% below on LLM-SQL, placing mid-field on two of five tasks while leading on two others. The paper's own reading is honest ("solver scores cluster tightly across systems", and the differentiator is "what happens after the solver finishes"), which is the right conclusion; it is simply not the same as "state of the art".

Every system's papers read better than they hold up. Soundness spans 1.1 to 2.3 of 4 across all five systems while clarity spans 2.5 to 3.1. The best-scoring system on integrity is still at 2.3 soundness, and the reviewer's two most frequent complaints are missing comparisons against published baselines and proxy-only evaluation without end-to-end measurement. Passing every integrity check makes a paper true; it does not make the research good.

How to develop with it

Attach provenance at claim-production time, not afterwards. The measurable difference between the systems is whether the writer had verified numbers and named baselines in hand before it wrote a sentence. Retrofitting citations onto finished prose is what produces 20% method-code alignment.

Emit a machine-checkable tag per claim. ScientistOne's native check is exactly this: each sentence containing a number carries {source: "experimental_log.md:N"}, and a verifier extracts the number from both the sentence and the referenced line and compares within 5% relative tolerance. Across 15 papers it finds 639 numerical claims and passes 627 (98.1%). The 12 failures are mostly extraction artifacts (a hardware constant like "80GB GPU" matched against an unrelated log line, a LaTeX subscript read as a number), leaving at most 2 to 4 genuine mismatches and a corrected rate near 99.4%.

Build the score-verification path first. It is the check with the clearest signal and the most damaging failure mode, and it needs only a re-runnable evaluator and a number extractor. Adopt the adaptive tolerance: five evaluator runs and max(1%, 3 sigma / |mean|) is the difference between catching a real discrepancy and chasing scheduling noise.

Gate on specification violations before selecting a best run. ScientistOne's best-run selector drops flagged solutions before the highest score is chosen. That ordering matters: if the selector picks first and the audit runs later, the system has already optimised toward the exploit. The general treatment is in evaluation integrity and anti-gaming.

Audit your static assets. Curated seed bibliographies, prompt libraries, and example files ship with your framework and propagate deterministically. AutoResearchClaw's only hallucinated references came from a YAML file, not from a model.

How to run it in production

Version the audit and the tolerance together. I1 verdicts depend on the evaluator, the number of runs, and the tolerance formula; I2 and I4 verdicts depend on the judge model and the vote threshold. Record all of them beside the verdict, or a re-audit six months later is not comparable.

Record vote margins, not just verdicts. The paper's own near-miss (2 of 5 judges flagging a real exploit) is invisible in a pass/fail column. A 2-of-5 and a 0-of-5 are different risks.

Keep the forensic checks separate from any native provenance check. The four checks run on submitted artifacts and apply identically to every system. A native check like claim-provenance rate is only available to a system that emits provenance, and mixing the two produces a comparison in which the system that instrumented itself wins by construction.

Do not let an automated reviewer be both the improvement target and the judge. The integrity checks in this study are robust to that concern; the review scores are not, given the five-of-six author overlap and the shared Gemini backbone between generator and reviewer. LLM judge reliability covers the general failure.

Budget the audit. I1 re-runs every submitted solver five times on the golden evaluator. On an infrastructure benchmark that is real GPU or CPU time, and it scales with papers times seeds times evaluator runs. Note also that the paper excludes EPLB from I1 entirely because its scoring formula includes an execution-time component that varies with hardware, which is exactly the class of metric a shared cluster produces.

How to maintain it

Re-resolve bibliographies periodically. Scholarly APIs change coverage, and an entry that resolved last quarter may not resolve today for reasons that have nothing to do with the paper.

Re-run the adapter after any change to a system's output format. The audit's uniformity depends on normalising deliverables into one bundle, and a silently changed output path turns a check into a false pass.

Track the infrastructure-retry rate. In this study, 16 of 75 runs needed at least one retry for API timeouts, rate limits, or LaTeX compilation, with up to three attempts and an explicit rule that no run was retried to improve a score. That rule is the one worth copying verbatim: retry for infrastructure, never for outcome.

Failure modes

  • Grading the paper instead of the artifacts. Automated review scores and leaderboard positions both measure surface presentation. Neither detects a fabricated citation, an unreproducible score, or a method section describing code that does not exist.
  • Cherry-picked scores from a search tree. When the writer sees summaries from every stage, it selects the best number rather than the one belonging to the submitted node. Bind the reported score to the submitted artifact mechanically.
  • Environment-gated tuning paths. A solver that behaves differently under the canonical harness than under its own will produce a number nobody can reproduce, and will look like evaluator noise.
  • Multi-file solvers that do not stand alone. Five of 15 AutoResearchClaw solvers import helper modules absent at re-evaluation time, so the evaluator returns a fallback score. Submit what runs.
  • A bundled evaluator that differs from the canonical one. One system shipped a patched Cloudcast evaluator, producing different scores for the same solver.
  • Existence-only citation checking read as support. A real paper cited for a claim it never made passes I3 cleanly.
  • Majority-vote checks reported without their margins. The threshold, not the judgment, decides borderline cases.
  • Comparing a system that was adapted to the benchmark against one designed for it. Sakana needed a rewrite of its stage goals and 14 prompt locations before it produced valid solutions at all, and its I2 and I4 numbers carry that mismatch.

Open questions and validation

  • Fifteen papers per system is not enough to rank the good ones. The failure findings are solid; the ordering between systems that mostly pass is not, on three of four checks.
  • One domain, one benchmark. All five tasks are computer-systems optimisation with deterministic evaluators. The claim taxonomy is domain-agnostic; the checks are not, and no domain without a golden evaluator has been tested.
  • Citation support is unmeasured. Passage-level entailment between a claim and the cited paper's text is the check that would matter most, and it is future work.
  • Review quality is judged by a same-lab automated reviewer on the same model family. Human expert review of the same 75 papers would settle whether the accept-rate gap is real.
  • Seed variance is large and unexplained. ScientistOne's own EPLB review scores are 1, 3, and 8 across three seeds on one task. The paper attributes rejected runs to qualitative overclaims the verifier does not cover, which is a hypothesis, not a measurement.

References

Related: Frontis-MA1 and OpenMLE · Autonomous experimentation loops · Agentic paper replication · Evaluation integrity and anti-gaming · LLM judge reliability · Agent evaluation · NatureBench · Agent intent verification · Self-improving agent harnesses · Governance registries for prompts and data · Experiment tracking and model registry · Glossary