The failure that looks like health , what does EC-WP-1002 say?

The rows arrived on their normal cadence the entire time. Row counts were nominal. No staleness check fired, because nothing was stale. No communications alarm raised, because the links were healthy. No tile went grey, because there was nothing absent for a monitoring system to notice. There was simply a wrong number , present, punctual, at every site, for eleven days. Every performance-ratio and insolation-quality calculation downstream consumed those zeros as measurement. Eleven days of numbers that were precise, internally consistent, confidently rendered, and false.

A taxonomy, and why symptom-sorting fails , what does EC-WP-1002 say?

The distinction matters more than it sounds. A punch list is finite and closes. A taxonomy generalises: once you can recognise denominator drift in a capability score, you will find it in a soiling ratio, a peer-comparison coverage figure and a fleet availability rollup without being told to look. Substitution feeds denominator drift: a zero-filled sensor is often excluded from a peer set, silently shrinking the comparison population. Plausibility void feeds substitution: without a bound, a garbage value is stored rather than refused, and the next process to encounter it may replace it with a default. Provenance erasure makes all five of the others harder to diagnose, because once the epistemic status of a value is gone from the record, the only way to establish it is forensic.

Substitution , what does EC-WP-1002 say?

A measurement that does not exist is written into the record as a number that does. The number is almost always zero, for a reason that has nothing to do with engineering. Zero is the type-default of a numeric column. When an acquisition path cannot obtain a value , the sensor is faulted, the tag is unmapped, the poll timed out, the transform threw , the value that lands in the row is whatever the code produced by default. In a strongly typed pipeline with nullable columns that is NULL. In most real pipelines it is 0, because somewhere in the path a variable was initialised and never assigned.

Denominator drift , what does EC-WP-1002 say?

A derived metric defines its denominator over the set of currently-healthy assets. When an asset fails it leaves the numerator and the denominator at the same instant, and the metric improves. Every derived metric is a ratio, and every ratio is an argument about what the correct comparison population is. That argument is made once, usually early, usually by one engineer under time pressure, and then it is never revisited , because the number it produces looks reasonable, and a number that looks reasonable is never audited.

Clock collapse , what does EC-WP-1002 say?

Collapse occurs when one column serves both. Because the ingest sweep rewrites its column on every pass, the surviving semantic is observation, and onset is destroyed. The system retains the less informative of the two and loses the one operators actually reason with. Worse: the sweep typically re-stamps every alarm it sees, including the ones it is in the middle of closing out. So the column is not even a reliable observation time for the alarm , it is a heartbeat of the process, painted onto every row it touched.

Staleness masquerade , what does EC-WP-1002 say?

The data is correctly stored, correctly timestamped, and correctly retrieved. The display drops the part of the timestamp that would tell you it is fourteen months old. A display formats a timestamp as time-of-day. On a screen refreshed every few seconds, showing seconds and omitting the date is a defensible choice , until a value stops updating. From that moment the display is indistinguishable from a live one, and the older it gets the more confidently wrong it becomes.

Plausibility void , what does EC-WP-1002 say?

A value arrives on time, from a healthy link, in the right column, and is physically impossible. Nothing refuses it, because nothing in the system holds a bound it could have been checked against. Monitoring stacks validate three things well: that data arrived, that the link is up, and that the value parses as the right type. They rarely validate the fourth: that the value is physically possible for this asset.

Provenance erasure , what does EC-WP-1002 say?

Two values sit in the same column. One was issued by the entity of record. One was inferred from the plant's own history because no issued value was available. On screen they are identical. Only one of them can be cited, and nobody can tell which. Values in an operational database differ in kind, not only in magnitude. A setpoint may be measured, modelled, inherited from a prior configuration, inferred from the plant's own behaviour, or issued by an external authority. Those are five different epistemic statuses with five different evidentiary weights.

The Computational Load Entity

How NERC built a registration for data centers: the April 2026 Computational Load Entity proposal and its three-part test, the Rules of Procedure machinery, the Board-approved Computational Load Owner and Operator criteria that replaced it, and what becoming a registered functional entity requires of a large computational load.

Foreword
How to Use This Reference
Executive Summary
Chapter 1. A New Functional Entity
Chapter 2. The Registration Test
Chapter 3. The Rules of Procedure Machinery
Chapter 4. How Registration Actually Happens
Chapter 5. What Registration Obligates
Chapter 6. Structuring Options and the Materiality Question
Chapter 7. Implications and What to Do Now
Glossary of Terms
How Energy Compliance Can Help
About the Author
About Energy Compliance, Inc.
Sources and Authorities

Read offline

The full EC-WP-1002 reference as a formatted PDF, with cover, glossary and sources.

Download the PDF

Foreword

This reference is one of a series Energy Compliance, Inc. publishes for registered entities and the people who run their compliance programs. I have spent more than thirty years on every side of the bulk electric system. I have operated control centers as a Reliability Coordinator, Transmission Operator, and Power System Operator. I have audited grid facilities and signed off on findings as a senior compliance auditor. I have worked enforcement matters from inside the regulator’s process. For the last several years I have advised registered entities directly through the firm I founded.

The entities that handle reliability well share a common habit. They take the standards seriously without confusing them with reliability itself. They know that a NERC Reliability Standard is a floor, not a ceiling. They know that compliance is what an auditor evaluates, but reliability is what the system either delivers or does not. They prepare for audits by building programs that survive real questions.

Becoming a NERC-registered functional entity is not a paperwork event. It is the moment a facility crosses from being a participant in someone else's reliability obligation into being a holder of its own. Generators have lived inside that distinction for decades. NERC's computational load registration extends that discipline to a population of facilities that has never carried it. This third book in the series examines what the registration requires, why the registry criteria were drawn where they were, and how the machinery that produces and revises those criteria works. I wrote it in June 2026 around NERC's Computational Load Entity proposal. NERC has since replaced that proposal, and this October 2026 edition says so wherever it matters.

These references are written for the compliance manager who wants to understand the system, not just memorize requirements. For the counsel who has to brief a board on what the next eighteen months of large-load regulation will require. For the planner or operator being told their system has a new kind of load. And for the data center owner who has been told their facility may now be a registered entity, and wants to know what that means.

These references are not marketing material dressed as content. They are the product of three decades of doing this work and watching it succeed and fail. I have written them in the voice I use in a control room or in front of a Regional Entity audit team: direct, evidence-grounded, honest about what the standards do and do not require.

Energy Compliance, Inc. exists because most of the consulting offered to registered entities today is structured for billable hours rather than for outcomes. Every engagement is overseen by a senior practitioner. We automate the work that should be automated and apply senior judgment to the work that requires it. If that approach matches what you are looking for, the back of this reference tells you how to reach us.

If not, the reference still belongs to you. Take what is useful. Apply it well. And remember the only test that ultimately matters: when the system needs to perform, does it?

Rob Smith, Founder and Principal, Energy Compliance, Inc.

Bloomington, Minnesota

How to Use This Reference

This whitepaper is the third of five in the Energy Compliance Large Load and Data Center Series, with an October 2026 update, EC-WP-1005, that carries the current status of the registration and the standards. EC-WP-1000 established the grid layer. EC-WP-1001 traced NERC's response through alerts, technical white papers, a reliability guideline and the standards project. This book concentrates on the institutional machinery of registration: who becomes a registered computational load, how the determination is made, and what the registration carries with it.

The grid layer (EC-WP-1000)

What the demand shock is, why the existing planning and interconnection frameworks cannot absorb it, and how the federal and state interconnection regimes are being rebuilt in response.

The standards layer (EC-WP-1001)

