BESS Is No Longer Optional Infrastructure. NVIDIA Just Made That Official.

On May 28, 2026, NVIDIA published a 33-page application note titled BESS Self-Qualification Guidelines (DA-12516-001_v01). It defines a structured, partner-run qualification process for battery energy storage systems (BESS) intended to support AI data center campuses. The BESS OEM owns compliance: it performs or arranges the required testing and submits the supporting data. NVIDIA reviews the submitted evidence against published pass criteria, requests clarification where needed, and provides a qualification disposition. The document specifies 12 qualification tests, 10 core requirements, instrumentation standards, supply chain readiness criteria, and a four-party role framework that assigns distinct responsibilities to NVIDIA, the BESS OEM, an independent test lab, and the customer.

If you are a data center developer, infrastructure fund, or anyone deploying compute at scale, this document is not a white paper you can file for later. It is the first formal specification by a hyperscale compute company that treats BESS as production infrastructure for AI, not as an optional power quality accessory. And it carries implications that reach well beyond equipment-level testing.

The companion blog post from NVIDIA’s engineering team frames the shift directly: BESS is part of the DSX platform for AI factories. It is designed to buffer fast-changing AI workloads, support ride-through during grid disturbances, enable seamless transitions between grid-connected and islanded operation, and accelerate interconnection timelines by presenting a more controllable load profile to utilities. In NVIDIA’s architecture, BESS is not a standalone battery asset. It is a grid-interactive control system that sits at the center of the AI factory power stack.

That reframing changes the conversation for every developer evaluating co-located storage. The question is no longer should we include BESS? The question is how do we develop, permit, interconnect, and commission it correctly? And that question lands squarely in the development process, not in the equipment spec sheet.

This article does two things. First, it translates NVIDIA’s self-qualification framework into plain language for data center developers who need to understand what the requirements mean. Second, it identifies the critical development work that falls outside the qualification boundary, the site-level work that determines whether a qualified BESS product can actually be permitted, built, and energized at your location.

Inside the NVIDIA BESS Self-Qualification Framework

The self-qualification guidelines establish a clear boundary: the BESS is qualified at the AC terminals, including the Power Conversion System (PCS). Everything inside that boundary, including power conversion performance, control stability, telemetry, current-limit behavior, and dynamic response, must be demonstrated with both hardware test evidence and validated electromagnetic transient (EMT) models. Site transformers, line reactors, switchgear, relays, generators, campus control systems, and the overall site design are outside that boundary. Passing the BESS qualification does not, by itself, demonstrate site-level stability, interconnection compliance, permitting compliance, or suitability for a particular project. However, the partner must provide models and evidence sufficient for the customer to validate site-level integration.

The qualification process moves through four steps, followed by two additional qualification domains. Here is what each one requires, and what it means for a developer evaluating a BESS supplier.

Step 1: Product Requirements Document Review

The OEM must respond to each line item in NVIDIA’s BESS Product Requirements Document (PRD) with one of three designations: Compliant, Non-Compliant, or Exception. Non-compliant items require the OEM to document its current behavior, its product roadmap, any available workaround, and the associated risk. Exception items require the OEM to explain its technical substitute and provide supporting results.

What this means for developers: This is NVIDIA’s way of forcing transparency. When you evaluate OEM responses to the PRD, you are not looking at a marketing brochure. You are reading a line-by-line compliance matrix with evidence references. If your OEM has marked items as Non-Compliant or Exception, ask what those items are and what the roadmap looks like. A qualification submission with multiple Non-Compliant items in core requirement areas is a procurement risk, regardless of what the sales team tells you.

Step 2: Materials, Safety, and Compliance Disclosure

The OEM must disclose cell chemistry, enclosure type, cooling method, fire detection and suppression approach, hazardous materials (electrolyte class, refrigerants), and dielectrics/insulation class. The OEM must also provide certificates or alignment statements for UL 9540/9540A, NFPA 855, IEEE 2800, CE/UKCA, RoHS/REACH, and EMC compliance relevant to the PCS.

