NSF 26-509: Integrated Data Systems & Services (IDSS) Cyberinfrastructure Grant

NSF 26-509: Integrated Data Systems & Services (IDSS) Cyberinfrastructure Grant

The U.S. National Science Foundation’s NSF 26-509 solicitation funds national-scale data systems and services for open, data-intensive, and artificial-intelligence-driven science, engineering, research, innovation, and education. NSF lists the solicitation as active and identifies it as the current version. It was posted on April 15, 2026, replacing NSF 25-544.

The first deadline in this solicitation has passed: July 28, 2026 was the due date for Category I and Category III submissions. The next listed deadline is July 27, 2027 for Category II submissions, due by 5 p.m. in the submitting organization’s local time. NSF also states that the relevant category deadlines recur on the fourth Tuesday in July annually thereafter. This page therefore uses July 27, 2027 as its next upcoming deadline. It is not a rolling opportunity, and applicants should not treat the passed Category I/III date as still open.

Key details at a glance

Why this opportunity is relevant now

The NSF explicitly frames IDSS as a program for operations-level, national-scale data systems and services that enable open, data-intensive, and AI-driven science and engineering. In plain terms, this means NSF is not asking for one-off prototypes that end with a publication; it is asking for infrastructure that can run and scale over years.

That distinction matters. NSF created this line of investment because many institutions can build impressive tools, but far fewer can operate resilient infrastructure across communities with predictable access, performance, and governance. If your organization already has a proven pilot or regional platform and can document reproducible demand across user communities, IDSS is often a better match than more general NSF research awards.

The timing now needs to be read by category. The July 28, 2026 window for Category I and Category III has passed, while NSF lists July 27, 2027 for Category II. The solicitation remains active, so a team with an established smaller-scale or pilot system can use the open planning time to assemble performance evidence and prepare for the Category II window. NSF’s fourth-Tuesday-in-July recurrence is useful for longer-range planning, but it does not make the passed window rolling or permit late submissions.

What the solicitation is actually funding

The program is built on three categories with materially different scope, scale, and likely workload:

Category I: Development, deployment, and operation at national scale

Category I supports novel national-scale data systems and services, with budgets between $10 million and $30 million for up to five years, and explicitly described as potentially renewable. These proposals are expected to either create new capabilities or combine existing ones into scalable systems that support broad user communities.

The expectation is national impact, not incremental local upgrade. Proposals should describe:

• Clear national-level use cases for the system,
• how performance and operations are designed for broad, multi-disciplinary users,
• what the project contributes to interoperability with existing infrastructure,
• evidence that the proposed system would not just be useful, but necessary.

Category II: Transitioning operational regional systems to national scale

Category II targets projects that already have proven smaller-scale or pilot systems and are ready to expand toward national operations. The solicitation caps these at up to $9 million for up to three years, with potential renewals possible.

This is a strong fit for organizations running proven observatory-like services, domain-specific data operations, or distributed infrastructure components that have users but need reliability, operational maturity, and broader federation.

A key nuance in Category II is that NSF expects existing strong use cases and measurable user demand before scaling. In review, teams that can show real throughput, existing adoption, and clear pathways for scaling generally fare better than those proposing only concept-level architecture.

Category III: Planning grants

Category III is explicitly for planning future development or transition proposals and has a budget cap of $500,000 for up to two years. These grants are not for technical implementation. They are for planning: evidence mapping, engagement, requirement development, and concrete readiness activities.

NSF says Category III proposals cannot include technical development or operations activities, so teams should avoid budgeting or planning for software engineering outputs as full deliverables at this stage. This category is useful for institutions that need an NSF-backed pre-award phase to make a future Category I or II proposal coherent.

One practical implication of the three-track structure

Many teams incorrectly try to blend all stages into one proposal and lose clarity. Because the funding structures are different, your first decision should be category-first. For new teams without an existing national-scale operation, Category III can de-risk the process and convert a strategic concept into an implementation-ready plan. For mature teams already running reliable systems, Category II is often a clearer route to growth.

Eligibility and compliance: the constraints that eliminate weak entries

The solicitation is precise about who can submit and how often:

• Proposers must be U.S. institutions of higher education (2- or 4-year, including community colleges), U.S. non-profit non-academic research organizations, or certain U.S. federal agencies/FFRDCs subject to PAPPG limitations.
• There are no explicit PI-level status barriers like citizenship filters in the short eligibility section we have, but all proposals still must comply with NSF rules in the full solicitation.
• Each organization may submit only one lead proposal for Category I and one for Category II per deadline.
• An individual may not appear as PI/co-PI/senior personnel on more than one lead proposal across Categories I and II for the same deadline.

This means teams should create a clear internal governance process before submission:

1. Decide which PI will front which category.
2. Decide whether a second organization proposal can be a subaward instead of a separate lead.
3. Freeze roles to prevent a PI from overlapping categories.
4. Verify whether your institution has internal policies for single-lead limits on federal grant submissions.

