--- title: "NERC Project 2026 02: NERC’s computational‑load rules — a 30‑day checklist for owners, planners and protection engineers" description: NERC Project 2026 02 guidance covers practical lifecycle controls and safer, traceable engineering decisions for teams to review and. url: "https://mangansoftware.com/docs/nerc-project-2026-02/" updated: "2026-10-26" category: Functional Safety News --- # NERC Project 2026 02: NERC’s computational‑load rules — a 30‑day checklist for owners, planners and protection engineers # NERC Project 2026 02: NERC’s computational‑load rules — a 30‑day checklist for owners, planners and protection engineers NERC Project 2026 02 frames a new regulatory baseline for very large computational loads and is the focus of this article. NERC announced on 15 October 2026 that three Computational Loads reliability standards (CLO‑001‑1, CLO‑002‑1 and CLO‑003‑1), together with revisions to FAC‑001/002, passed the final ballot stage and now move toward Board adoption and regulatory filing. The package targets large computational facilities — data centres, AI farms and large mining operations — and establishes registration thresholds, modelling, disturbance monitoring and interconnection expectations that will reshape how owners, planners and protection engineers record decisions and verify performance. [![NERC Project 2026 02 shown as an editorial photo for the BetterDocs news article](https://mangansoftware.com/wp-content/uploads/2026/10/nerc-project-2026-02-editorial-photo-1024x683.jpg)](#elementor-action%3Aaction%3Dpopup%3Aopen%26settings%3DeyJpZCI6IjE5MzAyIiwidG9nZ2xlIjpmYWxzZX0%3D) ## NERC Project 2026 02: Latest Evidence and Technical Context The standards package arising from Project 2026‑02 cleared a significant stakeholder hurdle when the final‑ballot period closed on 14 October 2026 and NERC publicly announced the outcome the following day. The ballot produced three new Reliability Standards — CLO‑001‑1, CLO‑002‑1 and CLO‑003‑1 — plus targeted revisions to existing FAC requirements. Together they are intended to govern the interconnection, modelling, data exchange and disturbance monitoring expectations for large computational loads. Final ballot documents set out scope, registration thresholds (for example, criteria tied to loads of 50 MW or greater and specific connection voltage bands) and implementation plans that include proposed compliance timelines. NERC’s stated next steps are submission to the Board of Trustees for adoption and subsequent filing with applicable regulatory authorities, as directed by the RD26‑7 direction. Those procedural milestones matter because they determine when compliance obligations move from proposal to enforceable requirement. For engineers and planners the immediate relevance is the technical content: required deliverables for interconnection studies, clearer modelling inputs for power‑system studies and explicit monitoring requirements intended to improve ride‑through and recovery behaviour during system disturbances. The original evidence can be reviewed in [North American Electric Reliability Corporation (NERC) Newsroom — NERC’s Computational Loads Standards Pass Final Ballot, Advance to Board Adoption](https://www.nerc.com/?cfu=TAA&cpid=WKUS-Legal-Cheetah). ## Why NERC Project 2026 02 Matters Across the Lifecycle The proposed standards change how project teams and system operators manage the lifecycle of a large computational load from planning through operations. Organisations that host or interconnect computational loads at or above the registration thresholds will need to consider three linked topics: registration and regulatory status, the modelling and test evidence required for interconnection, and operational data sharing and disturbance monitoring once the facility is online. Those items influence protection coordination studies, interconnection study scope, scopes of work for modifications (MOC) where loads interact with generation responses, and asset integrity plans for both distribution and transmission owners. At the plant level this looks like revised inputs to protection relay settings, additional scenarios in dynamic simulations, explicit ride‑through parameters in SRS‑style documents, and nodes in HAZOP/LOPA analyses for large, concentrated load centres. From a process point of view, the practical question is not only “what the standards require” but “how the evidence for a decision is recorded, approved and verified over time.” Clear assignment of ownership for registration, modelling deliverables and operational monitoring, plus a documented verification plan, ensures that decisions remain traceable as the project moves through procurement, commissioning and into steady operation. For related MSS guidance, see [Module Connections](https://mangansoftware.com/docs/instrumented-systems-module-connections/), [IEC 61511 Compliance Explained](https://mangansoftware.com/docs/iec-61511-compliance/), [SIL Determination Explained](https://mangansoftware.com/docs/sil-determination/) and [What Is IEC 61511?](https://mangansoftware.com/docs/iec-61511/). ## Requirements and Practical Controls For utility planners, protection engineers, host operators and integrators the immediate task is to convert the standards’ deliverables into executable work packages. The final‑ballot material lists modelling, data exchange and disturbance monitoring expectations; teams should start by testing whether an installation meets the registration thresholds and, if so, compiling the specific modelling inputs described in the implementation documents. A practical control approach begins with a clear statement of the decision or change, identification of the governing source documents, and engagement of the disciplines needed to validate assumptions. Record what models, boundary conditions and disturbance cases were used; name an owner for each deliverable and set review dates that align with the implementation plan. Where a modification or connection is proposed, scope the Management of Change to include ride‑through verification and operational reporting responsibilities. Suggested verification steps include agreeing steady‑state and dynamic model deliverables, defining disturbance monitoring points and formats, and scheduling commissioning tests that demonstrate the expected ride‑through and recovery behaviour. Importantly, actions should carry named owners, explicit due dates and a follow‑up verification task that confirms the intended outcome was achieved and has been retained in operation. ## How MSS Supports Better Lifecycle Information Controlled lifecycle information and structured workflows make it easier to comply with the new standards without changing where engineering judgement is applied. Mangan Software Solutions provides ways to link source evidence, design artefacts and approval events so that a modelling deliverable, an interconnection agreement or a commissioning test record can be associated with the decision it supported. Workflows can assign ownership, capture assumptions and attach the output of reviews and verification steps, preserving the authoritative basis for a decision as projects move from design through operation. That approach emphasises auditability and findability: when a protection engineer needs to know which disturbance case set relay coordination values, the current technical basis is discoverable and the review history is visible. This does not replace specialist analysis or professional judgement; rather, it keeps the evidence chain intact and makes compliance‑related records easier to locate and maintain as the new CLO standards move from ballot into practice. [Watch a recorded demo](#elementor-action%3Aaction%3Dpopup%3Aopen%26settings%3DeyJpZCI6IjE5NDk5IiwidG9nZ2xlIjpmYWxzZX0%3D)