Data-center dynamic model requirements: a 2026 submission checklist

Start with the governing authority—not a universal template

“Data-center dynamic model requirements” sounds like a single standard. It is not. NERC’s May 2026 Level 3 alert establishes a strong continental baseline: transmission planners and planning coordinators should use PERC1, or a model with equivalent or better capability, as the basis for computational-load data requirements. The same alert says it is not a Reliability Standard and does not create a mandatory obligation to implement the Essential Actions.

The project-specific requirement may come from a transmission owner, utility, RTO/ISO procedure, interconnection agreement, study request, or reviewer comment. Those sources can differ in model class, file format, simulator version, milestone, and required evidence. FERC’s June 2026 show-cause orders to all six jurisdictional RTOs/ISOs are another reason to expect the rules to keep moving.

Primary sources: NERC Level 3 computational-load alert and FERC’s June 18, 2026 large-load action.

The 10-part data-center dynamic model checklist

This checklist translates the current NERC baseline and Dominion Energy Virginia example into an engineering workflow. It is a completeness screen, not a compliance determination.

1. Requirement identity and model target

• Governing authority, document revision, effective date, and project stage.
• Requested model class: CMLD, PERC1, UDM, OEM model, or a defined combination.
• Simulator, exact version, required file formats, naming rules, and electrical bases.
• Point of interconnection or common coupling and the network boundary included in the model.

2. Electrical size, power factor, and buildout

• Minimum and maximum MW and Mvar or power factor at the delivery point.
• Seasonal and operating-state values, not only ultimate nameplate capacity.
• Phased buildout dates and forecast load by phase.
• Initial study point and the relationship between installed, contracted, and expected demand.

3. IT and non-IT load composition

Separate compute/UPS load from cooling motors, variable-frequency drives, lighting, distribution losses, and other static or motor load. Record how the percentages change across loading and seasonal conditions. A single PUE value does not say which non-IT devices produce the overhead or how they behave dynamically.

4. Dynamic response and UPS configuration

• UPS topology and operating modes relevant to the study boundary.
• Voltage and frequency response of active and reactive power.
• Control filters, time constants, limits, deadbands, and initial conditions represented by the selected model.
• Which values come from OEM documentation, site settings, tests, fitted records, or an assumption.

5. Voltage and frequency protection

Collect settings for every device or scheme that can reduce or isolate load as seen at the grid boundary. Include thresholds, delays, measurement basis, per-phase versus three-phase logic, reset behavior, and the fraction of load affected. Avoid translating a relay setting directly into a model parameter until voltage base, filtering, timer logic, and aggregation are reconciled.

6. Cease behavior

• What fraction of electronic load ceases for each condition?
• Does it cease consumption, transfer internally, or disconnect from the grid?
• What starts and resets the timer?
• Does the response vary with operating state, firmware, loading, or equipment population?

7. Reconnect and restoration

Document reconnect voltage and frequency windows, qualifying time, deliberate delay, restored fraction, ramp rate, sequencing, and whether loads reconnect together or in blocks. Reviewers need to know both when load may return and how quickly the system sees it return.

8. Backup generation, BESS, islanding, and load transfer

• Transfer triggers, delays, and operating sequence for emergency generation and BESS.
• Whether onsite resources can run in parallel with the bulk power system.
• Whether the facility can island, participate in demand response, or transfer compute to another site.
• What the point-of-interconnection P and Q channels show during each mode.

9. Model artifacts and accepted-tool execution

• Steady-state case data and the requested dynamic-model file, such as a PSS®E .dyr.
• All supporting user-model libraries, parameter dictionaries, and execution instructions where applicable.
• A clean initialization record and a fingerprint of the simulator build used for the replay.
• A conformance comparison showing that the delivered artifact matches the reviewed reference behavior.

10. Validation, provenance, and lifecycle

• Measured, commissioning, laboratory, or disturbance records with channel and timebase provenance.
• Measured-versus-modelled overlays for the relevant P, Q, voltage, frequency, and switching states.
• Parameter identifiability and held-out validation, including explicit refusals.
• Source and artifact hashes, approvals, known limitations, and the events that trigger a model update.

Current Dominion/PJM example: what the execution-stage package asks for