This step is where NVIDIA captures compliance status for domains that are excluded from the qualification testing scope, including safety and cybersecurity. These areas are not ignored; they remain under OEM responsibility and are governed by established regulatory and standards frameworks (AHJ, NFPA, UL, NERC CIP, IEC 62443, NIST CSF). The qualification process requires disclosure of compliance status but does not duplicate the testing those frameworks already require.

What this means for developers: This is your starting point for fire protection and code compliance diligence. The UL 9540A status is particularly important: does the OEM have a completed installation-level test report, or only cell- and module-level results? The IEEE 2800 alignment statement tells you whether the PCS has been validated against the interconnection requirements your utility will apply. These disclosures should be forwarded to your fire protection engineer and your interconnection consultant before you proceed to OEM selection.

Step 3: Core Requirements

NVIDIA designates 10 capabilities as Core Requirements, the minimum essential capabilities to pass qualification. Failure on any core requirement is disqualifying. These are not stretch goals. They are the floor.

#	Core Requirement	Requirement ID	What It Means
1	Autonomous Island Operation	CTRL-CORE-01	PCS must stably transition to and sustain island mode (voltage and frequency regulation without an external grid reference). This is what keeps your facility powered during a grid outage.
2	AI Buffering Dynamic Response	PERF-CORE-01	The system must actively smooth rapid power ramps from AI workloads without oscillations or control instability. This is the core AI factory use case.
3	Current Limit Behavior	PERF-CORE-02	When the PCS hits its current limit, it must behave predictably: no oscillation, no voltage collapse. This prevents cascading failures during grid disturbances.
4	LVRT/HVRT	GRID-CORE-01	Low/High Voltage Ride-Through per IEEE 2800 baseline. The BESS stays connected and contributing during grid voltage disturbances rather than tripping offline.
5	Reactive Power Support	GRID-CORE-02	Voltage support via reactive power injection within PCS current limits. This is what utilities require for grid stability compliance.
6	Seamless Grid/Island Transition	MODE-CORE-01	Controlled transitions between grid-connected and islanded modes without loss of synchronism. Quantified against ANSI C84.1 voltage standards and IEEE 2800 ride-through curves.
7	Black Start	MODE-CORE-02	Ability to energize a dead bus and establish stable voltage and frequency independently. This is what restores power to a fully de-energized campus.
8	Telemetry and Controls	TELE-CORE-01	Real-time reporting of voltage, current, power, frequency, SOC, alarms, and limit states. Must support three concurrent Modbus TCP connections polled at 1-second intervals.
9	Control Transparency	MODEL-CORE-01	EMT model with validated impedance scans and Nyquist/passivity artifacts, compliant with NERC Reliability Guidelines. No black boxes accepted.
10	DR Dispatch Capability	OPS-CORE-01	Follow dispatch setpoints with defined response times and ramp limits while maintaining SOC reserve logic. Enables participation in demand response programs.

What this means for developers: If your OEM cannot demonstrate all 10 of these capabilities with test evidence, the product has not passed NVIDIA’s qualification. Requirements 1, 6, and 7 (island operation, grid/island transition, black start) define whether the BESS can keep your facility operational independently of the grid. Requirements 2 and 3 (AI buffering, current limiting) are specific to the AI workload profile that traditional BESS deployments have never had to address. Requirement 9 (control transparency) means the OEM must provide a runnable EMT model, not just a data sheet, so your engineering team can validate site-level integration. If an OEM tells you their control architecture is proprietary and cannot be shared, that is a qualification failure under NVIDIA’s framework.

Step 4: The 12 Qualification Tests

This is the technical core of the framework. All tests are performed at the BESS AC terminals unless explicitly designated as model-only. All measurements must meet minimum accuracy standards (voltage and current at 0.2%, power at 0.5%, frequency at 0.01 Hz) and sampling rates (5 kHz for EMT, 10 Hz for operational). Every event must include pre-trigger and post-trigger data capture. Here is what each test validates:

Test 1: Telemetry Verification. Operates the PCS at 10%, 50%, 75%, and 100% of rated power and compares internal telemetry against external revenue-grade meters. Pass criteria: power error at or below 0.5%, time alignment within 5 ms, no missing channels or flatlined sensors.

