Metadata Management Plan for Genomics Grants: Template and Examples

By Dr. Zubair Khalid, DVM, MS, PhD · 2026-11-11

By the end of this article you will be able to write the metadata portion of a data management plan for a genomics grant, fill in a reusable template with project-specific detail, choose a metadata standard your community actually recognizes, validate a sample sheet before sequencing starts, and budget storage for the full data lifecycle. You need three things on hand: your grant mechanism's data plan requirements (for NIH applications, the six Data Management and Sharing Policy elements described below), a spreadsheet or plain-text sample sheet template, and a place to run small validation scripts such as a laptop with Python installed.

This article covers the metadata side of bioinformatics data management in depth, because metadata is where most plans are weakest and where reviewers push back hardest.

Why Metadata Deserves Its Own Section in a Genomics Grant

A metadata management plan is the part of your grant that answers one question in concrete detail: what information will you record about your samples, instruments, reads, and analyses so that someone else (including you, three years from now) can understand and reuse the data? It is a component of the broader data management plan, not a separate document, but it earns its own section because genomics metadata is unusually complex and unusually easy to get wrong.

The evidence for this is consistent across multiple studies of research practice. Mannheimer's study of how data management plans affect grant-funded research found that principal investigators manage data internally to prevent loss and to survive personnel turnover, but that most "still have room to grow in understanding specialized concepts such as metadata and policies for use and reuse". A Cornell survey of NSF principal investigators found the same gap from the other direction: the majority of respondents created no metadata at all, and of those who did, most did not follow any particular standard. A University of British Columbia survey of science and engineering faculty identified metadata, storage, and data plans as three areas where researchers explicitly wanted institutional help.

In genomics the stakes are higher than in many other fields because the raw output of a sequencer is nearly meaningless without context. A FASTQ file contains reads and quality scores. It does not contain the species, tissue, extraction protocol, library kit, sequencing platform, or batch. Those facts live in metadata, and if they are not captured in a structured way at the time of collection, they often cannot be reconstructed later. The AgBioData consortium, which coordinates agricultural genomics databases, puts it plainly: the value of data increases when it is properly described, integrated, and shared, and doing that requires attention to metadata, ontologies, and curation [2].

What Funders Actually Review

Under the NIH Data Management and Sharing Policy, which took effect for applications in January 2023, every NIH applicant must submit a plan covering six elements: Data Type, Related Tools, Software, and Code, Standards, Data Preservation, Access, and Associated Timelines, Access, Distribution, or Reuse Considerations, and Oversight of Data Management and Sharing. NIH institutes review and approve the plan before issuing an award and monitor compliance afterward [3]. Experience from the first year of review at the National Institute on Aging's Division of Behavioral and Social Research showed that researchers had persistent questions about how to handle metadata, how to distinguish primary from secondary data, and how to select an appropriate repository, and that review teams increasingly coach grantees through revisions [3].

Two findings from the DMS review experience matter directly for your metadata section. First, reviewers look for specificity: named standards, named repositories, named roles. Second, plans that treat metadata as a one-line promise ("all data will be annotated appropriately") fare poorly compared with plans that list the actual fields captured, the standard each field maps to, and the file format that carries them [3].

Independent assessment work points the same way. A librarian-developed assessment rubric for DMS Plans, adapted from the FASEB DataWorks! DMP Challenge evaluation rubric, scores plans on data type, repositories, data standards, and dissemination timelines, and found that paired reviewers agreed overall but diverged on specific questions, which argues for writing standards choices explicitly rather than leaving them to reviewer interpretation [4]. Mannheimer's interviews found that PIs "may need guidance on practices that facilitate FAIR data, such as using metadata standards, assigning licenses to their data, and publishing in data repositories". FAIR stands for Findable, Accessible, Interoperable, Reusable, and metadata is the mechanism that delivers the F and the I.

The lesson is simple. Reviewers reward metadata plans that name concrete standards and concrete tools. The rest of this article gives you the format for doing that.

Metadata Management Plan Template for a Genomics Grant