NERC's Large Loads Action Plan, the Level 2 and Level 3 Alerts, the technical white papers, the reliability guideline, and the mandatory standards developed under Project 2026-02.

The entity layer (EC-WP-1002)

The Computational Load Entity proposal and the three-part test it introduced, the Rules of Procedure machinery, the Computational Load Owner and Operator registration that replaced the proposal, and what becoming a NERC-registered functional entity actually requires.

The owner layer (EC-WP-1003)

The data center owner's playbook under Texas Senate Bill 6: the interconnection trigger, the study-fee and site-control regime, the curtailment bargain, and the standalone-versus-co-located choice.

The operating layer (EC-WP-1004)

The compliance operating model for a registered computational load: internal controls, governance, evidence infrastructure, and the day-to-day disciplines that convert obligations into demonstrable compliance.

The 2026 update (EC-WP-1005)

The Board-approved Computational Load Owner and Operator registry criteria, the 50 MW and 100 kV site test, what CLO-001-1, CLO-002-1 and CLO-003-1 require, and the compliance calendar. Where this book and EC-WP-1005 describe status differently, EC-WP-1005 controls.

Every factual assertion in this reference is grounded in a primary source identified in the Sources and Authorities appendix. Where a regulatory matter was proposed or pending at the time of writing, it is described as such, and the reader is reminded to confirm current status before relying on it. Energy regulation in this area moves on monthly timescales. The status of a docket or a NERC project when you read this may differ from its status on October 17, 2026.

Executive Summary

For the first time, the data center itself is being pulled inside the fence. Through most of the bulk power system's history, reliability obligations ran to generators, transmission owners, and the operators and planners who run the grid. They did not run to the customers drawing power from it. NERC's computational load registration breaks that pattern. It makes the largest computational loads, meaning data centers, AI compute campuses and cryptocurrency facilities, registered entities in their own right, directly subject to mandatory Reliability Standards and the enforcement that backs them. This book is about who is captured, how registration happens, and what it obligates.

The first two books in this series set the context. EC-WP-1000 examined the grid-layer reliability problem and the federal interconnection framework, and EC-WP-1001 traced NERC's Large Loads Action Plan from white paper to alert to standards project. This third book takes up the entity layer: the registration determination that decides which loads cross from unregulated customer to NERC-registered entity. It is the hinge of the series, because everything downstream, including the compliance program examined in EC-WP-1004, follows from the registration decision analyzed here.

The registration did not land where it started. In April 2026 NERC proposed a single new function, the Computational Load Entity, with a three-part test. In August it replaced that proposal with two functions, the Computational Load Owner and the Computational Load Operator, and a higher, site-based threshold. On October 8, 2026, the NERC Board approved the revised Rules of Procedure. FERC has directed NERC to file initial standards by December 31, 2026, and expects the registry criteria by the same date. This edition keeps the June analysis of the April proposal, because the reasoning behind it explains the final criteria, and marks it as history.

Five findings frame the analysis

The original test was conjunctive and it was replaced. As proposed in April 2026, a Computational Load Entity was one that contributed to an aggregate connected Load capability of 20 MW or greater, at a single point of interconnection to the Bulk Power System at 60 kV or greater, and that hosted 1 MW or more of Computational Load. The August revision, approved by the Board on October 8, captures the owner and the operator of a Computational Load Site with total connected Load of at least 50 MW, supplied through electrical equipment connected at 100 kV or above, from one or more points of connection.

The character test moved from IT load to the site. The April proposal defined Computational Load as demand from information technology equipment such as servers, storage and networking hardware, and used a 1 MW IT-load prong to separate data centers from other industrial customers. The approved approach drops that prong. A Computational Load Site must instead primarily contain information technology infrastructure, and NERC has said manufacturing facilities and large hospitals are not within scope.

Creating a registered function is a Rules of Procedure undertaking. NERC cannot announce a new obligation. It revised Appendix 2 (definitions), Appendix 5A (the registration and certification manual) and Appendix 5B (the Statement of Compliance Registry Criteria), took two rounds of public comment, and obtained Board approval. Under Section 1402 of the Rules of Procedure, the revisions do not take effect until FERC approves them.

Registration is the gateway to mandatory standards and FERC enforcement. A registered entity is subject to the Reliability Standards applicable to its function, the Compliance Monitoring and Enforcement Program, and penalties under Section 215 of the Federal Power Act. The standards for these entities, CLO-001-1, CLO-002-1 and CLO-003-1, passed their final ballot in October 2026 and await Board adoption and FERC approval. NERC's implementation plans expect Computational Load Owners to be registered beginning in 2027.

Materiality runs through everything. Appendix 5B directs NERC to register the owners, operators and users of the bulk power system that have a material impact on it. NERC grounded its thresholds in aggregate risk as well as individual size, and it retains room to register an entity below the criteria, exclude one above them, or limit an entity's obligations to a sub-set list of standards.

The practical message has not changed since June. Registration is not automatic, not optional for those who qualify, and not the end of the analysis. A facility that meets the criteria should expect to register and to carry the obligations of a registered entity. A facility near the thresholds should understand exactly where the lines fall and how materiality and the transfer mechanisms could pull it in or leave it out. This book draws those lines. EC-WP-1005 maps the new standards requirement by requirement, and EC-WP-1004 covers the compliance program that follows registration.

Chapter 1. A New Functional Entity

NERC registers functions, not industries. To understand why a data center is becoming a registered entity, you have to understand how NERC's framework decides who is covered at all. It does not regulate "the power industry" in the abstract. It registers organizations that perform defined functions on the bulk power system, such as Generator Owner, Transmission Operator and Balancing Authority, and applies to each the Reliability Standards relevant to that function. NERC first proposed one new function for computational loads, the Computational Load Entity. The Board approved two instead, the Computational Load Owner and the Computational Load Operator. That framing explains both why a new category was needed and how it works.

1.1 Why a new category was necessary

Large computational loads did not fit any existing registration. They are not generators, not transmission owners, and not the operators or planners of the system. They are end-users, customers, and customers have historically sat outside the registry. Yet the first two books in this series showed that these particular customers can destabilize the bulk power system when they connect or disconnect, in a way ordinary load does not. NERC faced a structural mismatch: an object capable of causing a reliability event, with no functional category through which to impose reliability obligations on it. The new registration resolves that mismatch by creating the missing category.

The proposal grew out of NERC's Large Loads Working Group, which began as the Large Loads Task Force in August 2024 and moved large loads from an emerging-risk topic to a sustained program. NERC's April 2026 technical reasoning supplied the rationale. Citing the working group's first white paper, it explained that certain large loads have a material impact on reliability for two reasons: the size and electrical behavior of individual facilities, and the sheer number of such facilities in aggregate. Power-electronic loads use software controls that let them change consumption rapidly, which produces load behavior planners and operators have not seen before. That two-part rationale, individual and aggregate, is why the registration is anchored to size thresholds and to the computational character of the site rather than to the bare fact of being a data center.

A new functional registration category is a substantial institutional event, and there is a recent precedent on the generation side. Appendix 5B, in Revision 8 effective June 27, 2024, carries Category 2 Generator Owner and Generator Operator registration for non-BES inverter-based resources of 20 MVA or more connected at 60 kV or above. The computational load registration follows that pattern, with one complication: the population being registered has not historically thought of itself as a reliability participant. Generators understood, when they connected, that they were entering a regulated reliability framework. Many data center owners did not. In my experience, that makes the registration as much an exercise in industry education as in regulatory machinery.

