Data Management Plan: Check Commitments Before Submission

A data management plan explains what a study will do with its research outputs: how they will be documented, protected, preserved, and shared. A useful plan connects those promises to the actual data, people, and services involved.

Suppose a draft says, “We will share cleaned interview data.” That sentence leaves several choices open. Which outputs can be shared under the approved permissions? Which archive will accept them? Who will prepare the files and check the release? Record those gaps beside the draft passage before polishing the prose.

What a data management plan should settle

The plan is a record of planned actions. It helps a reviewer understand whether the plans fit the study. It also gives the research team a record to work from when collection, analysis, and publication begin.

Do not confuse a good description with a working plan. Naming an archive does not show that it accepts your file types or access limits. Naming a team member does not show that they have time, funding, or the authority to release data.

Check those claims with the people and services responsible. The NSF guidance helps frame this review.

Your study scope helps set the output boundaries. A plan may cover more than a spreadsheet. Research outputs can include code, images, physical samples, recordings, file notes, or models. Name the objects your project expects to produce before writing one generic paragraph about “the data.” NSF's current ENG guide makes this study-specific scope clear.

Start with the governing guidance

Gather the call for proposals, current funder policy, local rules, and any archive guidance that applies to the planned outputs. Record their dates and versions in a research log.

Resolve conflicts with the responsible research office or program contact rather than choosing whichever template is easiest to fill.

Submission details can change while older examples remain online. NSF engineering guidance points to the Research.gov plan tool introduced in April 2026. NIH's current writing guidance requires its 2026 format. Check the rules for your grant submission and award; this article's review note is not a substitute for that format.

University guides can help turn rules into questions. UW Madison's writing guide offers practical prompts and flags the format changes. Use these prompts to improve clarity, while using the funder's current requirements to decide what is needed. Place the plan within the wider research proposal outline.

Turn broad promises into specific commitments

Start with a short inventory. For each output, write its expected type, rough scale, format, and origin. Distinguish raw files from processed files and file notes. If the exact scale is unknown, state the assumption and when the team will revisit it.

Then describe the plans that make each promise possible:

• File notes: name the codebook, README, metadata standard, or process record that explains the files.
• Working storage: name the institution-approved service and who manages access, backups, and restoration checks.
• Sharing: describe the planned audience and access route, along with limits that need an approved rationale.
• Long-term storage: name the planned archive and the needed service policy.
• Role: name who prepares, checks, deposits, and keeps the outputs, including a handover if that person leaves.

The NSF guidance on data products and accountability helps make the roles specific. These are review questions, not universal funder fields. Map them to the current grant submission rules. NIH guidance on sharing limits explains why limits need a reason. Avoid inventing a retention period or promising open release merely because it sounds transparent.

File notes also affect reuse. A deposit may be technically downloadable yet difficult to interpret. Once the plan names its file notes, use the FAIR principles to examine what another researcher would need to find and reuse the outputs.

Work through a draft with unresolved gaps

Consider a fictional interview study. The team expects text records, a codebook, and a report. Its draft mentions a shared drive, cleaned text records, and a future archive, but has not checked the access route or an archive.

The table below shows a review note. Its passages are invented for teaching; the choices are questions for the study team, not findings about a real grant.

Table 1: Each row needs a source location and a status in the working note. Useful statuses include documented, unclear, conflicting, and awaiting choice. “Unclear” means the supplied text does not settle the question. It does not prove that the team lacks a plan elsewhere.

A reviewer may find a clash rather than a blank. For example, the plan promises public release of interview records while the approved consent form describes access with checks. Keep both passages in the note and refer the choice to the right local owner. Do not quietly rewrite one promise to make the files appear consistent.

A research paper appendix can hold supporting method text later, but the appendix does not replace the approved plan or archive file notes. Keep those file roles distinct.

Check plan passages in Atlas

Use Atlas for a bounded file review after checking that the supplied text is permitted for this use. Add the current guidance, the draft plan, and a suitable study description to one project. Keep private raw data in its approved research environment.

Open a chat and use @ to select the files. Ask a focused question:

Check the draft plan with the named guidance. For each requirement, cite the guidance passage and the needed plan passage. Mark missing wording, ambiguous promises, and conflicts separately. Do not infer a plan that the files do not describe.

Atlas can compare the selected files, but the answer is a candidate review. Inspect it before relying on it. Open each citation, check the expected file, and read enough surrounding text to check the requirement and the plan's wording.

The screenshot shows the interface pattern: a PDF on the left and a cited answer on the right. Its paper concerns AI research, not the fictional interview study.

The useful action here is opening the text behind an answer; the image does not demonstrate compliance or a tested DMP review.

Correct claims that exceed the source. If the answer says “no long-term storage plan,” but the draft names an archive without a date, change the note to “archive named; timing open.” If the cited location is unclear or missing, find the named file and read it yourself.

Save a checked requirement-plan-passage-gap note with the guidance version, file locations, review date, choice owner, and remaining question. Preserve open entries instead of treating a polished AI response as approval.

Atlas does not choose storage permissions, assess consent legality, or guarantee a complete review.

Resolve decisions and maintain the plan

Take the checked note to the people who can settle its gaps. Ask data support about storage and archives, the study team about formats and file notes, and the right local reviewer about limits. Update the draft only after the underlying plan is agreed.

Review costs as well as promises. Preparing file notes, controlling access, and depositing outputs can require staff time or service charges. Tie the planned work to the project budget and named roles rather than assuming that archiving happens without effort.

Keep a revision record when data types, personnel, archives, or sharing plans change. The University of Oregon guidance treats the plan as a file that evolves with the research. Check whether the funder needs approval for an update before changing an awarded commitment.

Start with one output

Start with one output in your draft. Trace its handling promise to a passage, name the person who owns it, and record the next open choice. That gives the team a clear review task and a reason to revisit the plan when the study changes.

Before you close a row, ask its owner to show how the promise will work. For a shared drive, check who can read and change a file; for an archive, check what it accepts and who will make the deposit. Keep the row open if the team cannot yet show this.