Data Management and Sharing Plans for Computational Research

By Cristo Leon, Ph.D.
Director of Research
Updated September 18, 2026

Quick Answer: A Data Management and Sharing Plan (DMSP) for computational research should identify not only traditional datasets, but also mathematical models, simulation code, software, parameter sets, machine-learning models, computational workflows, and model-generated data. Researchers should explain how these products will be documented, shared, preserved, and made reproducible.

What Is a Data Management and Sharing Plan?

A Data Management and Sharing Plan describes how research products will be created, documented, organized, stored, shared, preserved, and maintained throughout and beyond the life of a research project.

Developing a DMSP can be relatively straightforward when a project produces conventional datasets. The process becomes less obvious when the primary outputs are mathematical models, simulation code, machine-learning models, parameter sets, computational workflows, or model-generated data.

Researchers sometimes assume that a project without surveys, clinical records, or laboratory datasets has little to describe in a DMSP. Computational research demonstrates why that assumption can be misleading. The equations, code, parameters, trained models, simulation outputs, documentation, and workflows required to reproduce a scientific result are themselves important research products.

Start With Research Products, Not Just «Data»

One of the most useful ways to approach a DMSP is to replace the question:

What is my dataset?

with a broader question:

What research products would another researcher need to understand, evaluate, or reproduce my work?

For a computational research project, an appropriate research product category might be:

Computational Models, Simulation Code, and Model-Generated Data

This category could include mathematical models, numerical simulation code, model parameters, configuration files, validation procedures, uncertainty-quantification routines, neural surrogate models, computational notebooks, figure-generation scripts, and simulation outputs.

1. Define the Data or Research Product Category

Use terminology that researchers in your discipline will recognize. The objective is to define a meaningful category of outputs rather than identify every individual file.

Example:

Computational Models, Simulation Code, and Model-Generated Data

Avoid descriptions that are too broad, such as «Research Data,» or unnecessarily narrow descriptions based on individual files.

2. Describe What the Research Product Category Contains

Explain what the research team expects to produce during the project. For computational research, this may include:

mathematical or statistical models;
source code and numerical solvers;
model parameters and configuration files;
simulation outputs;
parameter sweeps and response surfaces;
machine-learning or neural surrogate models;
model-validation procedures;
uncertainty-quantification procedures;
computational notebooks;
scripts used to generate figures and analyses.

The goal is to provide enough information for a reviewer to understand what research products will exist at the end of the project.

3. Identify Access Restrictions Before Promising Public Sharing

If computational products can be publicly released, researchers should state that clearly. However, different research products may require different access policies.

Restrictions may arise from human-subject protections, privacy, confidentiality agreements, intellectual property, cybersecurity considerations, data-use agreements, or industry collaborations.

For example, an industry collaborator might provide proprietary experimental measurements while mathematical models developed using those measurements may eventually be publicly released.

In such cases, restricted inputs and publicly shareable computational outputs should be described separately rather than applying the same access restriction to every research product generated by the project.

4. Choose Open Data Formats and Document the Metadata

Whenever practical, computational research products should use open, interoperable, and well-documented file formats.

Common examples include:

CSV or TXT for tabular numerical data;
JSON or YAML for structured parameters and configurations;
native programming-language formats for source code;
Markdown for repository documentation;
PDF for human-readable supporting documentation.

File format alone is not sufficient. Researchers should also document information needed to interpret and reuse the research products.

A computational repository should normally include a README describing:

the purpose of the model or software;
software dependencies;
parameter definitions;
units of measurement;
file and directory organization;
expected inputs and outputs;
installation or execution instructions;
steps for reproducing major analyses or figures;
version and release information.

5. Explain Where the Research Products Come From

The DMSP should distinguish among newly generated research products, existing datasets, and existing data resources.

For computational research, newly generated products may include mathematical models, source code, parameter estimates, simulation datasets, trained models, and uncertainty-quantification outputs.

If existing experimental or public datasets are used for calibration, training, or validation, researchers should identify their original source, persistent identifier when available, and applicable reuse conditions.

6. Should Researchers Use GitHub for a DMSP?

Yes—but GitHub and long-term research archiving serve different purposes.

GitHub is particularly useful for:

version control;
collaborative software development;
documentation;
issue tracking;
release management;
public dissemination of research software.

GitHub should be viewed primarily as the active computational research environment.

For long-term scholarly preservation, researchers should consider depositing stable releases in an archival research repository such as Zenodo or another appropriate disciplinary or institutional repository.

Recommended workflow:

GitHub → Active computational research environment

Zenodo or another repository → Persistent archival record and DOI

7. Connect GitHub Releases With Persistent Research Records

