When to apply When the institution needs to capture the project lifecycle as structured CRIS metadata — calls, applications, funded projects, milestones, work packages, phase transitions, project end and post-end outputs — rather than only the headline grant record.
Before you start
Prerequisites
What needs to be in place before you operationalise Research lifecycle stages and project metadata terminology in your CRIS or repository.
- A CRIS with native Project and Application entities (Pure, Symplectic, Worktribe, Converis, DSpace-CRIS)
- A position on RAiD adoption — RAiD provides the persistent project identifier and is the cleanest anchor for cross-institutional projects
- A controlled vocabulary for lifecycle phases (proposed, applied, funded, started, in_progress, mid_term_review, close_out, post_award, completed, terminated)
- An agreement on which entities link to projects (outputs, datasets, applications, persons, equipment, ethics determinations)
- A position on multi-institution projects — usually the lead institution mints the RAiD and partners reference it
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.
Mint a project identifier
For every new project, mint a RAiD (or an institutional handle as a transitional placeholder). The identifier resolves to a project record carrying participants, dates, funding references, and linked outputs.
Define phase transitions as records, not as a single status field
Each phase transition (funded, started, mid-term review, close-out, completed) is its own dated record with the transition_event, supporting_document, and authorising_person. The current phase is derived from the timeline of transitions, not stored as a separate string.
Capture milestones and deliverables as structured records
Each milestone has a planned_date, actual_date, status, deliverable_type, linked_outputs. A milestone slipped by three months is not a project-level annotation; it is a structured record that funder reporting can roll up.
Wire post-award and post-project capture
A project does not end at the final-report submission; outputs and datasets continue to be produced. Configure the linked-outputs and linked-datasets relationships to remain editable after the formal end_date, with a structured "post-project output" flag.
Pilot a complex cross-institutional project
For one Horizon Europe or NIH multi-PI project, verify that all participating institutions reference the same RAiD, that the milestone records sync across CRIS systems, and that the linked outputs surface on every participant's ORCID profile.
Worked example
Sample workflow
A realistic walk-through of a single record passing through the Research lifecycle stages and project metadata 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.
Strong native Project entity with phase and milestone modelling; supports custom relationship types for cross-institutional partners.
Grant entity covers the project lifecycle; supports custom milestones and deliverables via the Elements Reporting Database.
Native project lifecycle module with phase, milestone, and variation tracking; widely used in UK HEIs for the pre- to post-award lifecycle.
Project module supports the full lifecycle with native phase-transition modelling and integration with Web of Science funding-acknowledgement data.
Federation target — RAiD is the persistent project identifier that resolves to a structured project record independent of any single CRIS.
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.
- Storing project phase as a single field that overwrites at each transition, losing the timeline
- Treating milestones as project-level free-text notes rather than as structured records
- Allowing the formal end_date to lock the record, so post-project outputs cannot be linked
- Letting multi-institution projects fragment into N separate Project records without a shared RAiD or comparable anchor
- Failing to capture variations and no-cost extensions as their own records, so the as-funded plan and the as-delivered project look identical in retrospect
Frequently asked
Implementation FAQ
- Who maintains this checklist?
- The Research lifecycle stages and project metadata 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.