Use this template as a subsection inside your Standards element (and cross-reference it from Data Type and Oversight). Copy it into your application and replace every bracketed placeholder. The format below follows the structure reviewers expect under the NIH six-element scheme, adapted from the review experience described by the NIA DMS review team [3] and from the logic of standardized DMP generators such as DataPLAN, which combines a questionnaire with pre-written, standards-aware responses [5].

### M1. Data and Metadata Inventory
- Data products: [e.g., raw reads (FASTQ), alignments (BAM/CRAM),
  variant calls (VCF), count matrices (TSV)]
- Estimated volume per sample and total: [see worked calculation below]
- Metadata captured at each stage:
  - Collection: [fields list]
  - Processing: [fields list]
  - Analysis: [fields list]

### M2. Metadata Standards
- Sample-level standard: [e.g., MIxS / project-specific schema mapped to it]
- Experiment-level standard: [e.g., ISA-Tab investigation file]
- Ontologies / controlled vocabularies: [e.g., specific term sources
  for species, tissue, disease, and phenotype fields]
- Deviations from the standard and justification: [none, or list]

### M3. Data Dictionary
- Location of the data dictionary: [file name and repository path]
- Every column in every tabular deliverable is defined here, including
  units, allowed values, and missing-value convention.

### M4. File Naming and Directory Layout
- Naming convention: [pattern with fixed field order]
- Version control location for schemas and codebooks: [repo]

### M5. Identifiers
- Sample IDs: [scheme, minted by whom, stored where]
- Linkage between identifiers across data types: [key field]
- Permanent identifiers for released datasets: [DOI or accession class]

### M6. Validation and Quality Control of Metadata
- Validation script or checklist, run when: [sample sheet receipt,
  before submission]
- Who runs it and where results are logged

### M7. Storage, Backup, and Retention for Data and Metadata
- Working storage: [location, capacity]
- Backup: [schedule, locations, retention]
- Long-term archive and its metadata requirements: [repository or
  institutional archive]

### M8. Repository and Submission Plan
- Repository: [name and why it fits the data type]
- What is deposited: [raw data, processed data, metadata files, codebook]
- Controlled-access tier for human data if applicable: [mechanism]

### M9. Access, Reuse, and Licensing
- Metadata license: [a named license]
- Data access terms and any controlled-access path

### M10. Roles, Oversight, and Persistence
- Responsible person(s) for metadata capture, validation, submission
- Metadata tasks in onboarding for new personnel
- How metadata survives personnel turnover: [systems, not memory]

Two template decisions deserve explanation. First, M3 exists because a data dictionary is the single cheapest insurance against the most common reuse failure: a column whose meaning nobody remembers. Second, M10 exists because Mannheimer's research found PIs already manage data to survive personnel turnover, but metadata knowledge tends to live in individual heads rather than in systems, which is exactly what a plan can fix [1].

Worked Example: 96-Sample RNA-Seq Study

This section gives a metadata management plan genomics grant example with real numbers, a real sample sheet, and a real validation script. The scenario: a transcriptomic study of 96 tissue samples sequenced as paired-end 150 bp libraries on a short-read platform, with 50 million read pairs targeted per sample.

Step 1. Estimate the Volume

Plan storage from read counts and bytes per base, not from instrument promises. A compressed FASTQ file runs roughly 0.3 bytes per sequenced base as a planning figure. The arithmetic:

Bases per sample = 50,000,000 read pairs x 2 reads x 150 bp
                 = 15,000,000,000 bases (15 Gb)

Raw FASTQ per sample ≈ 15e9 bases x 0.3 bytes/base ≈ 4.5 GB
Alignments (BAM) per sample ≈ 4 to 6 GB with index

Working set per sample (FASTQ + BAM + QC) ≈ 10 GB
96 samples ≈ 960 GB ≈ 1 TB working copy

Total request with one backup copy plus one archive copy ≈ 3 TB

Request at least three times your working set: one working copy, one backup, one archival copy. State this calculation in your Data Type element so the storage budget is traceable.

Step 2. Define the Sample Sheet Before the First Run

Create a sample sheet as a CSV with a fixed schema. Here is the first five rows of the example study's sheet:

