The Mechanism Boundary in Automated Research

Date: May 18, 2026 | Author: Henry Eigen

The verifiability surface of research

Agents perform most effectively in domains with a large verifiability surface, where much of the output can be mechanically checked for correctness. Mathematics is often presented as a best case, where, through autoformalization, an entire proof can be rendered in a formal system and machine-checked. Code is another where, although semantics can lie outside the verifiability surface, syntax and form provide enough checkability that agents remain effective.

Scientific research has no equally obvious surface. An automated research system does not merely output a hypothesis and a verdict, but also the design of the experiment which connects them, the implementation and execution of that experiment, and the interpretation of its results in order to render a verdict. A flaw in any of these intermediate outputs undermines the verdict’s inferential weight. The verdict depends on a correct interpretation of the results, which themselves depend on the execution of the experiment, which depends on a faithful implementation. And the implementation depends on whether the design actually operationalizes the hypothesis.

This creates a reflexive problem. The system is not only testing a hypothesis, it is also testing whether the experimental apparatus it constructed is itself a valid test of that hypothesis. In human science, confidence in the experimental apparatus is distributed across background theory, instrumentation, calibration, controls, disciplinary convention, and expert judgment. In an automated system, such stabilizers must either be made explicit, or implicitly left to be absorbed into agent judgment. The degree to which the apparatus can be made explicit, constrained, and mechanically checkable defines the verifiability surface of automated research.

Two ways to get verifiability

One way to get verifiability is to narrow the scope of the system. A common formulation of automated research systems, which we’ll refer to as “hill-climbers”, specifies a baseline, provides a pre-built grader, and then tasks agents with mutating the baseline in order to improve the grader’s score. By removing experiment design and results analysis from the agents’ responsibilities, these systems provide a strong verifiability surface by moving much of the epistemic burden onto pre-specified components. Because the grader fixes much of the process mechanically and in advance, it can serve as a strong verifier of the agent’s output. But the same fixedness limits the system. Anything the grader was not built to score remains outside the scope of the agent’s exploration.

General auto-research systems, by contrast, do not restrict themselves to a fixed task. Instead, they delegate the entire research process to agents, who are responsible for hypothesis generation, experiment design, implementation and execution, and interpretation of results. In the absence of a provided verifiability surface in the form of a grader, these systems must find verifiability in the invariant structure of valid experiments. Doing so requires designing the system to expose this structure in the first place, thereby making it a mechanically checkable surface against which intermediate outputs can be validated. Existing systems do generally decompose the research process, but their decompositions are primarily procedural, focused on how tasks are split among agents, how open-ended their instructions are, and whether domain knowledge is hardcoded or ingested [1].

This post asks how much of that surface can be exposed. The following post will propose a design framework for exploiting this surface, so that automated research systems can make stronger claims about the verdicts they render on hypotheses.

The missing machinery

The architectures of existing automated research systems describe how agents move work through workflows resembling the stages of the scientific method. But they say little about how those workflows preserve the validity conditions by which an experiment can bear on a hypothesis. Setting aside the agents’ prompt context, little in the machinery of these systems is specific to scientific research, as opposed to agent orchestration work in general [2].

This is not for want of a body of theory to build on. A long tradition of work on experimental design and validity methodology offers a strong foundation upon which to build such machinery. These bodies of work seem largely neglected by the prominent auto-research systems however. A scan of the works cited sections of several such systems uncovered sparing references to works in the philosophy of science concerning topics such as statistical validity, experiment design, or causal inference.

This would be a pedantic complaint if the performance of these systems suggested they had little to benefit from such grounding. But common failure points identified by audits [3, 4] of these systems suggest otherwise. Issues surfaced by these audits include unvaried factor levels, post-hoc selection bias, failure to isolate control factors, etc. These are exactly the types of issues which structural machinery can catch mechanically.

It is expected that, over the course of a long running, multifaceted task, individaul agents may make mistakes. The more important failure occurs when these mistakes go unchecked, allowing them to undermine work in subsquent stages. This is symptomatic of a system design in which validity is carried largely by prompt context and agent judgment. What is missing is an explicit representation of the inferential chain connecting hypothesis, design, implementation, execution, metrics, and verdict.

Various surveys decompose the research process according to slightly different phase taxonomies. Some group more broadly (e.g. a four-stage pipeline which treats experiment planning and execution as one). Some introduce additional phases (e.g. a six-stage pipeline which distinguishes literature review from idea generation). But none otherwise deviate significantly from each other, nor from our five-stage chain.

Each link in that chain holds only under certain conditions: a comparison must be well-formed, an implementation must be faithful to its design, a verdict must follow from the metrics it rests on. The experimental-design and validity methodology invoked earlier exists precisely to characterize these conditions. The degree to which the satisfaction of these conditions can be checked mechanically defines the verifiability surface of the scientific process in general. Unlike the hill-climber’s grader, which is fixed to one experiment in advance, this surface is intrinsic to the structure every valid experiment shares. A system built on it can therefore offer mechanical guarantees over whatever experiment its agents design.

In the following sections, we take that inferential chain as the object of design, and try to understand what each link requires to be valid. The system we propose is built on the result.

Design

The first link in the chain sees the design of an experiment to be used to test the hypothesis. This design defines the experimental factor, controlled conditions, variable treatments, etc. Crucially, it also defines the verdict function, that is, the metrics, thresholds, and directional assertions which map the eventual output of the experiment to a verdict on the correctness of the hypothesis. (The decisions on what outputs are being measured, and how they are interpreted have to be defined up front; it can’t be decided after results have been seen)

The validity of this link hinges on whether the experiment, as defined, will actually yield a confirmation / disconfirmation of the hypothesis. We can decompose that into two separate, more precise questions, roughly matching the distinction Cook & Campbell (1979) [5] drew between internal validity and construct validity:

