1 Introduction↩︎

Large language models have made it possible to automate substantial portions of the scientific workflow: ideation, experiment scripting, result interpretation, manuscript drafting, and review simulation [1], [2]. Related agent systems have shown that language models can reason, act, write code, repair software, and operate over long horizons [3]–[7]. However, a system that generates a plausible manuscript is not necessarily a system that can be trusted as research infrastructure. The hard problem is not only text generation. It is the management of evidence, failures, revisions, and handoffs over time.

XScientist addresses this operational problem. The system is designed around four principles:

1. Research runs should be observable. Each stage should emit structured artifacts that can be inspected without replaying the entire workflow.

2. Research runs should be forkable. A later agent should be able to continue from a specific experiment node instead of cold-starting from the final PDF.

3. Research claims should be grounded. Manuscript assertions should remain linked to the experiment nodes and evidence artifacts that support them.

4. Research automation should expose uncertainty. Failed branches, reviewer objections, integrity warnings, and blocked gates should be preserved as first-class outputs rather than hidden as pipeline noise.

The result is a long-running autonomous scientific research system with a git-like artifact protocol. XScientist can be used as a local project runner, a continuous paper generator, or a daemon that schedules multiple research sources over time. Its output is not just a manuscript but a structured record of how the manuscript came to exist.

The system described here is not only a design sketch. It is tied to the open-source XScientist repository at https://github.com/smileformylove/XScientist, which contains the running implementation, protocol schemas, command-line tools, examples, documentation, and the arXiv source for this report. The repository is therefore part of the research contribution: it is the inspectable substrate for the protocol, figures, release workflow, and future replication attempts.

This report makes three contributions. First, it describes the design of a long-running research operating system whose core abstractions are run artifacts, quality gates, and operator handoffs rather than a single prompt. Second, it specifies the ARA layer as a practical interchange format for agent-native research state: exploration graphs, node bundles, claim anchors, content hashes, and provenance. Third, it documents the guardrails that have become necessary in practice, including sample-first execution, truth contracts, deterministic integrity forensics, and daemon controls. The paper is therefore best read as a system report and protocol proposal, not as a claim that autonomous research can replace scientific review.

2 Related Work↩︎

2.0.0.1 Autonomous scientific discovery.

The AI Scientist introduced an end-to-end loop for automated idea generation, experiment execution, paper writing, and review [1]; related open research prototypes such as autoresearch also explore lightweight automation loops for scientific work [8]. AI Scientist-v2 extends this line with agentic tree search and workshop-level paper generation [2]. XScientist follows the same broad goal of automating research workflows, but shifts the main abstraction from “generate a paper” to “produce a forkable research protocol artifact.” The protocol layer is intended to make continuation, review, and cross-system handoff explicit.

2.0.0.2 LLM agents and long-horizon work.

ReAct combines reasoning and acting in language models [3]; Reflexion studies verbal feedback loops for language agents [4]; Tree of Thoughts explores deliberate branching search [5]; Voyager demonstrates open-ended skill accumulation in an embodied environment [7]. Software-engineering agents such as SWE-agent show how interface design affects autonomous repair [6], AIDE explores code-space search for ML engineering tasks [9], while multi-agent frameworks such as AutoGen support conversation-based orchestration [10]. XScientist borrows the branching and repair mindset of these systems but applies it to scientific artifact management.

2.0.0.3 Experiment tracking and versioned research state.

MLflow and DVC are representative tools for machine-learning lifecycle tracking and data/model versioning [11], [12]. They address important parts of reproducibility but do not directly specify a claim-to-experiment protocol for autonomous research manuscripts. XScientist’s ARA layer is closer to a git-like object model for research runs: a portable directory contract with nodes, edges, content hashes, provenance, and re-execution hooks.

2.0.0.4 Automated review and integrity checking.

Reviewer-oriented systems such as DeepReviewer explore stronger automated review signals [13]. Anti-Autoresearch motivates evidence-led scrutiny of generated research artifacts [14]. XScientist integrates reviewer-style repair with deterministic integrity forensics, but keeps these checks conservative: they are safeguards and audit aids, not proofs of scientific correctness.

3 System Overview↩︎

XScientist is organized as a research operating system. Figure 1 summarizes the high-level control flow. The pipeline begins with topics or source queues, produces ranked ideas, executes experiments, generates manuscripts, performs self-review and repair, applies quality and integrity gates, and archives reusable artifacts.

3.1 Execution Modes↩︎

The current repository exposes three main entry points.

• run_project.py runs an end-to-end project from a topic or idea file.

• continuous_paper_generator.py performs batch and continuous generation across selected ideas and paper types.

• continuous_research_daemon.py runs a long-lived scheduling loop with source queues, dashboarding, reports, and operator controls.