The materiality principle has a procedural counterpart, and it is worth getting right. Regional Entities run registration day to day: they review applications, request information and initiate registration of entities that should be on the registry. But a decision that turns on materiality, registering an entity below the criteria or excluding one above them, must be made by a NERC-led Registration Review Panel under Section III(D) of Appendix 5A. That decision can be appealed to the Compliance Committee of NERC's Board and from there to FERC. The Regional Entities are still the first audience for how the criteria work in practice, and their early handling of computational load sites will shape how the criteria are read across the country. Entities anticipating registration should find out early how their Regional Entity is staffing the work.

1.2 The materiality principle

NERC's registration framework rests on a materiality principle. Appendix 5B states that NERC must identify the owners, operators and users of the bulk power system that have a material impact on it, and that any entity reasonably deemed material will be registered. That principle is the lens through which every registration question is answered. It is why the criteria are set high enough to capture loads large enough to matter, and it is why Appendix 5B allows an entity that falls below the criteria to be registered if it is shown to be material, and an entity that meets them to be excluded if it is shown not to be. Materiality, not a mechanical reading of a number, is the ultimate test.

This matters to a facility near the line. The registry criteria, examined in the next chapter, are the presumptive screen: meet them and you are a candidate for registration, miss them and you are presumptively out. The materiality backstop means a facility just under a threshold cannot treat the numbers as an absolute safe harbor, and a facility just over them is not without arguments in unusual circumstances. The numbers are where the analysis starts. Materiality is where close cases are resolved.

The principle is doing more work than its phrasing suggests. In the NERC framework, materiality distinguishes a facility whose behavior can affect reliable operation of the bulk power system from one whose behavior cannot. The test is structural. It does not turn on what the facility is called, what industry it belongs to, or whose business model it serves. It turns on the electrical question of whether the facility's disturbance behavior, disconnection characteristics or operating characteristics can reach the bulk system in a way that matters. Appendix 5B lists factors for that assessment, including whether removal of an entity's Element would cause a reliability issue on another entity's system and whether operation or misoperation of its Protection Systems could harm a Balancing Authority, Generator Operator or Transmission Operator. For computational loads, NERC's incident reviews of large load loss events in January 2025 and voltage-sensitive crypto load reductions in January 2026 put the materiality question on the record.

1.3 Risk-based registration

The computational load registration reflects a philosophy NERC has applied to registration for years: register entities and impose obligations in proportion to the reliability risk they present, rather than sweeping in every organization that nominally performs a function. Appendix 5B says it plainly. Registering every organization within the scope of "owner, operator, and user" while ignoring its impact on reliability would cost more than the reliability it buys. That philosophy shows up in two features that recur throughout this book: specific thresholds that target the loads that matter, and NERC's ability to limit an entity's or a class's obligations to a sub-set list of Reliability Standards. A computational load does not inherit the standards written for a transmission operator. It is subject to the standards written for it, which Project 2026-02 produced as CLO-001-1, CLO-002-1 and CLO-003-1.

Risk-based registration animates the criteria. A criterion that registered every load above a low nominal threshold would over-register, capturing facilities whose materiality to the bulk system is negligible. A criterion that registered only the largest, most visible loads would under-register and miss facilities whose aggregate effect is material. NERC's own record shows the tension. The April proposal set a low threshold expressly so that enough entities would be covered to address aggregate impact. After comments, NERC expanded its analysis to sites planned to be operational by the end of 2027 and concluded that 50 MW at 100 kV still addressed the aggregate risk while registering fewer entities. Both thresholds were attempts to find the population where the reliability return on registration is highest.

Chapter 2. The Registration Test

The threshold question has a precise answer, and that answer changed between June and October 2026. This chapter sets out the three-part test NERC proposed in April, the reasoning NERC gave for each prong, and the site-based test that replaced it. The April test is history, but its reasoning explains where the final lines fell.

2.1 The April 2026 proposal: three prongs

As proposed in April 2026, a Computational Load Entity was the end-user, or the entity that hosts end-users, that receives electric power for Computational Load, and that met all of the following:

Aggregate connected Load capability of 20 MW or greater. The entity had to contribute to an aggregate connected Load capability at or above 20 MW. This was the size threshold.
A single point of interconnection at 60 kV or greater. The aggregate had to be taken at a single point of interconnection to the Bulk Power System at 60 kV or higher. This was the connection threshold, aimed at loads connected at bulk-system voltages rather than loads embedded in the distribution system.
Hosting 1 MW or more of Computational Load. The entity had to host at least 1 MW of Computational Load, defined as demand from information technology equipment such as servers, storage and networking hardware. This was the character threshold, the prong that separated a computational facility from any other large industrial customer.

Candidates had to meet all the criteria. NERC posted the proposal for a 45-day comment period from April 1 to May 15, 2026.

The 20 MW anchor matches the figure FERC uses to describe large loads in its large load interconnection docket, RM26-4, where large loads are described as generally greater than 20 MW. It also mirrors the 20 MVA and 60 kV thresholds in Appendix 5B for Category 2 inverter-based generators. NERC's technical reasoning tied the number to its own record: 20 MW captured the vast majority of computational loads that posed risk, and the data NERC received through the Level 2 Alert supported it. In June I wrote that this alignment made the threshold likely to hold. It did not. Comments pushed NERC to re-examine the aggregate risk, and the number moved.

2.2 Why each prong was drawn where it was

NERC's technical reasoning explained each prong. The 20 MW floor was chosen so that enough entities would carry standards to address the aggregate impact of computational loads connecting to the system. The 60 kV floor ensured that the full set of 20 MW computational loads would be registered while leaving out loads connected to the distribution system. The 1 MW computational-load prong was meant to keep out entities, such as industrial manufacturers, with only a de minimis amount of computational load, because their electrical behavior has historically differed. A 50 MW steel mill at 138 kV is large and bulk-connected, but it is not computational. The third prong left it out.

Each prong carried a regulatory and a technical rationale, and the two are not identical. The voltage prong is a regulatory proxy for presence on the bulk power system. The size prong is a technical proxy for the contingency the system must plan against: a block of load large enough to matter on disconnection. The character prong is a behavioral proxy for what makes computational load distinct: rapid, voltage-sensitive disconnection, protection logic governed by the load's own priorities rather than the system's, and similar response across many facilities with similar designs. Each prong on its own is an imperfect filter. Together they were designed to catch the population for which a reliability obligation is most clearly justified. That logic survived into the final criteria even though the numbers did not.

2.3 The August 2026 revision and Board approval

On August 19, 2026, NERC posted revised criteria for a 30-day comment period through September 18. The revision did more than raise a number. It changed the unit of analysis from an entity's IT load to a physical site, and it split one function into two. On October 8, 2026, the Board approved the Rules of Procedure revisions creating the Computational Load Owner and Computational Load Operator and their registry criteria. NERC has said it plans to file them with FERC.

As posted in August, Appendix 5B captures the Computational Load Owner, and separately the Computational Load Operator, of a Computational Load Site with a total connected Load greater than or equal to 50 MW that is supplied through electrical equipment connected at a voltage level greater than or equal to 100 kV from one or more points of connection. A Computational Load Site is one or more buildings, structures or installations at a single location that primarily contains information technology infrastructure used for software applications and services, artificial intelligence training, deployment and delivery, cryptocurrency mining, or other computational activities at a data center, and that is supplied through electrical equipment connected to the Bulk Power System.

Element	April 2026 proposal	August 2026 revision (Board-approved October 8)
Registered function	Computational Load Entity	Computational Load Owner; Computational Load Operator
Size test	Aggregate connected Load capability ≥ 20 MW	Total connected Load ≥ 50 MW
Voltage test	≥ 60 kV	≥ 100 kV
Character test	Hosts ≥ 1 MW of Computational Load	Site primarily contains IT infrastructure
Connection	Single point of interconnection	One or more points of connection

