When to apply When the 14 baseline CRediT roles are in production but contributions from reviewers, data engineers, lab managers, and software maintainers are still being recorded as freeform acknowledgement prose.
Before you start
Prerequisites
What needs to be in place before you operationalise CRediT extensions and adjacent contribution vocabularies terminology in your CRIS or repository.
- CRediT (ANSI/NISO Z39.104-2022) already in production for the author list
- A structured acknowledgement section in your submission system or repository deposit form
- Editorial decision on whether reviewer attribution will be opt-in, opt-out, or open-by-default
- ORCID lookup available at form-fill time so non-author contributors can be uniquely identified
- A controlled vocabulary for the extension roles — start from the CASRAI extension list, do not invent local terms
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.
Adopt the CRediT-extensions controlled list alongside the 14 baseline roles
Add Acknowledged Contributor sub-roles (Lab Manager, Research Assistant, Technical Specialist, Field Coordinator) and Reviewer sub-roles (Peer Reviewer, Statistical Reviewer, Methods Reviewer) as a single closed vocabulary. Treat them as first-class roles, not a different schema.
Extend the contributor block in your metadata model
Each non-author contributor needs the same triple as authors: ORCID, name, role(s). Mark them as contributor_type="acknowledged" or "reviewer" rather than "author" so existing CRediT consumers do not break.
Update the submission UI
Replace the free-text Acknowledgements field with a structured contributor table that shares the author-block UI: ORCID lookup, name autocomplete, multi-select role picker. Keep a freeform "additional acknowledgements" field for thanks that do not warrant attribution.
Add JATS and JSON-LD emit
JATS contrib-group with contrib-type="reviewer" or "acknowledged-contributor"; JSON-LD schema:contributor with a roleName-extension property. Crossref and DataCite both accept these without schema extension as of their current versions.
Pilot with a single journal or repository community
Run the new contributor block on one journal for a release cycle, measure depositor friction (target: less than 60 seconds per non-author contributor), and adjust the role list before rolling out broadly.
Worked example
Sample workflow
A realistic walk-through of a single record passing through the CRediT extensions and adjacent contribution vocabularies 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.
Pure already supports CRediT on outputs; add the extension roles to the local CRediT picklist. Reviewer attribution is not native — capture via a custom relationship type.
Elements supports custom contributor roles on Publication entities. The Acknowledged Contributor relationship type ships with recent versions.
Extend the contributor relationship type with sub-types for acknowledged and reviewer; ensure ORCID auto-population is on for the contributor lookup field.
Add the extension roles to the contributor role picker via the CRediT plugin and the user-roles configuration. Reviewer attribution requires the Open Peer Review module.
Both accept structured contributor data on import; configure the extension roles in your local taxonomy mapping and surface them in the production-handoff XML.
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.
- Inventing local extension roles ("data wrangler", "PI support") instead of using the shared CASRAI list
- Mixing reviewer attribution and editor attribution into one field — they have different consent and confidentiality rules
- Forgetting to set contributor_type so downstream readers count reviewers as authors and inflate the author list
- Treating the acknowledgement block as optional polish — once authors learn it carries ORCID-visible credit, take-up surprises everyone
- Failing to update editorial policy at the same time as the form, leaving reviewers unsure whether attribution is opt-in or default-on
Frequently asked
Implementation FAQ
- Who maintains this checklist?
- The CRediT extensions and adjacent contribution vocabularies 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.
