NSF Computational and Data-Enabled Science and Engineering (CDS&E) Meta-Program for 2026–2027

NSF Computational and Data-Enabled Science and Engineering (CDS&E) Meta-Program for 2026–2027

The NSF CDS&E page is not a standalone grant with a single, fixed award amount. It is a cross-program umbrella that routes proposals to one of the program’s participating “related programs” when your project’s core value is computational and data-enabled science and engineering. In practical terms, it means this is a way to place a high-computation, high-data proposal into the NSF system where standard disciplinary pathways may not give enough room to emphasise the computing/data innovation itself.

If you are trying to move from an idea to funded work and your contribution is mostly algorithmic, simulation-driven, or data-intensive in a way that changes what is scientifically possible, CDS&E can be the right route. If your project is standard field work with minor computational support, CDS&E is usually not the right fit.

Key details at a glance

What CDS&E actually is (and what it is not)

Most applicants confuse this one with one direct NSF solicitation that accepts everything. It is the opposite. The page describes CDS&E as a meta-program that supports projects that use computational and data science in ways that exceed what individual programs typically expect.

The page explicitly says three things that define it:

• It is for work where computation and data are central, not incidental.
• It is intentionally cross-disciplinary and cross-directorate.
• It is a routing mechanism: your proposal still lands in a related program context.

This distinction matters. A proposal that uses computation only as background analytics is likely to be pulled back into a regular disciplinary program (or rejected from CDS&E review if it is not sufficiently distinctive). NSF can also treat your submission as non-responsive and move it accordingly.

In plain terms: CDS&E is for projects that can prove they are doing something materially different because of computation and data science. Examples include:

• A design that changes how experiments are combined with simulation workflows.
• A software-enabled method enabling new scale, speed, or accuracy.
• A cross-domain data integration strategy that creates measurable new discovery capacity.
• A proposed computational methodology that is required for the scientific question, not decorative.

Why this is suitable for 2026–2027 planning

The CDS&E page is not just a legacy document. It has explicit annual-cycle language. The listed submission windows include recurring dates “annually thereafter.” For teams planning around 2026/2027, that means your planning window is stable and predictable.

The reason teams use it in 2026–2027 is not that every division is always open every week, but that this page gives you a repeatable framework:

1. Build proposal quality with a high-computation and data science component.
2. Confirm the relevant division’s submission window.
3. Ensure alignment with the related program’s scope.
4. Include a proposal title and narrative structure that make CDS&E intent explicit.

The page’s due-date table includes windows for:

• ENG/CBET (Sept 1–15 annually)
• ENG/CMMI (Sept 1–15 annually)
• MPS chemical programs (Sept 1–30 annually)
• MPS materials (Oct 15 annually)
• MPS astronomy ATI-like windows (Oct 1–Nov 15 annually)
• MPS plasma programs (third Monday in November annually)
• MPS chemistry life/computational programs (full proposals accepted anytime)

If you are still preparing in late spring or early summer, you can use this as a realistic planning engine for the next annual open window, rather than waiting for a one-time “new” call.

Who this is for

CDS&E works best for teams that can describe impact at two levels:

• A strong science result to deliver.
• A substantive technical mechanism (computation or data infrastructure) that explains why the result is only possible now.

This is not just useful for pure computer science proposals. NSF explicitly says proposals may involve multiple disciplines and cut across divisions if they address major problems with computational depth. In review terms, this helps teams from:

• Engineering (for transport, materials, manufacturing workflows)
• Physics and chemistry (for simulation-heavy discovery pipelines)
• Mathematical sciences (for computational methods, modelling ecosystems)
• Astronomy/observational data science (for high-volume inference)
• Any discipline where theory, experiment, and observation connect through data platforms

What teams often miss: you do not need to be a core “CS-only” lab. You need to demonstrate that computational and data approaches are essential. If the same scientific question can be solved without building a computational advance, CDS&E is usually a weaker choice.

Eligibility and fit checks before you start

The program page does not present a simple checklist like some fellowships do. You need to infer fit from explicit rules:

• Must submit in accordance with NSF PAPPG requirements.
• Must align with one of the related program windows and division context.
• Must include a significant computational/data-science contribution beyond standard methods.
• Must title the proposal with CDS&E: if requesting treatment under this context.
• Must avoid non-responsive scope (or the proposal may be transferred or returned).

These are practical gating points because CDS&E is a “meta” channel, not a replacement for normal programmatic review. Think of it as a pre-coding layer you add to your NSF routing, not a bypass.

Use this quick fit test:

• Is computational work merely support, or is it core?
• Is there a measurable method that is novel to the project?
• Does the method create a stronger scientific claim than any routine pipeline would?
• Do related program objectives match your scientific question?
• Can the team provide a review-ready explanation of this computational advantage in plain language and in technical detail?

If most answers are “yes,” CDS&E is likely appropriate.

Application process (what to do, in sequence)

Because CDS&E is not a direct single-form portal, your process is two-layer:

1. Build the proposal as a high-quality NSF-style submission.
2. Use CDS&E-specific routing logic to place it in the right related program window.

A working sequence for 2026/2027 looks like this:

1) Pick the right division and confirm window

You should map your project to one or more of the listed divisions. You can use the CDS&E windows as a first filter, then verify detailed related-program guides for specifics.

2) Confirm submission system requirements via related program pages

The CDS&E page lists broad windows but not all operational forms. In practice, the related program handles many submission mechanics. Before final submission, confirm:

• Which NSF solicitation number applies in your target program.
• Whether there are PI-only or proposal-type restrictions.
• Whether your PI/co-PI limits and institution constraints are standard or special.

3) Build your proposal structure around a clear computational promise

