When to apply When the institution is operationalising the TOP, ARRIVE, CONSORT, PRISMA, or NIH Rigor & Reproducibility expectations as structured metadata that travels with outputs, rather than as policy aspirations in author guidelines.
Before you start
Prerequisites
What needs to be in place before you operationalise Reproducibility and computational research terminology in your CRIS or repository.
- A CRIS or repository that can hold typed metadata fields beyond title and abstract
- Editorial / institutional alignment on which reporting checklist applies to which output type (CONSORT for trials, ARRIVE for in vivo, PRISMA for systematic reviews, STROBE for observational)
- A position on the reproducibility-replicability-robustness distinction following NASEM 2019, so the controlled-list values do not drift
- Familiarity with FAIR4RS for the software side of reproducibility and Software Heritage for code archiving
- An identifier strategy for preregistrations and registered reports (OSF preregistration, AsPredicted, journal-issued registered-report stage-1 acceptance ID)
Deployment
Five steps to deploy
Each step is small enough to land in a single sprint or a single sitting with the relevant CRIS administrator. Follow in order.
Add typed reproducibility fields to the output record
preregistration_url (with controlled platform tag), data_availability_statement (controlled status + free-text), code_availability_statement (controlled + URL + Software Heritage ID), materials_availability_statement, reporting_checklist_used (closed list), checklist_completion_url.
Wire FAIR4RS-aligned code archiving
When code accompanies an output, require a Software Heritage archive of the release (not just a GitHub URL), the corresponding Zenodo or DataCite DOI for the release, the OSI license, and the FAIR4RS scorecard if available.
Capture preregistration and registered-report status
Mark each output with one of: not preregistered, preregistered (with URL and date), registered report stage 1 (URL and acceptance date), registered report stage 2 (URL and publication date). The four values are not interchangeable.
Wire reporting-checklist enforcement
On deposit, the output_type determines which checklist applies; the deposit form embeds the checklist URL and requires the completed checklist as a structured attachment, not a single PDF page in the supplementary.
Pilot a robustness-check or multiverse-analysis record
For one quantitative output, capture the robustness checks and multiverse-analysis results as their own structured records linked to the headline output. Verify they remain discoverable and re-runnable a year later.
Worked example
Sample workflow
A realistic walk-through of a single record passing through the Reproducibility and computational research pipeline once the checklist is in production.
Integration points
CRIS and repository systems
Vendor-specific notes on where this vocabulary fits in real research-information systems. Names appear here only where there is public field evidence — they are not vendor partnerships.
Add the reproducibility fields as a custom metadata schema; configure the deposit form to switch checklist requirements on output_type.
Custom metadata template on the Output entity for the reproducibility block; surface on the Pure Portal as a structured reproducibility section.
Reporting-checklist plugins exist for CONSORT, PRISMA, and ARRIVE; the data and code availability statements can be enforced through the metadata-fields configuration.
Federation target — every code release linked from an output should be archived via the SWH save-code-now flow, with the SWHID persisted on the output record.
Federation target for preregistrations and registered reports; the OSF API returns structured preregistration metadata that the CRIS can ingest at deposit time.
What goes wrong in the field
Common pitfalls
The patterns that show up repeatedly when this checklist is skipped or misapplied. Address these before they become entrenched.
- Conflating reproducibility, replicability, and robustness — these are three distinct constructs and the metadata must keep them apart
- Accepting a GitHub URL as code availability without a Software Heritage archive of the release
- Letting the data availability statement remain freeform so "available on request" passes silently — make this a controlled value with a documented access path
- Requiring a reporting checklist as a PDF attachment in the supplementary instead of as a structured deposit
- Ignoring preregistration status because the field is optional — once optional, it stays empty even for preregistered work
Frequently asked
Implementation FAQ
- Who maintains this checklist?
- The Reproducibility and computational research working group maintains the checklist alongside the dictionary terms in the same domain. It is reviewed each release cycle (March and September) and updated when a working-group consultation, a vendor product change, or a federation-partner schema update materially changes the operational guidance.
- What if my CRIS or repository is not listed?
- The integration points listed name the systems CASRAI has direct field experience with — Pure, Symplectic Elements, Worktribe, Converis, DSpace and DSpace-CRIS, EPrints, VIVO, Dataverse, Invenio-RDM. The CERIF mapping in the checklist is vendor-neutral and applies equally to other CRIS or repository products. If your system supports the underlying entities (Person, Project, Output, Funding, plus the domain-specific extensions), the steps transfer.
- How do I validate my implementation?
- Three validation surfaces. First, the deposit form should refuse a record missing required fields rather than warn and accept. Second, the resulting metadata should round-trip through the federation layer your institution uses (OpenAIRE Guidelines 4.0 for European federation, DataCite Commons for DOI-anchored discovery, Crossref for article-anchored discovery) without upstream errors. Third, walk a real-world record through the sample-workflow path on this page and confirm the structured fields capture what the prose describes.
- Where do I report errors in the checklist?
- Open a comment via the dictionary-feedback flow at /dictionary/contribute. Editorial corrections — wrong vendor module names, deprecated standards, broken integration paths — are queued into the next release cycle. Substantive disagreements on the operational guidance are routed to the working group for review and may motivate a checklist revision.
- Is this checklist enough to certify my implementation?
- No. The checklist gives you the operational baseline; certification against federation profiles (CoreTrustSeal, OpenAIRE-compliant, COAR-aligned) is a separate process with its own audit. Treat the checklist as the engineering scaffolding and the certification as the institutional sign-off that the scaffolding is being used.