Sources: NERC, Computational Load Entity proposed Rules of Procedure revisions summary (April 1, 2026); Computational Loads proposed Rules of Procedure revisions summary (August 19, 2026); Large Loads Action Plan Q3 2026 Update.

NERC's response to comments explains the changes. It raised the threshold to 50 MW after expanding its analysis to sites planned to be in service by the end of 2027, and noted that 50 MW is generally aligned with some RTO and ISO large load definitions. It replaced "aggregate connected Load capability" with "total connected Load," meaning all the electrical equipment in the site, because commenters could not agree on how to measure capability. It added "supplied through electrical equipment" so the voltage test looks to the bulk-system connection serving the site, not the site's service voltage. And it replaced "single point of interconnection" with "one or more points of connection" to cover multiple interconnections, shared substations and co-located generation. Two points remained open when this edition was finalized: whether the Board-approved text differs in any respect from the August posting, and the docket in which NERC will file it. EC-WP-1005 tracks both.

2.4 Worked scope examples

The examples I used in June read differently under the approved criteria. Measured against both tests:

A 300 MW AI training campus interconnected at 230 kV met all three April prongs comfortably. It meets the August test just as comfortably.
A 25 MW facility connected at 60 kV hosting 5 MW of servers met all three April prongs. It falls below both the 50 MW and the 100 kV thresholds of the August test and is outside the criteria, subject only to the materiality backstop.
A 50 MW industrial load at 138 kV with no information technology load failed the April character prong. It fails the August site definition too, and NERC has stated that manufacturing facilities are not within scope.
A data center whose load is split across several points of interconnection, none individually reaching the threshold, was a real line-drawing problem under the April "single point of interconnection" language. The August language counts total connected Load supplied from one or more points of connection, which largely answers the question. How specific multi-connection and co-located configurations are treated will be addressed in an ERO Registration Reference document NERC and the Regional Entities have said they will develop once the criteria are final, as they did for Category 1 and Category 2 Generator Owners and Operators.

The interesting cases still sit at the edges. A 75 MW site with its service delivered at 69 kV from a 138 kV transformation owned by the utility. A campus whose IT share grows until it primarily contains information technology infrastructure. A site whose connected Load crosses 50 MW in a later phase. The approved language answers some of these, and the Registration Reference document will answer more. I expect the early determinations to set the precedent the later ones follow. Entities within reach of the criteria should assess each element of the test against the facility's actual characteristics before any Regional Entity engagement, document the analysis, and flag the points that depend on rules still being finalized. The next chapter turns to where the operative language lives.

Chapter 3. The Rules of Procedure Machinery

A new obligation requires a change to the rulebook. NERC cannot create a registered-entity category by announcement. Its authority to register entities and apply Reliability Standards runs through its Rules of Procedure, and adding computational loads required revisions to three appendices. That machinery is not academic. It is where the definitions are set, where the obligations are anchored, and where an affected entity had a formal opportunity to shape the outcome.

3.1 The three appendices

To add the new functions, NERC revised three parts of its Rules of Procedure, each doing distinct work:

Appendix 2, Definitions Used in the Rules of Procedure. The April proposal added "Computational Load" and "Computational Load Entity." The August revision replaced them with "Computational Load Site," "Computational Load Owner" and "Computational Load Operator." Definitions are foundational. The scope of the entire registration follows from how these terms are written.
Appendix 5A, Organization Registration and Certification Manual. The procedural manual for how organizations register, how registration disputes go to a NERC-led Registration Review Panel, and how registration decisions are appealed. The revisions add the Computational Load Owner (CLO) and Computational Load Operator (CLOP) to the list of entities required to register.
Appendix 5B, Statement of Compliance Registry Criteria. The criteria that determine who must register for each function, the materiality provisions, the sub-set list mechanism and the transfer-of-responsibility exclusion. The new thresholds live here, in Section III(c).

Read together, the three appendices show how the registration operates. Appendix 2 defines what a Computational Load Site is and who owns and operates it. Appendix 5B defines which owners and operators must register. Appendix 5A defines how registration happens and how a determination can be tested. The obligations themselves come from the standards that apply to the registered function.

The April comment period was the most consequential venue for substantive engagement, and the record proves it. NERC received 32 sets of comments from 44 commenters. Comments from data center operators, utilities, RTOs and trade groups changed the function, the size test, the voltage test, the character test and the connection language. Comments that raised specific technical concerns, supported by evidence of how the text would operate, moved the outcome. That is the lesson to carry into the next round.

3.2 Alignment with the standards project

The Rules of Procedure revisions do not stand alone. NERC coordinated them with Project 2026-02, the standards project examined in EC-WP-1001, so that the registry definitions and the applicability of the standards stay aligned. The project's Standard Authorization Request, dated February 20, 2026, set two goals: Glossary changes consistent with the registry criteria, and a Reliability Standard addressing the reliability issues of integrating these loads. It tentatively defined "Computational Load" and "Computational Load Entity" for the Glossary. When the registry criteria changed in August, the standards changed with them, and the CLO standards use the Computational Load Site, Owner and Operator terms.

Parallel sequencing is how registration and requirements arrive together. If registration produced a registered population before the standards existed, those entities would be subject only to standards of general applicability, which would understate what the registration is meant to capture. If the standards advanced without the registration, they would apply to an unsettled population and invite disputes about who is in. FERC's July 16, 2026 order in Docket No. RD26-7-000 locked the two tracks together by directing NERC to file the standards by December 31, 2026 and stating its expectation that the registry criteria would be filed by the same date.

3.3 The comment process was where the influence was

Both comment windows on the registry criteria have closed: April 1 to May 15, 2026 for the original proposal, and August 19 to September 18, 2026 for the revision. Comments went to [email protected]. Those windows were the principal points at which a prospective registrant or an industry coalition could influence where the thresholds landed and how the definitions were written. The entities that engaged helped shape the criteria they will live under. Those that sat out inherited the result.

The machinery has one more step. Section 1402 of the Rules of Procedure requires Board approval after notice and comment, then submission to the Applicable Governmental Authorities, and provides that no amendment is effective until those authorities approve it. The Board acted on October 8. FERC review is next, and a FERC proceeding on the filing will carry its own opportunity to be heard.

For our clients and prospective registrants, the practical takeaway is to treat these proceedings as live and consequential. Engagement is still available. Two Phase 2 Standard Authorization Requests, one on event reporting and model validation and one on load loss in planning and operations studies, are open for comment through October 22, 2026. A separate SAR on disturbance performance and ride-through is scheduled to go to the Reliability and Security Technical Committee on October 20 and the Standards Committee on October 21. Early intervention works best. A technically credible comment on a SAR can shape the drafting team's framing before any text exists. A comment on a draft standard can reshape specific requirements. After final adoption, the substantive drafting is over. Plan participation around the calendar, not around the moment a requirement becomes uncomfortable.

Chapter 4. How Registration Actually Happens

Meeting the criteria and being registered are two different events. Once the criteria take effect, a facility that meets them does not simply receive a letter. NERC's registration framework runs through a defined process: an application through a central system, backstopped by NERC's and the Regional Entities' own obligation to identify and register entities, and bounded by an entity's right to challenge. That process tells a prospective registrant what it will be expected to do, and when.

4.1 Registration through CORES

