NSF 26-7607: Energy, Power, Control, and Learning (EPCL)

NSF 26-7607: Energy, Power, Control, and Learning (EPCL)

Energy, power, transport, and resilient infrastructure are no longer isolated research topics. They are linked design problems where sensing, control, learning, optimization, and deployment constraints collide in real time. The NSF Energy, Power, Control, and Learning (EPCL) program—listed as NSF 26-7607—is a 2026 funding program for that exact convergence.

The official NSF page describes EPCL as a mechanism for fundamental research on control and learning theories and methods, designed to improve operation, performance, and reliability of systems across national infrastructure domains. It is explicitly positioned as a program that can influence the power grid, transportation, manufacturing, healthcare, and other critical sectors.

If your team is at the point where you are deciding whether to write a proposal now for 2026/2027 workflows, this is one of the few NSF programs in this range that is still clearly in a usable planning state with a public “full proposal accepted anytime” posting.

Key details at a glance

The lack of a fixed single due date and fixed award amount does not mean this is casual; it means you are competing in a rolling review style within a broad thematic umbrella, where proposal strength and internal readiness matter more than a single calendar sprint.

What this opportunity is funding

The EPCL page frames its mission around engineered systems, not one narrow technical category. The program explicitly supports:

• control systems for complex engineered environments,
• learning and adaptive methods,
• optimization under uncertainty,
• networked multi-agent systems,
• risk-aware decision design,
• and system resilience in national infrastructure.

The scope includes both conceptual and operational concerns, including electricity systems and electric vehicles, power electronics and storage, and the interaction between regulation, market structure, behavior, and energy-system operation. The program description also places emphasis on practical transfer potential: while projects are fundamental research, they should provide a clear path toward real-world influence.

That nuance is important. NSF often has very theoretical programs, and yes this one does, but this one is written to bridge theory and infrastructural systems. A project that only presents elegant math without a concrete path to infrastructure relevance likely underperforms against reviewers’ expectations for value and applicability.

The opportunities list also names partnerships as part of impact strategy, mentioning federal agencies, industry, and international groups. For teams asking “Does EPCL fund pure method development only?”, the best reading is: method development is welcome, but it should not drift into purely abstract work without a control, learning, or system-performance application pathway.

Why this is relevant for the 2026/2027 cycle

The NSF 26-7607 public page was posted in April 2026 and the current status is not closed. More importantly, the page shows “Full proposal accepted anytime,” which makes it practical for researchers and teams that are not tied to a single fixed annual cycle.

That matters for planning:

1. Teams with high-confidence ideas can begin submission prep immediately instead of waiting for a formal target date.
2. Institutions that miss one internal window are not automatically eliminated by a hard, one-shot date.
3. Applicants can stage internal review, compliance sign-off, and partner coordination while still staying in range.

For 2026/2027 planning, this gives a planning advantage if your institution has mature internal review cycles. You can keep the proposal in a “ready for finalization” state and submit once all system permissions and institutional approvals are in place.

The flip side is reviewer timing. When deadlines are rolling, your internal timing decisions should mimic hard deadlines anyway: build an internal cutoff earlier than submission date, and keep a dry-run review window.

Who this is most suitable for

Because EPCL is not a stipend or fellowship, this is aimed at teams able to run research proposals and manage federal grant administration.

Good fits typically include:

• faculty-led research groups in control, optimization, AI-enabled systems, power systems, transportation systems, robotics-enabled infrastructure, networked systems, cybersecurity for infrastructure, and data-driven system operation,
• universities and research organizations with active grants systems,
• cross-disciplinary teams where one side carries deep system modeling and another side carries testbed, deployment, or infrastructure context,
• groups that can frame a clean hypothesis, a plausible method pipeline, and measurable outcomes.

In short, EPCL is most suitable if you can explain why your math, algorithms, and implementation insight matters for real systems.

Typical institutional readiness signal

A strong EPCL applicant usually has:

• someone comfortable with NSF proposal mechanics,
• a PI who can defend both theoretical and implementation implications,
• strong internal compliance support in grant systems,
• and at least one real pathway toward validation data or operational context.

Because the program is open in a broad sense, teams can apply from different subfields. But breadth cuts both ways: proposals that overstate cross-domain relevance without technical depth usually lose.