3.2 Pipeline Artifacts↩︎

XScientist writes structured JSON and Markdown artifacts throughout the run: idea cards, research plans, experiment registries, reviewer findings, repair plans, manuscript candidates, quality reports, integrity forensics reports, source provenance, and handoff briefs. These artifacts are deliberately more important than transient console output. They give downstream agents and human operators a stable interface for audit and continuation.

3.3 Core Components↩︎

The system is decomposed into components that can be used independently or as part of the full pipeline.

3.3.0.1 Ideation and planning.

The ideation layer converts topics and source queues into candidate ideas, rankings, and research plans. Plans contain tasks, expected outputs, acceptance checks, baselines, and execution policy hints. In high-quality runs, the planner also produces artifacts used by later quality and truth checks.

3.3.0.2 Experiment execution.

Experiments are executed through a tree-search-style loop that records code, stdout/stderr, metrics, plots, and failure states. XScientist treats failed branches as useful evidence: they may explain why a later repair exists, why a claim was softened, or why a branch should not be continued.

3.3.0.3 Writing and review.

The writing layer produces LaTeX manuscripts and structured metadata. The review layer applies text and figure review, extracts issues, schedules repair actions, and can run multiple reviewer-oriented strategies such as novelty, rigor, clarity, and reproducibility checks.

3.3.0.4 Indexing and management.

The management layer surfaces boards for generated papers, review issues, repair priorities, process alignment, and evolution signals. This keeps the system usable as an operating workflow rather than only as a batch script.

3.4 Operating Assumptions↩︎

XScientist assumes that autonomous research should be operated under explicit budgets and review boundaries. The system can run for long periods, but it does not assume that every cycle should advance to a full manuscript. A run may stop because a sample gate fails, because a truth contract is violated, because integrity forensics finds hard flags, or because the operator pauses the daemon. These stopping states are treated as valid outcomes.

4 Agent-Native Research Artifacts↩︎

The most important interface in XScientist is the Agent-Native Research Artifact (ARA). An ARA is a directory rooted at a manifest.json file and an exploration_graph.json file. It is designed to be read by another agent without requiring that agent to reverse-engineer the final paper.

4.1 Exploration DAG↩︎

Each ARA stores an exploration DAG whose nodes represent concrete experiment, repair, failure, ablation, or manuscript-candidate states. Edges encode the parent-to-child evolution of the research process. The system validates that the graph is directed and acyclic, writes a summary file, and can render a self-contained HTML visualization. This turns each paper into a science exploration tree.

The exploration tree is intentionally not a polished success-only lineage. It includes bug states, discarded branches, and repaired branches because those states are often the most important for later review. A downstream agent that sees only the final successful experiment cannot know whether the result was robust, whether a metric was changed midstream, or whether a failed baseline was silently dropped. ARA makes those transitions inspectable.

4.2 Content Hashing and Provenance↩︎

ARA uses content hashes to identify node payloads and manifest revisions. Hashes are computed over canonical payloads such as code, metrics, and optional provenance fields. Forked runs preserve parent pointers, so a child research run can describe which previous ARA and node seeded it. The protocol therefore behaves like a lightweight object model for research state.

In practice, this gives XScientist a commit-like substrate. The final PDF is only one rendered view. The underlying research state can be diffed, logged, forked, or frozen. When an ARA is committed to a normal git repository, git records file-level snapshots, while ARA commands expose node-level scientific history inside those snapshots.

4.3 Claim Anchoring↩︎

The writing stage can insert invisible \claimref markers after quantitative or evidence-sensitive claims. A claim registry scans the manuscript source and writes claim records under the ARA. This creates a two-way link between paper assertions and the experiment nodes that support them. Claim coverage can then be summarized and used by quality gates or downstream reviewers.

4.4 Fork, Diff, Log, and Verify↩︎

The companion CLI run_ara_fork.py exposes operational verbs: inspect, exec, fork, freeze, validate, verify, diff, log, and refs. These commands let an operator inspect a node, re-execute its code, create a new seed ARA, compare two ARAs, or walk the provenance chain. The same graph data underlies the HTML visualization, the log view, and node-level diffs.

4.5 ARA Directory Contract↩︎

The minimal ARA contract requires two files: manifest.json and exploration_graph.json. Optional but common files include per-node code.py, term_out.log, metrics.json, plots.json, environment snapshots, claim records, verification reports, repair history, Pareto candidate pools, and a human-facing HTML graph view. Missing artifacts are not treated as fatal if they are declared; this lets lightweight producers implement the protocol incrementally while still being consumable by stricter tools.

4.6 Why a Protocol Instead of a Database↩︎