Stable software or model releases associated with publications and major project milestones can be archived in a research repository.

An archival release might contain:

source code;
model definitions;
parameter files;
configuration files;
documentation;
computational notebooks;
model-generated datasets;
scripts needed to reproduce published results.

A repository capable of issuing a persistent identifier such as a DOI provides a stable scholarly record that can be referenced from publications even as the active GitHub repository continues to evolve.

8. Make Reproducibility Part of the DMSP

A strong computational DMSP should help another researcher answer basic reproducibility questions:

What version of the model produced the reported result?
Which parameters were used?
What software dependencies are required?
Which files generated a particular figure or table?
How can the analysis be rerun?
Where is the archived version associated with the publication?

Reproducibility does not necessarily require preserving every temporary or intermediate file generated during a project. Instead, researchers should identify and preserve the research products necessary to understand, evaluate, and reproduce the reported findings.

9. Establish a Timeline for Public Accessibility

Research products supporting publications should be connected to clear release milestones.

A practical computational research workflow is:

Develop → Document → Validate → Release → Archive → Cite

Software and documentation may be publicly available during development when appropriate, while stable archival releases can be created when results are formally published.

10. Identify Who Is Responsible for Managing and Sharing the Products

A DMSP should assign clear responsibility for ensuring that research products are properly documented, versioned, reviewed, archived, and shared.

Responsibility will frequently rest with the Principal Investigator or another member of the project’s Senior Personnel who oversees computational infrastructure, research data management, or software development.

Individual researchers generating code or data should also be expected to maintain adequate documentation and transfer final research products to the designated repositories.

Do Not Force Every Research Product Into One DMSP Category

Complex research projects may produce several types of outputs with substantially different management and sharing requirements.

For example, a computational biomedical project might distinguish among:

Computational Models, Simulation Code, and Model-Generated Data
Machine-Learning or Neural Surrogate Models
Experimental or Biological Data Used for Calibration and Validation

These categories may require different file formats, metadata, repositories, access restrictions, preservation periods, and responsible personnel.

Separating them can make the DMSP considerably clearer and prevents a legitimate restriction applying to one dataset from appearing to limit unrelated software, mathematical models, or publicly shareable research products.

A Simple DMSP Formula for Researchers

Instead of writing only:

«The data will be available on GitHub.»

Build the DMSP around seven questions:

What will be produced? → How will it be documented? → What can be shared? → Where will it be shared? → When will it be released? → How long will it remain available? → Who is responsible?

This approach transforms the Data Management and Sharing Plan from an administrative requirement into part of the project’s reproducibility and research infrastructure.

Quick DMSP Checklist for Computational Researchers

Identify the major categories of research products.
Describe models, software, code, and generated datasets.
Separate restricted data from publicly shareable products.
Use open formats whenever practical.
Create clear README and metadata documentation.
Use Git for version control.
Use GitHub or an equivalent platform for active development.
Archive stable releases in an appropriate research repository.
Use persistent identifiers such as DOIs when available.
Connect archived releases to publications.
Document how analyses can be reproduced.
Assign responsibility for managing and sharing research products.

Frequently Asked Questions About DMSPs for Computational Research

What is a Data Management and Sharing Plan for computational research?

A DMSP explains what computational research products will be produced, how they will be documented and stored, what will be shared, where the products will be archived, when they will become accessible, how long they will remain available, and who is responsible for managing them.

Can mathematical models and software count as research products?

Yes. Mathematical models, source code, simulation software, parameter sets, configuration files, computational workflows, trained machine-learning models, and model-generated datasets can all constitute research products that should be considered in a DMSP.

Is GitHub sufficient for long-term research preservation?

GitHub is highly effective for version control, collaboration, documentation, and software development. Researchers should consider complementing GitHub with an archival repository capable of preserving stable releases and providing persistent identifiers such as DOIs.

Should experimental data and computational models use the same DMSP category?

Not necessarily. Separate categories are preferable when products have different access restrictions, metadata standards, repositories, preservation requirements, or responsible personnel.

Download the Computational Research DMSP Example

A companion DMSP example provides sample language for describing computational models, simulation code, model-generated data, metadata, provenance, GitHub repositories, archival preservation, accessibility timelines, retention, and accountability.

Download the DMSP Example for Computational Research

Important: This resource is intended as a practical example rather than project-specific compliance advice. Researchers should adapt their DMSP to the requirements of the relevant sponsor, solicitation, research products, disciplinary standards, collaboration agreements, and institutional policies.

Suggested citation:
Leon, C. (2026). Data Management and Sharing Plans for Computational Research: A Quick Guide to Models, Code, GitHub, and Research Data.

Data Management and Sharing Plans for Computational Research | DMSP Guide