Under Appendix 5A, entities begin registration by submitting an application to the Regional Entity of each Region where they perform or intend to perform the function, through an online application hosted by NERC. That application lives in the Centralized Organization Registration ERO System, CORES, in the ERO Portal. Section 501 of the Rules of Procedure puts the burden on the bulk power system's owners, operators and users to provide the information needed to complete registration and to keep it current. For a computational load, the obligation to come forward is, in the first instance, the entity's own. Once the criteria are effective and a site meets them, the expectation is that its owner and operator register rather than wait to be found.

That is a meaningful shift for organizations used to being customers. A data center developer deals with the grid as a purchaser of interconnection and energy service. Registration asks the same organization to step into the role of a regulated entity: to identify that it meets the criteria, enter CORES, and supply the registration information. The administrative act is modest. The conceptual shift is not.

The application is the front door, but it is not the whole house. In CORES the applicant enters corporate information, holding company and affiliates, compliance contacts, the functions it is registering for with an expected date, and a functional mapping, and uploads supporting documents. The Regional Entity reviews the submission and either approves it or sends it back for more information, NERC approves where applicable, and NERC sends the registration letter. Behind that procedure sits a substantive determination: the submission must be consistent with the functional definitions and registry criteria. For computational loads there is an added step. On October 8 the Board authorized expedited procedures under Section 1606 to develop a Section 1600 data request supporting registration of Computational Load Owners and Operators, pending FERC approval of the criteria. Expect that data request to be how NERC builds its first picture of who should register.

In my experience the materiality determination is a conversation more than a calculation. NERC has said Regional Entity staff will assist candidates in assessing the voltage threshold and connection configuration, and I expect the same pattern I have seen with other functions: a request for information, a technical review of the facility's electrical characteristics and operating posture, and an opportunity to register or explain why registration is not warranted. Entities that engage that process in good faith reach predictable outcomes, and entities that resist or delay find the conversation escalating in ways that are harder to manage. Assume the question will be asked and be ready to answer it.

Treat every exchange with the Regional Entity as part of the registration record. A submission that is internally inconsistent, or that the Regional Entity finds non-responsive to follow-up questions, can produce a registration record that complicates audits long after registration is complete.

4.2 NERC and the Regional Entities will also identify entities

Self-initiated registration is not the only path in. Appendix 5A provides that registration may also be initiated by a Regional Entity, NERC or an Applicable Governmental Authority, and Appendix 5B states that if NERC or a Regional Entity encounters an organization that should be on the registry but is not, it is obligated to initiate action to add it, subject to the organization's right to challenge. Any entity may also recommend in writing, with supporting documentation, that an organization be added to or removed from the registry. A site that meets the criteria cannot avoid registration by not volunteering. The realistic planning assumption for an in-scope site is registration, one way or the other.

Appendix 5B adds a point that matters for timing. An entity placed on the registry after it should have been is not subject to a penalty for actions before registration, but it may be required to follow a Remedial Action Directive or Mitigation Plan to become compliant. Waiting to be found buys nothing.

What a registered computational load must do is no longer a forecast. The three standards that passed final ballot in October 2026 define the job. CLO-001-1 covers interconnection, studies and modeling data, including Model Verification documentation. CLO-002-1 covers operational data, compliance with Operating Instructions, Interpersonal Communication and three-part communication training, and is the only standard with obligations for the Computational Load Operator. CLO-003-1 covers sequence of event, fault and dynamic disturbance recording and protection settings coordination. Ride-through, event reporting and model validation against measured events are Phase 2 subjects. EC-WP-1005 walks through every requirement.

First-cycle audits of these entities will, in my view, focus on program design as much as substantive compliance, because the standards phase in over months and years after their effective date. Audit teams in early cycles will want to see how the program was designed, who owns it, what evidence it produces, and how the entity is preparing for the requirements still phasing in. Entities that arrive with a credible design complete the cycle in better standing than those that do not, whatever position they take on a specific requirement.

4.3 The right to challenge

Registration is not unilateral. Section 501 of the Rules of Procedure allows any organization placed on the registry to challenge its placement. Appendix 5A routes registration disagreements first to a NERC-led Registration Review Panel and then, on appeal within 21 days of the NERC determination, to the Compliance Committee of NERC's Board. The Compliance Committee's decision is final unless appealed to the Applicable Governmental Authority, FERC in the United States, within 21 days. The same framework lets a Regional Entity seek to register an entity below the criteria where it can show materiality, and lets an entity that meets the criteria seek exclusion where it can show it is not material. The criteria create a strong presumption, but a mis-fit case in either direction has a defined channel. A facility with a real argument that it does not belong on the registry has recourse, and it should expect to carry the burden of proving it.

Disputes over registration are consequential when they happen. An entity considering a challenge should weigh the merits and the strategy. A successful challenge creates a precedent that may influence other determinations. An unsuccessful one creates a record that can complicate the entity's ongoing relationship with its Regional Entity.

4.4 Timing relative to the standards

Registration and obligation are sequenced, and the sequence is now visible. Appendix 5B provides that compliance begins at the later of inclusion on the registry and governmental approval of the standards applicable to the registered entity. Section 501 makes a registered entity responsible for its applicable standards from the time it receives NERC's registration notice. The CLO implementation plans make each standard effective on the first day of the first calendar quarter after FERC's approving order takes effect, phase individual requirements in from three to thirty-six months after that date, and state that Computational Load Owners are expected to be registered beginning in 2027. The communications and Operating Instruction requirements of CLO-002-1 arrive at twelve months. The gap between registered and obligated is short by design, and preparation should not wait for FERC.

Entities with sites in more than one Region need to plan for coordination across Regional Entities. Appendix 5A requires a separate registration application to each Regional Entity where the entity operates, with NERC coordinating when an entity registers with several. Each Regional Entity runs its own audit program and has its own expectations. A multi-region entity should plan its program to accommodate regional differences while keeping enough internal consistency that it does not split into parallel sub-programs that drift apart.

Multi-region entities also face the choice between centralized compliance leadership and regional staffing. Both work. Centralized compliance produces consistency, puts senior expertise to work across the fleet, and is easier to govern. Regional staffing builds closer relationships with each Regional Entity and responds faster to regional differences. The right choice depends on the organization's structure, its tolerance for variation, and whether it has senior compliance leaders willing to work across regional lines.

Chapter 5. What Registration Obligates

Registration is a gateway, and what lies beyond it is a different regulatory world. A registered entity is no longer merely a participant in the power system. It is subject to mandatory Reliability Standards, to the program that monitors and enforces them, and to the federal authority that backs them. This chapter sets out the shape of those obligations. Building and running the compliance program is the subject of EC-WP-1004. The purpose here is to make clear what registration commits an entity to.

5.1 Subject to mandatory Reliability Standards

The defining consequence of registration is that the entity becomes subject to the Reliability Standards applicable to its function. These are mandatory, enforceable requirements, unlike the alert recommendations and guidelines examined earlier in this series. Section 215 of the Federal Power Act requires all users, owners and operators of the bulk power system to comply with approved standards. NERC staff's recommended approach in the Project 2026-02 SAR was to address the most urgent issues in new, focused standards rather than reopen many existing standards at once, and to fold that work into existing standards in later phases. The drafting team produced three new standards plus conforming revisions FAC-001-5 and FAC-002-5. The obligations track the concerns documented throughout the action plan: interconnection requirements and studies, modeling data and verification, operational data, Operating Instructions and communications, disturbance recording and protection coordination.