Test 2: Grid-Adaptive Voltage and Frequency Regulation (Islanded). Demonstrates stable operation on an isolated bus with no external grid reference. Applies load steps of +10%, +20%, and -20% of rated power. Pass criteria: stable voltage and frequency, no sustained oscillation, no protective trip.

Test 3: Current Limit Characterization. Forces the PCS into current limit under P-priority, Q-priority, and mixed-priority modes. Pass criteria: stable and controllable behavior under current limit, explicit telemetry reporting of limit entry/exit, and monotonic voltage recovery within 5% of nominal after limit release. More than one control-mode transition during a single current-limit event (such as switching between grid-forming and grid-following modes) is an automatic disqualification.

Test 4: AI Buffering Proxy Test (Fast Ramp Tracking). This is the test most specific to the AI factory use case. The PCS must track time-varying active power commands representative of AI workload ramps under both weak-grid (short-circuit ratio of 3 or below) and strong-grid (short-circuit ratio of 20 or above) conditions. Pass criteria: steady-state tracking error at or below 2% of commanded ramp magnitude, no entry into current limit during the buffering profile, and no sustained oscillation. The partner must state the assumed IT load and demonstrate correct scaling of results.

Test 5: AI Buffering EMT Validation (Model-Based). Extends the AI buffering test into extreme weak-grid conditions (short-circuit ratio of 2.0) using electromagnetic transient modeling. The partner must provide a runnable EMT model with dq impedance curves and Nyquist or passivity evidence. Failure in this stress case is disqualifying regardless of performance at higher SCR values. The document is explicit: this test is intended to expose control fragility under the worst-case grid conditions expected in large AI campus deployments.

Test 6: Demand Response Dispatch. Validates DR execution at 10%, 25%, 50%, and 100% of committed capacity while maintaining SOC reserves for ride-through and buffering. Default response time: 2 seconds for fast DR, 60 seconds for slow DR.

Test 7: LVRT/HVRT Ride-Through. Applies voltage sag and swell profiles per IEEE 2800 at both weak- and strong-grid configurations. The BESS must stay connected within the IEEE envelope (or applicable utility curve) and correctly trip outside it.

Test 8: Seamless Grid/Island Transition. Starts grid-connected in buffering mode, executes an intentional islanding event, maintains voltage and frequency while continuing to supply load, then resynchronizes and reconnects without excessive inrush or protective trips.

Test 9: Islanded Operation with Generator Following (Model-Based). Validates BESS interaction with turbines or gensets in islanded mode: the BESS acts as voltage master, the generator follows with realistic governor dynamics, and the system absorbs an N-1 generation event without sustained oscillation.

Test 10: Black Start. The PCS energizes a dead bus from a de-energized state and picks up load in steps (10%, 25%, 50% of rated capacity) with stable voltage and frequency regulation.

Test 11: SOC Drift and Energy Management Under Combined Missions. This is the endurance test. The BESS runs a 24-hour simulation (or accelerated profile) combining AI buffering ramps, demand response dispatch events, and at least one grid-disturbance event, all while enforcing SOC reserve thresholds. Pass criteria: net SOC drift at or below 5% of usable capacity (excluding declared DR events), SOC remains within declared bounds at all times, and explicit de-prioritization behavior when approaching reserves. The framework is emphatic: oversizing battery capacity does not satisfy this requirement. SOC stability must come from control logic and energy management, not nameplate capacity.

Test 12: Control Transparency Package Review. The OEM must provide a complete, runnable EMT model package, dq impedance curves at key operating points, Nyquist/passivity assessment for both extremely weak (SCR = 2) and strong (SCR = 20) grid conditions, a controller description (loops, bandwidths, current-limit behavior), and a parameter list (droop coefficients, virtual impedance, inertia, PLL state). The model must reproduce measured hardware behavior within stated tolerances. Models that cannot be independently verified are invalid.

What this means for developers: You do not need to understand dq impedance scans to use this framework. What you need to understand is that these 12 tests create a binary: either the OEM’s product demonstrates these capabilities with evidence, or it does not. When evaluating OEM submissions, ask for the test results template (an Excel workbook with one tab per test). Ask which tests were completed with hardware evidence versus model-only. Ask whether the model-based tests used actual site-specific grid parameters or generic assumptions. And understand that Test 11 (combined missions over 24 hours) is where most marginal products will fail, because it tests real operational complexity, not just individual capabilities in isolation.

