Documentation
Documentation
e2er is an open infrastructure that makes research objects reproducible, composable, and attributable, extending scientific inquiry to the age of AI agents.
The conventions that make research trustworthy were built for work done by people. With AI, a manuscript takes minutes to generate, while checking whether it holds up still depends on an expert reading it closely.
In the empirical template, numbers and citations carry a trace to their source; in the literature library, statements about prior work do. The excerpts below are taken unedited from the showcase study in the repository. Each underlined element shows where it comes from.
A discipline's methods become skills that any AI system can use. An epidemiologist who knows how confounding hides in registry data writes it down once, and economists and sociologists working with such data gain from it.
A research process is a template of steps that anyone can read, run, adapt or ignore. Judgement written into one template can accumulate across fields.
When two fields approach the same question differently, both templates can run on it and their results can be compared, including where each one breaks.
e2er 0.16.1 ships eleven templates (the empirical template with and without a pre-registration step, an event-study template for finance, a replication template, a “Map a research field” template that maps a research field by main path analysis of its citation network, and, new in 0.16.0, a descriptive data study, time series and forecasting, policy evaluation by difference-in-differences, spatial analysis, a systematic review with meta-analysis, and text analysis), a literature library and connectors to 16 data sources. It draws on a public catalogue of skills published by other research projects. Everything beyond that is open to contribution. What exists today (§8).
Researchers can adjust and publish four kinds of building block. Each term below opens its definition, an example from e2er and its status.
Templates describe research processes as a sequence of steps. Each template organizes specialists, i.e., AI agents with defined roles, and each specialist draws on skills, i.e., written descriptions of methods. Researchers can adjust any template, specialist, or skill and publish their version for fellow researchers.
Researchers decide at which steps the process pauses for their review.
A study produced with e2er comes with a dossier that helps others verify and reproduce the work and attributes everyone whose templates, specialists, and skills it used.
The standard specifies how building blocks are described, how their output is checked in every study, how they are tested before others rely on them, and how the community decides what enters and who is credited. It describes building blocks independently of any software, so blocks built with other systems can meet it too.
Every building block states the same fields, so a researcher can judge whether it fits before running it. Skills follow the open Agent Skills format (Anthropic, 2025) and add the research fields below; exported folders are to follow established formats for packaging research outputs (Soiland-Reyes et al., 2022).
# Example: description of a skill, draft format 0.1 name: difference-in-differences kind: skill version: 1.2.0 purpose: Specify, estimate and diagnose DiD designs, incl. staggered adoption inputs: panel data description; treatment timing; identification spec outputs: econometric specification; estimation-results record implements: methodological literature the guide follows (DOIs) authors: names, ORCID, CRediT roles license: MIT tested_on: evaluation records, each naming data, model and version checks: required + estimation # checks this skill adds
Verification consists of checks that run automatically in every study. A template may add checks and enforce them more strictly. It may not remove the required checks.
| Check | What it establishes | Required | Status today |
|---|---|---|---|
| Output contracts | Every specialist wrote the file it declared, in the declared form | Yes | In place |
| Execution reliability | Analysis code ran and wrote a parseable, non-empty result | Yes | In place |
| Numbers | Every number in tables and text matches the output of executed code | Proposed | In place can currently be set to log-only |
| Citations | Every reference resolves to an existing publication via OpenAlex, Semantic Scholar or Crossref | Proposed | In place can currently be set to log-only |
| Verbatim passages | Every claim about a source points to a passage found word for word in that source | Proposed | In place in the literature library |
| Estimation contract | The estimation matches the specification declared before it ran | Per template | In place |
Two checks are required in every template today. Every specialist must write the file it declared, and the analysis code must run and write a result. Execution reliability always stops the process when it fails; output contracts can be set to record only (--governance off). Draft 0.1 proposes making numbers, citations and verbatim passages required as well.
Evaluation defines how building blocks are tested before others rely on them. Its purpose is to find where a block breaks. The protocol is described in §5.
The empirical template turns a research question and data into a draft paper with a replication package. It comes in two versions, with and without a pre-registration step. The literature library turns local PDFs, or papers found by DOI or search, into verified claims. Other researchers may build better versions of either, and evaluations let the versions be compared.
Steps as declared in pipelines/empirical.toml. Greyed steps do not run in the selected mode.
Researchers decide at which steps the process pauses for their review. A pause can be set after any step (e2er run --review-at). The template “Empirical study, pre-registered” adds a design review, a pre-registration and a draft review.
When the template finishes, e2er compiles the paper and writes an exported folder (paper, code, data, results, design, reviews) that e2er verify checks offline and without an API key.
Reads local PDFs, or papers found by DOI or search (e2er library add).
A sketch of how a template is put together under draft 0.1. The required checks stay in place whichever optional steps are selected.
Illustration of draft 0.1A check tells whether one study was faithful to its inputs. An evaluation tells whether a building block can be trusted, under which conditions, and at which point it fails. Developing and proposing this protocol is the centrepiece of the development stage.
Compare a template, specialist or skill with known answers, for instance an interview corpus that human coders have already coded.
Run a template on a published study and compare its results with the original (Brodeur et al., 2025; Kohler et al., 2026). The replication template does this for one study at a time since e2er 0.11.0; evaluation records that collect such tests are planned.
Vary document length, corpus, data quality or model to locate the point at which output degrades (Laban et al., 2026; Pangakis & Wolken, 2025).
Researchers rate a building block against a shared rubric and report failures. RISE already scores research systems against a published rubric.
A hypothetical coding template, evaluated on transcripts of increasing length. The evaluation record states the length at which agreement with human coders falls below the threshold the template declares.
block: qualitative-coding@0.3.1 test: stress / document length material: interview corpus, 240 transcripts, coded by two humans model: named model and version attempts: all attempts, incl. failed and aborted ones result: agreement by length band; breaking point where it falls below threshold evaluator: name, ORCID, CRediT role "validation" scope: valid for this material; other corpora need their own record
Records include failed and aborted attempts, because reporting only successful attempts overstates performance (Masters et al., 2026). They are stored in a common format for evaluation results (Batzner et al., 2026).
Governance decides what others can rely on. The process below is built on e2er.org as a prototype. Its rules will be settled with the researchers who contribute, starting at the special-issue workshop, following community models such as nf-core (Ewels et al., 2020) and mathlib (The mathlib Community, 2020). How the steering group is formed is still open.
Writes a skill, specialist or template and its description, and keeps it working.
Runs benchmark, reproduction or stress tests and authors the evaluation record.
Reads a submission as a method expert and decides with a maintainer whether it is listed.
Keeps a group of building blocks consistent with the standard and handles new versions.
Decides changes to the standard itself and settles disputes, in public and with written reasons.
Runs templates, reports failures, and may become an evaluator by doing so systematically.
Anyone can propose a change to the standard in a public proposal document, which states the problem, the change and its consequences for existing building blocks. Proposals are discussed openly and decided by the steering group, which publishes the decision and its reasons. Accepted changes receive a version number, and building blocks declare which version they meet.
Scholarly incentives currently reward novel findings and undervalue reproductions, verification and reusable infrastructure (Hanneke et al., 2026). e2er turns each kind of contribution into something a researcher can list and others can cite.
| Contribution | What you receive | Status |
|---|---|---|
| Write a template, specialist, skill or connector | A persistent identifier and citation for each version; authorship with CRediT roles (Brand et al., 2015) | Prototype versions with stable addresses on e2er.org; DOIs planned |
| Have a building block used | Credit in the dossier of every study that uses it; the paper's footnote links to that dossier (Smith et al., 2016) | In place e2er publish writes the dossier; released in e2er 0.10.0 |
| Evaluate a building block | Authorship of a citable evaluation record, with the CRediT role "validation" | Prototype evaluation records attach to submissions on e2er.org |
| Report a failure | Credit in the building block's change history and in the evaluation it triggers | Prototype failure reports reach the block's authors on e2er.org |
| Review or maintain | Named review and maintenance roles on the building block's record | Prototype review decisions with written reasons are recorded; the rules are to be settled with the authors |
| Publish skills elsewhere | Source, license and maintainers travel with every installed skill | In place |
Each building block below shows how the showcase study credits its authors. The full list is in its dossier.
e2er is open-source software under the MIT license (Hanneke, 2026a). It installs like any other software package and runs on consumer subscriptions to Claude or ChatGPT, which lowers the barrier for researchers without research budgets. Google ended Gemini CLI sign-in for individual accounts in October 2026, so e2er's Gemini backend needs a Gemini API key and is not tested. Complete studies have run live on Claude Code (Sonnet and Haiku), Codex (gpt-6-luna and gpt-6-astra) and OpenRouter (DeepSeek V4 Pro, billed per use), and their exports passed e2er verify. Each of the six templates new in 0.16.0 ran one complete study live on Claude Code with Sonnet on 11 October 2026, before the release, and each of the six exports passes e2er verify.
| Element | Status | Note |
|---|---|---|
| Empirical template and literature library | In place | First versions, open to better ones |
| Templates as validated files, chosen per study | In place | A study resumes under the template it started with |
| Checks in every study, with logged verdicts | In place | Required today: output contracts and execution reliability |
| Exported folder and offline check | In place | e2er export, e2er verify |
| Skill catalogue with provenance (RISE) | In place | Some skill packs cannot be redistributed, so e2er installs each pack from its source |
| Browser dashboard: library, skills, template choice | In place | Released in e2er 0.10.0 |
| Description format, draft 0.1 | Prototype | Templates follow it; skills and specialists to follow |
| Specialists as files | Planned | Today entries in one registry that names each specialist's output file and skills; e2er.org already accepts specialists submitted as files |
| Dossier and author line on every paper | In place | e2er publish writes the dossier and adds “with e2er” and a dossier footnote to the paper; released in e2er 0.10.0 (§9) |
| Researcher steps and pre-registration in templates | In place | The process stops where the template says; edits and instructions of the researcher appear in the dossier; a pre-registration is frozen before the analysis; released in e2er 0.10.0 |
| Data and code public or private; DOIs via Zenodo | In place | Stated at publishing; public data and code are listed in Discover; released in e2er 0.10.0 |
| e2er.org: accounts, publishing, reviewer access | In place | Live at e2er.org: sign-in with GitHub, reviewer access codes, publishing from the command line or a local folder, checks at the pinned commit; ORCID sign-in and email delivery follow (§9) |
| Evaluation protocol and records | Planned | Stage 2 |
| Governance and credit | Prototype | Built on e2er.org; the rules are to be settled with the authors |
| Templates beyond economics | In place | Descriptive data study, time series and forecasting, policy evaluation, spatial analysis, systematic review with meta-analysis, text analysis; released in e2er 0.16.0 |
| Data sources, each with its terms and citation | In place | 16 sources for economics, earth and climate, astronomy, health, literature and software; data whose terms keep them with the source are loaded again by the study's code instead of being published; released in e2er 0.16.0 |
| Templates for qualitative, experimental and theoretical research | Planned | Coding, survey and experiment design, theory building |
Researchers run e2er on their own computers, with their own accounts at the AI providers. When they publish a study, e2er.org receives its description, its dossier and the fingerprints of its files; the files themselves stay on the researcher's computer or in their repository. The platform keeps a public list of studies and building blocks, gives authors and reviewers their accounts, and credits the authors of a building block each time a study uses it.
Every paper produced with e2er names e2er once, next to its authors, and a footnote on its first page links to the study's dossier. The dossier lists, in order, every specialist task and every check, the model that carried out each task and the file it wrote, grouped by the template's steps, together with the exact version of every template, specialist, skill and connector involved. Its address is the SHA-256 hash of its content, so any later change to the record would change the address. In the showcase study the dossier lists 20 entries, 17 specialist tasks and 3 checks, including the check that rejected the first draft because it contained two tables typed into the text.
% paper.tex of the showcase run, as written by e2er publish \author{Björn Hanneke with e2er\thanks{This paper was produced with e2er. Its dossier lists every step of the run, the files each step produced, and the template, specialists, skills, connectors and AI models used, pinned to their exact versions: \url{https://e2er.org/d/c46711b0dc073e96}.}}
The dossier leaves the paper itself out, because the paper carries the dossier's address. Anyone can recompute the address from the published document; the page for each dossier does so in the browser. The showcase dossier.
e2er is local software that researchers use with their own AI accounts. The platform has no field that accepts an AI key, and publishing sends the study's description, its dossier and the fingerprints of its files.
| Stays on the researcher's machine | Goes to the AI provider the researcher chose | Goes to e2er.org on publishing |
|---|---|---|
| Data files, the literature library and its PDFs, the run database, AI keys and subscriptions | Prompts, including data summaries and the passages a specialist reads | The study's description, its dossier, the SHA-256 fingerprint of each file, authors and their roles |
Before sending, the command line removes local paths and refuses to publish if any text resembles a key; a dry run prints the exact request and changes nothing.
Researchers sign in with ORCID or GitHub, or with an email address and password. Password recovery uses single-use links that expire after 30 minutes and sign out every session. The command line signs in by showing a code that the researcher approves in the browser.
Editors receive one access code per manuscript. The code opens a workspace without a name or email address, in which reviewers can try publishing and contributing on sample records that are deleted when the code expires.
Every study, building block, contribution, check and dossier is a row in one SQLite database, held in the European Union. The analytics form a star schema of views over these tables, and every figure on the platform is the result of a named query that is published with its SQL, so anyone can rerun it on the exported database. Dossiers, study versions and building-block versions cannot be changed once written; a withdrawn study keeps its versions citable.
The full data model, with every table and the analytics.
| Phase | Scope | Status |
|---|---|---|
| 0 Foundations | Domain, database in the EU, schema, import of the current registry, staging environment | Done |
| 1 Figures from queries | Every figure computed by a published query; database available for download | Done |
| 2 Accounts | Sign-in with ORCID, GitHub or email, password recovery, roles, reviewer access codes | Built; live with GitHub sign-in; ORCID and email delivery follow |
| 3 Command line | Sign-in from the command line, publishing, study status, dossiers for private studies | Done |
| 4 Checks at the source | Checks run at the pinned commit of a study's repository and in GitHub Actions; publishing from a local folder in the browser | Done |
| 5 Contributions | Submissions and the review queue of §6, comments and failure reports, data export and account deletion | Prototype: built on e2er.org; the rules are to be settled with the authors |
The filters show the projects that provide a feature. Marks are our reading of each project's own description.
| Project | Describes blocks | Checks content | Evaluates blocks | Shared governance | For AI agents | Social science |
|---|
● provides ◐ partly ○ does not ◌ planned
Repository: github.com/bhanneke/E2ER-project (MIT). Skill catalogue: github.com/bhanneke/RISE.
All commands above are in e2er 0.16.1; the version cited is the current release, 0.17.3 (Hanneke, 2026a).
Anthropic. (2025). Agent Skills [Open specification]. https://agentskills.io
Batzner, J., Nelaturu, S. H., Stachura, D., Kornilova, A., Crall, J., et al. (2026). Every Eval Ever: A unifying schema and community repository for AI evaluation results (arXiv:2606.14516). https://doi.org/10.48550/arXiv.2606.14516
Binkyte, R., et al. (2026). Inspectable AI for science: A research object approach to generative AI governance (arXiv:2604.11261). https://doi.org/10.48550/arXiv.2604.11261
Brand, A., Allen, L., Altman, M., Hlava, M., & Scott, J. (2015). Beyond authorship: Attribution, contribution, collaboration, and credit. Learned Publishing, 28(2), 151–155. https://doi.org/10.1087/20150211
Brodeur, A., Sung, S. Y., Miguel, E., Vilhuber, L., & Hoces de la Guardia, F. (2025). Assessing reproducibility in economics using standardized crowd-sourced analysis (NBER Working Paper No. 33753). https://doi.org/10.3386/w33753
Crusoe, M. R., Abeln, S., Iosup, A., Amstutz, P., Chilton, J., Tijanić, N., Ménager, H., Soiland-Reyes, S., et al. (2022). Methods included: Standardizing computational reuse and portability with the Common Workflow Language. Communications of the ACM, 65(6), 54–63. https://doi.org/10.1145/3486897
Ewels, P. A., Peltzer, A., Fillinger, S., Patel, H., Alneberg, J., Wilm, A., Garcia, M. U., Di Tommaso, P., et al. (2020). The nf-core framework for community-curated bioinformatics pipelines. Nature Biotechnology, 38(3), 276–278. https://doi.org/10.1038/s41587-020-0439-x
Hanneke, B. (2026a). e2er: End-to-End Researcher (Version 0.17.3) [Computer software]. Zenodo. https://doi.org/10.5281/zenodo.23535112
Hanneke, B. (2026b). RISE: Research information systems engineering [Software repository]. https://github.com/bhanneke/RISE
Hanneke, B., Hering, F., Pfeiffer, J., Reijers, H., & Hinz, O. (2026). Academic publishing in the age of generative AI. Business & Information Systems Engineering, 68(4), 729–737. https://doi.org/10.1007/s12599-026-01013-0
Kassis, T., Agarwal, V., He, Y., Patel, D., Brueckner, A. M., et al. (2026). Scientific Agent Skills: A library of procedural knowledge for research agents (arXiv:2609.00065). https://doi.org/10.48550/arXiv.2609.00065
Kohler, B., Zollikofer, D., Einsiedler, J., Hoyle, A., & Ash, E. (2026). Read the paper, write the code: Agentic reproduction of social-science results (arXiv:2604.21965). https://doi.org/10.48550/arXiv.2604.21965
Laban, P., Schnabel, T., & Neville, J. (2026). LLMs corrupt your documents when you delegate (arXiv:2604.15597). https://doi.org/10.48550/arXiv.2604.15597
Lu, C., Lu, C., Lange, R. T., Yamada, Y., Hu, S., Foerster, J., Ha, D., & Clune, J. (2026). Towards end-to-end automation of AI research. Nature, 651(8107), 914–919. https://doi.org/10.1038/s41586-026-10265-5
Masters, C., Liu, Z., & Albrecht, S. V. (2026). Rollout cards: A reproducibility standard for agent research (arXiv:2605.12131). https://doi.org/10.48550/arXiv.2605.12131
The mathlib Community. (2020). The Lean mathematical library. In Proceedings of the 9th ACM SIGPLAN International Conference on Certified Programs and Proofs (pp. 367–381). https://doi.org/10.1145/3372885.3373824
Pangakis, N., & Wolken, S. (2025). Keeping humans in the loop: Human-centered automated annotation with generative AI. Proceedings of the International AAAI Conference on Web and Social Media, 19, 1471–1492. https://doi.org/10.1609/icwsm.v19i1.35883
Smith, A. M., Katz, D. S., Niemeyer, K. E., & FORCE11 Software Citation Working Group. (2016). Software citation principles. PeerJ Computer Science, 2, e86. https://doi.org/10.7717/peerj-cs.86
Soiland-Reyes, S., Sefton, P., Crosas, M., Castro, L. J., Coppens, F., Fernández, J. M., Garijo, D., Grüning, B., et al. (2022). Packaging research artefacts with RO-Crate. Data Science, 5(2), 97–138. https://doi.org/10.3233/DS-210053
Souza, R., Gueroudji, A., DeWitt, S., Rosendo, D., Ghosal, T., et al. (2025). PROV-AGENT: Unified provenance for tracking AI agent interactions in agentic workflows (arXiv:2508.02866). https://doi.org/10.48550/arXiv.2508.02866
Yamada, Y., Lange, R. T., Lu, C., Hu, S., Lu, C., Foerster, J., Clune, J., & Ha, D. (2025). The AI Scientist-v2: Workshop-level automated scientific discovery via agentic tree search (arXiv:2504.08066). https://doi.org/10.48550/arXiv.2504.08066
Zhang, Y. (2026). Vibe researching as wolf coming: Can AI agents with skills replace or augment social scientists? (arXiv:2602.22401). https://doi.org/10.48550/arXiv.2602.22401