sample_id,organism,tissue,collection_date,extraction_kit,library_kit,
read_length,batch,operator,sra_biosample_id
S001,Mus musculus,liver,2026-03-14,Qiagen RNeasy,NEBNext Ultra II,
2x150,B1,JRL,SAMN00000001
S002,Mus musculus,liver,2026-03-14,Qiagen RNeasy,NEBNext Ultra II,
2x150,B1,JRL,SAMN00000002
S003,Mus musculus,liver,2026-03-15,Qiagen RNeasy,NEBNext Ultra II,
2x150,B1,JRL,SAMN00000003
S004,Mus musculus,liver,2026-03-15,Qiagen RNeasy,NEBNext Ultra II,
2x150,B2,JRL,SAMN00000004
S005,Mus musculus,liver,2026-03-16,Qiagen RNeasy,NEBNext Ultra II,
2x150,B2,JRL,SAMN00000005

Every column is defined in the data dictionary. For example:

Field:            batch
Type:             categorical
Allowed values:   B1, B2
Definition:       Sequencing flow-cell batch. B1 = lanes 1 to 4 of
                  run #2026-03-18. Used to model batch effects.
Missing value:    not permitted

Note the missing-value rule. Missing data that is silently blank becomes ambiguous later. Distinguish "not recorded" from "not applicable" with explicit codes such as NA_not_recorded and NA_not_applicable, and say so in the dictionary.

Step 3. Validate the Sheet with a Script

Run validation at sample sheet receipt, and again before repository submission. A short Python script with pandas covers the checks that catch most real errors:

import pandas as pd

REQUIRED = ["sample_id", "organism", "tissue", "collection_date",
            "extraction_kit", "library_kit", "read_length",
            "batch", "operator"]

sheet = pd.read_csv("sample_sheet.csv", dtype=str)

errors = []

# 1. All required columns present
missing_cols = [c for c in REQUIRED if c not in sheet.columns]
if missing_cols:
    errors.append(f"missing columns: {missing_cols}")

# 2. Unique sample IDs
dupes = sheet["sample_id"][sheet["sample_id"].duplicated()].tolist()
if dupes:
    errors.append(f"duplicate sample_id values: {dupes}")

# 3. ID format matches the naming convention
bad_ids = sheet[~sheet["sample_id"].str.fullmatch(r"S\d{3}")]["sample_id"]
if not bad_ids.empty:
    errors.append(f"sample_id format errors: {bad_ids.tolist()}")

# 4. Controlled vocabulary fields hold only allowed values
if "batch" in sheet.columns:
    bad_batch = sheet[~sheet["batch"].isin(["B1", "B2"])]["batch"]
    if not bad_batch.empty:
        errors.append(f"batch outside allowed values: {bad_batch.tolist()}")

# 5. Dates parse
try:
    pd.to_datetime(sheet["collection_date"], format="%Y-%m-%d")
except ValueError as e:
    errors.append(f"collection_date parse failure: {e}")

if errors:
    print("VALIDATION FAILED")
    for e in errors:
        print(" -", e)
else:
    print(f"VALIDATION PASSED: {len(sheet)} samples, 0 errors")

Expected output on a clean sheet:

VALIDATION PASSED: 96 samples, 0 errors

Expected output when row 77 has batch b3 (lowercase, an allowed-value typo):

VALIDATION FAILED
 - batch outside allowed values: ['b3']

Log the script's output to a dated file in the project repository. That log is evidence of oversight, which is Element 6 of the NIH scheme [3].

Step 4. Name Files so Metadata Travels with Data

Adopt a naming pattern where field order never changes:

{sample_id}_{tissue}_{library_kit_short}_{batch}_{file_class}.ext
S001_liver_ultra2_B1_R1.fastq.gz
S001_liver_ultra2_B1.bam
S001_liver_ultra2_B1.bai

Verify checksums when files move, so you can prove integrity later:

$ md5sum S001_liver_ultra2_B1_R1.fastq.gz > S001_liver_ultra2_B1_R1.fastq.gz.md5
$ md5sum -c S001_liver_ultra2_B1_R1.fastq.gz.md5
S001_liver_ultra2_B1_R1.fastq.gz: OK