Comparison to other functional registrations clarifies what is new. Transmission Owner registration tracks ownership of qualifying transmission elements. Generator Owner registration tracks ownership of qualifying generation. Distribution Provider registration turns on criteria such as serving more than 75 MW of peak Load directly connected to the BES. Each category is grounded in a defined role. The computational load registration follows the same pattern, and the August revision made it more familiar still by splitting owner from operator the way NERC has long split Generator Owner from Generator Operator. The novel element is the load-side framing. The registration machinery itself is familiar ground.

The first day as a registered computational load is not dramatically different from the day before, but the posture is permanently different. The facility now carries evidence obligations, self-reporting obligations, audit-cycle expectations and a relationship with its Regional Entity that will run as long as the facility operates. The program disciplines that support those obligations, described in EC-WP-1004, should be in place before registration takes effect. Entities that wait until registration to design the program spend the first cycle on defense. Entities that design it in advance start the first cycle in good standing.

Coordination with neighboring registered entities deserves early attention. A registered site does not operate in isolation. Its disconnection behavior affects the Transmission Operator it connects to, the Balancing Authority for its area, and the Reliability Coordinator with wide-area responsibility. The CLO standards make much of that coordination mandatory: CLO-001-1 requires coordination on interconnection studies, CLO-002-1 requires the operator to satisfy data specifications from the Transmission Operator, Balancing Authority and Reliability Coordinator and to maintain Interpersonal Communication with the Transmission Operator and Balancing Authority, and CLO-003-1 requires protection settings coordination with the owners of electrically joined equipment. Put those relationships in writing, exercise them in advance, and keep them as part of the program's evidence.

5.2 The sub-set list: tailored, not total

A computational load does not automatically inherit the entire body of NERC Reliability Standards. Appendix 5B allows NERC to limit the obligations of a given entity, or a similarly situated class of entities, to a sub-set list of Reliability Standards, which may specify particular requirements. When NERC sets a sub-set list for a class, it posts the eligibility criteria and the list on its Registration and Certification page. Appendix 5A carries the same limit: a registered entity granted a sub-set list is responsible only for that list. In practice, the applicability sections of the CLO standards already do much of the tailoring by naming the Computational Load Owner and Operator. An entity assessing its obligations should look at the standards that name its function, not the full standards body.

Coordination with the Transmission Owner and Transmission Operator at the point of connection is where those standards turn operational. Under CLO-001-1 the Transmission Owner documents interconnection requirements for Computational Load Sites, and the Planning Coordinator and Transmission Planners set the modeling data requirements the owner must meet. Under CLO-002-1 the Transmission Operator issues the data specification and the Operating Instructions the operator must follow. The site and those entities must agree on data-sharing protocols, modeling cases, operating procedures and real-time communication channels. Document the agreements, exercise them, and update them as the facility changes. In my experience, a relationship built before the first event holds up better than one built during it.

Balancing Authority coordination follows the same logic one layer up. The Balancing Authority has area-wide responsibility, and a load that can move frequency on disconnection is part of its reliability picture. CLO-002-1 requires the Balancing Authority to maintain and distribute its own data specification and to maintain Interpersonal Communication capability with each Computational Load Operator in its area. The flow of information should be designed so the Balancing Authority is never surprised by the site's behavior.

5.3 The Compliance Monitoring and Enforcement Program

Mandatory standards come with a mandatory compliance regime. Registered entities are subject to the Compliance Monitoring and Enforcement Program in Appendix 4C of the Rules of Procedure. Its compliance monitoring processes include compliance audits, self-certifications, spot checks, compliance investigations, self-reports, self-logging, periodic data submittals and complaints, and an entity found in noncompliance must mitigate it. Registration means accepting those obligations: keeping evidence that demonstrates compliance, responding to data requests, self-reporting possible violations, and remediating them through mitigation plans. For an organization that has never operated inside this regime, the cultural and operational shift is significant. It is the reason EC-WP-1004 is devoted entirely to building and defending the program.

Reliability Coordinator coordination is the third layer. The Reliability Coordinator has the wide-area view and the authority to prevent or mitigate emergencies that individual Transmission Operators and Balancing Authorities cannot handle alone. CLO-002-1 requires the Reliability Coordinator to maintain and distribute a data specification for Computational Load Sites, and a Computational Load Operator must follow Operating Instructions from its Reliability Coordinator as well as its Transmission Operator and Balancing Authority. For most sites, day-to-day coordination will run through the Transmission Operator and Balancing Authority. Sites at the edge of an area, or whose disconnection could affect neighboring areas, may need direct engagement. Know where your site sits in the Reliability Coordinator's area and how data and instructions flow to and from it.

Event coordination is the stress test for these relationships. An entity that has documented protocols with its Transmission Operator and Balancing Authority, has exercised them in joint drills, and gives the responsible operators real-time visibility is positioned to coordinate during a disturbance. An entity without those preparations is not, and that is the outcome that produces post-event findings and the regulatory attention that follows them.

5.4 FERC enforcement risk

Behind NERC's enforcement sits the Federal Energy Regulatory Commission. Under Section 215(e) of the Federal Power Act, NERC may impose penalties on a user, owner or operator of the bulk power system for violating an approved standard, subject to FERC review, and FERC may order compliance and impose penalties on its own motion. Registered entities face real financial and reputational exposure, a category of risk most data center and cryptocurrency operators have never carried. That exposure is the strongest practical argument for engaging early, both in the remaining standards work and in building a compliant program before the obligations attach. Discovering the obligations through an enforcement action costs far more than preparing for them.

Documented coordination produces compliance value and operational value at once. A written agreement with the Transmission Operator, Balancing Authority and Reliability Coordinator describes the data flows, modeling cases, operating procedures and communication channels the parties use. It is reviewed during audits, exercised during drills and invoked during events. Informal arrangements break down when they are needed most: during events, after staff turnover, or when an auditor asks what the arrangement was.

Chapter 6. Structuring Options and the Materiality Question

The registration question is not always a simple yes or no. NERC's framework contains mechanisms that affect who actually carries the compliance obligation, how it is divided among related organizations, and whether a facility near the thresholds is pulled in or left out. For a sophisticated operator these are not loopholes. They are legitimate structuring and engagement options, and understanding them is part of understanding the registration.

6.1 Who registers: from end-user and host to owner and operator

The April proposal reached both the end-user that receives power for Computational Load and the entity that hosts end-users. NERC's technical reasoning explained that the host language was meant for scenarios where a data center hosts tenants and may be the more appropriate registrant. Commenters asked who would register in a multi-tenant facility, and whether the registrant should be the operator of the facility. NERC agreed that two functions give more clarity. The August revision replaced the Computational Load Entity with the Computational Load Owner, the entity that owns and maintains a Computational Load Site, and the Computational Load Operator, the entity that operates it, and removed the end-user and host language. In some circumstances one entity is both and registers for both functions.

That change matters for the increasingly common arrangements where one company owns a campus, another operates it, and tenants own the computing equipment inside. The registration follows ownership and operation of the site, not ownership of the servers. Where a developer owns the site and a separate company runs it, expect two registrations and two sets of obligations, with the CLO-002-1 operating requirements falling on the operator. Operators of colocation and multi-tenant facilities should settle now which entity will register for which function, and paper it.

The inverter-based resource precedent is instructive. NERC has said that, as it did once the Category 1 and Category 2 Generator Owner and Operator criteria were approved, it and the Regional Entities will develop an ERO Registration Reference document on how the computational load criteria apply to specific configurations. My expectation from the IBR experience is that the first cycle of computational load audits will be careful, that the drafting community will revise the requirements once operational experience is in hand, and that program expectations will mature over the first several years.

6.2 Transferring and sharing the obligation