The solicitation is stricter than a normal multi-institution collaboration: separate collaborative research proposals are not permitted and will be returned without review. A collaborative effort must be submitted as one proposal requesting one award, with partner organizations participating through subawards administered by the proposing organization. Prepare the consortium structure and accountability chain accordingly.

Another important compliance item: the page lists no voluntary committed cost sharing. If your internal finance team assumes matching funds are expected, that assumption is wrong and can weaken application alignment.

Review expectations and what distinguishes a strong IDSS concept

The NSF evaluation is based on the National Science Board criteria plus additional solicitation-specific criteria. The program text repeatedly emphasizes transdisciplinary impact and broad applicability.

In practical review terms, strong proposals usually satisfy all of the following:

• They avoid discipline-only outcomes and articulate broader benefit across multiple domains.
• They show explicit data lifecycle understanding (acquisition, transfer, analysis, sharing, curation, and reuse where relevant).
• They show how their design contributes to an integrated and federated infrastructure, not a standalone silo.
• They include an operations plan with milestones and performance targets that can be measured post-award.
• They provide a user onboarding and support design that matches national-scale expectations.
• They plan for open science principles through reliable interoperability with instrumentation, repositories, and compute layers.

The line about open software is especially strong: any software developed under IDSS must be made publicly available under an open-source license. Proposals with uncertain licensing plans can be flagged early.

Reviewers also tend to penalize projects that are “continuations with minimal changes.” This is a frequent failure mode: teams reuse existing infrastructure branding with small modifications and frame it as a national buildout. The call requires substantial change and new national-level value, especially for Category I. Category II can use existing roots, but still needs clear evidence of scalability and broad expansion.

Application process and submission workflow

The solicitation states full proposals only are required; there is no required letter of intent or preliminary submission stage listed for this cycle. A practical workflow looks like this:

1. Select a category (I, II, or III) based on maturity and deliverables.
2. Confirm internal eligibility (lead proposer, PI role, and organization limit constraints).
3. Draft a project narrative that maps tightly to category-specific expectations.
4. Prepare the title to include the exact category prefix: “Category I:”, “Category II:”, or “Category III:” as required by the Cover Sheet instructions.
5. Build a proposal structure aligned with required sections:
   • Vision, goals, and required use cases,
   • Project definition and architecture,
   • Concept of Operations,
   • Performance objectives and measures,
   • Project management,
   • Budget estimation.
6. Decide submission channel:
   • Research.gov route for applications prepared under NSF PAPPG,
   • Grants.gov route under NSF Grants.gov guidance when used.
7. Assemble the required supporting material. Category I and Category II proposals need a supplementary detailed cost estimate covering planned activities and costs over the award. All categories require a current list of project personnel and partner organizations. Letters of collaboration are optional when they document a significant arrangement; letters of support or endorsement are not acceptable.
8. Submit before 5 p.m. in the submitting organization’s local time on the applicable deadline and preserve the final proposal package for institutional records.

The solicitation does not accept separate collaborative research submissions from multiple organizations. Use one proposal and one requested award, with partner organizations included through subawards administered by the proposing organization. This single-award structure must be reflected in roles, reporting lines, budgets, and accountability.

For category choice, think in terms of reviewer burden:

• Category I demands clear national-scale architecture and five-year operating readiness arguments.
• Category II needs explicit evidence that existing systems already work and can scale to national operations.
• Category III should present a disciplined readiness plan and not promise implementation.

If you miss that distinction, your proposal reads as either too speculative (if you propose execution in Category III) or too conservative (if you submit Category II with no scale evidence).

Preparation strategy for a stronger application

To increase chances of competitiveness, teams should treat IDSS applications as infrastructure policy and operations documents, not just technical specifications.

Start with evidence of broad impact

The opportunity is not meant for projects serving one lab, one project, or one narrow customer class. Build a concise argument for cross-disciplinary uptake. If you say “this will help X,” support with quantified adoption signals and examples of communities that will use the infrastructure.

Include:

• usage data from existing pilots,
• expected growth curves,
• classes of users across domains,
• integration points with other national infrastructure.

Show data lifecycle clarity

The solicitation values end-to-end design. Proposals should identify which lifecycle stages they target and why those stages are sufficient for user outcomes. Even if the project touches only selected stages, the proposal should explicitly explain the boundary and how users hand off work across the pipeline.

Design for operations early

For Categories I and II, operations are central. Reviewers will expect a first-year operations readiness path. Define:

• performance targets,
• staffing model for sustained operations,
• user support structure,
• training and onboarding strategy,
• upgrade and refresh planning.

Do not reduce this section to infrastructure architecture alone. Many proposals fail at this stage because they under-specify support and monitoring mechanisms.

Build measurable criteria

Include measurable goals and targets: latency, throughput, access availability, user growth, integration success, and service reliability metrics. NSF expects project success to be judged with concrete evidence.

Align with open, shared standards

Because the page emphasizes openness and broad reuse, show clearly how your systems interface with existing computing resources, repositories, and facilities without duplicating everything. Position your contribution as a connective layer and a scalable enhancement.

Prepare the institutional package and roles

