Artifact-centered Claim-aware Observability for Autonomous Scientific Agents

# Artifact-centered Claim-aware Observability for Autonomous Scientific Agents
Source: [https://arxiv.org/html/2608.18312](https://arxiv.org/html/2608.18312)
GOVERNMENT LICENSE

The submitted manuscript has been created by UChicago Argonne, LLC, Operator of Argonne National Laboratory \(“Argonne”\)\. Argonne, a U\.S\. Department of Energy Office of Science laboratory, is operated under Contract No\. DE\-AC02\-06CH11357\. The U\.S\. Government retains for itself, and others acting on its behalf, a paid\-up nonexclusive, irrevocable worldwide license in said article to reproduce, prepare derivative works, distribute copies to the public, and perform publicly and display publicly, by or on behalf of the Government\. The Department of Energy will provide public access to these results of federally sponsored research in accordance with the DOE Public Access Plan\.[http://energy\.gov/downloads/doe\-public\-access\-plan](http://energy.gov/downloads/doe-public-access-plan)

Ming DuMichael H\. PrinceMathew J\. CherukaraAdvanced Photon Source, Argonne National Laboratory, Lemont IL, USAAffiliation:xyin@anl\.gov;mcherukara@anl\.gov\[0\.75em\] Accepted by LM4Sci Workshop at the Conference on Language Modeling \(COLM\) 2026\.

###### Abstract

Autonomous scientific agents now increasingly propose ideas, write code, run experiments, analyze results, and even draft papers\. Observe and audit those agents are necessary but logging every model call is not enough, scientists also need to inspect the artifacts and claims that the systems produced and their relations\. This is driven by the fact that failures in scientific agent systems are often distributed across several objects\. A manuscript claim may cite the wrong evidence, a search process may select a degenerate candidate, a laboratory novelty claim may depend on an unstated rule, or a multi\-agent plan may change without a visible trigger\. Existing tracing, experiment tracking, and archival provenance tools are valuable, but their native objects do not make these scientific audit relations first\-class\. We argue that autonomous scientific systems should emit portable, claim\-aware artifact lineage as a minimum audit layer\. We propose a compact observability profile organized around individuals, operators, fitness records, lineage, archives, runs, streams, and steering commands\. In this profile, scientific claims are ordinary individuals with explicit evidence bindings and verification records\. The profile is intended as a semantic layer that complements current telemetry and provenance standards\. Execution details can remain in OpenTelemetry\. Final packages can export to PROV\-O or RO\-Crate standards\.

## 1The audit unit is the artifact

Autonomous scientific agents are moving from assistants that answer questions toward systems that help execute research workflows\. Recent systems show they can automate paper writing pipelines, agentic tree search over research ideas, code generation for experiments, literature synthesis, laboratory planning, and closed\-loop chemistry or materials workflows\([12](https://arxiv.org/html/2608.18312#bib.bib16);[25](https://arxiv.org/html/2608.18312#bib.bib1);[18](https://arxiv.org/html/2608.18312#bib.bib17);[17](https://arxiv.org/html/2608.18312#bib.bib18);[14](https://arxiv.org/html/2608.18312#bib.bib19);[4](https://arxiv.org/html/2608.18312#bib.bib21);[5](https://arxiv.org/html/2608.18312#bib.bib22);[20](https://arxiv.org/html/2608.18312#bib.bib23)\)\. This shift changes what it means to observe a scientific computation system\. A log of prompts, completions, tool calls, and timestamps is necessary, but it is not sufficient\. A scientist also needs to know which artifact the agent produced, which earlier artifacts led to it, what evidence supports each claim, which evaluator accepted or rejected it, and which branch or human intervention changed the trajectory\.

We argue here that autonomous scientific agentic systems should make artifact lineage and claim\-evidence bindings first\-class observability records\. Span trees and run logs should not be the only portable audit trail\. The minimum trace for a scientific agent should include candidate artifacts, the operators that derive them, evaluator outputs attached to those artifacts, archive or selection decisions, human steering events, and claims represented as inspectable artifacts with evidence bindings\.

This distinction matters because the most damaging failures of scientific agents are often not localized to a single model/tool call\. Audits of manuscripts produced by automated research have reported coding failures, hallucinated or internally inconsistent numerical results, and malformed or unsupported claims\([2](https://arxiv.org/html/2608.18312#bib.bib2);[24](https://arxiv.org/html/2608.18312#bib.bib24)\)\. In autonomous materials synthesis system, novelty and yield claims have required later correction or dispute after the system completed its loop\([21](https://arxiv.org/html/2608.18312#bib.bib3);[10](https://arxiv.org/html/2608.18312#bib.bib4);[22](https://arxiv.org/html/2608.18312#bib.bib5)\)\. Such cases require an audit trail that connects claims with evidence, evaluators, and lineage\. A span tree can tell us which calls occurred\. It does not by itself identify the scientific claim, bind the claim to a measurement, or show that a later draft reused an invalidated result\.

![Refer to caption](https://arxiv.org/html/2608.18312v1/media/hero_spans_to_lineage.png)Figure 1:The observability shift\. Runtime spans record nested calls and timing\. Claim\-aware artifact observability records candidate artifacts, the operators that derive them, evaluator outputs, archive decisions, and evidence links for claims\.Figure[1](https://arxiv.org/html/2608.18312#S1.F1)summarizes the shift\. The left side resembles a conventional trace: an ordered tree of calls\. The right side shows the scientific units of inspection: artifacts, lineage, evaluations, and evidence\. Our proposal is not to replace tracing, experiment tracking, or archival provenance, but to add the missing semantic layer that lets autonomous research systems answer scientific audit questions during a run and compile richer archival packages afterward\.

## 2Why current infrastructure can miss scientific audit objects

Current infrastructure provides several partial views\. Tracing systems for LLM applications record spans: prompts, completions, tool invocations, latency, token counts, and nested call structure\([7](https://arxiv.org/html/2608.18312#bib.bib7);[8](https://arxiv.org/html/2608.18312#bib.bib8);[1](https://arxiv.org/html/2608.18312#bib.bib9);[23](https://arxiv.org/html/2608.18312#bib.bib11)\)\. Experiment trackers record runs, parameters, metrics, artifacts, and sometimes model lineage\([13](https://arxiv.org/html/2608.18312#bib.bib10);[23](https://arxiv.org/html/2608.18312#bib.bib11)\)\. Provenance and research object standards such as W3C PROV\-O, PROV\-DM, and RO\-Crate record entities, activities, agents, derivations, and bundled research artifacts for later sharing and reproducibility\([9](https://arxiv.org/html/2608.18312#bib.bib12);[3](https://arxiv.org/html/2608.18312#bib.bib15);[19](https://arxiv.org/html/2608.18312#bib.bib13)\)\. Version control systems for code and data, such as git, git\-LFS, and DVC, track lineage as content\-addressed commit graphs with branch and merge structure\([6](https://arxiv.org/html/2608.18312#bib.bib25)\)\. These tools are useful, mature, and should be reused\.

The gap is a mismatch of primary units\. A span\-centric system asks, “which call happened next?” An experiment tracker asks, “which run produced this metric?” An archival package asks, “how was this final object derived?” A version control system asks, “which lines changed between these two file trees?” A scientist auditing an autonomous system asks different questions: which candidate contains this claim, what evidence did it read, which evaluator accepted it, and what branch selected it? Those relations can be encoded in tags, metadata, file paths, or commit messages, but the conventions are local and fragile\. Two teams can both log every model call and still be unable to exchange traces that answer the same query about claims\.

Three audit scenarios illustrate the problem\. First, an agent that writes papers may report a numerical improvement that contradicts the experiment log\. The audit object is not the prompt that wrote the sentence\. It is the claim, the evidence artifact it cites, the extracted value, and the verification result\. Second, an evolutionary or tree\-search system may appear to improve while the population collapses to near\-duplicates that exploit a benchmark quirk\. The audit object is the lineage and fitness of the candidate population, not any single model completion\. Third, a closed\-loop lab may emit delayed physical measurements, sample identifiers, instrument files, and operator approvals\. The audit object spans software decisions and physical evidence, and may not align with synchronous call boundaries\.

Metadata conventions are not enough for scientific review\. A parent program ID can be stored as a span attribute, a token in a commit message, a database row, or a file name\. A claim’s evidence can be stored as a citation string, a notebook path, a retrieval snippet, or a table coordinate\. All are workable inside one lab\. None gives a reviewer, benchmark, or downstream archive an easy and portable way to ask common audit questions: show every unsupported claim, trace a result to its evidence, find the branch where a human intervention changed the plan, or list archive members that were later reused in the manuscript\.

## 3Audit questions reveal observability requirements

Claim\-aware artifact observability starts from the questions that scientists, reviewers, and safety monitors need to ask\. These questions mix distinct relation types\. Some ask for provenance, such as which parent artifact produced a child\. Some ask for epistemic support, such as which measurement or literature item supports a claim\. Some ask for control history, such as which human instruction or automated policy changed the search\. An observability contract should keep these relations distinct rather than compressing them into a single generic dependency edge\.

Table 1:Design requirements derived from scientific audit questions\. The profile separates derivation, evidence, evaluation, and steering because each supports a different class of review\.Table[1](https://arxiv.org/html/2608.18312#S3.T1)also explains why simple file provenance is not enough\. A generated sentence can be derived from a draft without being supported by the data it mentions\. A code candidate can descend from a strong parent while its reported score comes from an unstable evaluator\. A plan revision can be causally downstream of a human instruction while still failing to preserve the user’s intended constraint\. The observability schema must therefore represent derivation, evidence, fitness, and steering as separately queryable facts\.

This matters most when reviewers assess scientific agent outputs\. A reviewer may not need to replay the whole run\. They may need to inspect a few high\-risk claims: numerical comparisons, novelty assertions, safety\-relevant experimental decisions, or literature claims that could be hallucinated\. A trace format that exposes these objects makes review targeted rather than forensic\. Instead of reading thousands of spans, a reviewer can ask for all final claims with missing evidence, all accepted candidates with no independent evaluator, or all archive decisions made after an intervention\.

## 4Claim\-aware observable event trace profile

A trace is an append\-only event log\. Derived views \(current archive membership, best lineage path, evaluator dashboards, claim graphs, and worker utilization\) are computed from the event trace sequence\. This design avoids treating the latest dashboard state as the scientific record\. If a system removes a candidate from an archive, revises a claim, or changes a plan, the event that made the change remains inspectable\.

The proposed profile has five scientific abstractions and three structural records\. Anindividualis any candidate artifact under inspection: a program, manuscript draft, table, protocol, plan, sample, molecule, figure, claim, or agent version\. Anoperatoris an event that derives one or more child individuals from zero or more parents, or acts on an existing record\. Afitnessrecord is an evaluator output attached to a specific individual: a scalar score, pass/fail result, structured review, proof\-check status, wet\-lab measurement, novelty classification, or claim\-verification judgment\.Lineageis the parent\-child graph induced by operators\. Anarchiveis an optional curated set, such as an elite set, a Pareto front, a set of accepted claims, a list of retained samples, or a MAP\-Elites grid\. Three structural records complete the profile\. Arunframes one autonomous process\. Astreamidentifies a worker, agent role, instrument, tool subsystem, or human interface\. Asteering commandrecords a human or external intervention and links, when applied, to the operator that changed the run\.

The profile is deliberately small \(Appendix[A](https://arxiv.org/html/2608.18312#A1)gives the event contract and structural invariants\)\. It does not prescribe how to store a microscope image, diffraction pattern, molecule graph, proof object, code repository, or manuscript\. Instead, it requires every domain payload to be addressable by reference and hash, and every scientifically relevant transformation to be represented as an operator over individuals\. The result is a portable query surface: parentage, evidence, evaluation, selection, and intervention have stable meanings even when payloads are domain\-specific\.

### 4\.1Claims as individuals

A central requirement for scientific agent observability is claim inspection\. A generated paper, report, or lab note carries a particular risk: unsupported claims can look polished and pass through downstream review even when they are wrong\. We therefore treat a scientific claim as an ordinary individual rather than a special annotation embedded inside a manuscript\. A claim individual has text or structured content, evidence references, optional evidence bindings, and fitness records produced by verifiers\.

Evidence references list the artifacts the claim points to: measurements, tables, code outputs, literature items, human reviewer notes, instrument files, or earlier claims\. Evidence bindings optionally record how the evidence was used: which field was read, which value was extracted, what comparison was made, and why that evidence supports or weakens the claim\. A verifier then emits a fitness record such assupported,unsupported,contradicted, orneeds\_human\_review\. Later manuscript drafts inherit, revise, or reject claim individuals through ordinary operators\.

This design makes failures in paper writing queryable\. A reviewer or operator can ask for all claims in the final draft whose evidence does not exist, whose extracted value differs from the cited metric, or whose verifier failed\. It also avoids a separate system for claim provenance\. Claims can be selected into archives, superseded by new evidence, or traced back to earlier drafts just like other artifacts\. Because claim verification can be partial, the profile does not assume perfect verifiers\. It only makes the verification target and result explicit\.

A claim individual is not a guarantee of truth\. It is a stable handle for review\. Verifiers may be automatic scripts, retrieval\-augmented checkers, domain models, theorem provers, human reviewers, or later laboratory measurements\. The important invariant is that the claim, its evidence, and the verification result remain separately identifiable\. This lets a later system invalidate a claim without rewriting history\. The old claim remains in the log, a new fitness record captures the contradiction, and a revision operator can produce a corrected claim or remove it from the accepted archive\.

### 4\.2Interoperability rather than replacement

Claim\-aware artifact observability should be a bridge, not a replacement\. Execution details can remain in OpenTelemetry GenAI semantic conventions\([16](https://arxiv.org/html/2608.18312#bib.bib14)\)\. An operator can reference one or more spans as low\-level evidence for how the event was executed\. Final derivation graphs can export to PROV\-O by mapping individuals to entities, operators to activities, streams or humans to agents, and parent\-child edges to usage/generation relations\([9](https://arxiv.org/html/2608.18312#bib.bib12);[3](https://arxiv.org/html/2608.18312#bib.bib15)\)\. Research packages can serialize payloads and metadata through RO\-Crate\([19](https://arxiv.org/html/2608.18312#bib.bib13)\)\. Workflow datasets can export coarse\-grained input/output relations through OpenLineage\([15](https://arxiv.org/html/2608.18312#bib.bib20)\)\. Nothing in the profile fixes the underlying store\. A version control system can serve as its substrate: git already supplies content\-addressed identifiers and a multi\-parent derivation graph, and branch, tag, and commit conventions can encode individuals, operators, fitness records, and archive decisions\. It adds a standard schema rather than replacement, so those conventions become portable across labs rather than local to one repository\.

The profile is also complementary to the emerging ideas such as agent\-native research \(ARA\) artifacts\.[11](https://arxiv.org/html/2608.18312#bib.bib6)argue that traditional papers hide failed branches and omit engineering detail, and they propose agent\-native research artifacts as packages containing logic, code, exploration, and evidence\. Our proposal records the run from which such a package can be compiled\. An agent\-native artifact is an end\-state package\. Claim\-aware artifact observability is the live log that preserves branch structure, evaluator history, claim evidence, and steering events before the final package is assembled\.

## 5Proposed requirements for the community

We understand fully adopting the proposed observability profile can be infeasible in short terms, so we propose five minimum requirements for autonomous scientific agents for research venues, benchmarks, and tool builders such that they can still benefit from the ideas of this proposal\.

Emit artifact IDs, not only span IDs\.Every audit\-relevant research object created by an agent should have a stable individual ID, kind, payload reference or hash, creator operator, timestamp, and status\. The right granularity depends on the domain, but final claims, tables, figures, experiment logs, code versions, plans, and selected candidates should never exist only inside prompt text\.

Emit operators as lineage events\.Any refinement, mutation, synthesis, extraction, review, verification, selection, or plan update should record its parent individuals, child individuals, stream, tool or agent, and parameters sufficient to interpret the edge\. This makes the lineage graph replayable and queryable\.

Attach evaluator outputs to artifacts\.Metrics should not float at the run level when they judge a specific artifact\. A benchmark score belongs to a code candidate, a novelty decision belongs to a sample or claim, and a reviewer score belongs to a draft or claim set\.

Represent claims and evidence explicitly\.Scientific statements that appear in generated reports should be extracted or emitted as claim individuals\. Each claim should link to evidence artifacts and, when possible, to the exact value or field used\. Verification is then a normal evaluation step\.

Keep human steering and archive decisions in the log\.Pauses, approvals, forced forks, rejected candidates, archive additions, plan revisions, and safety stops should be visible events, not dashboard state that disappears when a run completes\.

These requirements leave implementation choices open\. They do not force one database or one UI\. They ask systems to expose the units that scientific review already depends on\. Appendix[B](https://arxiv.org/html/2608.18312#A2)lists representative audit queries, and Appendix[C](https://arxiv.org/html/2608.18312#A3)gives compact tracelets for common failure modes\. A reviewer should be able to load a trace and ask which claims are unsupported, which artifact introduced a result, which evaluation accepted it, which human command changed the path, and which archive members were later reused in the manuscript\.

## 6A minimal worked example

Consider a common failure: an agent writes that a new method improves accuracy by 4\.2 percentage points, but the experiment log shows a smaller gain or no gain\. In a span\-only trace, the claim may be buried in a completion and the evidence may be a file path in a tool output\. In the proposed profile, the same event sequence can be represented as a small graph of records\.

Table 2:A compact trace for an unsupported numerical claim\. The payloads can live outside the trace\. The trace preserves the audit relations\.Table[2](https://arxiv.org/html/2608.18312#S6.T2)simplifies the inspection workflow\. A reviewer does not need to read every model call to find the problem\. They can query claim individuals whose verification fitness is unsupported or contradicted, inspect the evidence binding, and follow lineage back to the draft and extraction operator\. A developer can still open the corresponding spans to debug the prompt or tool\. A provenance archive can still export the final graph\. The profile connects these views through stable artifact IDs\.

The same pattern scales to other domains\. A novelty claim can bind to a sample, diffraction pattern, database entry, and decision threshold\. A proof claim can bind to a theorem statement and proof\-checker output\. A claim in protein design can bind to a structure prediction, assay result, and acceptance rule\. In each case, the scientific assertion is not treated as free text\. It is a research artifact with provenance, evidence, and evaluation\.

## 7Trace shapes and example encoding

The proposed profile can cover more than a simple agent chat loop\. Autonomous research traces often appear as linear refinement, multi\-phase pipelines, tree search, evolutionary populations, self\-modifying artifacts, or closed\-loop discovery processes \(Figure[2](https://arxiv.org/html/2608.18312#S7.F2)\)\. The control structure changes, but the audit units remain the same: artifacts, derivations, evaluations, selections, evidence links, and interventions\.

![Refer to caption](https://arxiv.org/html/2608.18312v1/media/six_trace_shapes.png)Figure 2:Six trace shapes that can share the same artifact\-centered vocabulary: linear refinement, multi\-phase pipeline, tree search, evolutionary population, self\-modifying artifact, and closed\-loop discovery\.Linear refinement and multi\-phase writing\.A system that writes reports can emit a draft individual at each revision, extraction operators for numerical or literature claims, and verifier fitness records after checking claims against experiment outputs or cited sources\. A multi\-phase pipeline adds typed handoff artifacts \(research questions, code repositories, experiment logs, analysis summaries, drafts, and internal reviews\) so a final claim can be traced through the phase that introduced it and the evidence that supports it\.

Tree search and evolutionary populations\.A tree\-search system represents each state, plan, or candidate draft as an individual and each expansion as an operator\. An evolutionary design system represents candidate programs, molecules, or hypotheses as individuals\. Mutation and crossover are operators\. Benchmark, simulation, or assay results are fitness records, and survivor sets or Pareto fronts are archive events\. These records expose whether improvement comes from diverse lineages or from collapse onto near\-duplicate candidates that exploit one evaluator\.

Self\-modifying and multi\-agent systems\.In self\-modifying systems, prompts, policies, evaluator definitions, and agent code are themselves individuals\. A self\-modification is an operator that derives a new agent version\. Later operators list that version in context, so the event log remains acyclic even when the system changes the process that creates future artifacts\. In a hub\-and\-spoke research team, streams distinguish a PI, coder, runner, critic, instrument, or human supervisor\. Message and plan revision operators then show which specialist artifact or human intervention changed the shared plan\.

Closed\-loop laboratories\.A laboratory workflow can represent protocols, samples, instrument outputs, measurements, and novelty or yield claims as individuals\. Delayed measurements become evidence or fitness records even if they arrive long after the planning span has ended\. If a later manuscript claims that a synthesis improved yield or discovered a novel material, the trace can connect the claim to the relevant sample identifiers, instrument files, extraction operator, and acceptance criterion\.

These examples do not require separate schema\. They require the same small set of records emitted beside existing logs and domain\-specific payloads referenced by hash or URI\. The live system can keep its own databases and orchestration runtime\. The artifact\-centered log supplies the exchange layer for common review queries: the lineage of the best candidate, unsupported claims, evaluator disagreement, archive churn, the cause of a plan revision, and the effect of a human intervention\.

## 8Discussion & Limitations

The profile can be tested against existing review practices\. It also raises practical questions about deployment overhead, integrity, and scope\.

Audit coverage\.Given traces from pipelines that generate papers, evolutionary code search, multi\-agent planning, and closed\-loop experiments, independent auditors should be able to recover the evidence for each reported claim, the operator that introduced it, and the evaluation that accepted or rejected it\. The baseline should be the best available existing records, not an intentionally weak comparison\.

Reviewer utility\.Generated manuscripts can be reviewed with and without claim\-aware artifact traces\. Useful outcome measures include time to identify unsupported claims, agreement among reviewers about failure causes, and the number of reconstruction steps performed outside the trace\. The profile is useful only if it reduces review burden rather than adding another artifact reviewers ignore\.

Trace benchmarks\.A useful benchmark would pair research artifacts generated by agents with gold audit labels: claim records, evidence objects, verifier outcomes, lineage edges, archive decisions, and steering events\. A minimal package for reviewers could include a schema file, a redacted or synthetic run log, a manifest mapping payload hashes to public artifacts, validator output, and query examples matching Table[1](https://arxiv.org/html/2608.18312#S3.T1)\. This is weaker than full reproducibility, but stronger than a prose assurance that a system was logged\.

Overhead and portability\.A practical profile must tolerate high\-frequency tool calls without forcing every token or scratch file into the lineage graph\. Tiered logging offers one path: cheap IDs and hashes for most artifacts, richer evidence bindings for selected claims, and domain\-specific expansion when an audit requires it\. The same run should also export to OpenTelemetry, PROV\-O, RO\-Crate, and agent\-native archives without losing claim, lineage, fitness, archive, or steering relations \(Appendix[D](https://arxiv.org/html/2608.18312#A4)outlines one such package\)\.

Integrity and redaction\.High\-stakes deployments need tamper evidence as well as privacy controls\. Append\-only event streams, event signatures, hash chains, payload redaction records, and access policies can help distinguish a missing payload from a missing event\. These mechanisms do not make a bad evaluator correct, but they make silent rewriting of the scientific record harder and clarify which parts of the trace were emitted online versus reconstructed after the run\.

Other Limitations\.Artifact\-centered observability does not prevent hallucination, fabrication, unsafe laboratory action, or benchmark overfitting\. It makes the objects needed to detect and investigate such failures explicit\. Verification quality still depends on evaluators, domain rules, and human judgment\. A trace can faithfully record a bad novelty criterion or a biased benchmark\. The point is that the criterion and benchmark become visible objects\. The hardest open question is granularity: each domain needs conventions for what counts as a material individual, especially when claim extraction is partly automated and partly post hoc\.

## 9Conclusion

Autonomous science needs observability at the level of scientific artifacts\. The relevant audit object is often not a prompt, span, or run, but a candidate artifact and the relations among claims, evidence, and evaluation around it\. We argue that artifact\-centered, claim\-aware traces should become a minimum layer for scientific agent systems\. The profile proposed here is small by design: individuals, operators, fitness records, lineage, archives, runs, streams, and steering commands\. It complements existing telemetry and provenance standards while giving reviewers the graph they need to inspect generated research\.

## Acknowledgments

This research used resources of the Advanced Photon Source, a U\.S\. Department of Energy \(DOE\) Office of Science user facility at Argonne National Laboratory, and is based on research supported by the U\.S\. DOE Office of Science\-Basic Energy Sciences, under Contract No\. DE\-AC02\-06CH11357\.

## References

- Arize AI \(2023\)Arize AIArize Phoenix documentation\.Note:[https://arize\.com/docs/phoenix](https://arize.com/docs/phoenix)Accessed: May 2026Cited by:[§2](https://arxiv.org/html/2608.18312#S2.p1.1)\.
- Beelet al\.\(2025\)J\. Beel, M\. Kan, and M\. BaumgartEvaluating sakana’s ai scientist: bold claims, mixed results, and a promising future?\.ACM SIGIR Forum59\(1\),pp\. 1–20\.Cited by:[§1](https://arxiv.org/html/2608.18312#S1.p3.1)\.
- Belhajjameet al\.\(2013\)K\. Belhajjame, R\. B’Far, J\. Cheney, S\. Coppens, S\. Cresswell, Y\. Gil, P\. Groth, G\. Klyne, T\. Lebo, J\. McCusker,et al\.PROV\-DM: the PROV data model\.W3C Recommendation\.Cited by:[§2](https://arxiv.org/html/2608.18312#S2.p1.1),[§4\.2](https://arxiv.org/html/2608.18312#S4.SS2.p1.1)\.
- Boikoet al\.\(2023\)D\. A\. Boiko, R\. MacKnight, B\. Kline, and G\. GomesAutonomous chemical research with large language models\.Nature624\(7992\),pp\. 570–578\.Cited by:[§1](https://arxiv.org/html/2608.18312#S1.p1.1)\.
- Branet al\.\(2024\)A\. M\. Bran, S\. Cox, O\. Schilter, C\. Baldassari, A\. D\. White, and P\. SchwallerAugmenting large language models with chemistry tools\.Nature Machine Intelligence6\(5\),pp\. 525–535\.Cited by:[§1](https://arxiv.org/html/2608.18312#S1.p1.1)\.
- Kuprieievet al\.\(2020\)R\. Kuprieievet al\.DVC: data version control – git for data & models\.External Links:[Document](https://dx.doi.org/10.5281/zenodo.3677553),[Link](https://doi.org/10.5281/zenodo.3677553)Cited by:[§2](https://arxiv.org/html/2608.18312#S2.p1.1)\.
- LangChain Inc\. \(2024\)LangChain Inc\.LangSmith documentation\.Note:[https://docs\.langchain\.com/langsmith/home](https://docs.langchain.com/langsmith/home)Accessed: May 2026Cited by:[§2](https://arxiv.org/html/2608.18312#S2.p1.1)\.
- Langfuse \(2023\)LangfuseLangfuse documentation\.Note:[https://langfuse\.com/docs](https://langfuse.com/docs)Accessed: May 2026Cited by:[§2](https://arxiv.org/html/2608.18312#S2.p1.1)\.
- Leboet al\.\(2013\)T\. Lebo, S\. Sahoo, D\. McGuinness, K\. Belhajjame, J\. Cheney, D\. Corsar, D\. Garijo, S\. Soiland\-Reyes, S\. Zednik, and J\. ZhaoPROV\-O: the PROV ontology\.W3C Recommendation\.Cited by:[§2](https://arxiv.org/html/2608.18312#S2.p1.1),[§4\.2](https://arxiv.org/html/2608.18312#S4.SS2.p1.1)\.
- Leemanet al\.\(2024\)J\. Leeman, Y\. Liu, J\. Stiles, S\. B\. Lee, P\. Bhatt, L\. M\. Schoop, and R\. G\. PalgraveChallenges in high\-throughput inorganic materials prediction and autonomous synthesis\.PRX Energy3\(1\),pp\. 011002\.Cited by:[§1](https://arxiv.org/html/2608.18312#S1.p3.1)\.
- Liuet al\.\(2026\)J\. Liu, J\. Pei, J\. Huang, C\. Si, A\. Qu, X\. Tang, R\. Lu, L\. Chen, X\. Bai, H\. Zheng,et al\.The last human\-written paper: agent\-native research artifacts\.arXiv preprint arXiv:2604\.24658\.Cited by:[§4\.2](https://arxiv.org/html/2608.18312#S4.SS2.p2.1)\.
- Luet al\.\(2026\)C\. Lu, C\. Lu, R\. T\. Lange, Y\. Yamada, S\. Hu, J\. Foerster, D\. Ha, and J\. CluneTowards end\-to\-end automation of ai research\.Nature651\(8107\),pp\. 914–919\.Cited by:[§1](https://arxiv.org/html/2608.18312#S1.p1.1)\.
- MLflow project \(2018\)MLflow projectMLflow documentation\.Note:[https://mlflow\.org/docs/latest/genai](https://mlflow.org/docs/latest/genai)Accessed: May 2026Cited by:[§2](https://arxiv.org/html/2608.18312#S2.p1.1)\.
- Novikovet al\.\(2025\)A\. Novikov, N\. Vũ, M\. Eisenberger, E\. Dupont, P\. Huang, A\. Z\. Wagner, S\. Shirobokov, B\. Kozlovskii, F\. J\. Ruiz, A\. Mehrabian,et al\.Alphaevolve: a coding agent for scientific and algorithmic discovery\.arXiv preprint arXiv:2506\.13131\.Cited by:[§1](https://arxiv.org/html/2608.18312#S1.p1.1)\.
- OpenLineage project \(2021\)OpenLineage projectOpenLineage specification\.Note:[https://openlineage\.io/docs/](https://openlineage.io/docs/)Accessed: May 2026Cited by:[§4\.2](https://arxiv.org/html/2608.18312#S4.SS2.p1.1)\.
- OpenTelemetry GenAI Special Interest Group \(2024\)OpenTelemetry GenAI Special Interest GroupSemantic conventions for generative AI systems\.Note:[https://opentelemetry\.io/docs/specs/semconv/gen\-ai/](https://opentelemetry.io/docs/specs/semconv/gen-ai/)Accessed: May 2026Cited by:[§4\.2](https://arxiv.org/html/2608.18312#S4.SS2.p1.1)\.
- Romera\-Paredeset al\.\(2024\)B\. Romera\-Paredes, M\. Barekatain, A\. Novikov, M\. Balog, M\. P\. Kumar, E\. Dupont, F\. J\. Ruiz, J\. S\. Ellenberg, P\. Wang, O\. Fawzi,et al\.Mathematical discoveries from program search with large language models\.Nature625\(7995\),pp\. 468–475\.Cited by:[§1](https://arxiv.org/html/2608.18312#S1.p1.1)\.
- Schmidgallet al\.\(2025\)S\. Schmidgall, Y\. Su, Z\. Wang, X\. Sun, J\. Wu, X\. Yu, J\. Liu, M\. Moor, Z\. Liu, and E\. BarsoumAgent laboratory: using llm agents as research assistants\.Findings of the Association for Computational Linguistics: EMNLP 2025,pp\. 5977–6043\.Cited by:[§1](https://arxiv.org/html/2608.18312#S1.p1.1)\.
- Soiland\-Reyeset al\.\(2022\)S\. Soiland\-Reyes, P\. Sefton, M\. Crosas, L\. J\. Castro, F\. Coppens, J\. M\. Fernández, D\. Garijo, B\. Grüning, M\. La Rosa, S\. Leo,et al\.Packaging research artefacts with ro\-crate\.Data Science5\(2\),pp\. 97–138\.Cited by:[§2](https://arxiv.org/html/2608.18312#S2.p1.1),[§4\.2](https://arxiv.org/html/2608.18312#S4.SS2.p1.1)\.
- Swansonet al\.\(2025\)K\. Swanson, W\. Wu, N\. L\. Bulaong, J\. E\. Pak, and J\. ZouThe virtual lab of ai agents designs new sars\-cov\-2 nanobodies\.Nature646\(8085\),pp\. 716–723\.Cited by:[§1](https://arxiv.org/html/2608.18312#S1.p1.1)\.
- Szymanskiet al\.\(2023\)N\. J\. Szymanski, B\. Rendy, Y\. Fei, R\. E\. Kumar, T\. He, D\. Milsted, M\. J\. McDermott, M\. Gallant, E\. D\. Cubuk, A\. Merchant,et al\.An autonomous laboratory for the accelerated synthesis of inorganic materials\.Nature624\(7990\),pp\. 86\.Cited by:[§1](https://arxiv.org/html/2608.18312#S1.p3.1)\.
- Szymanskiet al\.\(2026\)N\. J\. Szymanski, B\. Rendy, Y\. Fei, R\. E\. Kumar, T\. He, D\. Milsted, M\. J\. McDermott, M\. Gallant, E\. D\. Cubuk, A\. Merchant,et al\.Author correction: an autonomous laboratory for the accelerated synthesis of inorganic materials\.Nature650\(8100\),pp\. E1–E1\.Cited by:[§1](https://arxiv.org/html/2608.18312#S1.p3.1)\.
- Weights & Biases \(2023\)Weights & BiasesW&B weave documentation\.Note:[https://docs\.wandb\.ai/weave](https://docs.wandb.ai/weave)Accessed: May 2026Cited by:[§2](https://arxiv.org/html/2608.18312#S2.p1.1)\.
- Xuet al\.\(2026\)Z\. Xu, Y\. Qiu, L\. Sun, F\. Miao, F\. Wu, X\. Wang, X\. Li, H\. Lu, Z\. Zhang, Y\. Hu,et al\.GhostCite: a large\-scale analysis of citation validity in the age of large language models\.arXiv preprint arXiv:2602\.06718\.Cited by:[§1](https://arxiv.org/html/2608.18312#S1.p3.1)\.
- Yamadaet al\.\(2025\)Y\. Yamada, R\. T\. Lange, C\. Lu, S\. Hu, C\. Lu, J\. Foerster, J\. Clune, and D\. HaThe ai scientist\-v2: workshop\-level automated scientific discovery via agentic tree search\.arXiv preprint arXiv:2504\.08066\.Cited by:[§1](https://arxiv.org/html/2608.18312#S1.p1.1)\.

## Appendix AEvent contract and structural invariants

The trace profile uses a compact event vocabulary\. Figure[A\.1](https://arxiv.org/html/2608.18312#A1.F1)shows the core records and their reference structure\. Table[A\.1](https://arxiv.org/html/2608.18312#A1.T1)records the fields that must survive export for the trace to remain inspectable\. Domain payloads can live outside the event stream\. The event stream only needs stable identifiers, typed relations, hashes or URIs, and enough version information to reconstruct the audit graph\.

![Refer to caption](https://arxiv.org/html/2608.18312v1/media/schema_er_diagram.png)Figure A\.1:Core records and their reference structure\. Payloads can remain in notebooks, databases, repositories, instrument stores, or archives\. The trace records the identities and relations needed for audit\.Table A\.1:A minimal event contract for portable artifact\-centered traces\.Five invariants are especially important\. First, every reference either resolves to an earlier event object or is marked as an external import\. Second, derivation edges are acyclic by artifact version, even when the system modifies its own code, prompt, or evaluator\. Third, every final scientific claim has an evidence binding, a failed verification record, or an explicit unsupported status\. Fourth, evaluator outputs name the evaluator version and the individual they judged\. Fifth, redaction removes payload access but not the fact that an event existed\. Otherwise a reviewer cannot distinguish private evidence from missing evidence\.

## Appendix BInspection queries

The trace is useful only when common audit questions can be answered mechanically\. Table[B\.1](https://arxiv.org/html/2608.18312#A2.T1)gives representative queries and the records they require\. These queries are deliberately stated at the schema level rather than in a particular database language, because an implementation may store events in JSONL, SQL tables, graph databases, version control history, or an experiment tracker with exported facets\.

Table B\.1:Schema\-level audit queries enabled by the event contract\.These queries are a useful acceptance test for an implementation\. A system that logs all prompts and tool calls but cannot answer them has execution telemetry, not artifact\-centered scientific observability\.

## Appendix CCompact tracelets for common failures

The following tracelets are intentionally partial \(Table[C\.1](https://arxiv.org/html/2608.18312#A3.T1)\)\. They show the few records that make an error inspectable, not the full runtime history\.

Table C\.1:Small trace fragments for diagnosing common audit failures\.
## Appendix DPackaging, export, and redaction

A reviewable trace package does not require access to a private production system\. The portable object can be small: an event stream, a payload manifest, validator output, and a few inspection queries \(Table[D\.1](https://arxiv.org/html/2608.18312#A4.T1)\)\. The package should separate event identity from payload access so that private data can be redacted without erasing the scientific dependency graph\.

Table D\.1:A compact package for review, benchmarking, or later archival export\.Export to existing standards should preserve artifact identifiers\. Operators can link to OpenTelemetry spans or span groups\. In PROV, individuals map to entities, operators to activities, and streams or invokers to agents\. Payloads, manifests, validator reports, and query examples can be packaged as RO\-Crate objects, and operators that produce data can expose OpenLineage facets when the payload is tabular\. The lossy boundary is claim semantics: evidence bindings, verifier versions, archive membership, and steering effects should be preserved as explicit fields or companion files rather than compressed into free text metadata\.

## Ethics Statement

This work advocates audit infrastructure for autonomous scientific agents\. It does not introduce a new autonomous agent or deploy a system in the world\. The intended ethical benefit is improved accountability for generated scientific claims, human steering decisions, and evidence use\. The same trace data could expose sensitive laboratory, personnel, or proprietary information, so deployments should add access control, redaction, and signing policies appropriate to the domain\.

## Use of Generative AI Assistance

A large language model \(Claude Opus 4\.8\) was used for editorial assistance in condensing, anonymizing, and reformatting an earlier manuscript draft\. The authors reviewed and edited the resulting text and remain responsible for the submission\.