At this stage, avoid generic “data-driven” language. You need a clear narrative:

• Why the computational/data component is indispensable.
• What new capability it creates.
• What the expected scientific output is.
• Why existing programs may not evaluate this adequately without CDS&E routing.

4) Final compliance sweep

Checklist at the end:

• Title starts with CDS&E:.
• Proposal is routed through the target program’s active window.
• PAPPG compliance basics are complete.
• Related-program-specific requirements are included.
• Eligibility and scope alignment is defensible in one paragraph.

5) Submit and track portal confirmation

Track your confirmation path in your own team log, including date, related division program, and whether the proposal was transferred.

Deadlines: annual windows, which one applies to you

There are no single universal dates and no one-time grant-close date. The page gives a division/dividend structure with annual recurring windows. Use it as a cycle map, not a single line.

For planning, the page includes examples like:

• ENG/CBET: Sept 1–16 in initial publication; recurring Sept 1–15.
• ENG/CMMI: same Sept window pattern.
• MPS chemistry track: Sept 1–30.
• MPS materials: Oct 15.
• MPS astronomy ATI: Oct 1–Nov 15.
• MPS mathematical sciences: Oct 15–Oct 31.
• MPS plasma physics: Third Monday in November (annual).
• MPS chemistry life processes/computational methods: full proposals accepted anytime.

For a real 2026/2027 playbook, treat this as a matrix:

• If you need a fixed deadline rhythm, target division-specific annual windows.
• If your proposal naturally lands in chemistry/computational methods-like tracks, the anytime route is strategically valuable but still requires all programmatic compliance.

Required materials and proposal content priorities

The CDS&E page itself does not publish a full generic attachments checklist. You should therefore assume the related program’s solicitation controls attachments and use that program’s requirements. Still, your CDS&E narrative can only be accepted if it answers specific questions in one place:

• What is the computational or data problem?
• Why does the solution need new computational design rather than routine tools?
• How does this produce progress across theory, computing, experiment, and observation?
• What are the proof points (results plan, data sources, benchmarks, validation steps)?

Reviewers using CDS&E logic typically expect the proposal to demonstrate both:

• Technical novelty in data methods.
• Scientific relevance in real outputs (not just technical elegance).

It is easy to fail here by overbuilding architecture details and underbuilding scientific claim clarity. Avoid that imbalance.

Common mistakes I see in CDS&E-ready applications

1) Treating CDS&E as a generic “submit to everyone” route

If your project does not clearly fit a related program, you increase the risk of transfer or return.

2) Missing the title signal

The page explicitly says requests for consideration should begin with “CDS&E:”. If you omit it, front-line screening may not treat it as intended.

3) Misunderstanding scope

Some teams submit incremental data analysis support. That is often better as a normal disciplinary NSF proposal.

4) Ignoring recurring windows

Some divisions operate on annual cycles; missing one can mean a full year delay. Build your workflow backwards from the earliest eligible annual window.

5) Over-reliance on pilot software claims without scientific grounding

You cannot justify CDS&E by toolbuilding alone. The method must tie to scientific discovery.

6) Assuming there is one fixed amount

This is not a single budgeted program in the meta-page sense. Amounts are program-specific. Teams that treat it like one flat grant with fixed caps often submit weak budget narratives.

Strategic preparation checklist

If you are serious about winning in this category, do this now:

1. Draft two-page computational significance brief.
2. Map your idea to one related division and one proposal track.
3. Confirm target window in 2026 or 2027.
4. Build a feasibility and validation plan that proves your computing component is central.
5. Align team skills and letters around computational leadership.
6. Contact program officers only after internal alignment, so questions are precise.

This category is strongest for teams that can talk both science and systems clearly.

How this compares with similar routes

CDS&E vs normal single-program NSF submission

A normal NSF pathway may be simpler if your proposal is already a straightforward disciplinary project. CDS&E is for cases where computation/data is the argument, not the garnish.

CDS&E vs CSSI (Cyberinfrastructure for Sustained Scientific Innovation)

The CDS&E page specifically points mature implementation of existing methods into robust cyberinfrastructure to CSSI instead. So if your effort is mostly deployment of known methods, CSSI may be a more direct fit.

CDS&E vs recurring disciplinary programs

Most teams should start by identifying where their scientific problem belongs and then ask whether that problem has a computational leap that changes the expected review narrative. If yes, CDS&E is a strong argument for differentiation.

FAQs (practical)

Is CDS&E itself a one-time grant or multiple grants?

It is a meta-program and routing mechanism. Funding outcomes are managed through related programs and their respective mechanisms.

Is the posting current for 2027?

The page lists recurring annual windows after initial publication, including recurring cycles into future years. Treat this as relevant for 2026 and 2027 planning.

Is there a fixed amount?

The CDS&E page itself does not provide a single consolidated budget figure. Budget shape comes from the specific related solicitation you submit through.

Can I submit a proposal if my team’s computational part is already established?

If it is the core of your contribution and still enables a novel research step, yes. If it is an incremental tooling improvement, you should evaluate other paths first.

Do supplements count?

The page explicitly says supplement requests to existing awards may also be considered, which is unusual for many calls and can matter for teams already funded by NSF with a strong computational upgrade story.

Official links

• Official CDS&E page: https://www.nsf.gov/funding/opportunities/cdse-computational-data-enabled-science-engineering
• NSF related program resources and division pages linked from the CDS&E page
• NSF PAPPG and award terms linked from the same official page for compliance

CDS&E can be a powerful route when used correctly because it lets you place computational ambition at the center of proposal review. It is less useful for teams that mistake scale for novelty. In 2026–2027, strong CDS&E proposals are the ones that can explain, in concrete terms, what becomes possible only because of the computational and data-science approach.