Submission and application mechanics (what to do first)

The official submission instructions on the EPCL page should be treated as the primary source. For now, the page states that proposals are submitted in line with NSF requirements and that, for this page state, they are to be processed through Research.gov using NSF 24-1 PAPPG settings and ENG/ECCS.

Step 1: lock the proposal route and program settings

• Open the current NSF solicitation page and confirm that Research.gov route instructions are still current.
• In Research.gov, ensure you are in the correct program context and avoid “similar sounding” legacy codes.
• Confirm whether your institutional role (PI, co-PI, collaborators) requires additional internal approvals.

Because NSF pages occasionally retain older text while operational guidance shifts, always confirm the exact flow on submission day and before upload.

Step 2: convert “idea” into a reviewable proposal narrative

EPCL rewards a structure that connects theory to systems behavior:

1. Problem statement in systems terms. What controlled system fails or is inefficient now?
2. State your novelty. How do your control and learning methods advance current capability?
3. Show transfer logic. What systems, sectors, or workflows does the work influence?
4. Define evidence. What metrics prove improvement? Efficiency, robustness, response times, stability margins, operational resilience, etc.
5. Address implementation friction. If the method requires data infrastructure or operational assumptions, state those clearly.

Step 3: build a PAPPG-compliant package early

NSF grants generally require strict proposal formatting and compliance:

• clean title and narrative structure,
• compliant budget format,
• clear roles and commitments,
• and all mandatory fields completed before submission.

For a rolling program, you should complete these before final technical content. Compliance fixes at the end are expensive and often reduce quality.

Step 4: verify institutional compliance and system permissions

Before submission, confirm:

• ORCID/identity and user permissions where required,
• PI account authority in Research.gov,
• budget sign-off rules,
• attachments and formats required by the solicitation and current NSF portal behavior.

Step 5: submit before system stress windows

Even when proposals are accepted continuously, portal windows can be noisy during high-volume periods. For NSF systems this can happen around the start of major internal university grant cycles.

Set an internal hard stop at least several business days before your planned submission date.

Proposal strategy for EPCL: how to be review-ready

EPCL sits in the engineering domain where reviewers want both deep rigor and credible transfer logic. A common strategic mistake is writing only one: either pure theory without system context, or practical systems language with weak science.

A winning EPCL narrative balances both.

1) Define the control objective sharply

Use a single sentence for your objective in technical language:

• If this is about grid reliability, specify what reliability dimension changes (frequency stability, scheduling quality, fault-tolerance, etc.).
• If this is about transportation, define whether you optimize routing, load balancing, safety margins, or dispatch control.

A vague statement like “improving infrastructure resilience” is too broad unless it is immediately tied to measurable outputs.

2) Tie learning methods to uncertainty and constraints

From the EPCL description, uncertainty appears central: dynamic resource allocation and risk management under uncertainty. Successful proposals usually perform better when they do not pretend systems are clean or static. Show how the learning model handles failure events, partial observability, or changing regimes.

3) Show why your method is not just generic ML

If your approach could apply to any optimization problem, explain why this one problem requires novel control-structure thinking. NSF reviewers compare proposals in a competitive environment where many teams claim innovation. Distinction comes from mechanism quality.

4) Build a credible evidence path

Even with fundamental research framing, show your evidence strategy clearly:

• theoretical guarantees where possible,
• simulation or benchmarking plans,
• reproducibility and data handling assumptions,
• and if possible, a roadmap from model development to systems test.

5) Demonstrate critical infrastructure relevance without overclaiming

The page explicitly positions sectors like energy, healthcare, and transport as intended beneficiaries, but it also says projects should provide a clear real-world vision. “Potential relevance” is enough to motivate a proposal; “guaranteed deployment outcome” is usually not.

Frame expected influence as plausible and measurable, not guaranteed.

Required materials and practical preparation

Because the public page does not list all attachment names or exact forms in one place, your local university grants office should supplement with the exact NSF solicitation text. At minimum, keep these elements in your draft environment early:

• concise project summary with systems context,
• objectives, technical plan, and milestones,
• evidence model and metrics,
• staffing and role assignments,
• budget and resource plan,
• risk and risk-mitigation description,
• and compliance checks.