A database would make local querying convenient but would make handoff harder. ARA uses ordinary files so that artifacts can be copied, archived, attached to issues, reviewed in pull requests, or consumed by other agents without running a XScientist service. This design is deliberately close to how software engineering uses repositories: the protocol specifies what must exist on disk, while different tools can provide richer user interfaces over the same state.

5 Quality and Integrity Controls↩︎

Autonomous research systems require checks that are deterministic enough to be run in CI and explicit enough to be audited later. XScientist implements several such controls.

5.1 Self-Review and Repair↩︎

The self-review subsystem runs LLM-based and VLM-assisted reviews, extracts structured issues, prioritizes repairs, and records repair attempts. The system tracks whether reviewer objections were addressed, whether manuscript changes regressed earlier claims, and whether quality thresholds were met.

Repair is represented as a trace rather than as a single overwrite. The system records which issue motivated a repair, which artifact was modified, which checks were rerun, and whether the repair introduced new risks. This is important for generated manuscripts because a fluent rewrite can hide evidence loss. XScientist therefore treats repair coverage and regression detection as first-class quality signals.

5.2 Truth Contracts↩︎

Truth contracts translate a research plan into explicit constraints. They separate objective facts, comparability constraints, artifact-binding rules, branch-state rules, and value guardrails. For example, a manuscript should not claim a baseline-comparable improvement unless the experiment registry contains a completed run on the declared dataset, metric, and baseline.

The categories are intentionally broad: objective facts, comparability constraints, artifact-binding rules, branch-state transitions, and value guardrails. They are not a formal proof system. They are a pragmatic checklist that converts ambiguous planner intent into concrete conditions that can be checked later by gates, reviewers, or downstream agents.

5.3 Sample Gates↩︎

Before full generation, sample gates can require that a small planned task has a completed experiment record, a budget audit, passing acceptance checks, and a result summary. This prevents the system from scaling a flawed plan into a full paper when the cheap preliminary evidence is missing.

5.4 Deterministic Integrity Forensics↩︎

XScientist adapts an evidence-ledger pattern inspired by Anti-Autoresearch into the manuscript stage. The integrity forensics pass is not an authorship detector. It builds a span-anchored ledger from the manuscript source, applies model-free consistency checks, and writes a deterministic adjudication report. Hard findings can block submission-ready status; soft findings are reported for reviewer attention.

The deterministic design is deliberate. Model-based critique is useful, but a submission gate needs repeatable behavior. Integrity forensics therefore focuses on checks that can be rerun with the same result: suspicious pipeline artifacts in the manuscript, unsupported strong wording, arithmetic drift in reported deltas, citation placeholders, repeated caption/table presentation signals, and evidence-ledger gaps. It is a conservative screen for risks that deserve attention before a paper is treated as submission-ready.

5.5 Decision Logs and Gate Preconditions↩︎

Recent XScientist runs also write decision logs for workflow strategy, sample-gate outcomes, and model-provider choices. Gate preconditions are checked before expensive or high-risk stages proceed. For example, a quality gate that requires high-quality mode should not run under a cheaper classic pipeline by accident; a full-generation stage should not proceed when the sample gate is blocked. These checks turn implicit workflow assumptions into explicit runtime contracts.

6 Long-Running Daemon Operation↩︎

The daemon mode treats research as an ongoing operation rather than a single script invocation. It supports source queues, source health tracking, dashboard serving, daily reports, handoff briefs, pause/resume controls, source boosting and cooldown, failure protection, and strategy feedback.

This matters because autonomous research systems accumulate operational state. A topic source may produce weak ideas for a week and then recover. A review-hardening source may be valuable only after enough experimental evidence exists. XScientist therefore records source-level and portfolio-level signals so later cycles can adjust scheduling rather than replay a fixed script.

6.1 Operator Controls↩︎

The daemon is designed for supervised autonomy. Operators can pause and resume, stop after the current cycle, force or boost a source, apply a cooldown, inspect dashboard state, and generate handoff reports. This makes the system suitable for long-running local operation where full automation is not always desirable. A useful autonomous research system should make it easy to interrupt, inspect, and redirect.

6.2 Feedback Loops↩︎

The daemon collects feedback at several levels: paper-level quality signals, source-level health, strategy-level success rates, repair pressure, and process alignment. These signals can influence later scheduling and execution policy. For example, a source that repeatedly produces blocked sample gates can be cooled down, while a source producing useful review-hardening tasks can be boosted when a manuscript is near submission.

7 Reproducibility and Release Workflow↩︎

