When to apply When the institution needs to capture supervision, mentorship, and career-stage milestones as structured CRIS metadata — typically to support narrative CVs, responsible-assessment policies, and PhD-supervision reporting.
Before you start
Prerequisites
What needs to be in place before you operationalise Mentorship, training, and career stages terminology in your CRIS or repository.
- A CRIS that can hold a Person entity with multi-affiliation history and an explicit career-stage timeline
- A controlled vocabulary for career stages (early-career researcher, mid-career, established, senior, emeritus) calibrated to your jurisdiction — UK Vitae, EU R1-R4, US tenure-track terminology are not interchangeable
- A mentorship-relationship entity that can express role, scope, date range, and the institutional context in which the relationship sits
- Consent from mentees for their supervisor relationship to surface on the supervisor's public profile (and vice versa)
- Alignment with narrative-CV formats your researchers must produce (UKRI R4RI, Royal Society Résumé, Dutch Recognition & Rewards, Wellcome narrative)
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.
Define a Career-Stage timeline on the Person entity
Each Person carries a date-ranged sequence of career-stage records with stage (closed list), institution, role_title, employment_type, ftepercent, start_date, end_date. The current stage is derived from the open-ended record rather than stored as a separate "is_senior" boolean.
Define a Supervision / Mentorship relationship
Each relationship is its own record: mentor (Person), mentee (Person, with ORCID where known), relationship_type (PhD supervision, postdoc supervision, formal mentorship, informal mentorship), scope, start_date, end_date, outcome_notes. Both directions surface on both profiles.
Capture training delivered and received
A first-class TrainingActivity entity for courses delivered (as researcher-developer) and courses taken (as researcher-developee); attach to the Person record and roll up into a narrative-CV section.
Wire narrative-CV export templates
For each narrative-CV format (R4RI, Royal Society, Recognition & Rewards), build an export template that populates the four-section structure from the structured Person, Career-Stage, Supervision, and TrainingActivity records.
Pilot with five researchers across career stages
Pick an ECR, a mid-career researcher, an established PI, an industry-academic joint appointment, and a re-entrant returning from career break. Verify that each can assemble a narrative CV without retyping more than 20% of the content.
Worked example
Sample workflow
A realistic walk-through of a single record passing through the Mentorship, training, and career stages 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.
Person entity supports career-stage and affiliation history; add supervision as a custom relationship type. The Pure narrative-CV export plugins cover R4RI and Royal Society.
User profile supports affiliation history; add Supervision and Mentorship as custom relationship entities. The Elements public profile API can drive an institutional researcher-profile site.
Native expression of training, mentorship, and supervision via the VIVO-ISF ontology (vivo:advises, vivo:advisedBy); supports narrative-CV-style profile pages.
Researcher profile supports career-stage timeline; supervision relationships modelled as project links between PhD students and supervisors.
Federation target — career-stage and affiliation histories should round-trip to the ORCID profile so the structured CRIS data is also discoverable externally.
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 career stage as a single label on the Person record instead of a date-ranged timeline, losing the history
- Listing PhD students by name only in a supervisor's biography rather than as ORCID-linked Person records
- Using US tenure-track terminology in a non-US institution (or vice versa), breaking cross-institutional comparability
- Letting the narrative-CV export template diverge from the underlying structured fields, so researchers re-write the document by hand each time
- Forgetting that career stage is calibrated to time-since-PhD in some funder profiles and to job title in others — capture both, derive what you need
Frequently asked
Implementation FAQ
- Who maintains this checklist?
- The Mentorship, training, and career stages 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.