NERC's rules allow compliance responsibility to be divided among related entities through formal instruments. Section 507 of the Rules of Procedure provides for Joint Registration Organizations, where one entity registers on behalf of others for specified functions. Section 508 provides for Coordinated Functional Registrations, where entities divide compliance responsibility for particular standards or requirements by written agreement. Appendix 5B adds an exclusion: an entity will not be registered on the basis of the criteria if responsibility for compliance has been transferred by written agreement to another entity that has registered for the appropriate function, including through bilateral agreements and Sections 501, 507 and 508. For computational loads embedded in larger corporate or contractual structures, such as an owner and an operator, a host and its tenants, or a load co-located with a generator, these instruments decide where the obligation actually lands. Structure them deliberately, not by default.

The co-located case deserves its own attention. CLO-001-1 and CLO-003-1 both name the Generator Owner in their applicability. A Generator Owner whose Facility carries a Computational Load Site interconnection, or who owns the main power transformer serving a site, picks up obligations of its own. Project agreements for generation built to serve a data center should allocate those duties with the standards in view. EC-WP-1005 covers this in detail.

Program maturity follows a recognizable path. In my experience, the first audit cycle establishes the program, the second refines it based on what the first audit found, and the third stabilizes it in a form that can run without constant reinvestment. By the fourth or fifth cycle, compliance is part of how the facility runs rather than a separate workstream. Entities that approach registration with that path in mind design programs that can mature. Entities that treat it as a project to finish find the program harder to sustain.

6.3 The materiality backstop, in both directions

The criteria are a presumption, not an absolute boundary. Appendix 5B allows an entity below the criteria to be registered if it is shown to have a material impact on reliability, and an entity that meets the criteria to be excluded if it is shown to NERC that it does not. Either decision must be made by the NERC-led Registration Review Panel. This cuts both ways. A facility just under a threshold cannot treat the numbers as a guaranteed safe harbor if its actual reliability impact is significant. A facility that nominally meets the criteria but presents no material risk has a basis to seek exclusion. The closer a facility sits to the thresholds, the more the analysis turns on the specific facts, and the more a rigorous, documented assessment of its actual bulk-system impact is worth.

Long-term governance of the registration will follow the pattern of other functional categories. Rules of Procedure revisions will refine the criteria. Standards revisions will refine the obligations, starting with the Phase 2 projects already in motion. Regional Entity practice will build up through audit results and the Registration Reference document. Over five to ten years, I expect a mature category with clear expectations and predictable enforcement. Entities registering now are registering during the formative period, and the posture they take, engaged or defensive, will shape both their own experience and how the category develops.

6.4 Size, risk, and the case for engagement

Underlying all of this is NERC's two-part view of risk: individual size and behavior on one hand, aggregate impact on the other. That view justified the thresholds, the materiality backstop and the tailored standards, and it shapes how an entity should think about its own position. A site well above the thresholds has little to gain from contesting registration and much to gain from shaping the standards it will live under. A site near the thresholds has a genuine analytical question worth resolving carefully. In both cases the rational posture is engagement: in the remaining comment and ballot opportunities, in the materiality analysis, and in structuring compliance responsibility.

Calendar tracking is the last piece of the institutional picture. NERC's Reliability Standards Under Development page shows which projects are active, what stage each has reached, and what postings and ballots are coming. Practitioners following the computational load work should also follow the adjacent families, because the Phase 2 SARs already propose changes to TPL, FAC and IRO standards and model validation in the manner of MOD-026. Treat the standards calendar as one coordinated workstream.

Chapter 7. Implications and What to Do Now

The registration decision sets everything else in motion. An organization that concludes it will be a Computational Load Owner or Operator has, in that moment, become a prospective regulated entity with a defined path ahead of it. The right response is not to wait for FERC to act, but to act on the visibility the process already provides.

7.1 Determine scope against the operative criteria

The first task is an honest, documented scope determination: does the site meet the 50 MW total connected Load and 100 kV tests, counting all points of connection, and does it primarily contain information technology infrastructure, measured against the operative Appendix 5B and Appendix 2 language rather than a paraphrase? For most large data centers the answer will be plainly yes. For sites near a threshold, with connected Load close to 50 MW, a supply arrangement where the 100 kV question depends on who owns the transformation, a mixed-use campus, or a co-located generator, the determination requires care. Reduce it to a documented analysis the entity can stand behind and, if needed, use to support a registration position or a challenge. Then decide which legal entity registers as owner and which as operator. This is evidence-anchored scope work, and it is what disciplined compliance practice looks like.

7.2 Engage in the proceedings

Second, engage while the rules can still move. The registry criteria have been through two comment rounds and Board approval, and a FERC proceeding will follow the filing. The Phase 1 standards await Board adoption. The Phase 2 SARs on event reporting, model validation and load-loss studies are open for comment through October 22, 2026, and the ride-through SAR is moving through committee approval. An in-scope entity still has a direct, time-limited path to influence what comes next. Given the FERC enforcement exposure that registration carries, the cost of engagement is small against the cost of living under requirements shaped entirely by others.

Some habits are worth building. Read NERC postings regularly. Attend standards drafting and working group meetings when the subject touches your sites. Join the industry associations working the issue. Build relationships with the Regional Entity staff who will oversee your registration. None of these is demanding on its own. Together they keep a compliance team ahead of the regulatory curve instead of behind it.

7.3 Prepare the structure and the program

Third, settle the structural and program questions before they become urgent. Decide how the compliance obligation will be allocated among owner, operator, host and tenant, and whether a Joint Registration Organization, a Coordinated Functional Registration or a written transfer of responsibility fits the ownership. Secure modeling data and verification rights in vendor contracts. Decide who owns the main power transformer and the recording obligations that come with it. Staff and train a point of contact for Operating Instructions. Begin assembling the evidence and processes registration will require, instead of waiting for the first audit or self-certification to reveal the gaps. With CLO-002-1's communications requirements arriving twelve months after the effective date, the runway is short.

Texas owners carry a parallel state track. The Public Utility Commission of Texas adopted new 16 TAC §25.194, Large Load Interconnection Standards, in Project No. 58481 by order filed September 18, 2026, effective October 8, 2026 according to the Texas Register acknowledgment in the project file. The rule implements Senate Bill 6 and, among other things, requires a large load customer to execute an intermediate agreement, make specified disclosures and post financial security of $50,000 per MW before it can be included in an ERCOT interconnection study. State interconnection obligations and NERC registration run on separate tracks, and a Texas site will likely face both.

7.4 The bridge to the rest of the series

This book has answered the entity-layer questions: who is captured, how registration happens, and what it obligates. It has not addressed the questions that follow a "yes" on registration. Those are covered in the remaining books:

The owner layer (EC-WP-1003): the data center owner's playbook under Texas Senate Bill 6, the most developed state framework, and the co-location decision.
The operating layer (EC-WP-1004): building, evidencing and defending the compliance program of a registered computational load, including controls, governance, evidence and audit defense.
The 2026 update (EC-WP-1005): the approved criteria, CLO-001-1, CLO-002-1 and CLO-003-1 requirement by requirement, the Generator Owner's exposure and the compliance calendar.

The grid layer explained why these obligations exist. The standards layer explained how NERC creates them. This entity layer determined who they fall on. What remains is the work of carrying them, and that is where the analysis becomes operational.

Glossary of Terms

The following terms are used throughout this whitepaper. Definitions are summarized for convenience; the operative definitions are those in the governing NERC Rules of Procedure and Reliability Standards.

Aggregate Connected Load Capability. The size measure in the April 2026 Computational Load Entity proposal, which set the threshold at 20 MW or greater at a single point of interconnection. The August 2026 revision replaced it with total connected Load.