A failed checksum prints FAILED instead of OK and means the copy is corrupt. Re-transfer rather than troubleshoot downstream.

Step 5. Write the Standards Paragraph

In the Standards element, name what you use and why. For this example:

• Sample-level context follows MIxS-style core fields (organism, collection date, geographic or tissue source), because MIxS packages are what sequence repositories request at submission.
• Experiment-level structure follows the ISA-Tab pattern, which separates the investigation, the study, and the assays into linked tabular files.
• Ontology-sourced terms (see the standards table below) for species, tissue, and phenotype fields.

Name your deviations too. If your clinical covariates do not fit any published standard, say that you maintain a project data dictionary mapped to ontology terms where possible. Reviewers accept honest specificity. They penalize vagueness.

Choosing Metadata Standards: The Practical Table

You do not need to memorize standards. You need to pick one per layer of your data and cite it by name. This table summarizes the standard options most genomics projects choose from. All are established community standards with published specifications and active maintenance.

How to choose: match the layer, not the ambition. Sample metadata goes into a MIxS-consistent sample sheet. Study structure goes into ISA-Tab. The released dataset gets DataCite or Dublin Core metadata at the repository. If your community has a domain effort, use it. The eDNAqua-Plan project, which is building standardized plans for environmental DNA sequencing of aquatic organisms, illustrates the payoff: complete and interoperable metadata is what allows DNA-derived data and analysis outputs to be reused broadly, and the project maps its workflows onto existing archives such as the International Nucleotide Sequence Database Collaboration [6].

Ontologies turn free text into computable meaning. For the example study, the species field should hold a taxonomic identifier or scientific name, not "mouse vs Mouse vs Mus musculus." AgBioData's recommendations for sustainable genomics databases dedicate full sections to ontologies, metadata, and curation precisely because consistent, ontology-backed metadata is what makes database integration possible later [2]. Tools in the GeCo project line take this further: their genomic data model provides interoperability across heterogeneous formats, and their repository supports attribute-based and keyword-based search over normalized metadata drawn from several open repositories. That is what normalized, ontology-aware metadata buys you at scale.

Genomics Data Storage Planning

Metadata planning and storage planning are the same problem in different clothes, because a storage plan without metadata is a pile of unidentifiable files. Your grant should describe four tiers.

Tier 1, working storage. Fast storage where analyses run. For the 96-sample example, about 1 TB. Name the system in the plan.

Tier 2, backup. A second copy on separate hardware or a separate service, on a defined schedule, with retention stated. The Cornell and UBC surveys both found researchers using a wide variety of backup strategies, on-campus and commercial, often without a documented schedule. A written schedule costs nothing and is a reviewable commitment.

Tier 3, archive. Long-term preservation with preservation metadata. The OAIS reference model, an international standard for archival systems, distinguishes the content data from its representation information, the metadata needed to interpret it, and archives built on this model handle research grant data ingestion, metadata management, and security as first-class operations [7]. Your plan does not need to implement OAIS, but naming it and saying your archival copy includes a data dictionary and checksum manifest aligns you with the model.

Tier 4, repository. The public or controlled-access copy. This tier's metadata must meet the repository's requirements, which is why the sample sheet should carry repository-mappable fields (such as BioSample identifiers) from day one.

Modern object-storage architectures change what is practical here. The Dementias Platform UK Trusted Research Environment implemented a MinIO-based object storage architecture with custom metadata tagging to enable efficient, privacy-preserving access to harmonized genomic data across 15 cohorts, embedded in a Five Safes governance model. The transferable idea for a grant plan: attach metadata as tags on the storage objects themselves, so access control and cohort discovery can be driven by metadata rather than by manual curation. If your institution operates a trusted research environment, describe it in the Access element and reference its governance model by name.

Repositories, Submission, and Primary Versus Secondary Data

Name the repository in the plan and justify the fit. For sequence data, the International Nucleotide Sequence Database Collaboration archives are the default public route, and domain-specific or controlled-access repositories serve specialist and human data respectively [6].

Handle primary and secondary data explicitly. The NIA review team's first-year lessons highlight that grantees struggled to distinguish primary data (generated by the project) from secondary data (reused from other sources), and that plans should state provenance, permissions, and metadata obligations for each category separately [3]. A practical formulation for your Data Type element:

