Verification in RSI Bench

Task Setup

RSI Bench aims to measure whether AI agents can advance AI R&D through open-ended, iterative research. A research-oriented task could be ill-designed in many ways: instructions that are under- or over-specified, verification that rewards only a subset of valid solutions, train/test splits that reward memorization over generalization, sensitivity to hyperparameter choices rather than genuine method improvements, or baselines that are not at the frontier. To this end, we designed a verification pipeline to ensure that every accepted task is well-designed to measure the intended capability.

Each task provides an agent with a fixed resource budget and a research environment containing a reproducible baseline and a validation feedback loop that allows agents to run multiple experiments, learn from their outcomes, and iterate on their ideas. The final submission is then measured by a separate hidden evaluator under held-out conditions (e.g., unseen data, models, or environments). If verification covers multiple objectives, it aggregates all scores into a final scalar reward.

Verification

RSI Bench uses Harbor task formats and builds on verification workflow developed for Terminal-Bench by extending it to this iterative-based research setting.

1. Step 1Proposal ReviewDesign

   Every submission starts with a research proposal rather than a full implementation. The proposal must identify a meaningful AI R&D problem, a baseline method that leaves room for improvement, the changes an agent is allowed to make, and a resource budget that allows for enough experimentation. Reviewers also consider what should generalize from validation to hidden evaluation and whether the proposed reward captures the important trade-offs and potential reward hackings. This review ensures that each selected task is a well-designed, verifiable research problem, with a credible evaluation plan and fits within RSI Bench's categories.

   ↓
2. Step 2Static ChecksStructure

   Static checks enforce the structure needed for an iterative research task. Every task must provide a runnable baseline.sh, an agent-visible val.sh, and a hidden test.sh. Both evaluators must accept the same self-contained submission and report the same continuous reward along with the individual measurements used. The checks also enforce a fixed experiment timer and keep hidden evaluation assets outside the agent's environment.

   ↓
3. Step 3Rubric ChecksMeasurement

   Rubric checks go beyond technical validity to ask whether a higher reward is credible evidence of stronger performance on the specific AI R&D skill the task is designed to measure. We use verdict and recommendation rubrics. Verdict rubrics cover requirements that every valid task should meet: the baseline must be credible, rewards must remain continuous, validation and hidden evaluation must use the same interface, invalid submissions must fail safely, and generated artifacts must include reproducible recipes. Recommendation rubrics address questions requiring greater scientific judgment, including whether the evaluation measures meaningful generalization, the reward captures important trade-offs, the baseline leaves measurable headroom, and the task genuinely elicits iterative R&D. Recommendation findings guide expert review and can be addressed by revising the task or through a well-supported appeal accepted by the expert reviewers.

   ↓
4. Step 4Baseline CalibrationReference

   The pipeline next establishes a trustworthy reference point. It begins with a no-op trial, which confirms that a submission lacking the minimum artifacts required by the evaluators is marked invalid rather than treated as a valid result. It then runs the packaged baseline repeatedly and evaluates each resulting submission under both validation and held-out conditions. These repetitions estimate the baseline's mean reward and variance, helping distinguish genuine solver improvements from noise.

   ↓
5. Step 5Agent TrialsEvidence

   Under the same fixed resource budget, agent trials evaluate models from different families and capability levels. Their reward distributions show whether the task distinguishes weaker from stronger systems without favoring one model family. Their trajectories help verify that these differences arise from the intended research problem rather than unclear instructions or infrastructure failures.

   ↓
6. Step 6Reward Hacking AnalysisAdversarial

   Repeated access to validation creates opportunities to optimize the evaluator rather than the intended capability. RSI Bench therefore inspects trajectories and artifacts for overfitting, leaked information, evaluator manipulation, irreproducible outputs, and improvements obtained by sacrificing an unmeasured property. When needed, adversarial trials explicitly ask agents to search for shortcuts in the validation signal, artifact boundary, or reward construction. If a shortcut succeeds, it is treated as a weakness in the task that must be fixed before acceptance.

   ↓
7. Step 7ApprovalDecision

   Automated checks can establish consistency and provide evidence, but they cannot decide whether a task measures a worthwhile research capability. Therefore, two independent researchers will review the task design, calibrated baseline, agent trajectories, and any reward-hacking evidence. Any task update requires the evidence to be refreshed. If both reviewers agree that improvements reflect the intended research capability, the task proceeds to final maintainer review.

Contribute

RSI Bench is actively collecting tasks. You can explore this verification pipeline in our public GitHub repo. If you’re interested, please see our Call for Contributions.