Business and Supply Chain Readiness

The framework extends beyond technical performance into what NVIDIA calls “Business and Supply Chain Readiness.” Partners must demonstrate actual historical manufacturing throughput (not theoretical capacity), present a credible plan to scale production by 10x within 24 months with quarterly milestones, disclose single-source components and geographic concentration risks, identify failure modes that could delay or cap the ramp, and provide a list of industrial standards and regulatory certificates.

The document is unequivocal: lack of demonstrated throughput or absence of a credible scale-up plan constitutes business non-qualification, regardless of technical performance. This section is intended to surface manufacturing reality early, not after technical qualification.

Quality and Reliability

Section 5 requires ISO 9001 certification, lot-level traceability for battery cells and power semiconductors, FMEA/DFMEA with top-20 risk items, reliability block diagrams, environmental and durability testing, factory acceptance procedures, and a serviceability plan with MTTR basis and recommended on-site spares. The stated intent is to prevent what the document calls “passes on paper”: systems that clear functional tests in the lab but deliver unacceptable field reliability. If the partner cannot defend reliability numbers under an AI buffering duty cycle, the system fails qualification regardless of lab results.

What the Framework Intentionally Excludes, and Why That Matters More

Here is the part that should command the attention of every developer reading this article. NVIDIA’s qualification boundary is drawn with surgical precision. The framework validates that the BESS performs as a grid-interactive electrical asset. It does not, and explicitly does not claim to, validate that the BESS can be permitted, sited, interconnected, or commissioned at a specific location.

The document states this directly: “Passing qualification does not imply site-level stability.”

Safety. The qualification testing scope excludes fire suppression, NFPA 855, UL 9540A, and seismic standards because these areas fall under OEM responsibility and are governed by the Authority Having Jurisdiction and applicable regulatory bodies. This does not mean NVIDIA ignores safety: Step 2 of the qualification process requires the OEM to disclose fire detection/suppression approach, UL 9540A status, and NFPA 855 alignment. But the qualification tests themselves do not replicate the regulatory frameworks that already govern these domains. As a result, a BESS product can pass all 12 NVIDIA qualification tests and still fail to obtain a building permit if the local fire marshal requires installation-level fire test data the OEM has not completed, or if fire code spacing requirements conflict with the site layout.

Battery sizing and cell chemistry. The tests are chemistry-agnostic by design. But site-level development requires specific UL 9540A data tied to the actual chemistry and enclosure configuration being deployed, because off-gas composition, propagation characteristics, and required separation distances are chemistry- and configuration-dependent.

Interconnection. Site transformers, switchgear, relays, generators, and campus controls are excluded from the qualification boundary. The interconnection assessment, including queue position, material modification risk, network upgrade costs, and utility coordination, remains the customer’s responsibility.

Permitting and land use. Zoning approvals, conditional use permits, setback requirements, environmental review, and AHJ coordination are entirely outside the scope.

None of these exclusions are oversights. They reflect a sound engineering decision: NVIDIA is qualifying the BESS as a grid-interactive electrical asset at its AC terminals, not validating site-level suitability. The excluded domains are still addressed through Step 2 disclosure requirements, where OEMs must document their compliance status against applicable AHJ, NFPA, UL, NERC, IEC, and NIST frameworks. But the practical implication for developers is that equipment-level qualification is a necessary condition for deployment, not a sufficient one. The gap between “qualified equipment” and “deployable project” is filled by development work.

The Fire Marshal Has Not Read Your Qualification Report

NVIDIA’s decision to exclude safety testing from the qualification scope, while still requiring safety compliance disclosure in Step 2, is the most consequential boundary decision in the entire document. Not because it is wrong. It is correct: NVIDIA is not a safety certification body, and the applicable AHJ, NFPA, and UL frameworks already govern these requirements. But the boundary creates a gap that many data center developers will not recognize until they are standing in front of a fire marshal who has never reviewed a BESS application before.

