Research data management plans go…

The Data Management Plan has been an awkward artefact of the funded-research workflow since the 2010 NSF mandate. For a decade it was a few-page PDF, written at proposal stage, signed off by a librarian, and largely forgotten until the next proposal. In 2026 the picture is different. The machine-actionable DMP (maDMP) has matured from a Research Data Alliance working-group concept into operational infrastructure at major funders, repositories, and institutions. This post walks through what changed, what the tooling actually does, and what the corresponding software-management-plan turn means for funded projects in 2026.

The maDMP idea

The traditional DMP described what the project would do with its data: which formats, which repositories, what metadata, what retention. The information was useful but was locked in prose; downstream systems could not consume it, so the same information was re-entered in each new context (the repository deposit form, the funder report, the institutional CRIS).

The maDMP idea, formalised by the RDA DMP Common Standard, is to express the DMP as structured machine-readable data (a JSON document conforming to the Common Standard schema) that downstream systems can consume directly. The same information that is human-readable in the PDF is also available as queryable structured data, with PIDs (ORCID for people, ROR for organisations, DOI for repositories, RAiD for the project).

The Common Standard, finalised by the RDA Active DMPs working group, defines the JSON schema, the controlled vocabularies, and the core required fields. Version 1.1 was the working release through 2022-2024; the 1.2 update (2024) added software-management-plan extension fields and refined the contributor model to align with CRediT.

The tooling landscape

By 2026 several mature tools implement the maDMP standard, with substantial integration across regions.

DMPRoadmap and its descendants

DMPRoadmap is the open-source maDMP platform jointly developed by the UK Digital Curation Centre and the University of California Curation Center. It powers the UK’s DMPonline service (used by all UKRI councils, NIHR, Wellcome, and most UK universities) and the US’s DMPTool (used by NSF, NIH, NASA, DOE, and a long list of US institutions). The 2024 unification of DMPRoadmap’s code base across the UK and US deployments was a significant administrative move; the platform is now a single shared upstream with regional customisations.

Argos

Argos is the European maDMP platform developed by OpenAIRE and EUDAT. Argos is the default DMP tool for HORIZON Europe-funded projects and integrates tightly with the EOSC Zenodo deposit workflow, the OpenAIRE Graph, and the Funding and Tenders portal. Argos’s interesting design choice was to model the DMP as a layered set of templates (funder-specific layered on discipline-specific layered on institutional), which allows a single underlying maDMP to be presented through whatever lens an evaluator needs.

RDA-DMP-Common-Standard-native tools

The RDA Common Standard is now natively supported by most major repository platforms (DataCite Fabrica, Zenodo, Figshare, Dryad), by several CRIS systems (Pure, Elements, Converis, DSpace-CRIS), and by funder portals. The interop story is real: a maDMP produced in DMPonline can be exported as Common Standard JSON, consumed by Argos for a HORIZON proposal, and round-tripped to a DataCite repository at the deposit stage.

What an maDMP integration looks like in practice

The integration patterns that have settled in 2026 follow this shape. At proposal stage the researcher uses DMPonline/DMPTool/Argos to draft a maDMP, pulling in ORCID, ROR, and grant metadata where available. The maDMP is exported as Common Standard JSON and attached to the proposal.

At award stage the funder pulls the maDMP into its grant-management system; the project’s RAiD or grant DOI is back-linked to the maDMP record. The maDMP becomes the canonical project plan that the institution’s CRIS, repository, and reporting workflow all reference.

At repository deposit the dataset metadata (title, authors, methods, related publications) is pre-populated from the maDMP fields. Saving the deposit triggers an update to the maDMP record itself, marking that planned dataset as deposited, with the resulting DOI.

At reporting stage the funder’s annual report and the institution’s research-information report both query the same maDMP record. Re-keying of the same information across systems is materially reduced.

The user-visible artefact is still a PDF (funders and reviewers still want one) but it is generated from the structured record on demand, not authored in prose.

Where it falls short

Three frictions remain in 2026. First, discipline coverage: the Common Standard was drafted with bench-science and social-science data primarily in mind. Humanities collections, qualitative archives, and operational data (e.g., conservation biology fieldwork data) fit the schema imperfectly. The RDA working groups have been extending the controlled vocabularies but the long tail is long.

Second, repository alignment: not every repository accepts maDMP-imported deposits cleanly. The big repositories do; the long tail of institutional repositories often have legacy metadata schemas that need mapping.

Third, privacy and sensitivity: a maDMP for a clinical study contains potentially sensitive information about data access controls, IRB approvals, and consent terms. The Common Standard supports flagging fields as confidential, but the operational practice of differential disclosure to different downstream consumers (funder, repository, public) is still being worked out.

The Software Management Plan turn

The 2024-2025 development that genuinely shifted the field was the formal addition of Software Management Plans as a sibling artefact to DMPs. Funders had been asking for them informally for years; the 2024 explicit requirement at NWO (Netherlands), NIH (for selected programmes), DFG (Germany), and several UKRI councils brought the SMP into the mainstream.

An SMP describes how the project’s software will be developed and stewarded: licence, repository, citation, dependencies, sustainability beyond the project life. The 2024 SMP guidance from the Software Sustainability Institute defined a five-section structure that has been broadly adopted: software descriptions, software development practice, software deposit and citation, sustainability and maintenance, and intellectual property and licensing.

The maDMP Common Standard 1.2 added an SMP extension that allows the SMP to be expressed alongside the data plan in the same JSON document, with cross-references between data products and the software that produces them. By 2026 this is becoming the default: a project produces one structured maDMP that covers data and software, with both halves referenced from the same RAiD.

FAIR data integration

The maDMP transition has reinforced the practical operationalisation of FAIR. A maDMP that names a repository (with a DOI), a metadata schema, a controlled vocabulary, and a licence is structurally more FAIR-compliant than a prose DMP that mentions “a suitable repository.” The maDMP-to-deposit integrations make F (findable) and A (accessible) measurable; the I (interoperable) and R (reusable) elements need the metadata-schema and licence choices to actually be implemented.

The RDA FAIR Data Maturity Model indicators are now being calculated automatically from maDMP records and repository deposits in several institutional CRIS systems. The 2026 picture is that institutions can measure FAIR-ness of their research outputs at the data-product level, not just claim it; this is a real improvement on the 2020 baseline.

What to do if you are starting now

For a researcher writing a proposal in early 2026:

Use the funder-recommended maDMP tool (DMPonline, DMPTool, or Argos depending on funder).
Identify your data products and their target repositories early; choose repositories that accept Common Standard imports.
If your project produces software, draft an SMP alongside the DMP using the SSI five-section structure. The Common Standard 1.2 lets you keep them in one record.
Provide ORCID and ROR identifiers everywhere they are asked for. Link the maDMP to the project’s RAiD if your funder supports it (Australian, UK, EU funders are most likely to).
Treat the maDMP as a living document. Update it on data deposit, on milestone reporting, and on project closeout. The point of machine-actionability is that updating it is cheap.

For institutions setting policy, the RDA federation page tracks the working-group outputs and adoption status. The maDMP domain at CASRAI carries the canonical Common Standard reference.

References

RDA Active DMPs Working Group, DMP Common Standard for machine-actionable DMPs (v1.1, 2022; v1.2, 2024). Miksa et al., Ten principles for machine-actionable data management plans (PLOS Computational Biology, 2019). Software Sustainability Institute, Checklist for a Software Management Plan (2024 revision). EOSC, EOSC FAIR Implementation Profiles (2023).