CASRAI Dictionary

Tag: ORCID

  • Funder ORCID iD requirements: 2026 landscape

    The trajectory of ORCID iD requirements across major funders has been steady through 2018-2025: voluntary for PIs, recommended for PIs, required for PIs, and now in 2026 increasingly required for co-investigators and other named project personnel. This post is a practical map of the requirements as they stand in mid-2026, with attention to the operational implications for institutions handling cross-funder applications.

    The PI requirement

    For principal investigators, ORCID iDs are now effectively required across the major Western funders. UKRI requires the PI’s ORCID iD at application; the seven research councils’ submission system pre-fills bibliographic data from the ORCID record where available. The Wellcome Trust, the major UK charities, and the major European national funders (DFG, ANR, NWO, the Swiss SNSF, the Spanish AEI) have similar requirements.

    The US federal funders have moved more cautiously. NIH requires ORCID iDs in the biosketch via the SciENcv tool; NSF requires ORCID iDs for personnel in current-and-pending support; DOE, DOD, NASA, USDA have varying requirements with a convergent direction. The 2025 update to the Common Forms work standardised the ORCID requirement across federal-funder personnel forms, with the binding date in 2026.

    EU funding (Horizon Europe, ERC) requires ORCID iDs for PIs and an increasingly complete coverage of co-investigators. The Funding & Tenders Portal integrates with ORCID for bibliographic data retrieval.

    For PIs, the practical posture is that an ORCID iD is now table stakes. The CASRAI funder applicant guide tracks the per-funder requirements.

    The co-investigator expansion

    The 2026 development is the expansion of ORCID requirements to co-investigators and other named project personnel.

    UKRI’s 2025-2026 transition expanded the ORCID requirement to all named investigators on an application. The Funding Service expects ORCID iDs for everyone listed.

    NIH’s pilot to require ORCID iDs for all senior/key personnel began in 2025 and is now standard practice. Co-investigators without ORCID iDs cannot be listed.

    The EU Horizon Europe expansion is in progress, with the Funding & Tenders Portal expected to require ORCID iDs for all consortium personnel by end-2026.

    For institutions, this means the ORCID-iD adoption work that previously focused on PIs now needs to cover the entire research staff. Most research-intensive universities are at or near saturation for PIs; the broader staff coverage is lower and the expansion requires sustained adoption work.

    The structured-data side

    The funder ORCID requirements are about more than identifier collection. The funders increasingly consume structured data from ORCID at application time and write structured data back at award time.

    At application: funders pull biographical sketches, affiliation history, prior funding, and publication lists from ORCID. The applicant’s ORCID record becomes the source-of-truth for these data; the funder’s application system displays them with allow-edit-but-prefer-ORCID semantics. This is a substantial UX improvement over the previous pattern of researchers re-typing their bibliographic data into each funder’s system.

    At award: funders write the award itself to ORCID as a funding-record entry, and increasingly the project as a RAiD reference. The researcher’s ORCID record accumulates a complete funding history without manual entry.

    The ORCID 4.0 contribution model (discussed in our earlier post on the IDR roadmap) is the underlying schema that supports this. Funders that have implemented the 4.0 deposit patterns can write rich structured data; funders still on 3.x produce thinner records.

    Operational implications for institutions

    Three operational priorities for research-administration offices.

    First, institutional ORCID-iD coverage. Run a coverage audit: what fraction of your research staff have ORCID iDs, and are those iDs current and verified? Where coverage is incomplete, run an institutional ORCID-iD adoption campaign. Many institutions have done this for PIs and need to extend it to early-career researchers, postdocs, and research-staff categories that were previously deprioritised.

    Second, ORCID-integration in CRIS. Your CRIS should be reading from and writing to ORCID for affiliated researchers. The CRIS-ORCID integration patterns are well-documented; the CASRAI CRIS integration guide walks through them per major CRIS vendor. The integration removes substantial duplicate-data-entry burden from researchers.

    Third, application-support workflow. Your application-support workflow should be ORCID-anchored: the researcher’s ORCID record is the source for biographical data; the application’s data-entry tools should pull from ORCID by default; any application-specific data should be entered once and propagated to ORCID where appropriate.

    The edge cases

    Three edge cases deserve flagging.

    First, researchers without ORCID iDs. As funder requirements tighten, researchers without iDs become unable to apply. The case is straightforward to resolve (registration takes minutes) but the institutional support to ensure no researcher is blocked at application time is non-trivial.

    Second, researchers with duplicate or fragmented ORCID records. Some researchers have multiple ORCID iDs from different registration events; some have records that are out of date or incomplete. The ORCID record merge process and the institutional support for record cleanup are not always smooth. Institutional ORCID-administrator workflows should handle these cases.

    Third, international researchers. ORCID is a global infrastructure but adoption varies by country and discipline. International collaborators on a US- or EU-funded project may not have ORCID iDs; the application workflow needs to accommodate getting them registered. Many institutions have built bridge-support for this scenario.

    The 2027 trajectory

    Looking forward, the trajectory through 2027 is clear. ORCID iDs will be required not just for personnel but for funded outputs (publications, datasets, software) at the deposit step. The funder’s compliance tracking will run on the ORCID-anchored graph: did the awarded researcher produce the outputs they committed to, were the outputs FAIR-compliant, were the contributors recognised with CRediT roles? The institutional infrastructure to support this picture is most of what current adoption work is building.

    For institutions, the strategic implication is to treat ORCID adoption not as a compliance item but as research-infrastructure investment. The return on the investment compounds: each researcher with a complete ORCID record reduces friction across every subsequent application, every output deposit, every reporting cycle. The institutions that did the work in 2022-2025 are reaping the benefit in 2026; those that have not are still doing the manual work.

    Related dictionary entries

  • Persistent identifiers in 2026: ORCID + ROR + RAiD + DOI

    By 2026 the persistent-identifier (PID) layer of scholarly infrastructure has stabilised into a quartet: ORCID for people, ROR for organisations, RAiD for projects, and DOI for almost everything else (articles, datasets, software, instruments, samples, preregistrations). Each is operationally distinct, each has its own governance, and the seams between them are where most metadata loss still happens. This post is a tour of the state in early 2026, the integrations that work well, and the crosswalk gaps that institutions and publishers are still grinding through.

    ORCID at 2 million+ active iDs and counting

    The Open Researcher and Contributor iD is by some distance the most successful PID for people. As of 2026, ORCID reports over 21 million registered iDs with active use across publishing, funding, and institutional workflows. The 2024 integration of CRediT at the ORCID-record level was the missing piece that closed the loop: a contributor’s roles on a specific work can now be carried persistently on their ORCID record, not just in the publisher’s JATS.

    The CASRAI-stewarded contribution to ORCID’s data model also added affiliation history with PIDs (ROR for the organisation, RAiD for projects, DOI for grants), which means a complete ORCID record now resolves the four-way join. The ORCID federation page at CASRAI documents the per-country member organisations and the institutional integration patterns; the ORCID implementation page documents the technical integration via the public API and the member API.

    What’s still hard with ORCID in 2026

    Coverage is uneven by discipline. Life sciences and physics push close to saturation; humanities, education, and applied fields still have large populations who have not registered. Coverage is also uneven by career stage: PIs are nearly universal, postdocs and senior researchers have high coverage, graduate students and undergraduate contributors are sparse. The policy question of whether to require ORCID at submission, mandate it for funding eligibility, or leave it voluntary remains contested; the major medical journals (NEJM, JAMA, BMJ, Lancet) effectively require it for corresponding authors, the broader landscape does not.

    ROR: the organisational identifier that finally worked

    The Research Organization Registry launched in 2019 and crossed 100,000 active records around 2023. By 2026 ROR is the default organisational PID across Crossref, DataCite, ORCID, and most institutional CRIS systems. The decision to keep ROR governance light, the data open under CC0, and the IDs free at all volumes has been validated by adoption.

    ROR replaced a Babel of organisational identifiers (GRID, ISNI for orgs, ad-hoc Crossref Funder Registry entries, individual database keys at each tool). The integration pattern is clear: every author affiliation should resolve to a ROR ID, and that ID should travel through the metadata to Crossref, DataCite, ORCID, and the institutional repository. Most publishers now require or strongly prefer ROR at submission.

    ROR’s main 2025-2026 work has been on hierarchies: capturing the parent/child relationships between research institutions, hospitals, university systems, and consortia in a queryable way. A hospital with an academic affiliation needs both identifiers; a multi-campus university needs the campus-level resolution; an INSERM unit needs both the unit ROR and the parent INSERM ROR.

    RAiD: the project-level PID

    The Research Activity Identifier is the newest of the quartet and is filling a real gap. A project (a grant, a clinical trial, a multi-institution collaboration, a piece of fieldwork) was for years the orphan of the PID world: it had no canonical identifier, so its outputs (papers, datasets, software, training of students) could not be reliably linked back to it. RAiD, now an ISO standard (ISO 23527:2022) and operated as an open infrastructure with multiple national service providers, fills the gap.

    The RAiD model is straightforward: a RAiD record names the project, lists its participants (with ORCID iDs), its institutions (with ROR IDs), its outputs (with DOIs and other PIDs), its funders (with ROR or Funder Registry), its dates, and its status. A funder issues or registers a RAiD on award; the awardees update it as the project evolves; the outputs reference it.

    In 2026 RAiD adoption is strongest in Australia (where the ARDC operates a national RAiD service), New Zealand, the UK (where UKRI has integrated RAiD into its funding workflow), and parts of the EU. North American uptake has been slower; NIH’s evolving project-identifier approach overlaps with but is not identical to RAiD, and the harmonisation is still in negotiation.

    DOIs across artefact types

    The Digital Object Identifier is the workhorse. The interesting story in 2026 is not DOIs for journal articles (a settled problem) but DOIs for everything else.

    • Data. DataCite issues DOIs for datasets; coverage is high in well-funded disciplines (biology, astronomy, climate, social sciences via ICPSR), lower in others. The FAIR-data push has pulled coverage up.
    • Software. Software DOIs via Zenodo and via journal-specific archives (e.g., Software Impacts, JOSS) are now standard practice. Citation of software with DOIs is endorsed by the FAIR4RS principles.
    • Preprints. Every major preprint server issues DOIs; the Crossref preprint relationship metadata links the preprint DOI to the eventual journal-article DOI.
    • Preregistrations. OSF and AsPredicted issue preregistration DOIs.
    • Samples. IGSN (International Generic Sample Number) is a specialised PID for physical samples, increasingly issued as a DOI under the DataCite umbrella.
    • Instruments. The PIDINST initiative is rolling out DOIs for major research instruments, with full metadata about specifications and operators.

    The crosswalk layer

    The most underrated work in the PID ecosystem is the crosswalk layer: the mappings between identifier systems that make the quartet actually function as a graph. Crossref’s references and relations blocks link DOIs to other DOIs and to other PIDs. DataCite’s relatedIdentifier field plays the same role for datasets. ORCID’s work entries carry DOIs and increasingly RAiDs. ROR records carry relationships to other organisations and to Funder Registry entries.

    Where crosswalks fail is at the institutional repository boundary. A paper deposited in a university IR may have a DOI, but the IR record’s author affiliation may not resolve to a ROR ID; the project funding may be in a free-text field rather than a Funder Registry ID; the dataset associated with the paper may have a DOI but no relation to the paper’s DOI declared. The result is a graph with broken edges, which then degrades discovery downstream.

    The work to fix this in 2026 is mostly unglamorous metadata QA at the repository and CRIS layer. Several institutional CRIS vendors have shipped “PID completeness” dashboards that flag records with missing or unresolvable identifiers. The OpenAIRE Graph project rolls up the global picture and is the most useful external check.

    What we expect to settle by 2027

    Three threads are in motion. First, contributor-affiliation provenance: an ORCID record’s affiliation history with PIDs at both ends will become the canonical record, replacing the per-publisher author-affiliation strings that journals still maintain separately. Second, funder-PID standardisation: the Crossref Funder Registry and ROR are converging, with funders that are also research organisations getting unified records. Third, project-PID interop: RAiD, NIH project IDs, and the EU’s HORIZON identifiers are being mapped to allow a single project to be tracked across funder boundaries.

    For institutions setting strategy now, the practical priorities are: require ORCID at hire and on every publication; map every internal organisation to ROR; integrate RAiD into the funding-receipt workflow if you have it; and run quarterly QA against your CRIS for missing PIDs. The CRIS guidance at CASRAI walks through the integration patterns by vendor.

    Related dictionary entries

    References

    Meadows et al., Persistent Identifiers: The Building Blocks of the Research Information Infrastructure (Information Services and Use, 2019). Cousijn et al., A data citation roadmap for scholarly data repositories (Scientific Data, 2019). FAIR4RS Working Group, FAIR Principles for Research Software (RDA, 2022). ARDC documentation on RAiD operational service. ROR governance documentation and CC0 data dumps.

  • Crossref’s grant-linking initiative and CRediT: a 2025 status

    Crossref’s Grant Linking System (GLS), in development since 2019 and in steady production since 2022, has quietly become one of the most useful bits of plumbing in scholarly metadata. Its 2025 expansion — covering more funders, more grant metadata, and tighter integration with Crossref’s content-registration deposit schema — is worth a closer look, particularly for anyone integrating CRediT contributorship with funding attribution. This post walks through what GLS does, what changed in 2025, and how a CRediT integrator should consume the data.

    What GLS is, briefly

    A grant, as a thing in the world, has a funder (an organisation that paid), one or more awardees (people and institutions), a title, a project description, an amount, a duration, and a set of outputs (papers, datasets, software, other artefacts) that the grant produced. Pre-GLS, each piece sat somewhere different. The funder lived in the Funder Registry (a Crossref-maintained list of funder organisations). The grant number was a free-text string in publisher metadata. The outputs were registered with DOIs at Crossref but without structured links back to the grant. The result was that the graph from funder through grant to output existed only in fragments.

    GLS provides the missing middle layer. A funder registers grants with Crossref via a dedicated deposit schema; each grant gets a DOI; the grant DOI carries structured metadata about the funder, the project, the awardees (with ORCID iDs where available), and the institutions (with ROR IDs). Publishers and other depositors then reference the grant DOI from the output’s metadata, closing the loop.

    2025 expansion: more funders, more metadata

    The major story of 2025 was funder participation. Through 2024 the GLS depositors were a small set of early adopters (Wellcome, the Templeton Foundation, ANR, a handful of others). 2025 added the major UK research councils (UKRI’s component councils now register grants via GLS), several EU H2020 and Horizon Europe streams (via OpenAIRE-mediated deposit), the Australian Research Council, and — significant for the US ecosystem — initial NSF and NIH pilots. NIH’s pilot is small (a few thousand R01 grants), but it signals direction.

    The metadata expansion was equally important. GLS 2025 added structured fields for: project abstract (free text but indexed), discipline classification (using Crossref-curated CODE FOR codes and OECD FoS), expected outputs, ethics-board identifiers, and — the field most relevant to CRediT integrators — a participants structure that names each grant participant with an ORCID iD and a role from a controlled vocabulary (principal investigator, co-investigator, collaborator, named researcher, fellow, named staff). This is not CRediT, but it interlocks with CRediT cleanly.

    The CRediT-GLS interlock

    Here is the integration pattern that is now possible. A grant is registered with GLS, getting a DOI and a structured participant list. A paper acknowledges the grant by including the grant DOI in its Crossref deposit. The paper’s JATS carries a CRediT contributor statement, which is also deposited to Crossref via the relationships block. ORCID consumes both deposits via the public API and can now answer: this researcher contributed to this paper in these CRediT roles; the paper acknowledges this grant; this researcher is on the grant participant list in this grant role.

    The query is structured and unambiguous. Pre-2025, it required string matching grant numbers and best-effort author-name disambiguation. Post-2025, the entire chain runs on PIDs. The CRediT adoption ledger at CASRAI tracks which publishers deposit CRediT to Crossref in the form that makes this work, and which still drop the qualifiers at the deposit step.

    What integrators need to do

    For publishers depositing content with Crossref, the 2025 GLS recommendations are: include grant DOIs in the funding section of every deposit where a grant is acknowledged; resolve and validate the grant DOI before deposit; carry CRediT roles with the degree-of-contribution qualifier in the contributor section. Crossref’s submission schema 5.4 supports all of this; older schema versions do not, and a number of publishers are still on 4.x.

    For institutional CRIS systems, the recommendation is to ingest grant DOIs into the funding record alongside the internal grant number, and to use the grant DOI as the join key when reconciling CRIS funding records against ORCID’s funding entries and Crossref’s content metadata. The CASRAI CRIS integration guide has been updated with the GLS ingestion patterns by major CRIS vendor.

    For funders not yet depositing to GLS, the question is what to do about historical grants. Crossref’s recommendation is to deposit prospectively (new awards from a chosen start date) and backfill historical grants over time. The funders that have done well at GLS uptake budgeted a small data-engineering effort over 6-12 months to backfill 5-10 years of historical grants from internal records.

    The RAiD-Crossref-GLS triangle

    An open question for 2026 is the relationship between GLS and RAiD. Both can identify a research project; both can carry participant, institution, funding, and output metadata; both have ISO-standard or de-facto-standard status. The honest answer is that they overlap meaningfully but serve different communities and emphases.

    GLS is funder-centric: a grant is the unit; the funder registers it; outputs reference it. RAiD is project-centric: a project can span multiple grants, multiple funders, multiple institutions, with the project itself the persistent unit. For a single-funder, single-project grant they are functionally identical. For a multi-funder collaboration (typical in clinical trials, large astronomy or particle physics projects, EU consortia), RAiD captures the project shape; the individual grants funding it would each be GLS-registered and the RAiD would reference them.

    The Crossref-DataCite-ARDC working group has begun work on a formal crosswalk that lets a GLS grant DOI declare a RAiD that it contributes to, and vice versa. This will not collapse the two but will let consumers traverse the graph in either direction.

    Consuming the data

    The Crossref REST API exposes GLS grants under /works with a type filter of grant; the relationship from a paper to its grant is in the paper’s relation block with relationship type is-funded-by. For ORCID-aware consumers, the ORCID 4.0 funding resource now carries the grant DOI as a primary identifier, with the Funder Registry entry as the funder.

    OpenAIRE consumes GLS deposits and exposes the resulting graph in its OpenAIRE Graph, which is the easiest single endpoint to query for the full funder-grant-output structure. For institutional consumers without the bandwidth to consume Crossref directly, OpenAIRE Graph is the recommended starting point.

    What’s still rough

    Two known limitations. First, the GLS participants structure does not yet carry CRediT roles directly; it carries grant participation roles, which are a coarser categorisation. This is by design — grant participation is not authorship — but it means that the question “which CRediT role did this person play on this grant” can only be answered indirectly, by intersecting grant participation with CRediT roles on the grant’s outputs. We expect this to be cleaned up in a future GLS schema revision.

    Second, historical-coverage gaps remain. Pre-2020 grants are almost entirely absent from GLS; 2020-2023 coverage is partial; 2024 onward is increasingly complete. Tools building on the GLS graph need to handle the missing-grant case gracefully.

    Related reading

  • ORCID 4.0: the IDR roadmap and what it means for CASRAI integrations

    ORCID’s Integration and Data Roadmap (IDR) work, which culminated in late 2025 with the 4.0 release of the public and member APIs, is the most consequential PID infrastructure change of the year for anyone who cares about the contributor-affiliation-funding crosswalk. The headline is technical: a new contributions resource that supersedes the old works and employment pairing for representing what a researcher did, where, on whose money, and with whom. The implications reach into nearly every persistent-identifier integration CASRAI tracks.

    What 4.0 actually changes

    The pre-4.0 ORCID record was a federation of resource types: works (with DOIs), employment (with ROR organisation IDs), education, funding (with grant IDs and Funder Registry entries), peer reviews, and the like. Each was useful in isolation. None of them carried the relations between them in a structured form. If a researcher’s ORCID record listed a paper, an employment at the institution that hosted the work, and a grant that funded the work, those three facts sat in separate resources with no machine-readable link.

    4.0 introduces a top-level contribution entity that binds these. A contribution carries: a primary artefact (DOI, software identifier, dataset identifier, or RAiD), a set of CRediT roles with the degree-of-contribution qualifier, an affiliation in force at the time of the contribution (with ROR), funding in force at the time (with Funder Registry or ROR for the funder, plus the grant identifier and ideally a RAiD), and a temporal span. The relationships are explicit and queryable. A consuming system can ask: what did this researcher contribute, at this affiliation, under this grant, on this date? — and get an answer without inference.

    The CRediT-at-record-level integration matures

    The 2024 work to allow CRediT roles to live on an ORCID record (not just in publisher JATS) was the precursor to 4.0. The integration shipped, was widely adopted, and exposed two limitations that 4.0 closes. First, role assignments lived inside the work resource, making it awkward to express a Conceptualization role spanning several papers and datasets. Second, the qualifier was carried only at per-work granularity. 4.0 lets a CRediT role attach to a contribution that groups multiple artefacts, with the qualifier traveling with the contribution.

    Practical example: a researcher who is Lead for Conceptualization across a clinical trial’s primary paper, protocol paper, registered data, and statistical analysis plan should be representable that way. Pre-4.0, the assertion had to be repeated four times; post-4.0, it lives on the contribution entity. See the ORCID implementation guide for the API patterns.

    RAiD becomes a first-class citizen

    One of the unsung wins in 4.0 is the elevation of RAiD to a first-class identifier alongside DOI. Pre-4.0, RAiD could be carried in an ORCID funding resource as an external identifier, but the schema treated it as a second-tier metadata field. 4.0 adds RAiD to the primary identifier set for both contributions and funding, with the same validation and resolution support as DOI.

    This matters because RAiD is increasingly the canonical project-level identifier, and ORCID is increasingly the canonical person-level record. The interlock — researcher X contributed to project RAiD Y, which produced papers A, B, C — is now a structured query rather than a string-match exercise.

    Affiliation history with PIDs at both ends

    The 4.0 employment and affiliation model has been quietly tightened. Every affiliation now requires a ROR organisational ID at registration; legacy string-only affiliations are preserved but flagged. The optional department field accepts a ROR sub-organisation ID where one exists (the ROR hierarchy work has caught up to make this practical), or a free-text department name as a fallback. The result is that affiliation history on an ORCID record is now reliably machine-readable at the ROR ID level.

    For institutions running a CRIS, this closes a longstanding crosswalk gap. CRIS-to-ORCID deposit can now write structured affiliations that ORCID-to-CRIS retrieval can read back without ambiguity. The CASRAI CRIS integration guide has been updated with the 4.0 deposit patterns.

    What CASRAI integrations need to do

    Three things, in priority order.

    1. Update CRediT JATS round-trips. Publishers depositing structured CRediT to ORCID via the member API should switch to the contribution resource for new deposits. Legacy works-with-roles deposits will continue to be accepted through 2026 but will be migrated server-side in 2027. The CASRAI CRediT JATS integration patterns now include both the legacy and the 4.0 deposit forms; new integrators should implement only the 4.0 form.
    2. Validate ROR IDs at affiliation deposit. A CRIS or publisher pushing affiliation data to ORCID should resolve and validate the ROR ID before deposit. The 4.0 API will reject obviously bad ROR IDs at the schema layer but will accept ROR IDs that resolve to deprecated or merged records. A pre-deposit validation pass against the ROR public API catches the common error cases.
    3. Test the funding-to-contribution link. If your integration writes funding entries, link them explicitly to the contributions they funded via the new funded_by relation on the contribution resource. This is the integration point that was missing pre-4.0 and that downstream consumers (funder dashboards, institutional reporting) most want to query.

    Backwards compatibility and the migration window

    ORCID’s commitment is that the 3.x APIs remain available through end-of-2027, with the 4.0 API the recommended target from now. The data model migration is largely automatic for existing records: pre-existing works with associated employment and funding are projected into the contribution model server-side. Consumers reading via the 4.0 API will see contribution entities even for data that was deposited in the 3.x form.

    The one wrinkle is CRediT role assignments that were deposited in 3.x without explicit qualifiers. These project into the contribution model with no qualifier set — a valid state, but less informative than it could be. Publishers should re-deposit historical CRediT data with qualifiers where they have them during 2026.

    What this enables downstream

    The most interesting consequence of 4.0 is the ability to ask compound questions across the PID graph. Which researchers, affiliated with which institutions, contributed in which CRediT roles, to outputs funded by which funders, on which projects? — that query reduces to a structured traversal across ORCID, ROR, Crossref/DataCite, and the Funder Registry, with RAiD optionally tying the project layer together. The OpenAIRE Graph already operationalises a version of this; 4.0 makes it cleaner.

    For institutions, the practical implication is that reporting against funder mandates becomes substantially less manual. For publishers, the JATS-to-ORCID deposit becomes more valuable because it now persists in a queryable graph. For funders, the funder-PID-to-output traceability that ORCID has long promised starts to deliver at scale.

    What’s still missing

    4.0 does not solve everything. The contributor-affiliation-funding triple is now structured; the contributor-contributor relationship (collaboration graphs, mentorship) is not. A relationships resource is in development but not in 4.0. CARE-aligned identifiers for Indigenous researchers are also still in design.

    CASRAI’s integration tracking will follow 4.0 through 2026. The persistent-identifiers domain is being updated to reflect the contribution model; the ORCID federation page tracks member implementation.

    Related dictionary entries