Consider the scenario: a developer selects a BESS OEM that has passed all 12 NVIDIA tests. The product demonstrates stable island operation, sub-2% ramp tracking, and clean ride-through behavior. The developer proceeds to site design.

Then the local fire marshal asks for the UL 9540A installation-level test report. The OEM has completed cell-level and module-level testing but not the full installation-level fire test for this specific enclosure. Without that data, the fire marshal cannot determine the required separation distances, the appropriate explosion control methodology, or the fire water supply requirements. The permit application stalls.

Alternatively, the UL 9540A data exists, but it specifies separation distances that conflict with the site layout. The containers that passed NVIDIA’s 12 tests do not physically fit on the parcel with the required fire setbacks.

The principle is straightforward: the fire code defines the physical constraints that determine whether a qualified product can be deployed at a specific site. Those constraints must be known before the Design Basis is locked. In a disciplined development process, the fire protection engineer reviews UL 9540A data during OEM evaluation, not after procurement. The output is a Fire Safety Design Basis Memo that defines spacing, setbacks, explosion control, and water supply requirements. That memo becomes an input to the site layout. If the fire data does not support the site constraints, the developer knows before committing capital.

Adding BESS to Your Interconnection: Accelerator or Landmine?

NVIDIA’s blog post makes a compelling case that BESS can accelerate interconnection timelines by presenting a more controllable load profile to utilities. Several ISOs have introduced accelerated pathways for sites that demonstrate load flexibility. This is an important development.

But for developers who already hold a queue position, adding BESS introduces a question the framework does not address: does adding a BESS to your site trigger a Material Modification of your interconnection agreement?

A Material Modification can trigger a restudy that adds 12 to 24 months and potentially resets your queue position. Adding a grid-forming BESS with black start capability to a site originally studied as a passive load is, in many ISO tariffs, exactly the kind of change that requires review.

The solution is to evaluate the interconnection impact before committing to a BESS configuration. A Material Modification Assessment, performed during the technology selection phase, determines whether the proposed BESS triggers a restudy and identifies what technical modifications would keep the project within existing study assumptions. For greenfield campuses entering the queue for the first time, designing with BESS from the initial interconnection request positions the project for accelerated pathways, but that requires the BESS to be part of the application from day one, with the single-line diagram and technical data package reflecting the integrated architecture.

Supply Chain Readiness Meets Federal Trade Compliance

NVIDIA’s guidelines require partners to disclose exposure to export controls, trade restrictions, and geopolitical risk. This intersects directly with the Foreign Entity of Concern provisions under current federal law.

Under the IRA and subsequent OBBBA legislation, BESS projects seeking the Section 48E Investment Tax Credit must demonstrate that their battery components do not include cells manufactured by, or under the effective control of, specified foreign entities. Six battery OEMs are categorically disqualified. For non-disqualified OEMs, the Manufactured in America Component Ratio thresholds are tightening annually, and battery cells represent over half of grid-scale BESS equipment cost under the IRS safe harbor table.

An OEM whose product passes all 12 NVIDIA tests may still present a federal tax credit risk if its cell supply chain involves flagged entities. And an OEM that clears the FEOC screen may lack the manufacturing scale to meet NVIDIA’s 10x ramp requirement. Evaluate both frameworks simultaneously. The OEM evaluation should include NVIDIA qualification status, FEOC entity screening, MACR calculation, effective control contract review, and supply chain geographic analysis. These are inputs to a single procurement decision.

The Customer Role That Most Developers Do Not Have

Appendix E of the guidelines defines a four-party framework. NVIDIA authors the criteria, reviews submitted evidence against published pass criteria, and provides a qualification disposition. The BESS OEM owns compliance, performs or arranges the required testing, and submits the supporting data. The test lab executes the 12 qualification tests and issues the compliance report. And the customer reviews the qualification data against site needs, validates site-level integration, commissions in the field, and issues site acceptance.

That customer role requires the technical capacity to review qualification data against site-specific conditions (grid impedance, protection coordination, campus control architecture), validate that site-level integration performs as modeled, and issue the acceptance that unlocks deployment.