Dominion Energy Virginia’s Facility Interconnection Requirements, effective April 1, 2026, offer a concrete example of how broad the request can become. Attachment 2 labels noteworthy load characteristics as an execution submittal due at least 90 days before the target energization date. It asks for load composition; installed load, distributed generation, and capacitor information; data-center load and power factor; seasonal IT and cooling percentages; cooling-system details; voltage and frequency performance; reconnect behavior; backup systems; customer equipment; and operating and protection documentation.

The same attachment requests a phasor-domain CMLD, PERC1, and/or other user-defined model representing the facility in PSS®E format, and explicitly allows a combination to represent the mechanical and compute load. That language does not mean every project should be reduced to PERC1. It means the model composition must match the site composition and the review question.

Primary source: Dominion Energy Virginia Facility Interconnection Requirements, effective April 1, 2026. Confirm the latest revision with the project authority before relying on it.

Map each requirement to the person who owns the evidence

A submission often stalls because the consultant assembling the model does not own the settings or records needed to support it. Build the evidence map early.

Put an owner, status, source, and decision deadline beside every row. “Requested from OEM” is a project risk, not evidence. If a value cannot arrive in time, surface the assumption and its study impact before the deficiency cycle.

What a reviewer-ready model package should contain

The exact file list follows the authority, but a defensible package generally has five layers:

1. Requirement matrix. Every applicable row, its source, disposition, evidence, owner, and open issue.
2. Model artifacts. The steady-state and dynamic files, exact tool/version target, parameter dictionary, and execution instructions.
3. Evidence register. Settings, one-lines, equipment data, normalized event records, channel mappings, hashes, and provenance.
4. Validation report. Initialization, event definition, measured/modelled overlays, transition ledger, residuals, identifiability, holdout score, and conformance replay.
5. Claim boundary. Assumptions, unsupported parameters, manual-review items, test plan, and the changes that invalidate the package.

A folder of files is not yet a package if the reviewer must guess which source produced which number. The chain between requirement, evidence, parameter, exported byte, and plotted response is the product.

Common submission failure modes

• Generic parameters presented as site-specific. A library value may be a starting assumption; it should never inherit the authority of an OEM setting sheet.
• One model for the entire building. Compute, cooling, static load, and backup systems can require different representations.
• Protection settings fitted from one trace. Moving thresholds and continuous-response parameters together can produce a neat overlay with the wrong mechanism.
• Model version omitted. A parameter row can initialize or behave differently across tools and patches.
• Holdout from the same event family. It may prove repeatability while missing the same structural error in both records.
• No refusal path. When the record does not excite frequency, the package should not claim a measured droop gain.
• No lifecycle trigger. Firmware, UPS population, protection, operating mode, and major composition changes can invalidate the reviewed model.

The readiness gate before submission

Before calling the package ready, ask three questions. Does every requirement have a current source and disposition? Does every consequential parameter have evidence appropriate to the claim? Does the delivered artifact reproduce the reviewed response in the exact accepted tool and version?

If any answer is no, do not hide it in a footnote. Convert it into a named gap, an owner, and either a test or a reviewer decision. The next step is then concrete—and the model stops pretending to know more than the facility records can support.

For model-class selection, read what PERC1 is and how it differs from ZIP and CMLD. For the validation workflow, continue with PSS®E dynamic model validation using disturbance data.

Frequently asked questions

What dynamic model does a data center need for interconnection?

The applicable transmission owner or planning coordinator decides. Current examples may accept a CMLD, PERC1, another user-defined model, or a combination. The correct choice depends on the facility composition, study questions, software version, and authority-specific criteria.

When should the dynamic model package be submitted?

Follow the project-specific schedule. As one current example, Dominion Energy Virginia’s April 2026 customer delivery-point criteria request noteworthy load characteristics and customer equipment information at least 90 days before the target energization date.

Is the NERC computational-load alert a mandatory standard?

No. The May 2026 Level 3 alert explicitly says it is not a Reliability Standard and does not itself create a mandatory implementation obligation. It provides a baseline for planner and transmission-owner actions; applicable standards, tariffs, facility requirements, and agreements still govern each project.

What is usually missing from a data-center model submission?

Frequent gaps include site-specific UPS and protection settings, IT versus non-IT composition, reconnect timing and ramp behavior, channel provenance for disturbance data, the exact simulator version, and evidence that the exported model reproduces the intended response.