Some teams also include a short appendix for infrastructure assumptions (regulatory, operating conditions, and data governance assumptions). This is useful in EPCL because systems context can otherwise look overly abstract.

For institutions new to NSF, do not wait until the portal step to prepare submission assets. Build the package in a shared internal folder with clear version naming so the grant office can run a quick internal compliance review.

Common mistakes and practical fixes

Mistake: treating “full proposal accepted anytime” as a reason for last-minute submission

Even with rolling proposals, quality collapses under rushed submissions. Fix: set internal two-stage deadlines (internal draft, compliance pass, final submission).

Mistake: only emphasizing algorithm novelty

This program values control and learning, but it is framed around systems and infrastructure impact. Fix: pair method novelty with system-level outcome statement and validation route.

Mistake: ignoring programmatic routing details

The EPCL page contains a specific system path (NSF 24-1 under ENG/ECCS). Fix: lock this early and confirm changes to submission route before final file export.

Mistake: writing a proposal that says “critical infrastructure” but never defines stakeholders

Reviewers ask, “who benefits and how?” Fix: name explicit infrastructure contexts and define measurable pathway for transfer.

Mistake: underestimating internal approvals

A technically strong proposal can fail at the administrative stage. Fix: schedule grants-office review as a required gate before submission.

FAQ for teams evaluating fit

Is this an open call with a fixed award amount?

The official EPCL page does not publish a single fixed award amount. It states program support and rolling full-proposal acceptance. Teams should plan without relying on a fixed award ceiling from this overview page and confirm details in the solicitation context.

Does the program only support electric power projects?

No. Power and energy are central themes, but the listed scope also includes broader engineered systems in transport, healthcare, manufacturing, and infrastructure-relevant applications.

Is Research.gov required or can we submit through Grants.gov?

The EPCL overview page strongly references Research.gov with NSF 24-1 and ENG/ECCS settings. It also includes guidance notes that can include Grants.gov processing context. This apparent mixed messaging should be confirmed in the live interface before submission.

Is this suitable for one group with only theoretical work?

The program funds fundamental research, but it is strongest when the proposal also explains a clear path toward system-level relevance and impact. Purely theoretical work without systems path is typically weaker.

Is there a hard national deadline this year?

The public “Full proposal accepted anytime” language indicates this call is not tied to one near-term closed date. But internal university cycles, reviewer windows, and programmatic budget pacing still matter.

Who should we contact before submission?

Use the program team email [email protected] for clarifications. Keep requests specific: scope, routing path, and any ambiguity about collaboration models.

How to position your team for success in 6–8 weeks

A practical 6–8 week execution plan for institutions:

1. Week 1: Align lead PI, collaborators, and technical lead; define the infrastructure problem statement.
2. Week 2: Draft concept paper with method and objective alignment to EPCL.
3. Week 3: Complete first pass budget and resource rationale with grants office.
4. Week 4: Build compliance checklist against NSF requirements and PAPPG references.
5. Week 5: Internal technical and compliance review.
6. Week 6: Revise for clarity of system impact and measurable outputs.
7. Week 7: Final internal sign-off and portal dry run.
8. Week 8: Submit with buffer time.

Because submission windows are rolling, you can repeat this cycle for future cycles too, but this cadence produces a disciplined baseline.

Official links

• Official opportunity page: https://www.nsf.gov/funding/opportunities/epcl-energy-power-control-learning
• NSF Proposal & Award Policies & Procedures Guide: https://www.nsf.gov/pubs/policydocs/pappg2024/
• NSF award and proposal guidance pages: https://www.nsf.gov/
• Contact: [email protected]

Final check before applying

Before you submit, answer these five questions with a yes/no in your team notes:

1. Is the objective tied to measurable system improvement (not only theoretical novelty)?
2. Are all technical assumptions and operating constraints explicitly stated?
3. Does the proposal describe a realistic path to meaningful infrastructure relevance?
4. Are submission settings and program routing confirmed for the current NSF portal behavior?
5. Have grants and compliance staff signed off on a version-ready package?

If any answer is no, this is a high-risk submission window. If all five are yes, you can submit and still improve after submission through internal institutional retrospectives for future iterations.