Most data center developers do not have in-house BESS development teams. They have procurement teams, construction teams, and operations teams. But the NVIDIA framework assigns the customer a scope of work that is, in practice, an Owner’s Representative function: someone who bridges the gap between the OEM’s equipment qualification and the site’s development requirements. That function includes reviewing UL 9540A data before locking the Design Basis, coordinating fire protection inputs into the site layout, managing interconnection assessment, navigating local permitting, and ensuring that qualification data, site design, and permitting tell a consistent story.

If you do not have that function today, you need to build it or source it. NVIDIA’s framework assumes the customer has this capacity. The framework does not provide it.

This is precisely the role that an Owner’s Representative firm fills. A BESS-specialized Owner’s Rep does not design the system or stamp the engineering drawings. It manages the development process on behalf of the owner: coordinating the fire protection review that validates UL 9540A data before OEM commitment, drafting the scope of work for the engineers of record who produce the stamped deliverables, running the interconnection assessment that determines whether adding BESS triggers a restudy, managing the AHJ permitting strategy, and maintaining the project controls that keep qualification data, site design, and permitting aligned on a single critical path. In NVIDIA’s four-party framework, the Owner’s Rep is how the “customer” role actually gets executed. 

Carina Energy provides this function as a dedicated service for data center developers entering the BESS space, from initial site feasibility through commissioning and site acceptance.

What Developers Should Be Asking Right Now

If you are evaluating BESS for an AI data center campus, these are the questions that belong in your next internal review:

Does my OEM’s BESS product have NVIDIA self-qualification status, or is it in progress? If the OEM cannot point to a completed qualification package with pass/fail evidence against the 10 core requirements, you are evaluating a product against a standard it has not yet met. Ask for a timeline and ask which tests are complete.

Has my fire protection review been completed before I commit to an OEM? If you have not reviewed the UL 9540A installation-level test data for the specific product you intend to deploy, you do not yet know whether the product physically fits your site under the applicable fire code.

Does adding BESS to my interconnection trigger a material modification? If your site already holds a queue position, adding a grid-forming BESS with different fault characteristics may require a restudy. Get a Material Modification Assessment before you finalize the BESS configuration.

Who on my team is responsible for the “site acceptance” role that NVIDIA’s framework assigns to the customer? If you cannot name the person or team that will review qualification data against your site conditions and issue site acceptance, you have an organizational gap that will surface during commissioning.

Have I evaluated the OEM’s supply chain against both NVIDIA’s business readiness requirements and federal FEOC provisions? An OEM that passes NVIDIA’s technical qualification but fails the FEOC screen costs you the ITC. An OEM that clears FEOC but cannot scale manufacturing costs you the deployment timeline.

Am I treating the BESS as part of my site’s integrated power architecture, or as a procurement line item? NVIDIA’s framework is explicit: passing equipment-level qualification does not imply site-level stability. If your development process treats BESS procurement as a line item rather than a system integration challenge, the framework is telling you to rethink that approach.

The Bar Just Moved. The Question Is Whether Your Development Process Has Moved With It.

NVIDIA’s BESS Self-Qualification Guidelines are not a minor technical update. They are a market-defining signal that BESS has crossed from optional infrastructure to production infrastructure for the fastest-growing segment of power demand in the United States. When the company building the compute stack publishes a 33-page specification for the storage system that buffers it, the conversation about whether data centers need BESS is over. The conversation about how to develop it has begun.

The developers who will navigate this transition most efficiently are the ones who recognize the gap between equipment-level qualification and site-level readiness, and who close that gap with the right development sequence: fire protection review before OEM commitment, interconnection assessment before BESS configuration lock, permitting strategy informed by direct AHJ engagement, and an Owner’s Representative function that bridges the OEM’s product qualification and the site’s development requirements.

NVIDIA built the framework for validating the equipment. The site-level development work that makes a qualified BESS deployable is a different discipline, and it starts now.

Carina Energy provides BESS Development-as-a-Service for data center developers, infrastructure funds, and project sponsors, including fire safety and code compliance screening, OEM technical evaluation, interconnection management, and full-spectrum Owner’s Representative services from fatal flaw analysis to COD. If you are evaluating co-located BESS for an AI factory site and want to understand the site-level development work before you commit capital, contact us at carina.energy/message-portal/ to discuss your project.