A verifier for autonomous scientific code caught every seeded defect, after two of its own tests were made able to fail

CheAI Research Inc. | Methods article | October 4, 2026

Keywords: scientific software; verification; reproducibility; AI agents; negative controls; mutation testing

Abstract

1. Introduction

Automated agents increasingly generate and execute scientific code. Their errors are often silent: a number is produced, formatted and reported, but it rests on a unit off by a factor of a thousand, a fuel quantity on the wrong heating-value basis, or the output of a solver that did not converge. Reproducibility practice holds that a computational result should be re-executable and checkable [1]. This study asks whether executable evidence, re-running the computation and testing its outputs against independent rules, exposes such failures, and how the checks themselves should be validated, a question with a long history in mutation testing [2].

2. Methods

2.1 Corpus

The corpus contains 2 valid cases, water heated by a known amount (502.32 kJ) and a gas heat input on a stated higher-heating-value basis (380.0 MJ), each with an independent hand calculation. It contains 7 defects, each seeded into a copy of a valid case's recorded outputs, with the expected rejection code recorded before the verifier was run (Table 1). The defect cases are checked statically, from their recorded files; only the valid cases are re-executed.

2.2 Robustness probes

Two replays of the valid cases compared file hashes between runs. The 6 failure probes covered a process that hangs and must be terminated with its children, a process that exits with an error, one that writes no output, malformed output, a non-finite value and a corrupted byte. The 5 path-escape attempts to read or write outside the case directory used relative paths, an absolute path and a symbolic link.

2.3 Validation of the checks

Each probe counts as passing only if the rejection names the expected reason; a rejection for any other reason is treated as a silent acceptance. Checks whose result could be guaranteed by construction were given negative controls.

3. Results

3.1 Seeded defects

The verifier rejected all 7 defects with the expected reasons (0 missed) and rejected 0 of 2 valid cases (Table 1, Figure 1). Each defect was rejected for its own reason rather than by a generic failure; the truncated output containing a NaN token returned two codes, being both non-finite and missing its provenance record.

Table 1. Seeded defects and the rejection reasons returned.

3.2 Replays, failure probes and path escapes

Two replays of the valid cases hashed 6 files each and found 0 mismatches. Each failure probe was rejected with the expected code; 0 of 6 were silently accepted. All path-escape attempts were refused before any file was accessed; 0 of 5 were accepted.

3.3 Two uninformative checks and their repair

The byte-flip probe was intended to show that a single corrupted byte is detected by its hash. In its original form it ran in a scratch directory containing only the output file, so the verifier rejected the case for a missing file before reading the corrupted byte. The probe passed without testing corruption. It now stages the complete valid case with a correct manifest, flips one byte, and passes only if the rejection reports a hash mismatch or corrupt JSON.

The check that every benchmark claim links to an independent answer counted 0 orphans across 7 links. That result was guaranteed by how the claims were generated. The check now includes a negative control: a fabricated claim about a nonexistent case is passed through the same interface and must be flagged.

4. Discussion

Executable evidence reliably detects the mechanical failure classes represented in the corpus, provided the checks are themselves validated. The two repairs illustrate the principle: a check earns trust by being shown to fail on an input it should reject, and a check whose pass is guaranteed by construction provides no evidence. Executable evidence does not, however, judge whether the scientific question, model or assumptions were appropriate.

5. Limitations

• The corpus of 9 cases shows that these failure classes are detected, not that all failures are.
• The verifier runs local, trusted case directories, not adversarial code.
• Solver failures are detected from reported status; no optimizer runs inside the verification loop.
• Evidence was obtained on one operating system and architecture.

6. Conclusions

A verifier combining output checks with re-execution rejected all 7 seeded defects, checked from their recorded outputs, with the expected reasons, and reproduced and accepted all valid cases. Detecting defects by re-executing faulty code was not tested. Validating the checks with negative controls was necessary for these results to be meaningful.

References

1. Peng RD. Reproducible research in computational science. Science, 334(6060):1226-1227, 2011.
2. Jia Y, Harman M. An analysis and survey of the development of mutation testing. IEEE Transactions on Software Engineering, 37(5):649-678, 2011.

Related studies

• Governance of an autonomously built engineering model: the wider process these checks belong to
• Independent verification of nine published studies: the same principle applied to a report set
• Independent verification of IAPWS-IF97: a test corpus that was itself wrong