CASRAI Dictionary

Tag: Grant Compliance

  • Horizon Europe Open Access Requirements in 2026: A Practical Compliance Checklist for Grant Administrators

    Research offices reviewing Horizon Europe calls for proposals in 2026 face a familiar but persistent problem: the open science obligations attached to EU grant agreements are not optional add-ons, but they are also not uniform. Some provisions in the horizon europe open access requirements are contractual conditions with financial consequences for non-compliance; others are strongly encouraged practices that reviewers reward but auditors do not enforce. Grant administrators who conflate the two categories either over-engineer compliance workflows for recommendations that carry no penalty, or — more dangerously — miss a mandatory obligation buried in boilerplate annex text.

    With the horizon europe work programme 2026 calls now open across multiple clusters, institutions are fielding a fresh wave of applications, and pre-award teams need a working checklist rather than a policy summary. This article separates what is genuinely mandatory under the Model Grant Agreement from what is best-practice guidance, and sets out a practical review sequence research offices can apply to each new proposal.

    Horizon Europe Open Access Requirements: What Is Actually Mandatory

    The core obligation has not changed in substance since the start of the programme, though its enforcement has sharpened as later horizon europe calls 2026 reference updated annotated grant agreement language. Three elements remain non-negotiable for funded projects:

    • Immediate open access to peer-reviewed publications. Beneficiaries must ensure open access to any peer-reviewed publication arising from funded work, deposited in a trusted repository at the moment of publication — there is no embargo period available under the standard grant conditions.
    • A licence permitting reuse. Publications must carry a licence, typically CC-BY, that allows reuse, distribution and text/data mining, subject to proper attribution.
    • Bibliographic metadata and persistent identifiers. Deposited records must include funding acknowledgement, project identifiers, and — increasingly checked at reporting stage — persistent identifiers such as DOIs, ORCID iDs for authors, and, where applicable, Research Organization Registry (ROR) identifiers for affiliated institutions.

    These are contractual terms under the Model Grant Agreement. Non-compliance can trigger corrective action requests during reporting and, in persistent cases, affect payment of the final instalment.

    Data Management Plans and FAIR Data: Mandatory Process, Flexible Content

    The second pillar of Horizon Europe open science policy concerns research data, and this is where administrators most often misjudge the compliance boundary. Every project that generates, collects or reuses research data must produce a Data Management Plan (DMP), typically as a deliverable within the first six months and updated at least once more during the project lifecycle. Producing the DMP is mandatory. What the DMP says is not prescriptive in the same way.

    The underlying principle — data should be “as open as possible, as closed as necessary” — gives beneficiaries legitimate grounds to restrict access where commercial exploitation, personal data protection, security concerns or third-party rights apply. The FAIR principles (Findable, Accessible, Interoperable, Reusable) are the design standard the DMP must address, but FAIR does not equal fully open. A dataset can be FAIR-compliant with metadata openly discoverable while the underlying data remains access-controlled.

    Grant administrators should check that the DMP:

    • Identifies which datasets will be shared openly, and which are justifiably restricted, with a stated rationale for each.
    • Names a repository (project-specific, institutional, or a generalist option) and describes metadata standards to be applied.
    • Assigns responsibility for updates, since a stale DMP submitted once and never revisited is a common audit flag.
    • Addresses costs — data management and open access publication costs are eligible under Horizon Europe, and DMPs should reference the relevant budget lines.

    Recommended, Not Mandatory: Where Reviewers Reward Beyond Compliance

    A separate set of practices appears throughout horizon europe work programme guidance documents and evaluation criteria as encouraged behaviour rather than contractual obligation. Distinguishing these matters because over-promising in a proposal creates a self-imposed obligation that reviewers will later check against actual delivery. Common recommended-not-mandatory items include:

    • Open access to monographs and other long-form outputs, where CC-BY-ND is accepted as an alternative to full CC-BY.
    • Preprint deposit ahead of formal peer review, which is widely encouraged but not required for compliance.
    • Open access to software and code produced during the project, generally framed as good practice aligned with FAIR principles rather than a hard deliverable.
    • Citizen science and public engagement components, which strengthen an application’s societal-impact score without being conditions of the grant agreement.

    Bodies such as cOAlition S and national funders including UKRI maintain parallel but not identical open access frameworks, which is why administrators supporting international consortium partners should confirm which funder’s policy is operative for each work package rather than assuming Horizon Europe terms travel automatically to co-funders.

    A Practical Review Checklist

    For research offices triaging applications against upcoming horizon europe calls 2026 deadlines, a sequential review works better than a single long checklist. At proposal stage, confirm the DMP outline (even a short version) addresses data types, FAIR alignment, and repository choice; confirm ORCID iDs are recorded for all named researchers; and confirm the budget includes open access publication and data management costs as eligible items. At grant agreement stage, verify the consortium agreement assigns clear DMP ownership, confirm repository selection meets trusted-repository criteria, and check that publication clauses in any co-funding or industry partnership agreement do not conflict with the immediate open access requirement. At reporting stage, audit that deposited publications carry correct funding acknowledgement and persistent identifiers, and confirm the DMP has been updated to reflect actual project data outputs rather than left in its original submitted form.

    What This Means for Research Administrators

    The practical risk in 2026 is not ignorance of the headline open access requirement — most institutions have internalised that peer-reviewed outputs must be openly deposited. The risk sits in the secondary layer: DMP maintenance treated as a one-off submission, persistent identifiers omitted from repository metadata, and proposal teams voluntarily committing to open code or open monographs that then become de facto obligations reviewers expect to see delivered. Building a standard pre-award checklist that flags mandatory versus recommended items separately — and assigning DMP review to the same office that tracks reporting deadlines — closes most of this gap without adding significant administrative burden.

    Professional bodies including EARMA, ARMA and INORMS continue to publish guidance aimed at exactly this administrator audience, and research offices new to Horizon Europe compliance should treat their briefings as a first point of reference alongside the Commission’s own annotated grant agreement.

    Looking Ahead

    As the horizon europe work programme 2026 cycle progresses, expect continued tightening around persistent identifier reporting and repository certification, mirroring trends already visible in national policies such as the UKRI open access update and NIH data sharing enforcement. Institutions that build DMP review and identifier hygiene into standard pre-award workflows now will find compliance easier to demonstrate as funders move from policy statements to systematic verification.

  • Writing a Data Management Plan That Satisfies NIH, NSF, and Horizon Europe

    Research administrators managing multi-funder portfolios face a recurring headache every grant cycle: no two major funders ask for a data management plan in the same way. A single investigator with an NIH R01, an NSF collaborative award, and a Horizon Europe consortium grant may need three structurally different documents that all attempt to answer the same underlying question — how will research data be generated, described, preserved, and shared? Building a reusable data management plan template that maps cleanly onto each funder’s requirements is now one of the most practical efficiency gains available to a research office.

    The stakes have risen. NIH’s 2023 Data Management and Sharing Policy is now actively enforced through award terms and conditions, UKRI’s open access policy has tightened expectations around data underlying publications, and Horizon Europe continues to treat the data management plan as a living deliverable rather than a one-off proposal attachment. Administrators who still draft a fresh plan from scratch for every submission are absorbing avoidable cost. A well-designed crosswalk — and a template built from it — turns a compliance burden into a repeatable process.

    The Funder Crosswalk: NIH, NSF, and Horizon Europe Data Management Plan Requirements Compared

    The three funders diverge on format, timing, and philosophy, even though all three now anchor their expectations in FAIR (Findable, Accessible, Interoperable, Reusable) data principles in substance if not always in name.

    • NIH: The Data Management and Sharing Plan is submitted as a distinct attachment at the time of proposal, is not subject to the page-limit rules that apply to the research strategy, and is expected to address six elements — data type, related tools and software, standards applied, oversight of data sharing, and preservation and access timelines, including where data will be deposited. NIH review does not score the plan competitively but the awarded terms make compliance a condition of funding, and lack of an approved plan can hold up an award.
    • NSF: The data management plan is a mandatory two-page supplementary document across all directorates, required since NSF’s foundational 2011 data sharing policy. NSF is comparatively brief on prescribed sections but expects coverage of the types of data produced, standards for metadata, provisions for access and sharing, and policies for reuse and redistribution. Reviewers do weigh the plan as part of the intellectual merit and broader impacts criteria, which makes NSF’s version more consequential to scoring than NIH’s.
    • Horizon Europe: The DMP is not typically required at proposal stage for most calls; instead it is a formal deliverable due within the first six months of a funded project and is explicitly framed as a “living document” to be updated at least once more during the project lifecycle, often at mid-term and final reporting. Horizon Europe’s template, aligned with its open science policy, requires explicit narrative on FAIR compliance for each dataset, plus details on cost, responsibilities, and security, including whether data will be open by default or requires a documented exception.

    The practical consequence for administrators is that the same investigator’s data description work has to be repackaged three times: NIH wants it compact and attached at submission, NSF wants it capped at two pages and reviewer-facing, and Horizon Europe wants it detailed, iterative, and post-award. A shared template only works if it separates the stable content — data types, standards, repositories, roles — from the funder-specific packaging around it.

    Where UKRI and Clinical Trial Plans Diverge Further

    Multi-funder portfolios rarely stop at the “big three.” Two further categories complicate the picture for UK-facing and clinical research offices.

    A UKRI data management plan follows UKRI’s Common Principles on Data Policy, but implementation is devolved to the individual research councils (MRC, BBSRC, ESRC, and others), each of which has its own template and level of prescriptiveness. This is a different model from Horizon Europe’s single harmonised template, and it means a UKRI-funded co-investigator on a Horizon Europe project may technically owe two structurally distinct plans for the same dataset. UKRI’s broader push on open access — extended in recent policy updates to cover monographs and underlying data alongside journal articles — has raised the profile of the DMP as a compliance artefact rather than an administrative afterthought.

    A clinical data management plan is a different instrument entirely, and administrators should not conflate the two. Where a funder DMP addresses data stewardship at the study or grant level, a clinical data management plan operationalises data collection, validation, cleaning, and quality control for a specific clinical trial, typically governed by Good Clinical Practice (GCP) principles and referenced in trial protocols. ICMJE’s data-sharing statement requirement for clinical trial registration adds a further, related but non-identical obligation: a public statement, at registration, of whether and how individual patient data will be shared after publication. A portfolio that includes clinical trials therefore needs both a funder-facing DMP and a trial-level clinical data management plan, cross-referenced but not merged.

    Building a Template Structure That Works Across Portfolios

    A functional cross-funder template separates content into modular blocks that can be recombined per submission rather than rewritten. A workable structure includes:

    • Data inventory: types, formats, and estimated volumes of data to be generated or reused, written once and reused across all funder versions.
    • Standards and metadata: discipline-specific metadata schemas and file formats, referencing recognised community standards where they exist.
    • Storage and security during the project: active storage, backup, and access-control arrangements, particularly relevant to Horizon Europe’s security section and to clinical trial data governance.
    • Preservation and repository: the named repository (disciplinary, institutional, or generalist, such as those indexed by DataCite) and expected retention period.
    • Access and reuse conditions: licensing terms, embargo periods, and any restrictions arising from participant consent, commercial sensitivity, or export control.
    • Roles and responsibilities: named individuals accountable for each stage, which Horizon Europe expects explicitly and NIH and NSF increasingly expect implicitly through institutional data stewardship policies.

    From this modular base, administrators can generate NIH’s compact attachment, NSF’s two-page version, and Horizon Europe’s fuller living document by adjusting emphasis and length rather than starting over. Tools such as DMPonline (maintained by the Digital Curation Centre) and DMPTool already offer funder-specific templates built on broadly this logic, and reviewing existing data management plan examples published through these platforms is a faster route to a working draft than starting from a blank page. The discipline is in maintaining the underlying data inventory as the single source of truth and treating each funder’s version as an export, not an independent document.

    What This Means for Research Administrators

    For research offices supporting investigators across NIH, NSF, Horizon Europe, and UKRI portfolios simultaneously, the crosswalk approach changes three things in practice. First, pre-award staff can build a standing “data profile” per investigator or dataset at the proposal-development stage, rather than waiting for each funder’s specific form to trigger the work. Second, post-award compliance monitoring becomes more tractable: Horizon Europe’s requirement for plan updates at mid-term and final reporting, and NIH’s enforcement of the terms attached at award, both depend on someone tracking which version is current and when the next revision is due. Third, offices supporting clinical research need to keep the clinical data management plan and the funder DMP as separate but cross-referenced documents, since conflating them risks under-specifying either the trial-level quality controls or the funder-level FAIR compliance narrative.

    The administrative overhead of multi-funder compliance is not going away — if anything, the direction of travel among NIH, NSF, UKRI, and Horizon Europe is toward more explicit, more frequently updated, and more publicly scrutinised data plans. Institutions that invest now in a modular, crosswalk-based template will spend less time reconciling funder idiosyncrasies later, and will be better positioned as additional funders and national mandates converge, however unevenly, on the same underlying FAIR data commitments.

  • NIH’s 2026 Data Management and Sharing Plan Format: What Changed and Why It Matters

    The NIH data management and sharing policy, in force since January 2023, is getting its first substantial format revision. Under guide notice NOT-OD-26-046, the National Institutes of Health has updated the required structure of the Data Management and Sharing (DMS) Plan that accompanies most extramural applications, with the revised elements taking effect for applications submitted on or after May 2026. For grant administrators, the change is not cosmetic: reviewers and program staff will now expect more granular metadata detail at the point of submission, not left for post-award justification.

    The revision arrives as NIH data sharing policy compliance has moved from a novelty to an audited routine. Institutions have spent three years building DMS Plan templates, and many of those templates are now out of step with what NOT-OD-26-046 asks for. This article walks through what changed, what stayed the same, and how research administration offices should adjust their internal checklists ahead of the effective date.

    What NOT-OD-26-046 Changes in the NIH Data Management and Sharing Policy

    The original 2023 policy set out six required elements for a DMS Plan: data type, related tools and software, standards, preservation and access timelines, access and distribution considerations, and oversight. NOT-OD-26-046 keeps that six-element skeleton but sharpens what “sufficient detail” means within each one. The revision responds to two years of program-staff feedback that plans were frequently too vague to be enforceable — naming a repository without specifying a deposit timeline, or citing “standard formats” without naming which standard.

    The most consequential change is a new expectation that plans identify specific, named metadata standards and persistent identifier schemes rather than describing them generically. Plans that previously said data would be shared “using appropriate metadata” will now need to name the applicable schema — for example, a Dublin Core or DataCite metadata profile, or a domain-specific standard where one exists. This mirrors a broader trend across funders and publishers: DataCite, CrossRef, and ORCID have each pushed toward named, machine-actionable identifiers rather than free-text descriptions, and NIH’s revision brings its DMS Plan expectations closer into line with that norm.

    Section-by-Section Checklist for the Revised DMS Plan

    Administrators preparing applications for the May 2026 cycle should work through each element against the following practical checklist. This is not a substitute for the official NIH guidance, but it reflects where NOT-OD-26-046 tightens expectations relative to the 2023 baseline.

    1. Data type

    • Distinguish clearly between data that will be preserved and shared versus data generated but not intended for sharing, with a stated rationale for any exclusions.
    • Estimate approximate data volume and modality (imaging, sequencing, survey, sensor, etc.) rather than describing data in purely narrative terms.

    2. Related tools, software, and code

    • Name any custom code, pipelines, or proprietary software required to access or interpret the data.
    • State whether code will be deposited alongside the data (for example in a version-controlled repository) and under what licence.

    3. Standards

    • Name the specific metadata schema and, where applicable, community data standard (such as those maintained by domain repositories or standards bodies).
    • Confirm which persistent identifier scheme will be used for datasets — a DOI issued via DataCite is the default expectation in most disciplines.

    4. Data preservation, access, and timelines

    • Name the repository and confirm it meets NIH’s criteria for an established, sustainable repository, rather than describing repository characteristics generically.
    • State a concrete deposit timeline tied to publication or award milestones, not an open-ended commitment.

    5. Access, distribution, and reuse considerations

    • Address any human subjects, privacy, or controlled-access considerations explicitly, including how consent language supports secondary use.
    • State the reuse licence or terms under which shared data will be made available.

    6. Oversight

    • Name the institutional office or role responsible for monitoring compliance with the plan across the life of the award.
    • Confirm how deviations from the plan will be reported to NIH, consistent with the enforcement posture program staff have adopted since 2023.

    How the NIH Genomic Data Sharing Policy Interacts With the Revised Format

    Applications involving genomic data must continue to satisfy the NIH genomic data sharing policy (GDS Policy) in addition to the general DMS Plan requirements. NOT-OD-26-046 does not replace the GDS Policy’s separate requirements around Institutional Certifications, data use limitations, or submission to NIH-designated data repositories such as dbGaP. What changes is that the DMS Plan’s “standards” and “access” elements now need to explicitly reference the GDS-specific data use limitation categories and repository submission timelines, rather than treating GDS compliance as a parallel, loosely linked process. For research administration offices handling both genomic and non-genomic awards, this means the DMS Plan template can no longer be a single generic document — it needs a genomic-data branch that pulls in GDS-specific language by reference.

    This tightening reflects a pattern seen across major funders: as more institutions ask “what is a data management plan supposed to demonstrate”, the honest answer has shifted from “an articulated intention” to “a verifiable operational commitment.” Reviewers are increasingly trained to check whether named repositories, standards, and identifiers actually correspond to what the applicant’s field uses, rather than accepting boilerplate language.

    What This Means for Research Administrators

    The practical burden of NOT-OD-26-046 falls squarely on research administration offices, sponsored programs staff, and data librarians who support investigators through the DMS Plan drafting process. Three actions are worth prioritising before the May 2026 effective date:

    • Audit existing DMS Plan templates. Any institutional template built around the 2023 language should be checked against the sharpened standards and access-timeline expectations, particularly where templates currently rely on generic placeholder text.
    • Build a named-standards reference list. Rather than asking each investigator to independently identify the correct metadata schema, administration offices should maintain a discipline-by-discipline reference list of accepted standards and identifier schemes, updated as fields evolve.
    • Clarify oversight roles in writing. Because NOT-OD-26-046 expects a named office or role for monitoring compliance, institutions without a designated data-sharing oversight function should assign one now, rather than leaving it implicit.

    None of this is exotic. It is largely the same discipline that publishers, funders such as UKRI, and initiatives like cOAlition S have already been pushing through open-access and open-data mandates elsewhere in the research lifecycle. What is new is that NIH — as the single largest funder of extramural biomedical research — is applying the same rigour to its own plan format.

    A Standards-Originator Perspective

    Consistent, well-documented metadata practice is the connective tissue that makes data management plans auditable rather than aspirational — the same principle that underpins contributor attribution standards. CASRAI originated the CRediT contributor role taxonomy in 2014. The standard is now stewarded by NISO as ANSI/NISO Z39.104-2022. That history is a useful reference point here: a taxonomy or metadata convention only becomes durable once a neutral standards body maintains it beyond its originating organisation, and once funders and publishers build compliance checks around it rather than treating it as optional guidance. NOT-OD-26-046 is, in effect, NIH doing the same thing for dataset metadata that CRediT did for authorship — moving from generic description toward named, checkable categories.

    For grant administrators, the takeaway is not that the DMS Plan has become harder to write — it is that the plan must now say precisely what the institution intends to do, in terms that a reviewer, a repository, and an auditor can all verify independently. Offices that treat the May 2026 changes as an opportunity to formalise their metadata and oversight practices, rather than a compliance inconvenience, will be better positioned as NIH data sharing policy enforcement continues to mature through the remainder of the decade.

  • No-Cost Extensions, Carryover, and Prior Approval: A Glossary for NIH Grant Administrators

    Search traffic around the NIH Grants Policy Statement no-cost extension provisions spikes every year around the same time: the final months of a project period, when a principal investigator realises the data collection is behind schedule and someone in the sponsored programs office has to explain, again, what counts as an allowable extension and what does not. The terminology in the NIH Grants Policy Statement (GPS) is precise, but it is scattered across dozens of pages, cross-referenced against 45 CFR Part 75 and the Uniform Guidance, and rarely explained in one place for the administrators who have to apply it daily.

    This glossary collects the recurring terms — no-cost extension, carryover, consortium agreements, and program income — that generate the highest volume of long-tail searches from research administrators, and sets out what each one actually means in practice. It follows the same reference format CASRAI uses across its dictionary of research-administration terms: definition first, then the operational detail that determines whether an institution stays compliant.

    The audience is deliberately broad. US-based sponsored programs offices are the primary users of NIH terminology, but institutions that hold both NIH awards and funding from UK bodies increasingly need to translate between systems — a researcher who has learned to apply for grants under UKRI’s rules and then moves onto an NIH-funded consortium project discovers quickly that “extension” and “carryover” do not mean the same thing, or follow the same approval path, on both sides of the Atlantic.

    What the NIH Grants Policy Statement Says About No-Cost Extensions

    A no-cost extension (NCE) lengthens the period of performance on an NIH award without adding funds. The NIH Grants Policy Statement recognises two routes:

    • First, unilateral NCE: the recipient institution may extend the final budget period of a grant once, for up to 12 months, without prior NIH approval, provided the award is not in its final year of a competitive segment for reasons that require agency sign-off (for example, if additional time is needed beyond the single automatic extension, or if the award carries specific terms restricting this authority). This authority sits with the institution’s authorised organisational representative, not the principal investigator alone.
    • Second, NIH prior-approval NCE: a second extension, or any extension where the unilateral authority does not apply, requires a formal request to the assigned NIH awarding component, submitted well before the current project period ends, with a justification tied to the scientific rationale — not simply “more time is needed.”

    The distinction matters because a unilateral NCE that should have gone through prior approval is a compliance finding waiting to happen. Institutions that log every NCE — automatic and approved — in a central tracking system tend to catch these errors before an NIH grants management specialist does.

    Carryover: The Companion Concept to No-Cost Extensions

    Carryover is the mechanism that lets unobligated funds from one budget period move into the next. It is distinct from a no-cost extension, though the two are frequently requested together: a project that needs more time to spend down its budget usually also needs the unspent funds to travel with it.

    Under the NIH Grants Policy Statement, carryover authority depends on the type of award:

    • Awards issued under the Streamlined Non-Competing Award Process (SNAP) generally carry automatic carryover authority, meaning unobligated balances may move forward without a separate request.
    • Non-SNAP awards, and awards with specific restrictive terms, require prior NIH approval before carryover funds can be obligated in the next budget period.

    Administrators should treat carryover and NCE requests as related but separate compliance events. A common error is assuming that approval of one automatically covers the other — it does not. Each has its own authority basis in the GPS, and each needs its own documentation trail in the institution’s grants management system.

    Consortium Agreements and Subrecipient Monitoring

    Multi-institutional NIH awards are structured through consortium agreements — legally binding documents between the prime recipient and each participating (subrecipient) institution. The NIH Grants Policy Statement requires that these agreements flow down all applicable federal terms, including the prime award’s specific conditions, and that the prime recipient carry out subrecipient monitoring consistent with the Uniform Guidance (2 CFR 200.332).

    Where searches for “nih grants policy statement” cluster most heavily around consortium terms is usually at renewal or no-cost extension time, because an NCE on the prime award does not automatically extend the subaward — each consortium agreement needs its own amendment, on its own timeline, coordinated by the prime institution’s sponsored programs office. Institutions that manage large multi-site NIH awards (common in clinical trials networks and multi-PI R01s) typically maintain a master tracking sheet cross-referencing prime award dates against every subaward’s period of performance, precisely to avoid a subrecipient continuing work after its own agreement has technically lapsed.

    Program Income: An Often-Overlooked GPS Category

    Program income is gross income earned by the recipient that is directly generated by a supported activity, or earned as a result of the award — for example, fees from clinical services delivered through a research protocol, registration fees at a conference funded by the grant, or proceeds from the sale of research-generated data or materials. The NIH Grants Policy Statement sets out three methods for handling it: deduction (reducing NIH’s contribution), addition (adding it to the project’s committed funds), or cost-sharing/matching. Which method applies is usually specified in the notice of award, and applying the wrong method is a recurring finding in post-award reviews.

    Because program income rules interact with the same budget period concept that governs carryover and no-cost extensions, administrators processing an NCE should verify whether unspent program income also needs to be reported and carried forward under the applicable method.

    What This Means for Research Administrators

    The terms in this glossary are not abstract definitions — each one triggers a distinct approval workflow, a distinct system-of-record entry, and in some cases a distinct federal reporting obligation. The practical implications for institutional research offices are:

    • Track authority levels separately. Unilateral NCE authority, prior-approval NCE, automatic carryover, and prior-approval carryover each rest on different sections of the GPS. Conflating them in institutional policy documents is a common source of audit findings.
    • Coordinate consortium timelines actively. A no-cost extension on the prime award is not self-executing across subawards; each consortium agreement needs its own amendment.
    • Build cross-training between NIH and non-NIH portfolios. Institutions managing both NIH grants and awards from bodies such as UKRI, Horizon Europe, or other funders that researchers may apply for grants through, benefit from a single internal glossary that maps equivalent-but-different terms (for example, NIH’s “no-cost extension” against a UK funder’s “extension request”) so that PIs moving between funding streams are not caught out by assuming identical rules.
    • Document the scientific justification, not just the administrative request. NIH awarding components scrutinise the rationale behind prior-approval NCE and carryover requests; a request that reads as purely administrative is more likely to be questioned or delayed.

    These distinctions also matter for research integrity and reproducibility more broadly. Standards bodies such as NISO and initiatives supported by SPARC and cOAlition S increasingly expect that data management, sharing, and reporting obligations tied to federal awards are tracked with the same rigour as the funding mechanics themselves — an NCE that extends a project’s timeline, for instance, typically extends the data-sharing and reporting deadlines tied to NIH’s data management and sharing policy as well.

    A Reference Point, Not a Substitute for the Statement Itself

    No glossary replaces a careful reading of the current NIH Grants Policy Statement, which is updated periodically and should always be consulted in its original form for the specific fiscal year and award terms in question. What a reference like this can do is give research administrators — particularly those new to federal awards, or those managing a mixed portfolio spanning NIH grants and non-US funders — a shared vocabulary for the conversations that recur every budget cycle: whether an extension is unilateral or requires approval, whether carryover is automatic or restricted, whether a consortium agreement needs its own amendment, and how program income should be handled once it appears on the books.

    As federal reporting requirements continue to tighten and data-sharing obligations extend further into the post-award period, the administrative precision this glossary describes is likely to matter more, not less. Institutions that build internal reference materials mapping these terms — and keep them current against each GPS revision — will spend less time reconciling compliance findings after the fact.

  • Horizon Europe Open Science Requirements: Compliance Guidelines for Grant Recipients

    1. Introduction to the Role of Horizon Europe Open Science in Scholarly Infrastructure

    In the contemporary landscape of global science, open research practices, and institutional data governance, establishing robust standards is crucial. The integration of Horizon Europe Open Science represents a landmark advancement in addressing long-standing hurdles in scholarly communication, administrative reporting, and metadata curation. This extensive guide provides an expert-level breakdown of the operational frameworks, specifications, and systemic requirements surrounding Horizon Europe Open Science in 2026.

    As academic funders and research ministries worldwide enforce increasingly rigid compliance pathways, universities must transition from ad-hoc administrative workflows to unified, persistent-identifier-driven schemas. Implementing Horizon Europe Open Science is not merely a technical adjustment; it is a strategic necessity that secures institutional research visibility, ensures frictionless metadata reporting, and compounds the impact of scientific investments.

    2. Technical Architecture and Core Specifications

    Underpinning the deployment of Horizon Europe Open Science is a set of rigorous, machine-actionable specifications designed to operate seamlessly across diverse platforms. This environment relies heavily on the mandatory open science mandates of Horizon Europe, including immediate open access and data management plans (DMPs). By establishing clear, standardized data exchange layers, organizations can bypass the siloed architectures that have traditionally plagued research information networks.

    A key focus of these specifications is the preservation of structural metadata integrity. This is achieved by mapping data payloads to recognized open vocabularies, such as Dublin Core, Schema.org, and custom JSON-LD graphs. This ensures that every scientific output—be it a journal article, a software version, or an administrative record—carries citable provenance tags, enabling automated indexing and cross-referencing by global citation engines such as OpenAlex and Crossref.

    3. Institutional Challenges, Workflows, and Solutions

    While the administrative and scientific benefits of Horizon Europe Open Science are indisputable, the practical deployment across universities and libraries reveals significant hurdles. Major friction points include securing intellectual property, depositing in certified repositories, and reporting compliance indicators in project portals. Faculty reluctance, legacy software limitations (such as outdated CRIS databases), and the high administrative cost of manual curation represent substantial barriers to widespread compliance.

    Overcoming these implementation bottlenecks requires a systemic, top-down commitment to administrative automation. Institutions must deploy modern API middleware to coordinate data transfers between local enclaves and global public registries, eliminating manual data-entry redundancy. Furthermore, university promotion and tenure committees must update their evaluative rubrics to formally credit researchers for complying with these modern curation workflows, establishing a cultural positive-feedback loop.

    4. Technical Evaluation and Integration Matrix

    Integration Domain Primary Objective Core Interoperability Standard Friction Mitigation Strategy
    Persistent Identification Ensure permanent, citable links across registries. Unique URI / DOI Resolve Systems Implement automated metadata harvesting on ingest.
    Metadata Exchange Frictionless transfer between CRIS and repositories. JSON-LD / XML Schema Mapping Deploy standardized REST APIs with OAuth 2.0.
    Compliance Auditing Track, verify, and report on policy adherence. Standardized SQL / GraphQL Querying Generate real-time compliance scorecards for PIs.

    5. Five-Step Institutional Implementation Roadmap

    • Step 1: Institutional Alignment & Sign-off — Establish an official cross-departmental committee representing the library, IT services, and the research office to draft the institutional deployment charter for Horizon Europe Open Science.
    • Step 2: API & Schema Mapping — Audit existing repository databases and map local metadata schemas to match the international JSON-LD specifications required for Horizon Europe Open Science.
    • Step 3: Middleware Integration & SSO — Configure enterprise middleware layers to handle automated data harvesting and synchronize access using Single Sign-On (SAML/Shibboleth).
    • Step 4: Training & Support Networks — Deploy interactive workshops, dedicated helpdesks, and online documentation to educate researchers, metadata curators, and administrative staff.
    • Step 5: Automated Verification & Auditing — Launch real-time validation checks and annual data-quality audits to measure compliance rates and automatically identify and correct orphaned records.