Primary data: 96 RNA-seq libraries generated under this award.
Metadata obligations: sample sheet, data dictionary, submission to
[repository] at publication.
Secondary data: none, or [named source dataset, its access terms,
and the metadata fields we will preserve alongside it].

If your project uses AI-based analysis of genomic or imaging data, add two metadata commitments. A systematic review of data stewardship in AI-based genomics and automated microscopy found that data governance, quality management, access control, traceability, and curation frameworks are the recurring weak points, and that these vast datasets require deliberate stewardship to maintain integrity, privacy, and accessibility [8]. Concretely: record model versions, training data provenance, and preprocessing parameters in your analysis metadata, because traceability is the axis that fails first.

The Data Dictionary: Your Highest-Leverage Document

A data dictionary is a table defining every field in every deliverable: name, type, units, allowed values, and meaning. Write it once, keep it under version control, and treat it as a deliverable in its own right. The practice is standard in research data management, where metadata use is understood as the mechanism that makes research data findable and interpretable across projects [9].

A dictionary entry pattern that works:

Field:            read_length
Type:             string, pattern "2xNNN"
Allowed values:   2x75, 2x150, 2x250
Definition:       Paired-end read lengths requested from the platform,
                  in base pairs per read.
Source of truth:  Sequencing service quote dated 2026-02-10.
Missing value:    not permitted

Keep the dictionary in the same repository as the validation script, so schema and enforcement never drift apart. DataPLAN's design insight applies here: pre-written, standardized responses and field definitions reduce the cost of doing the right thing, which is why generator tools pair a questionnaire with standardized content rather than leaving each project to write prose from scratch [5].

Roles, Oversight, and Turnover

The Oversight element asks who does what. Assign metadata tasks to named roles, not to whoever is available:

1. Sample sheet custodian. Maintains the master sample sheet, applies the naming convention, mint sample identifiers.
2. Validation owner. Runs the validation script at defined checkpoints and archives the output.
3. Data dictionary maintainer. Approves field definitions and allowed values.
4. Submission lead. Prepares repository submissions and confirms accession numbers are recorded back into the sample sheet.

Then make the knowledge survive people. Mannheimer's interviews found PIs already manage data to prevent loss and to continue smoothly through personnel turnover. Extend that instinct to metadata: put the dictionary, the template, and the validation script in a version-controlled repository, and put a metadata walkthrough in the onboarding checklist for every new technician, student, or postdoc. A 30-minute onboarding session covering the sample sheet and dictionary is a concrete, reviewable commitment for the Oversight element. Libraries and institutional data services frequently support exactly this kind of metadata consulting and repository selection, so name your institution's support unit if one exists.

Access, Reuse, and Licenses for Metadata

State a license for the metadata explicitly. Metadata is generally low-risk to share because it describes rather than embodies sensitive content, but that logic breaks down for small-cohort human genomics, where combinations of fields (rare disease, small region, specific age) can be identifying. For human data, your plan should say which metadata fields are shared openly, which are shared only through a controlled-access mechanism, and why. The trusted research environment pattern, where metadata matrices support cohort discovery without exposing record-level data, is one published model for this. For the reuse element, name the license for data and metadata separately and state any consent limitations recorded in the consent metadata field itself.

Common Mistakes and Limitations