Since limits are strict on number of submissions and PI overlap, set a pre-submission institutional rulebook:

• Which unit submits Category I vs II,
• who serves as PI and co-PIs,
• what each partner becomes through subaward,
• legal and budget responsibilities for open-source licensing.

Budget realism

Award sizes are large and diverse across categories. Build a realistic staffing and operations plan with explicit non-renewable planning constraints for Category III and potential renewal logic for Categories I and II. Even though the solicitation allows renewals, they depend on performance and review outcomes. Avoid assuming continuation.

Common mistakes that can sink a proposal

1. Submitting category-inappropriate scope

Applications that mix long-term implementation and planning activities in Category III often fail because this category cannot include technical implementation.

2. Trying for international funding through ineligible partner structures

The solicitation indicates the NSF channel does not permit awards to include funding for international partners. Projects may still engage global users in some form, but funding structure must respect NSF rules.

3. Ignoring internal limit rules

The one-lead-per-category and one-PI-across-category limits are strict. Noncompliance can trigger returns without review.

4. Using old cost-sharing assumptions

The page explicitly prohibits voluntary committed cost sharing. Writing a budget assuming matching funds as a mandatory condition can create a weak message and possible compliance issues.

5. Underestimating operations planning

Some teams focus on architecture and omit detailed operational rollout and support. IDSS explicitly funds operational systems; operations quality is part of scientific value in this solicitation.

6. Narrowing to one discipline

The solicitation is explicit that primarily discipline-bound projects are not supported. If your use case is too narrow, it may be rejected early as out of scope.

7. Treating this as a software product pitch

The page’s requirement for national-scale service readiness, interoperability, and open-source conditions favors infrastructure projects with durable mission and governance, not just a product launch.

Official timeline interpretation and planning recommendation

NSF posted this solicitation on April 15, 2026 and currently labels it an active funding opportunity. The July 28, 2026 deadline for Category I and Category III has passed. The next listed deadline is July 27, 2027 for Category II, followed by the fourth Tuesday in July annually thereafter for the applicable category deadlines.

For a Category II team, the preparation sequence should be evidence-first:

• Confirm that the existing pilot, regional system, or smaller-scale service has real users and documented performance.
• Select a lead organization and settle the single-proposal, single-award structure before assigning subawards.
• Gather quantitative demand, user, reliability, throughput, support, and adoption information for the existing service.
• Map the proposed national operating model to the required project description sections and define measures for performance, user satisfaction, reliability, and growth.
• Complete the institutional review of eligibility, the organization limit, the cross-category personnel limit, the title prefix, and the submission route.
• Submit the full proposal by July 27, 2027 at 5 p.m. in the submitting organization’s local time.

Teams considering a future Category I or Category III submission should use the annual fourth-Tuesday schedule as planning guidance and verify the applicable date on the official NSF page before submitting. A passed date is not a rolling intake, and this solicitation does not provide a basis for late applications.

Frequently asked questions (based on the published solicitation)

Is the July 28, 2026 deadline still open?

No. NSF lists July 28, 2026 as the deadline for Category I and Category III submissions, and that date has passed. The next listed deadline is July 27, 2027 for Category II submissions.

Is the program discontinued?

No. NSF marks NSF 26-509 as an active funding opportunity and says the document is the current version. The program page lists the July 27, 2027 Category II deadline and a fourth-Tuesday-in-July schedule thereafter.

Who can lead the proposal?

An eligible U.S. IHE or U.S. non-profit non-academic research organization can lead, subject to NSF rules. Federal agencies and FFRDCs have additional chapter-specific constraints.

Can we submit more than one full proposal per institution?

Not for Categories I and II per deadline as lead institution. One each across Category I and II is allowed. Category III has separate treatment.

Do we need a letter of intent?

No. Full proposals are the entry point listed for this solicitation.

Do proposals need cost matching?

No. Voluntary committed cost sharing is explicitly prohibited.

Can we include software code development in Category III?

No. Category III is planning; technical development and operational activity are not intended for this stage.

Are collaborative proposals allowed?

Separate collaborative research proposals from multiple organizations are not permitted. A collaborative effort must be submitted as one proposal requesting one award, with partner organizations participating through subawards administered by the proposing organization.

Next steps checklist

• Confirm category (I, II, III) against your current project maturity.
• Validate proposer and PI/compliance limits for your institution.
• Build a cross-disciplinary impact narrative from the first page.
• Draft a realistic operations and user service plan.
• Include performance metrics and open access/interop design.
• Confirm title prefix and submission channel.
• For Category II, submit the full proposal by July 27, 2027 at 5 p.m. in the submitting organization’s local time.

Official links

• Official NSF IDSS opportunity page (resolved): https://www.nsf.gov/funding/opportunities/idss-integrated-data-systems-services/nsf26-509/solicitation
• NSF Funding page: https://www.nsf.gov/funding
• Grants submission systems: https://www.research.gov and https://www.grants.gov
• NSF Proposal guidance: see the NSF page references to PAPPG in the solicitation.