Is it a well-formed experiment comparing different treatments of the same factor along a common metric, and without confounding conditions (i.e. the experiment is structured so as to rule out any explanations for a difference in the metric apart from the techniques themselves)?
Do the factor, treatments, and metrics operationalize the constructs named in the hypothesis (i.e. is the experiment relevant to the hypothesis)?

The first question can be mechanically checked to a certain extent. Prior works have built DSLs in which to specify experiment designs such that they can be statically analyzed for problems like treatment-assignment errors and gaps in causal sufficiency (PlanAlyzer [6]; PLanet [7]).

The latter question, however, exists in “reasoning space,” and the responsibility for validation therefore falls to an agent.

Implementation

Next, the experiment specified by the design is implemented. The validity criterion here is whether or not the implementation is faithful to the design.

As we did before, we’ll consider the two separate interpretations of “faithful,” roughly mapping onto the concept of verification vs validation in software engineering:

Verification is concerned with the implementation’s adherence to the explicit specifications of the design. That is, whether there is an implementation for each technique, whether each of these emits correctly labeled and shaped metrics, whether each plugs into a shared harness which purportedly implements the controlled conditions, etc.
Validation asks whether the implementations are faithful to the methods which the design intends them to be.

In terms of verification, the formulation of the DSL determines the degree to which structural questions are explicitly answered in the design, and therefore the surface area for mechanical checkability. This pattern, declarative specification compiled into an artifact against which code is mechanically checked, is well-trodden ground. It traces at least to Meyer’s Design by Contract [10] and surfaces today in interface description languages like Protocol Buffers and in content-addressed build systems like Nix. The verification we ask for here sits in that contract-checking tier, not in the heavier verification-language tier (Liquid Haskell, F*, Dafny, TLA+) where richer invariants are statically proven.

Validation, on the other hand, asks whether the implementations are faithful to the design’s intent. Even generally speaking, in terms of SWE tasks, this validation is relegated to a code reviewer agent, since “intent” is very much a reasoning-space concept.

Our particular problem leans on agent reasoning for validating intent even more heavily than a typical engineering task does. Tests normally carry part of the load by checking code against known-correct outputs, but our implementations have no such output to check against. Behavior tests we can still write, but only for behaviors we specify in advance. Choosing what to specify is itself the interpretive work, and passing the tests is never the same as faithfulness to the method as a whole.

The check that would settle faithfulness, holding the implementation against the experiment’s own expected results, we can never run. Were those results known, the experiment would be pointless, its verdict already in hand. Ours is, in Weyuker’s sense, a “non-testable program” (Weyuker 1982) [8], written to reveal an answer unknowable beforehand. Validating its faithfulness is therefore solely the province of reasoning-space actors.

Footnote. Since the experiment set-up (implementation) is, for our purposes, a matter of writing code, we appealed to Weyuker’s argument about this tautological validation (i.e. the implementation is correct because it yields expected results, and the expected results are correct because they were yielded by a correct implementation) in the context of software engineering testability.

However, this same “experimenter’s regress” (Collins 1985) [9], in which an apparatus can be shown to work only by producing the correct result while the correct result is knowable only from an apparatus already shown to work, risks manifesting itself in experimental science more generally.

Execution and verdict

Finally, the implemented experiment is executed, and its output used to render a verdict. Execution is the one purely mechanical link in the chain, calling for no agent reasoning of its own. The final question, then, is whether the verdict is correct. There are two interpretations of correctness here:

Was the verdict correctly calculated using the proper metrics (this question largely overlaps with a third form of validity given by Cook & Campbell, statistical conclusion validity)?
Is the verdict truly confirming or disconfirming the hypothesis?

In regard to the first, this isn’t so much mechanically verified as it is mechanically guaranteed: the design specifies the verdict calculation, and verification has already established that the implementation emits the metrics that calculation requires.

The second isn’t really specific to this link, but rather concerns every link up to, and including, this final one. It gets into a sort of Quinean idea that we’re rendering a verdict not only on the correctness of the hypothesis in isolation, but also on the aptness of our experiment design, and the faithfulness of our implementation.

Footnote. Various questions throughout have mapped to three of Cook & Campbell’s forms of validity: internal, construct, and statistical conclusion, but the framework from which these were drawn defined a fourth as well, external validity, the question of whether the experiment’s findings are generalizable beyond the particular experiment’s limited scope. Currently, we place this question in the wider research workflow, beyond the chain examined here. That is to say, it is the research agent’s job to take this question into account when generating hypotheses. An argument could be made, though, that this question belongs to the chain itself, seeing as the chain is where experiments are designed, and follow-on experiments are what is required to satisfy external validity.

The machinery

Taken link by link, the chain partitions cleanly. The design of an experiment can be checked for well-formedness, but whether it captures the constructs the hypothesis names is left to an agent’s judgment. An implementation can be verified against the design’s explicit specifications, yet its faithfulness to the method behind them again relies on an agent to judge. The verdict itself, once the design has fixed how it is computed, follows by construction, though it is sound only insofar as every link before it held.

That division between what is settled mechanically, and what is left to agents, is the verifiability surface this post set out to find. The surface is intrinsic to the chain, but it is latent. A mechanism can only check what has been made explicit, so how much of the surface a system reaches depends on the declarative language its experiments are written in. A language that forces more structure into the open exposes more of the surface to checking; a looser one leaves more to agents. All languages though, however well designed, will fall short of reaching the interpretive judgments this post has traced. That is irreducibly the domain of agents.

Early on we observed that many of the existing auto-research systems lacked machinery specific to scientific research. The companion post, How SMAI works, gives one example of how the concepts discussed in this post could be used to construct such machinery.