NERC large-load interconnection: what the 2026 reporting actually found
NERC’s 2026 work on large loads did not create a new reliability standard. It documented a modeling gap, named a baseline model, and left the project-specific requirement where it already sat: with your transmission owner.
NERC’s 2026 large-load work documented a modeling gap rather than creating a new reliability standard. It found that roughly three quarters of reported operating data-center load carried no explicit dynamic model, and it pointed planners toward PERC1 or an equivalent as a baseline. Your binding requirement still comes from your transmission owner, and the thing that actually holds up submissions is evidence for the parameters, not the file format.
What the reporting found
NERC’s March 2026 aggregated report covers 33,282 MW of operating data-center load. Of that, 25,504 MW, about 77 percent, was submitted with no explicit dynamic load model or with a blank response, leaving the load represented by inherent ZIP behavior. Only 137 MW used a user-defined model such as PERC1.
The second finding is the one that gets less attention and matters more over a facility’s life: almost all respondents lacked a process to update models after design changes or observed events. A model is a claim about a facility at a moment. Without a refresh process, the claim and the facility drift apart silently, and the drift is discovered by a study that disagrees with a real event.
Primary source: NERC Level 2 aggregated report, March 2026.
What it is, and what it is not
It is worth being precise, because the distinction changes who you have to satisfy. A NERC alert and its aggregated response are an industry-wide information-gathering and guidance instrument. They are not a Reliability Standard with compliance obligations and penalties attached, and they do not by themselves impose a model on your project.
What they do is establish a shared expectation. Once the industry has a documented finding that three quarters of a load class arrived unmodeled, and a named baseline model for representing it, reviewers have something to point at. That is usually how a submission requirement tightens in practice, well before any standard changes.
Treat the alert work as the reason your reviewer’s questions got harder this year, and treat your transmission owner’s current criteria as the thing you actually have to satisfy.
Who actually sets your requirement
The applicable transmission owner or planning coordinator does. That is not a dodge, it is the operative fact, and it has three consequences worth planning around.
- Requirements are local and versioned. Two projects in different territories can owe different models, different studies, and different evidence. A checklist that worked last year in one territory is a starting point elsewhere, not an answer.
- The simulator and its version are part of the requirement. A model that imports in one release and errors in another is a deficiency, regardless of whether the physics were right.
- The effective date matters. Criteria get revised. A submission built against a superseded profile can be complete and still be returned.
The practical move is to capture the governing criteria as a dated, cited artifact at the start of the project, and to re-check it before you submit rather than after.
The gap is evidence, not file format
Producing a PERC1 file is not the hard part. Any of the common tools will write one. The hard part is that a dynamic model asserts specific behavior: how much load rides through a sag, when it ceases, and how it comes back. Those assertions have to come from somewhere.
When they come from a library default, nobody can say whether they describe your facility. When they come from a fit against a record, the question becomes whether that record could distinguish the parameters at all. Both failure modes produce a file that imports cleanly and answers the reviewer’s real question with nothing.
A model that imports is not a model that is supported.
We measured the second failure mode directly, on synthetic records where the true parameters were known. A fit can report full rank, pass a held-out check, declare itself submission-ready, and still return a parameter many times its true value, if the fit set held fixed something the record actually disagreed with. The identifiability note has the matrices and the control case.
What to do before your next submission
- Pin the governing criteria. Name the transmission owner document, its effective date, and the simulator version your reviewer runs. Store it with the project.
- Inventory what you can actually support. Separate parameters backed by settings, parameters backed by a record, and parameters that are currently library defaults. The third list is your risk.
- Check excitation before fitting. If the frequency channel never leaves nominal, no amount of data supports a droop claim. If terminal voltage never approaches the cease threshold, the record cannot substantiate cease behavior.
- Write down the refusals. For each parameter you cannot support, state the claim and the test that would support it. This is the item NERC found almost nobody had, and it is far cheaper to hand a reviewer than a number you cannot defend.
- Create the update trigger. Decide now what design change or observed event causes the model to be revisited, and who owns that.
None of this requires knowing how the standards landscape settles. It is the same work whether the requirement stays guidance or hardens, and it is the work that makes the difference between one review cycle and three.
Frequently asked questions
Does NERC require a PERC1 model for data centers?
Not as a blanket obligation on every project. NERC’s 2026 alert work points planners toward PERC1 or a model with equivalent or better capability as a baseline for computational load. The binding, project-specific requirement still comes from the applicable transmission owner or planning coordinator.
Is a blank protection-device model the same as no dynamic model?
In practice, yes. A blank or "None" protection-device entry leaves the load represented by its inherent ZIP behavior, which has no timed cease decision, reconnect threshold, or restoration ramp. NERC’s aggregated reporting counted those submissions as lacking an explicit dynamic representation.
We already submitted a model. Do we need to revisit it?
If the facility design changed after submission, or an event has been recorded since, then probably. NERC’s aggregated response found that almost all respondents had no process for updating models after design changes or observed events, which is the condition that produces a stale model nobody notices until a study disagrees with reality.