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)

Prioritise I1 and I3 on anything you plan to act on. Their final comparisons are deterministic in the common case, and they catch failures that are expensive downstream. They are not necessarily cheap: I1 re-runs each evaluator five times, while I3 queries several scholarly APIs and uses an LLM to disambiguate title-only matches.

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 transfer I1 and I2 unchanged to domains without deterministic evaluators. Those checks work here because ADRS ships golden evaluators. Biology, materials science, and theoretical work need domain-specific equivalents such as wet-lab protocol verification, simulation reproduction, or proof checking. I3 and the claim taxonomy still transfer; the paper has not validated the full four-check audit outside systems optimisation.

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 architectural hypothesis. In this audit, systems without shared evidence between code generation and writing have 20-33% method-code alignment, but the five-system comparison does not isolate architecture from prompts, adapters, or other implementation differences.

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
naive_ref_p = fisher(*I3["S1"], *I3["DS"])
assert naive_ref_p < 1e-10                       # 0/337 vs 42/201 if entries were independent

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.

The paper-level sample does not rank the systems that mostly pass. The method-code comparison of 14/15 against 12/15 gives p = 0.598, with Wilson intervals [70.2, 98.8] and [54.8, 93.0]. Score verification at 12/12 against 11/12 gives p = 1.000. The entry-level reference contrast, 0/337 against 42/201, is descriptively large, but the nominal p = 5.6e-20 treats bibliography entries from the same paper as independent. They are clustered within 30 papers, and Table 1 does not provide the per-paper counts needed for a paper-level test. Quote the aggregate rates, not that nominal p-value, as the evidence.

The abstract's uniqueness claim is a conjunction. ScientistOne is the only system to combine zero hallucinated references, perfect score verification, and the highest method-code alignment. Zero hallucinated references alone is not unique: Sakana AI-Scientist v2 also records 0/159 through cached citation retrieval. This distinction matters operationally because retrieval-grounded citation already appears in a system with a poor score-verification and method-code profile.

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 does not imply score leadership. 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. These five best-of-three results do not establish that verifiability caused a performance cost. They do support the paper's narrower reading that solver scores cluster and the measured differentiator appears after the solver finishes.

Every system's papers read better than they hold up under this reviewer. 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 all four checks supports only the properties they measure; it neither establishes every claim as true nor makes the research sound.

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. AutoResearchClaw's disconnected code and writing stages coincide with 20% method-code alignment in this audit; the comparison is observational rather than a causal ablation.

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.

Open questions and validation

  • Fifteen papers per system is not enough to rank the good ones. The audit documents concrete failures in this sample; the ordering between systems that mostly pass and the prevalence beyond these tasks remain unresolved. Reference-entry totals are additionally clustered within papers.
  • 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.

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.

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