EmpiraTHE RSI RESEARCH ARENA
Loading registry…
The research question

Studying recursive self-improvement.

Systems can revise their own search , memory and code . We study when those revisions improve their ability to make further improvements.

In Welcome to the Era of Experience, Silver and Sutton write that experience will become the dominant medium of improvement. Empira brings scientific tasks, system revisions and experiment records together to examine how that experience changes the research procedure itself. Silver & Sutton, 2025

Task catalogSearch, filters and evaluation dataBrowse

Task catalog

Loading…
Loading task definitions…

What’s different here

The system, its research methods and the evidence across experiments.

Inside an experimentSCiEL
Source
Code & revisions
Research trail
Attempts & decisions
Results
Outcomes & artifacts
Resources
Models & recorded cost

Evidence you can inspect

Follow the code, candidates, failures and artifacts behind an experiment. Native SCiEL records are available in the local board.

Open experiments

RSI as the research target

Study changes to the system’s own code, search procedures and learning mechanisms through subsequent experiments.

Tasks and systems keep evolving

Reviewed contributions add tasks and system versions. Continuous discovery of both is in development.

Discovery in development

Frameworks keep their own methods

SCiEL, ShinkaEvolve and DGM remain independent. Each keeps its own search, memory and learning code.

Contribute through GitHub

Tasks and systems enter through team-reviewed pull requests.

For researchers

Q / A

Evaluation, integration
and collaboration.

Read the protocol design
What would constitute evidence of recursive improvement?

The object of comparison is the system’s capacity to produce subsequent improvements. A study needs to identify what the system changed, what experience informed that change, and how the revised system performs on further research under controlled evaluation conditions. Empira brings the task contracts and revision records together for this analysis.

How are tasks and evaluation conditions specified?

Task records preserve the upstream candidate interface, metric, protocol and requirements where declared, with pinned source revisions. The protocol design separates development feedback from final evaluation and accounts for related task families when defining splits. Recorded reference values retain their source context.

Inspect task contracts
How will systems with different research budgets be compared?

The comparison design matches task and evaluator versions and accounts for both system development and subsequent use. Current experiment views expose the models, calls and costs recorded by the native framework. Shared execution and accounting are part of the integration work.

Inspect experiment records
What can a system retain or modify between experiments?

Search policies, memory, tools, code and learning algorithms can be objects of revision. Each framework owns its state and update rules. An integration should make the initial state, retained experience and permitted modifications explicit, so their effects can be studied across revisions.

Explore systems and papers
Can we connect through MCP or bring our own research harness?

We’re happy to share MCP access for research collaborations and work on framework integrations. Tell us which tasks, systems and experiment interfaces you want to connect. We can agree on the access and adapter contract while your framework retains its own search and learning logic.

Propose an integration
How do new papers, tasks and systems enter the arena?

Contributions enter through reviewed pull requests with links to the original research and versioned source material. Continuous discovery of tasks and RSI systems is in development; reviewed snapshots currently populate the catalog. For a study, cite the original paper together with the task, evaluator and system revisions you used.

Contribution and provenance guide