• Promising standards you do not use. Writing "we will use community standards" and then generating ad hoc spreadsheets is the most common reviewer complaint pattern in DMS assessments [3][4]. Name the standard, then actually map your fields to it, or state the deviation and the reason.
• Capturing metadata after the fact. Metadata reconstructed from memory months later is unreliable. Build capture into the wet-lab workflow, at the bench or in the laboratory information system, on the day of collection.
• Free text where controlled values belong. "Batch 1," "batch_1," and "run 1" will not join. Enforce allowed values in the validation script, not by vigilance.
• No missing-value convention. Blank cells are ambiguous. Define codes for "not recorded" and "not applicable" and validate against them.
• Forgetting the metadata for derived data. VCF headers, count matrix column definitions, and analysis provenance are metadata too. Your Data Type element should inventory derived products and their metadata, not just raw reads.
• One disk, no second copy. The most common real-world failure. State the backup schedule and location in writing, and verify checksums after every transfer.
• Treating the plan as a one-time document. The NIH model treats the approved plan as a compliance baseline for the life of the award [3]. Revisit the plan when the data scope changes, and document what changed.
• Assuming a general template covers genomics. General DMP templates help with structure but do not carry genomics-specific fields. Domain-specific generators exist for plant science grant schemes and can be adapted, and the same principle applies everywhere: use a template built for your data type where you can [5].
• A limitation to state honestly. No metadata standard covers every clinical or ecological variable, so nearly every genomics project maintains a project-specific data dictionary alongside the community standard. Say so in the plan. Reviewers read candor as competence.

Frequently Asked Questions

What is a metadata management plan for a genomics grant?

It is the section of your data management plan that specifies exactly which descriptive fields you will record about samples, experiments, and analyses, which metadata standards those fields map to, how the fields are validated, and where the metadata will be stored and shared alongside the data.

Does the NIH Data Management and Sharing Policy require metadata documentation?

Metadata falls under the Standards element of the required six-element plan, which also covers Data Type, Tools and Code, Preservation and Access timelines, Access and Reuse Considerations, and Oversight. The policy requires you to describe the standards you will apply, and review experience shows reviewers look for named, specific standards rather than general promises [3].

What metadata standard should I use for sequencing data?

Use MIxS-consistent fields for sample-level context, ISA-Tab or MINSEQE for experiment-level structure, and DataCite or Dublin Core metadata at the repository for the released dataset. Match one standard per layer of your data rather than forcing one standard to cover everything.

How much storage should I budget for a genomics project?

Compute from bases and bytes per base. For example, 50 million paired-end 150 bp reads per sample is roughly 4.5 GB of compressed FASTQ per sample at about 0.3 bytes per base, so a 96-sample project with alignments needs roughly 1 TB of working storage and a total request near 3 TB including backup and archive copies.

Where should I deposit my sequencing data?

Name a repository in the plan and justify the fit. Public sequence data typically goes to the International Nucleotide Sequence Database Collaboration archives, while human genomic data generally requires a controlled-access mechanism, and specialist communities often have domain repositories that better support their metadata [3][6].

What is the difference between a data management plan and a metadata management plan?

The data management plan covers the whole data lifecycle, including collection, storage, sharing, preservation, and oversight. The metadata management plan is the detailed subset that specifies fields, standards, vocabularies, validation, and persistence of descriptive information. You write it as a subsection, not a separate application document.

Do I need controlled-access arrangements for human genomics metadata?

If metadata fields can identify individuals, alone or in combination, restrict them. Describe in your plan which fields are shared openly, which are shared through a controlled-access pathway, and how that pathway works. Trusted research environments that use metadata-driven access controls are one published approach.

Who on my team should be responsible for metadata?

Assign metadata tasks to named roles, typically a sample sheet custodian, a validation owner, a data dictionary maintainer, and a submission lead, and put a metadata walkthrough in onboarding for every new team member. Research on grant-funded practice shows metadata knowledge must live in systems and documents rather than in individual memory to survive turnover.

Sources

1. Toward a Better Data Management Plan: The Impact of DMPs on Grant Funded Research Practices
2. AgBioData consortium recommendations for sustainable genomics and genetics databases for agriculture
3. CREATING A SUCCESSFUL DATA PLAN: NIA BEHAVIORAL AND SOCIAL AGING RESEARCH DMS REVIEW EXPERIENCE
4. 386 Developing an assessment tool for NIH data management and sharing plans to understand current data practices and needs
5. DataPLAN: a web-based data management plan generator for the plant sciences
6. eDNAqua-Plan-Standardisation Overview for eDNA Sequencing of Aquatic Organisms and the Downstream Data Ecosystem
7. Preserving Research Grant Data: Building an OAIS-Compliant Open Archive
8. Data stewardship and curation practices in AI-based genomics and automated microscopy image analysis for high-throughput screening studies: promoting robust and ethical AI applications
9. Metadata use in research data management