Appendix 2 (Rules of Procedure). The appendix containing definitions used in NERC's Rules of Procedure. The Board-approved revisions add Computational Load Site, Computational Load Owner and Computational Load Operator.

Appendix 5A (Rules of Procedure). The Organization Registration and Certification Manual, which governs how organizations register, the NERC-led Registration Review Panel, and registration appeals. The revisions add CLO and CLOP as entities required to register.

Appendix 5B (Rules of Procedure). The Statement of Compliance Registry Criteria, which sets the thresholds that determine who must register for each function, the materiality provisions, the sub-set list mechanism and the transfer exclusion. The computational load criteria are in Section III(c).

Compliance Monitoring and Enforcement Program (CMEP). NERC's program, in Appendix 4C of the Rules of Procedure, for monitoring compliance through audits, self-certifications, spot checks, investigations, self-reports, self-logging, periodic data submittals and complaints, and for enforcement and mitigation.

Computational Load. In the April 2026 proposal, Load comprised of electric power demand from information technology equipment such as servers, storage and networking hardware. The August 2026 revision did not carry this term into the registry criteria.

Computational Load Entity (CLE). The single registered function NERC proposed in April 2026 for large computational loads. Superseded by the Computational Load Owner and Computational Load Operator.

Computational Load Operator (CLOP). The entity that operates a Computational Load Site.

Computational Load Owner (CLO). The entity that owns and maintains a Computational Load Site.

Computational Load Site. One or more buildings, structures or installations at a single location that primarily contains information technology infrastructure for software applications, artificial intelligence, cryptocurrency mining or other computational activities at a data center, supplied through electrical equipment connected to the Bulk Power System.

Coordinated Functional Registration (CFR). A registration under Section 508 of the Rules of Procedure in which two or more entities divide compliance responsibility for particular standards or requirements by written agreement.

CORES. The Centralized Organization Registration ERO System, the registration application in NERC's ERO Portal through which organizations apply to register.

ERO Registration Reference document. A document NERC and the Regional Entities have said they will develop to explain how the computational load criteria apply to specific configurations, as they did for Category 1 and Category 2 Generator Owners and Operators.

Joint Registration Organization (JRO). A registration under Section 507 of the Rules of Procedure in which one entity registers on behalf of others for one or more functions.

Large Loads Working Group (LLWG). The NERC Reliability and Security Technical Committee group, established as the Large Loads Task Force in August 2024, whose analysis underlies the Large Loads Action Plan and the registration and standards work.

Materiality. The principle in Appendix 5B that NERC registers the owners, operators and users of the bulk power system that have a material impact on its reliability. Decisions to register below the criteria or exclude above them are made by a NERC-led Registration Review Panel.

Point of Connection. The location where a facility is supplied from the bulk power system. The approved criteria count total connected Load supplied from one or more points of connection.

Project 2026-02. NERC's standards project for computational loads, which produced CLO-001-1, CLO-002-1 and CLO-003-1 and the conforming revisions FAC-001-5 and FAC-002-5.

Registered Entity. An organization listed on the NERC Compliance Registry for one or more functions, and therefore subject to the applicable Reliability Standards and the CMEP.

Registration Review Panel. The NERC-led panel under Appendix 5A, Section III(D), that decides registration disputes, including materiality-based inclusion and exclusion.

Standard Authorization Request (SAR). The request on which a NERC standards project is based. The Project 2026-02 SAR is dated February 20, 2026.

Sub-Set List. A limited list of Reliability Standards, which may specify particular requirements, that NERC may apply to a registered entity or a similarly situated class of entities under Appendix 5B.

How Energy Compliance Can Help

This book ends where the work starts. If your site is within reach of 50 MW at 100 kV, three things need doing before NERC's registration outreach begins, and we do all three.

Registration. A documented scope determination against the operative Appendix 5B and Appendix 2 language, the owner-versus-operator decision, the CORES application, and, where the facts support it, a materiality position for the Registration Review Panel. The process for a computational load runs through the same Appendix 5A manual as every other function.

Compliance program management. The CLO standards arrive on a phased clock, and the communications and Operating Instruction requirements of CLO-002-1 land twelve months after the effective date. We build the program, the evidence structure and the coordination agreements with the Transmission Operator, Balancing Authority and Reliability Coordinator before the first self-certification asks for them.

RSAW production and audit defense. When the first audit cycle comes, the entity that can put sourced evidence behind each requirement finishes in better standing. That is our core practice.

WattOps Compliance is EC's NERC compliance evidence platform, at wattopscompliance.com. For a newly registered owner or operator it is where the evidence lives from day one. We will run one standard at one facility through WattOps at no cost so you can see how it fits; CIP standards are excluded from that offer.

RenewOps is EC's renewable operations monitoring and analytics platform, and it includes a Data Center module. Where a site's operations data has to reach the operator, the owner and the compliance program at the same time, that is the tool we bring.

Start with the scope determination. Send me the one-line, the connected Load figure and the ownership structure, and I will tell you where the site sits against the criteria.

Website: energycomplianceinc.com · Email: [email protected] · Phone: 763.438.4427

About the Author

Rob Smith is the Founder and Principal of Energy Compliance, Inc., with more than thirty years in the industry on every side of the system. He began in control-room operations as a Reliability Coordinator, Transmission Operator, and Power System Operator across RTO/ISO and utility control centers. On the regulator side, he was a senior compliance auditor and subject matter expert for NERC Reliability Standards. He audited grid facilities, evaluated mitigation adequacy, participated in risk-based oversight of utility mitigation activities, and supported the development of violation notifications and settlements in FERC-directed enforcement actions. He conducted a regulatory audit in the Sultanate of Oman against the Sultanate's Sector Law and Grid Code.

He founded Energy Compliance, Inc. to deliver senior regulator-side compliance authority without the layered staffing and billable-hour overhead of larger firms.

Education:

MBA, Energy Management, University of Mary
MSL, Compliance Law, Fordham Law University
BAS, Energy Management, Bismarck State College
BAS, Mechanical Engineering, Metallurgy minor, University of Florida
BAS, Criminology, St. Petersburg College (State Law Enforcement Certification)
AAS, Power Plant Technology, Bismarck State College
AAS, Electrical Transmission System Technology, Bismarck State College

Certifications: NERC Lead Auditor training; previously NERC-certified at the Reliability Coordinator level; 1st Class A Boiler Engineer License, Minnesota.

About Energy Compliance, Inc.

Energy Compliance, Inc. is a regulatory compliance consultancy serving the energy sector, with a focus on NERC, FERC, and RTO/ISO compliance and a particular concentration in the Texas PUCT and RTO/ISO markets. The firm helps registered entities and prospective registrants through the full compliance lifecycle, from registration and program design through evidence development, RSAW production, mitigation, and audit defense. That range positions it directly to support organizations facing a computational load registration determination.

The firm's approach is built on a research-analyst-first discipline: every conclusion is tied to an authoritative source, every narrative is evidence-backed, and every deliverable is built to stand up to regulator scrutiny. That discipline extends to two platforms: WattOps Compliance, EC's NERC compliance evidence platform, and RenewOps, EC's renewable operations monitoring and analytics platform with a Data Center module.

This whitepaper is the third in the Energy Compliance Large Load and Data Center Series, a multi-volume analysis of how the integration of data centers and other large computational loads is reshaping bulk-power-system reliability and the compliance obligations of the entities that build, serve, and operate them.

To learn more, or to assess whether a specific facility meets NERC's computational load registry criteria, visit energycomplianceinc.com.