XScientist separates source code from generated research outputs by default. Runtime artifacts are written outside the repository unless the operator chooses otherwise. This reduces accidental repository pollution while keeping outputs easy to archive. For reproducibility, a report should cite the public repository, the exact commit hash, configuration, model choices, output directory, and the ARA root used for any generated paper. For the present system report, the canonical repository is https://github.com/smileformylove/XScientist.

The recommended release workflow for a generated manuscript is:

1. run the project or daemon under an explicit output root and budget;

2. inspect the generated manuscript, ARA, review reports, and integrity forensics;

3. verify or re-execute important ARA nodes where feasible;

4. check claim coverage and manually review evidence-sensitive claims;

5. package the manuscript and artifact references with commit hashes.

This workflow does not guarantee correctness, but it raises the cost of silent evidence loss and makes later review more concrete.

8 Comparison to One-Shot Paper Generation↩︎

Table 3 contrasts the XScientist design with a typical one-shot autonomous paper generator.

9 Evaluation Strategy↩︎

This report does not present a large benchmark claiming that XScientist outperforms other autonomous research systems. Instead, the current evaluation strategy is artifact-centered. A run should be judged by whether it produces:

• a valid ARA with a DAG exploration graph;

• per-node code, metrics, logs, and environment descriptors when available;

• claim anchors and claim coverage summaries for evidence-sensitive manuscript statements;

• review and repair artifacts that explain how manuscript changes were made;

• deterministic integrity reports with clear hard and soft findings;

• enough provenance for another agent or human to fork, verify, or reject the result.

This evaluation style is closer to systems engineering than to leaderboard scoring. It asks whether the research process is inspectable and recoverable. Future empirical work should compare ARA-backed continuation against cold start baselines, measure the cost of re-execution, and study whether claim-anchored review improves human error detection.

10 Limitations↩︎

XScientist does not make autonomous research automatically correct. The system can organize evidence, preserve provenance, and expose warnings, but human review remains necessary for scientific validity, ethical judgment, and final submission decisions. The current system also has several engineering limitations:

• Re-execution can be expensive or environment-dependent when nodes call external APIs, GPUs, or web services.

• Integrity forensics is deterministic but incomplete; it catches some classes of inconsistency and overclaiming, not all scientific errors.

• ARA is a protocol surface rather than a universal standard; broader adoption requires independent producers and consumers.

• The daemon improves operations, but long-running autonomy still needs explicit budgets, stop conditions, and operator oversight.

• The present paper is a system report. It documents the implementation and protocol surface but does not yet provide a controlled user study or a broad external benchmark.

11 Ethical and Safety Considerations↩︎

Autonomous research tooling can create plausible but incorrect scientific artifacts at high speed. XScientist is therefore designed to preserve uncertainty, not to erase it. The system records failed branches, exposes blocked gates, and explicitly states that integrity forensics is incomplete. Users should not submit generated papers without human review, should disclose substantial automated assistance when appropriate, and should avoid using the system for domains where erroneous claims can cause direct harm without additional expert oversight.

There is also an operational safety concern: long-running agents can consume API credits, compute, and storage unexpectedly. XScientist includes output isolation, preflight checks, daemon controls, and budget-oriented gates, but operators remain responsible for configuring limits and monitoring runs.

12 Discussion↩︎

The central claim of XScientist is that autonomous research should be judged not only by the final manuscript but by the quality of the artifact trail that produced it. A generated paper without a recoverable experiment tree is hard to audit. A failed branch without provenance is hard to learn from. A claim without a node anchor is hard to verify. XScientist makes these relations first-class.

The same design suggests a path toward collaborative autonomous science: systems can exchange ARAs, fork one another’s nodes, verify claims without parsing PDFs, and use git-like diffs to review scientific changes. This does not remove the need for human scientists. It gives human reviewers and downstream agents a stronger substrate to inspect.

13 Conclusion↩︎

XScientist is a long-running autonomous scientific research system built around structured artifacts, continuous operation, and a git-like research protocol. Its ARA export turns each paper into a science exploration tree with claim anchors, content hashes, provenance, and re-execution hooks. Together with self-review, repair loops, sample gates, truth contracts, deterministic integrity forensics, and daemon scheduling, this design moves autonomous research from one-shot paper generation toward reproducible and forkable research infrastructure.

Availability↩︎

The primary artifact for this report is the public XScientist GitHub repository:

It contains the implementation, ARA protocol schemas, command-line tools, examples, documentation, and tests. The arXiv source for this system report is maintained in the same repository under:

Reproducibility claims should cite both the repository URL and the exact commit hash used to run or inspect the system.

Acknowledgements↩︎

XScientist builds on ideas from AI Scientist, autoresearch, AIDE, DeepReviewer, and related open-source autonomous research and review systems. The integrity forensics layer adapts an evidence-ledger pattern inspired by Anti-Autoresearch.

References↩︎