LLWG Meeting - 10/15/26 - VIDEO

All right, good morning, by my clock it is 9.30 a.m. and we’re about to get started. To begin with, we will start with the antitrust admonition. ERCOT strictly prohibits smart participants and their employees who are engaging in ERCOT activities from using their participation in ERCOT activities as a form for engaging in practices of communication that violate the antitrust laws. The ERCOT Board has approved guidelines for members of the ERCOT Committee, subcommittees, and working groups to be reviewed and followed by each market participant attending ERCOT meetings. If you have not received a copy of these guidelines, they are available at the Client Relations Desk. Please remember your ongoing obligation to comply with all active laws, including antitrust laws. In addition, I will remind everyone who is listening now, ERCOT does not use the raised hand function. If you raise your hand, you will be admonished if we see it. The reason we don’t use it is we can’t see them and we can’t keep track of the cue with the raised hand. So if you would like to make a comment or ask a question, please enter a Q or C in the chat and we will call you in the order in which received. All right, just a quick housekeeping item. Yesterday at PRS, I agreed to take on the NPRR file regarding front of the meter netting. I’m sorry, what? To limitary offsetting. This is going to be a much bigger conversation than just that. We’ll get a presentation today on load sponsored generation as a working group. Working on NPRRs is more challenging than a subcommittee because working groups cannot vote. That means that we can come to consensus items. Other items we can put options out for voting bodies. But it is a little trickier to do. I’m also going to need a small team of dedicated people to work on merging all of the various concepts together so that we can come up with something that works regarding bring your own generation. I personally think bring your own generation is probably close to the most important thing that we work on for the next decade in ERCOT because, frankly, we need generation badly. If we don’t find a way to let these people bring their own generation, we are not going to be happy with the grid we are left with. I think it is critically important we figure out a reasonable way for people to enter the market with their own generation that not only supports them but can also support the broader grid. So we will be having further discussions on that, but we are going to have to figure out how to pull together an NPRR with the various forms of bring your own generation. And it is also important to note to get an NPRR approved, we need the vote of at least four market segments.

So we can’t just do this on an island with just large loads. We need generation. We need transmission. Everybody has got to play together to make all of this happen. So with that, we will get started into our agenda.

Our first update is going to be on what is happening at NERC, and I see Eric heading to the mic.

All right. Good morning, everybody. We are here to give you your monthly NERC, you know, slash TRE update. This month we will just be giving an update on what is happening at the NERC level.

So some of this presentation you have seen before, some of you have not. So just to give you an update, NERC’s Rules of Procedure, this has been approved by the NERC Board of Trustees. So NERC originally proposed an update to the Rules of Procedure to define and register a computational load. On September 30th, you know, NERC had finished processing comments and provided an update to the standard drafting team. So they stated they were not making any changes to the proposed definition, and since last week when I put this slide together, they have put this on the agenda for the board meeting, and last week at the NERC Board of Trustees, they voted to approve this standard, and then NERC is preparing to file it with FERC ahead of the deadline at the end of the year. So they’ve also requested the ability to develop an expedited data request to support load registration. So if approved, it’s going to be presented at the December board meeting. This was approved by the Board of Trustees last week, so be ready. This should be at FERC by the end of the year, and NERC will then begin doing data requests to all entities. It is unclear who exactly will be receiving these data requests, but it could be loads, it could be data centers, it could be transmission providers, and other entities registered within the NERC framework.

So what did NERC approve as a definition of a computational load? It’s one or more buildings, structures, and installations that primarily contain information technology infrastructure used for creating, executing, and delivering software application and services, AI training, delivery, cryptocurrency mining, and other computational activities. Now what’s the threshold? 50 megawatts or more connected to the bulk power system at a 100 kV level from one or more points of connection. So this is applicable to the computational load owner and the computational load operator. So as a reminder, this is approved. This is heading to FERC. If you are, you know, at 50 megawatts or above and you meet these thresholds, you will need to register with your regional entity.

So now what has FERC done in July? FERC made a ruling, a proposed order for NERC to file a set of reliability standards and load registration thresholds by the end of the year. Now the rules of procedure is already on track. And then project 2026-02, which began this year, is working on creating a set of reliability standards in phase one to deliver to FERC. And so right now they’re also following the rest of right through in addition to these. So that’s been moved as a high priority item. So these ballot results were from the initial ballot that was done last month. All standards advanced. This was the highest ballot results ever from the initial ballot of a NERC standard.

Now the ballot went for final ballot from October 9th to October 14th, which was yesterday. NERC has confirmed that all these standards have passed final ballot and are now advancing to the Board of Trustees for approval. And we’ll be headed to FERC. So these are on track to be approved in the NERC round by the end of the year and to be delivered to FERC per the instructions from FERC. So this is not slowing down. This is continuing to move faster than any NERC standard you’ve probably seen.

So what happened since the last comment period and the final ballot? So the standard drafting team reviewed about 1,300 pages of comments that were filed. And they made several updates. These updates were non-substantive. It did not change any of the underlying intent or scope of the requirements that you saw in the first draft. So this corrected some typography, you know, typographical issues, some applicability and violation severity level issues. It aligned the evidence retention language with other NERC standards and templates, clarified some data specifications and operating instruction provisions in TLO002. It clarified implementation extensions and effective date language. It aligned TLO03 requirements with PRC28 and 27. It removed a duplicate technical rationale, clarified some equipment ownership, breakers scope, monitoring location and protection coordination responsibilities. And then finally, it corrected some figures, examples, and outdated references for where standards have been updated. So the standards that you saw earlier, you read and are familiar with, hopefully, have been modified, but the core requirements all remain and are all the same. So all of these changes were just clean up and, again, non-substantive and did not change the underlying intent and scope of the requirements.

So we’re going to give you a quick reminder what these standards are. So CLO001, which is computational load interconnection studies and modeling. So this is drawing upon existing language from FAC1, FAC2, MOD32, and MOD26. All of these standards drew upon existing time-tested and validated language that had already passed the stakeholder community and that we are all used to for the existing registered entities compliant with. They were then modified to add provisions for computational loads where necessary. So the first one is under interconnection requirements and processes. So the standard states that computational load-specific interconnection requirements shall be developed by the transmission owners, distribution providers, and generation owners, and it shall cover coordinated studies, procedures for notification of a new interconnection, or a qualified change. And then for interconnection studies, each transmission planner and planning coordinator shall study the interconnection of a computational load and those seeking to make a qualified change. So the computational load owners shall cooperate with this effort. Studies shall include steady-state, short-circuit, and dynamic studies, and then your TOs, GOs, and DPs shall coordinate on interconnection studies as necessary. And then your planning coordinators shall define a qualified change and make the definition publicly available.

What else? This is going to be the longest one of the three. TPs and PCs have to develop steady-state, dynamic, and short-circuit modeling data requirements and reporting procedures. So what does that mean? It explicitly means parameters, settings, and capabilities related to tripping, write-through, and disturbance recovery. I did not just add those there as an example. Those are the ones explicitly stated in the standard. It also specifies the amount and percentage of information technology infrastructure and the expected use or behaviors of the IT infrastructure. Again, directly in the standard. You must provide a data update at least every 13 months and upon the following events, which do not reset that 13-month clock, which is a post-commissioning modeling change corresponding with the as-built facility, and then any qualified change that is made as defined by the planning coordinator. And then computational load owners shall provide documentation of model verification for the facility, demonstrating that the configurable site-specific parameters are representative of the design and settings of in-service equipment. So just a reminder, every 13 months, you have to provide an update. If at month six, you commissioned or you had a qualified change, you provide that update, and then within seven more months, you still have to provide an update and say, we’ve made some change or there is no change.

So the next standard, CLO 002, is on operational data and communication. This is going to be a big one. So for the operational data, each transmission operator, balancing authority, and reliability coordinator shall maintain the documented specifications for data and information needed to perform operational planning analysis, real-time monitoring, and real-time assessments. They shall provide the data to any entities that need it, and then the CLOs, computational load owners, and computational load operators are required to provide the data. Now, here come the big ones, operating instruction and interpersonal communications. CLOs will have to have communication capabilities to the transmission operator and balancing authority and to the computational load. So that’s from the TLPA to the computational load operator. So this means control room, the control room communication, real-time communication capability. If there is a detection of interpersonal communication capability failure, that needs to be reported and mitigated. And the computational load owners are required to comply with operating instructions from the TO, BA, and RC. And then they shall be initial two-party, person-to-person operating instructions. You shall have training on that, and then follow the instructions like we do for current registered entities and control room to control room communication.

Bob, do you want to ask now or? Yeah, let me go ahead and ask now. So it sounds like we need registration for the CLOs with ERCOT is no longer a question. That’s a done deal. And my question is, is it the CLOs that have a direct communication with ERCOT, or is it the QIESI for the CLO that would have direct communication with the ERCOT? You don’t have to answer at this moment, but to me, it sounds more like the CLOs have direct communication with ERCOT.

Yes, I will decline to answer that one at the moment. I do know where we’re heading with that. But for the NOCC standards, for what we’re focused on now is NOCC will, and the regional entities, so in our region, Texas reliable entity, will be registering the computational load owners and operators. It’ll be the operators that are required to have the interpersonal communication capability. In the ERCOT parlance, that’s more of a QIESI. Okay. All right. Thank you.

I’m the only one with questions. Go ahead. All right. So the next one is CLO-003, computational load protection coordination and disturbance monitoring. So this draws upon PRC-28 and PRC-27. So essentially at each facility, the CLO is going to have sequence of event recording equipment installed. You will have, you know, now depending on who owns the main power transformer that supplies the site, this one’s going to be a bit variable. You will have to have fault recording information and dynamic disturbance recording. Whoever owns that transformer is the one that’s going to install that equipment. So it could be the TO. It could be the computational load owner. And then you’re required to do time synchronization and provide the data upon request. And if device fails, you have to restore that and develop a corrective action plan. So and for protection coordination, each computational load owner shall have to develop a process for new and revised protection system settings to coordinate that within the site and within the affected entities.

All right. What are we looking at for timing? This is fast.

Hmm? Yeah. So how does this work in the note ground is once the standards are approved by FERC, you have to wait a quarter and then the effective dates can start. So if they are approved, say January 1st, the next quarter would be April 1st, 2027. So if it says six months at six months to that, and that is October 1st, 2027.

Now you’re going to see that CLO001 will all take effect plus nine months of the next quarter. So for the most part, that means by the end of 2027.

For CLO002, which is the communication capability and operational data, that is one year after approval. So let’s say it’s approved January 1st, 2027. This would look at April 1st, 2028. All of that capability has to be developed and set up. Now the big one, CLO003, that requires hardware installation. For protection coordination, it’s nine months. But for the installation of SER, FR, and DDR monitoring equipment, for sites that go in service after the effective date, and the effective date is defined at next quarter of, say, April 1st, 2027, you have 15 months to install that equipment and have it ready. For sites that are in service prior to the effective date, say April 1st, 2027, you have 36 months for operational sites to install this equipment.

Now there’s a couple things that, for the 36 months, there is the possibility of deadline extensions under certain circumstances for R1 to R8, and that is for existing sites. Those extensions have to be approved by the regional entity, and it could be up to an additional 24 months.

So what’s left? So the standard drafting team referred the following items to the NERC Large Road Working Group, and some of these items are in progress. Some will be added to the NERC Large Road Working Group’s work plan in 2027. So the first one is disturbance performance and ride-through. I will pause on that one. We’ll touch that one soon. The second is commission and guidance. Third is qualified changes and model and data updates. Fourth is model validation. Fifth is operational and planning studies. Six is on electromagnetic transients. Seventh is co-located facilities. And eighth is sequence of event data, fault codes, and data retention periods.

So where’s the NERC Large Road Working Group? With its standard authorization request, there are three stars in flight. The first one is on ride-through, which is, we call, computational load disturbance performance. So as of Tuesday, this star was approved by the NERC Large Road Working Group. It has went through all its comment periods and drafting periods, and is now advancing to the Reliability and Security Technical Committee, and then to the NERC Standards Committee within the next two weeks. This one, NERC wants to move fast. They are retaining the existing Project 2026-02 team, drafting team, and will be assigning this star to that team. So that means as soon as it passes the Standards Committee, NERC could essentially begin calling meetings to begin drafting as soon as next month. So NERC wants to see this one go as quickly as it can. Its baseline is the OCOT requirements with modifications.

There are two standard authorization requests out for comments on computational load event reporting, model validation, and model quality assessment, and then studying computational load loss in planning and operational studies. Both of these stars are up for comments to October 22nd. We encourage you to please submit comments, provide your feedback on these stars. Once the comments are reviewed and implemented, we have a meeting in November to review this and approve it at the NERC Large Road Working Group, and then advance to the Standards Committee in December. So while NERC is transitioning through the modernization of standards process and procedures, process right now, or MSPP, which has put a hold on standard development for new standards, computational loads are the exception, and NERC will allow these to move forward as quickly as possible. And then the Large Road Working Group is also working on three other work products. So two white papers, one on disturbance performance, which is foundational to the SAR, a second one on study and simulation considerations, and then third, a reliability guideline on computational load commissioning. So this was to provide guidance on commissioning practices to both existing registered entities and then to computational loads. Bob? Bob Goulais Eric, and I guess, is NERC addressing the power variation issue as well? It’s not clear from this whether that’s on the agenda or not. That’s on the roadmap. So do you mean from a dynamic or a balancing perspective? I mean, from the perspective of those computational loads causing oscillations on the system, sub-synchronous oscillation issue caused by… Yeah, so that’s the part about a study and simulation considerations white paper. The second part will be doing a white paper on oscillations and high-speed recording. The issue under NERC ground is there’s no existing NERC standards around oscillations today. So if we are to eventually proceed with standards there, we would be breaking new grounds and have to do so a bit carefully. But once we have the two white papers to sort of lay the technical basis, we can proceed with a reliability guideline, which is the next highest level document below standards that provides guidance. And if that is ineffective, or if we decide it’s needed, we can evaluate potential standards. At the moment, what we’ll say is the reliability guideline and standards around oscillations are to be evaluated as more evidence comes to light. Everything that we’ve seen so far indicates that forced oscillations, nobody has, speaking as Eric, nobody has demonstrated a forced oscillation, and actually beyond an academic study. Now, there have been some… I’ve heard whisperings of it matters in co-located sites for generation and load that are directly next to each other. You may have some impact there. But all the events that we’ve seen to date with regards to more stability concerns have been converter-driven stability issues. So, we’ve seen that in Dominion, we’ve seen that in OCOT, and then it’s heard some whisperings and rumblings elsewhere across the United States, you know. So, in terms of, you know, what the mechanism is, that’s going to be important. It may be a deeper look at some of that converter-driven issues, rather, you know, we’ll also look at the forced oscillation issues. But so far, these two studies that I’ve seen, speaking as Eric, not just OCOT, but like outside that we’ve heard in the No College Road Working Group are forced oscillations are more of a issue for co-located facilities, but nobody’s really seen it propagate outwards yet. Okay, thank you very much.

Okay, so where are we on the standard authorization request roadmap? This is a busy step page. Essentially, the No College Road Working Group published a standard authorization request roadmap earlier this year. Everything in the column on the left is addressed by Project 2026-02. Everything with a green checkbox to Q4 2026 and beyond has been addressed by in-flight SARs already. Now, we are not going to get to the item that says evaluate oscillatory impacts from dynamic computational loads, and we’re not writing a SAR on that by Q4 2026. So what we’re going to be doing is refreshing this roadmap, adjusting some of the dates and adding some more standards supporting activities in it. I’ll also add that in terms of cyber and physical security, NOCC’s Security and Info Sites, Security Integration and Technology Enablement Subcommittee, ooh, mouthful, has elected to take up a white paper and standard authorization request on cyber and physical security related to computational loads. So that one is also in the works in the NOCC realm.

So what’s coming up? Upcoming deadlines. We have two SARs out. We are looking for comments on those. Comments are open until October 22nd. And then what next steps do you all have? You know, NOCC is preparing to issue a data request. If that comes your way, be ready to respond to that and be ready to register with your regional entity. In this case, Texas Reliability Entity, if you meet the registration criteria, and then prepare for implementation of the CLO standards beginning in 2027. So as we talked about earlier, if approved at the beginning of quarter one, 2027, we would expect the very first effective date to hit on 7-1-27 for a compliance date. So review the SARs, file comments if your organization wishes to do so, and then prepare to register if you meet the threshold.

Mark.

This is Mark Henry from Texas RE. Eric’s doing a fine job covering everything. So I wasn’t going to present. I just want to say that the question Bob brought up about, was the QSC going to be the one who did the operational communications? It’s going to be an end-to-end thing. Usually with generators, QSCs do communication with NERC. It’s just the understanding that somebody’s going to be registered as a responsible entity. That could be the owner of the CLO. It could be some kind of joint arrangement, but that will be worked out. These things are in process now to figure out how we’re going to go about registering people, as well as what kind of situations that we’re going to encounter and need to account for. There’ll be a lot of development in that, and I’ll be reporting on that to you in the months ahead. Right now, we really haven’t got anything we can tell you, but rest assured there will need to be some consideration of how things can be accomplished with the structures that we have across the country. That’s all. Thank you. Good job, Eric. Thank you, Mark. Evan Neal, you’re up. Hey, Eric. On this data request, who are we expecting to receive that? Like, what mailing list are you guys working off of? We do not know yet. It was just a file that the Board of Trustees last week. We are trying to decipher that ourselves, but they did not explicitly state it in the filing. Okay, so it’s just more information to come? Yeah. Okay, thanks. All right. Thank you very much, Eric. All right. Thank you. All right. Next up on the agenda, we have a presentation from Dominion.

All right, Nargis, you just have the presenter role now.

We can see your content, but we cannot hear you yet.

You are unmuted on our end.

Hello? Do you hear me? Now we can hear you.

Hello?

I think we can hear you.

Hello? We heard that. We got the hello. Yeah, there we go. Good, good. Okay. Hello. Good morning, I guess. Yes, good morning.

Let me get my screen, please. Patrick, can we try to turn her up a little bit?

Okay. How’s that now? That’s a little better. Let’s go with that. Okay. Okay. And you see my full screen of my presentation?

We can. Okay, good enough. So once again, hello. My name is Nargis Kiasi, and I’m a senior engineer from Strategic Initiative Dominion Energy Virginia. So this presentation, we want to address the data center responses to the recent large load events and an experience that we saw in Dominion Energy for the past few years and what we have done. So we categorized – let me go to the next slide.

Okay. We categorized this presentation into two sections. The first one, we want to review the two selected large load events that we saw in Dominion Energy. One is from July 10, 2024, and the second one is the April 18, 2026. We have some reason to bring these two events up as we want to compare them and show some work that we have done through these two – between these two years. And after that, we want to address the most recent large load event that we saw in our system on July 22, 2026, a couple months ago. And this was kind of the largest event that we saw on our end. So first, the previous event comparison, July 2024 and April 2026. So we had a couple of events since July of 2024, but we decided to go and go for July 2024 and April 2026 for a comparison as these two events were comparable in the magnitude. And also, we saw some differences in the results based on the work that we have done. So the initial load response that we saw for both – when we say these two events are comparable, this means that we are seeing some similarities. So first, I’m going to point out the similarities, and then I’m going to show the difference that we are seeing in the response of the total system and data center. So the initial response for both of these two events were 1500 megawatts. For the July 10, it was like 7% of the load prior to the event. And for April 18, it was like 12% of the load prior to the event for the total system. The number of voltage sags, especially on our customer side, what we were tracking was six voltage sags for both of these two events. Minimum voltage sags was comparable for both of them, 68% on July 10 and 63% or 64% on April 18. Maximum voltage sag duration was, again, kind of comparable, 75 millisecond for July 10, 67 millisecond for April 18. And impacted substation was 22 for both of these two events. When we say impacted substation, we have defined the impacted substation as any substation that has a transformer that saw more than 4 megawatt. The threshold is 4 megawatt. Any that they have any transformer that saw more than 4 megawatts of change during the event. So the total of the impacted substation for both of these events is 22. But there’s a little bit of difference regarding these 22 substation. For the April 18, it was a broader area that we saw that was impacted as we saw the fault recorder trigger was 95 for July 10, but for April 18 was 177. So all in all, we can say that April 18 was a little bit more severe, especially with the minimum voltage sag magnitude that we are seeing. The April 18 was comparable, but if you want to be picky, it was a little bit more severe than the July 10. But there are two different points that we want to highlight.

The first one is the sustained load transfer. For April 18, we only saw 500 megawatts of sustained load transfer. After like less than two minutes, out of those 1500 megawatts, we are only seeing that 500 of them is sustained or sustained after that two minutes. But for the July 10, like all 1500 megawatts, whatever we saw as the initial load response was a sustained load transfer.

Is there a question? So the sustained transfer data center, we are seeing as these two events again were comparable or similar kind of. The number of data centers that sustainably transferred the load for July 10 was 11, but for April 18, we are only seeing one data center that was sustainably transferred. And we’re going to talk about the time of that.

Before we go through the data center response details, we introduced or we are using four different categories for the data center response. We divided into four sections. The first one is right through. Of course, we know about that. But for any transfer, we divided the transfer, the load transfer into three different sections. The first one is the transient load transfer. The load drops, but it doesn’t stay low, but immediately ramps up back to its previous amount, back to its previous load profile, whatever it was before, prior to the event. And this is some kind of, these are based on the real data that we are seeing for different events. So this is one example. So we are seeing this V shape for the transient load transfer. So we define it as transient load transfer. Temporary load transfer, regardless of the load drop percentage, we saw that the load goes down, stays down for less than 20 minutes, and it starts ramping back up. So the amount of the time that load was impacted is 20 minutes or less. So we define this category as the temporary load transfer. And the third one, anything, any load, again, regardless of load drop percentage, any load that goes down, and it stays down for more than 20 minutes, we consider that as the sustained load transfer. So with this definition in mind, we’re going to address the data center responses during the, we want to compare their responses during the July 10 of 2024 and April 18, 2026. So out of all the data centers that we are having in Dominion Energy Territory, we picked 50 data centers since there were POI level monitoring on those. So we can have a more, we can have a higher resolution data from there, from our data center. And so it would be better, like this is, it would be better if we pick these 50 data for our analysis, since we are having more resolution. So for July 10, 2024, the minimum voltage stag, so first of all, we are seeing 28 data center that wrote true. But for the April 18, we are seeing almost 27 data center that wrote true. Transient load transfer was five on July 10, again, having those definition in mind. Transient load transfer on July 10, the number of data five, but you’re seeing six data center that look, that transferred the load transiently on April 2026 or April 18. Temporary two and temporary six and sustained load transfer, the one that we are looking for, 10 or 11 based on the, please consider this one as 11. So 11 data center that we are seeing that had sustained load transfer and one data center that was sustainably transferred. Again, with a more focus on the last line, since the sustained load transfer has the most impact on our total system load, our total data center load. So the sustained load transfer for July 10 was three hours, but for April 18 was one hour and 25 minutes. So we are seeing some improvement when we compare the April 18 and July 10. To have a more detailed look at what happened, we listed some of the data center and we compared their results. They’re actually the responses during these two events. So for example, data center number 12, we picked that one. In July 10, first of all, in July 10, we are seeing like 10 data center are having sustained transfer. This is just a small package of those 50 data centers that we are doing the analysis on, not all of them. So on July 10, we are seeing 10 data centers with sustained transfer. On the same data center responses, when we compare those in the April 18, we are seeing only one of them was sustained transfer. And there’s a reason behind this one that is acting the same way is that the new – because these changes, these improvements all are based on the collaboration between Dominion Energy and customers that we are working with since July of 2024. So in 2025, all these setting changes or improvement in the right was implemented. So April 18 was the first event after that setting changes that we are seeing. So we are seeing good – we’re going to say this is a successful collaboration between Dominion Energy and the customers. So the only reason that we are seeing this one is staying here because the setting change on this one was not applied yet during the April 18. So based on that, if we had the new setting, the new right to requirements kind of was applied to this data center, we would not even see even one single data center that sustained transfer. But to be more accurate, to zoom in on one of them, for example, data center number 12, we are seeing six voltage on both of them. And voltage per unit that this data center saw was .81. And during the April 18, it was .64 almost with the almost same duration. So during this voltage time, this data center dropped out or transferred. But with a more severe voltage situation for the April 18, this data center broke through. So this is all based on – again, this is all based on the collaboration between Dominion Energy and the customers that we worked on after July 2024.

So the key takeaway from the comparison of April 18 and July 10. So April 18 event happened on a 500 kV tie line between Dominion Energy and First Energy, our neighbor utility on the First Energy territory. We are highlighting this to say that an event that is happening even on a neighbor territory, but it was also close to our data center alley. So an event that is happening even on the neighboring territory, it still can affect the data center alley in our territory. So it caused a 500 megawatt transfer on the Dominion Energy load side. Relative to the previous comparable events, which was July 2024, April 18 saw less load that was transferred, although, as I mentioned in the table that we were comparing these two events, a broader geographical area was impacted. These – again, this is kind of repeating what I said before, but this outcome indicates the effectiveness of our collaboration with the customer to improve their ride-through settings. So we are still working with different – we are targeting and still working with different customers to work with their ride-through requirement, and this is still under process effort that we are working on. So we are hoping for better results for the next events. So this was the comparison of the July 10, 2024, and April 18, 2026 to show the improvement on the ride-through requirement that we were working with customers. Now we get to the large load event, the most recent large load event, and this is actually entitled the large load event title that we are using since this was the most severe so far, and hopefully for a long time this would be the most severe large load event that we are seeing on our Dominion Energy – on our territory Dominion Energy. So it happened on July 22, 2026. At 7.56 a.m., a 230 kV line locked out. At the same time, three capacitor banks tripped out due to abnormal voltage automatically. The fault line saw a face-to-face fault persisting through all the reclosing attempts, which was seven attempts during this event, and the root cause of that was the conductor hardware failure in that 230 kV line. So the faulted line is 1.5 miles long in the heart of data center alley, and it took like almost – this is kind of a rule of thumb, but this is like – it took like 25 minutes to 30 minutes for the total system load to come back to previous trend. And the total first response, or the lowest – or the most change that we saw in our system was about 3.9 gigawatts of change in the total load system.

We want to emphasize the severity of this event by comparing it to the previous events that we saw that we selected July 10 and April 18. So if you take a look at this table, the initial load for both of those events were 1,500. In this event, we have 3,900 of megawatts of change, which 2,900 of it was temporary load transfer. Not all the 3,900 was sustained. So impacted substation in comparison to the previous events that it was 22. In this event, it’s 39, or it was 39 impacted substation, again with the same threshold of 4 megawatt of change of any transformer on the substations. We are seeing seven voltage stags in comparison to the six voltage stags that we are seeing. The lowest minimum – the lowest voltage stag magnitude percentage that we are seeing in this event is 5%, which is quite low in comparison to the previous events. The duration of voltage stags, the maximum duration of the voltage stags, almost the same, 76 milliseconds for this event. But still, we want to emphasize the number of transferred data center that we are – the number of data center that transferred sustainly during these events. So on July 10, before any collaboration between us and – not before any, but before the new collaboration between us and the data center, it was 11. April 18, we saw one data center that was transferred. But during this event, although the severity of the event was – the event was more severe, we are only seeing four data center that transferred for a long time based on the definition of the sustained load transfer.

Moving forward, zooming in on the first few seconds of the event, we just want to show what happened. So at 7.56, we had the line open and instantaneous reclosing, immediately automatic response from the capacitor banks due to the abnormal voltage alarms. We have circuit breaking reclosing in the next 15 seconds. And after that, we opened three more capacitor banks manually in our system and closed two reactors again manually in our system to bring the voltage back to its normal level. How did individual data center react? Having those definitions in mind, except the write-through, we have the write-through and transient, temporary, and sustained load transfer. Having these three definitions in mind, out of those 50, again, 50 data center, we picked those 50 because of the POI level monitoring, which gives us more freedom or more accuracy for our analysis. We picked those 50. So out of those 50, we had – and some of those 50 during this event, their data was not available for multiple reasons. It was some of the data center were offline. Some of the data center were monitoring due to the change in the configuration, the temporary change in the configuration of the data centers. We saw that the monitoring device was on their secondary feeder. We’re still working monitoring device, but during the time of the event, it was not – the data was not available. The actual data of the data center was not available. Or we had one data center that was offline. So we are still working with our customers to have a better grasp of what happened during this event, especially for those 12 data centers that their data was not included in this analysis. So besides those 12, out of those 50 data centers, 38 data centers, we had the data available. Three data centers wrote through, 17 had transient load transfer, went down, came back up immediately. Twelve data centers had temporary load transfer, went down, stayed down for less than 20 minutes, and then came back up. And four data centers experienced a sustained load transfer that stayed for – stayed low for more than 20 minutes.

So to have a graphical view of what I just said and have a little bit more of information of those 50 or 38 data centers that we are working with, three of them, again, wrote through, but the minimum voltage sag was – the minimum voltage sag for all of those – between all those three was 58 percent. We had 17 that had transient load transfer. The minimum voltage sag was 5 percent. Temporary load transfer, 6 percent, and sustained load transfer was 7 percent of the voltage sag. So – and on the right side, we are seeing your electrical distance, like all these data centers based on their electrical distance. And I just want to highlight that when we say electrical distances, as an electrical engineer, our mind goes to the ohm amount of the ohm value of the lines between the event and the impacted substation. But we are talking – we are not talking about that ohm. We are talking about the minimum distance on the transmission lines between the fault location and the impacted substation. So we are seeing all those 38 data centers or of the substation of those data centers based on their electrical mileage distance from default location. So as we see, it does – there is no direct relationship between their distance and their response, since we are still working on some of the data centers, and they are having different settings for write-through. So four categories, write-through, transient, temporary, and sustained. So we are seeing that they are scattered through, like from zero miles to 45 miles of distance between the impacted substation and the fault location. So about the voltage measurement with respect to write-through performance curve, we are seeing multiple – for those data centers, we are seeing multiple alarms that we are seeing or multiple voltage sags that we are seeing. So the point of this graph in here is, I don’t know to say fortunately or unfortunately, if we had that write-through requirement, something like whatever ERCOT has or NERC has or PJM suggested – and please neglect this ITIC curve. This is just for our information. So if we had something like that for those 50 data centers, we could have avoided the transfer that they are seeing on their side, if and only if we had enforced or we had that write-through, this write-through, some write-through requirement like this in place. So this is evident as data points are within ERCOT, NERC, large working group, and the PJM proposed write-through curves. And the general observation on the July 22, 2026, this event had a higher impact if we consider the voltage profile, the load reduction, and also the parameters for the load for the voltage, which is voltage sag magnitude and impacted area in comparison to the previous events. The system load was recovered in less than 30 minutes, if we are being a little bit strict. During this event, we saw seven voltage sags in comparison to the previous event that we saw only six voltage sags. This event resulted in a lower voltage level in comparison to the previous events, less than 0.4 on the transmission line on substation level, on the transmission substation, in comparison to any previously observed event. And the collaboration – again, we want to highlight the collaboration between Dominion Energy and the customers was evident during the event. But in this event, because we saw a lower voltage sag, the customers responded to the first voltage sags mainly. So we didn’t care about the three – we didn’t start counting the voltage sags based on the write-through requirement that we had with some of our customers. So we saw some voltage swell on our end and, of course, on the customer’s end. And since the first voltage sag was more severe, it could not be – based on the previous improvement that we had with the customers, it could not be prevented. So the ongoing effort – I’m going to fly through these. We are increasing the deployment of high-fidelity monitoring. We are still working on installing more high-resolution monitoring devices on the strategic location to have a – instead of 50 data centers, we can have more data center visualization on our end. We are performing multiple studies to update the write-through requirement. We are working – we are updating the FIR requirement again, as we do twice a year, but this time we are trying to work the broader range of customers that we are working with. We are applying – we are working on dynamic studies that develop the tailored write-through requirement. Also, on modeling improvement, we are doing – we are working on analysis and the adoption of PRC-1 model for data center modeling and the engagement with the modeling and the vendors to define realistic write-through settings. And we are working – we are also creating a working group. We are actually – that just recently we created to have a better collaboration inside and outside of Dominion Energy to work and maybe hopefully prevent this – or better go through the event like this. So I’m still working with different customers on our side. So I saw, I guess, during my presentation, I saw that you’re skipping the questions. I don’t know if I saw it correctly or not, but this is open for any question. Yeah, we have a queue. We’re also running really tight on time, so those of you asking your question, please limit your question to one and be concise. Yeah, sure. Of course, we have the two main persons in point of contact from our team emails in here, the first one is me, the other one is Francisco Zelaya from our team. So if there’s any question that you want to ask later or we want a more detailed answer for it, we can always get back to you in email. Please. That’d be helpful. Thank you. All right, let’s go. Aruna? Yeah, yeah, quick, quickly. So it seems like these events were actually transmission events, right? The events were not caused by any data center tripping and things like that. Is that correct? Correct, correct, yes. So the events happened on the transmission system, at least one on 230 kV, right? And then so you are looking at how the data centers rode through and things like that, right? So at what transmission voltage these data centers were connected in general? It could be different, right? What voltage? At least for the ones that we are showing their analysis in here, they are not connected directly to our transmission level voltage. They’re connected to our distribution level voltage.

Okay, distribution level.

So, okay. All right. Thanks.

Negar?

Hey, can you hear me? Yeah. Hi. Thank you, Nargis, for the insightful presentation. I have a question regarding the kind of drops that you had for your load in the first part of your presentation regarding the slide five. Did you see any difference between these three types of drops for the loads in terms of their frequency, their impact and the frequency and the protection devices that have been triggered?

Good question. Wrong person to ask, but I just want to point out one of the part of your questions. So if I got it correctly, please correct me if I’m wrong. But we also, especially for the April 18 and July 2024, and also, of course, the July 22nd, we went through the frequency side of the – whatever they are seeing on their frequency. So we had a full analysis on the frequency. So there was no frequency outside of the limits, if this is what you’re asking. But I just want to mention one more thing since you brought up this question. Thank you so much. We have a report, a white paper that we recently sent out regarding the July 22nd event. And also, we had one that is probably public on July 10 of 2024. So far, we have two white papers that goes through these two events in details. And of course, one of the section on both of these two events, both of these two reports was for protection question – actually, for protection side of the analysis and also for the frequency. So as I might not be the right person to – since I’m not, to be honest, a protection person, we only worked on the – but I think that external report would be really helpful to go through the protection side of the events. Okay. That is great. Yeah, yeah, of course. And just one quick question regarding the second part of your presentation where you showed a slide 14 that you showed the relationship between the number of drops and the distance. Do you have a guess of the approximate SCR of these data centers and where they are located instead of the distance?

Sorry. I didn’t catch clearly. I mean, you have investigated the number of these – the different types of, I don’t know, drops for this connection of the loads with respect to their distance, right? Yes. I just want to clear one thing. If you’re mentioning these numbers, like these are like three data centers that were true, but just to be like on one person – I don’t want to give it one person chance of misunderstanding. Maybe I presented not good enough. But these numbers that you’re seeing on the right side, graph on the right side, it’s just to make the data center anonymized. Yeah, yeah, I know. This is the number that you assigned to the data centers. Yeah, I got that. So my question is that do you – have you investigated the SCR of the data center, those data centers that have showed these drops during these disturbances instead of the distance that the distance might not have? Yeah, you know what I mean? Yeah, yeah, yeah. I know what you mean, but then again, being on the strategic initiative team, we are working on the RCA, root cause analysis of the events. So the SCR is more of a public planning question. To be honest, I’m not sure even it’s addressed in the external report, but to be honest, I’m sure. As I heard about these studies that are going on, but we didn’t mention that in the external report. So I’m not fully aware of the – Okay, this is great. Yeah, I’m going to contact you more. Thank you so much. Of course, of course. Thank you. I believe we’re at your – you’re up. I just wanted to see if – first of all, congratulations on the efforts that you guys have made between the first event and the second event. Of course, the July 22nd event was much more severe. But when you say coordinated efforts between Dominion and the data center loads, are you guys able to provide more specifics around what those coordinated efforts are? And was that installation of hardware? Was that – there could be probably a number of things that that is. Is there information sharing happening between you guys and ERCOT related to that?

Not exactly. We are working with different customers. And like, of course, any of these customers have different facilities in our system. And they are like – even the facilities responsible are different. We are working with customers based on – for now, whatever we achieved was based on their right to requirement. But to be honest, sharing that information is not what we can do. Lee? I think you’re mute.

You good, Lee? Yeah, that was my only question.

Seems – Joel, you’re up. Seems like there could be – oh, go ahead. Yeah. My question is, especially on the July 26th event, do you guys have enough data resolution to try to look at how many data centers rode through the first – the initial fault versus the recloses?

So for – we are still like adding more high resolution monitoring devices to have a higher resolution data for all of the data centers. It’s something that we are working on. Based on what we saw, most of the – I’m going to say almost most of the data centers were impacted by the first voltage tags, not by the next six sequences, the next six voltage tags. So we had some data center based on what they saw, and we had some customers mentioned, and also we saw it on our site a little bit, that they were impacted by the voltage flow immediately. I wish I had that voltage profiling here. But most of them – I’m going to say most of the data center that we could see, they were impacted by the first voltage tags, not by the next voltage tags. Okay. And can you contrast that with like the earlier, less severe events? Was it always the first fault gets everybody, or is it with a lower magnitude of energy? Is it the later? Yeah. So for example, for the previous events on April 18, we had – this is exactly based on the setting discussed between us and the customers apologies if I cannot go through details of that. But for the April 18, for example, the voltage tags was – as soon as we saw and the data center saw the voltage tag, they started counting one, two, three, four. So after a number of voltage tags that they saw on their site, they dropped out. So the definition of that voltage tags and how many voltage tags, it was something that we discussed with the customer. So this reaction to the first voltage tags was the thing that we saw on July 22. But on April 18 and July 10, this was not the case for them. So they happened to transfer after like a number of voltage tags based on the definition of the voltage tag that we have between us and our customer. So they were not reacted to the first voltage tag during those two past events. Right. And yeah, and then for those of us here in ERCOT, that it – this sort of points out a hole to me in NOGR 282 that we’re not – we have no standard in there that says how many times this can happen and what period of time and we have to ride through it. Just a comment there. Yeah, okay. Also, just a note that we are working for the FIR, especially on attachment 8, we are working – I don’t know if – I think this is a public document. For the FIR attachment 8, we are working on the – on setting kind of like as a suggestion, kind of a standard right to requirement for the data centers or for the large load. Let’s call it the large load for now because we are not targeting data center and data center only. For the large load, we are specifying a number of voltage tags that they should ride through. So, there is still working – the attachment 8 is still under process for the next revision, but we are working on something like that to make it a standard for all the large loads. Thank you. Mark Henry, you’re up. Yeah. Thank you so much for the presentation. I appreciate Dominion’s work to spread the news about this and help us learn from you. My question is real quick. I think you said that the fault occurred on First Energy’s transmission, and I was curious if First Energy had any impacts on their system. I’m not familiar with topology. Just a curiosity on my part. Thank you. No, of course. Yeah, the First Energy had – they saw some impact on their site. To be honest, I – at least for this presentation, I didn’t think to bring whatever they are seeing. We had a conversation with First Energy, and we had like sharing experience of what we saw on both ends. But I’m not going to say it was more severe or no, because maybe the load type would be different on their end and on our end. But definitely, they had like a severe impact on their own site too.

So, that would be in addition to what you were reporting, right?

Sorry, it was in addition to what? In addition to the transfers and load loss that you were telling us about.

Oh, maybe a person from First Energy could answer this question a little bit better, because I don’t know how to compare what they saw on their end and what we saw on our end, especially that this presentation was mainly focused on the data center reaction in comparison to all the load. And to be honest, I’m not sure what type of load they have on their site and how it was severe for them or not, to be honest. Yeah. Again, thank you so much. Appreciate it. Of course. All right. Thank you very much for an informative presentation. There are a couple more questions written out in the queue. You get a chance if you could respond to those in the chat window. Sorry, but we really have to move on because I just stole 10 minutes from Patrick without telling him I was going to do that. So, really appreciate your presentation currently. Definitely relevant to what we’re doing here with ERCOT. And thank you again. Of course. Thank you so much. Thank you.

So, for the NOGR 289 discussion, we don’t have anything to present. We’ll just kind of kick it off for the discussion. Just a little review of the ERCOT comments that we submitted on NOGR 289. We do have significant concerns with this NOGR in allowing additional ride-through exemptions, even if it’s just for the cooling load and specifically the impact it may have on the impending IRL situation. The more exemptions we allow, the more frequent and the quicker we’re going to get to a potential having to activate these mitigation plans and curtail some of the loads in these IRL groups. We also have some additional concerns about how we’re going to monitor and implement the cooling load in these IRL plans, IRL mitigation plans. We don’t really know in real time how much is cooling load versus computational load. So, we would likely need to break out that telemetry, which is going to be challenging as well and is going to take some time. I don’t think the TSPs really have the capability to do this. So, we’d have to have the data center themselves send this telemetry, which would require them to set up a QSC. So, there are a lot of problems, and then we’re going to have to figure out how we would actually curtail that load. You can’t really just curtail the cooling load for these data centers. So, we have to figure out how we would implement any of that curtailment because there’s really going to be two options that they’re impacting in IRL. Either you would curtail those that the non-exempt with the cooling load deficiencies first, or you’d have to kind of pass along those megawatts to the other data centers and crypto facilities in that IRL, and they would be curtailed sooner as well. So, at a very minimum, if we decide to proceed with this NOGR, what we would have to do for any of these entities requesting this exemption for the cooling load only, we would have to have dynamic models showing that cooling load ride through deficiency, and that would have to go through a QSA to determine the impact it would have on those existing IRLs or see if it creates additional IRLs. We don’t know how many people would be requesting this exemption. If it’s just a handful, it likely would be a problem we could handle, but if we have a lot of data centers that are requesting this additional exemption, it could have significant impact on those IRLs. We have been receiving multiple models showing ride through capability for these facilities. We have heard from multiple vendors that they do have cooling load that does meet the requirements. So, we would rather those entities focus on implementing that ride through capability for that cooling load within that one-year period instead of having to go through an additional QSA and updating these IRLs and seeing what kind of impact we’re going to have there. So, I’ll kind of leave it there and open it up for any questions or discussions and just kind of gauge the room on if this is something we really need to proceed with, and then we’ll figure out next steps. Thank you.

Crickets. Crickets, crickets. I need a cricket to speak. All right. Having no speaking crickets.

I guess my takeaway is ERCOT’s going to recommend a rejection of the NPRR. Is that the right way to think about it? I don’t know if we can really recommend a rejection. I mean, you could request a rejection. Yeah, I guess we could. We do want to open it up. I mean, if anyone really wants to continue pursuing this, we’d like to hear from you. We’d like to hear, you know, what are your actions going to take to implement ride through for the cooling load within a one-year period? Can you provide that telemetry? And are you going to be okay with, you know, still being subject to curtailment if you’re in an IRL? All right. That worked. Durga, you’re up. Thanks, Patrick. So, let me understand this.

So, you said that you would still allow the loads to have a year to meet the requirement. Is that true? Yeah, but they’d have to go through a QS. We’d have to get those dynamic models and see the impact on any of the IRLs before we grant this potential temporary exemption and allow energization.

For loads which have already met QSA, what’s the process?

I think they’d have to go through another QSA. So, you would stall the energization?

I don’t know how many loads have gone through a QSA at this point that aren’t already exempt. This is going to be a rare situation. I think that we’re going to have any loads that have already gone through a QSA that don’t meet the exemption requirements. So, I don’t know. We’d have to probably see how many of those loads are in that bucket. Yeah, Durga, this is A.G. Springer at Operations. Could you clarify your question a little bit? Are you asking for a load that is required to meet the requirements of NOVA 282 but might have exemption if NOVA 289 were adopted? Are you asking how that would be handled? I’m asking – so, we have loads which have gone through QSA, and it was at the time where we used to submit the CMLD models back in the day.

And we got through QSA and got through the conditional classification. We are trying to energize, and that’s the reason we asked for the exception until maybe August, September of next year. By that time, we’ll be compliant. But we need that exception from now until next year so that we can go and install stuff. So, Durga, the load that went through the QSA, did the dynamic model submitted reflect that cooling load deficiency and the ride-through capability of the cooling load? Yeah, just the cooling load. The IT portion is riding through. It’s just the cooling load. But the models did accurately show the cooling load trip settings? Yeah. Okay. So, it could be – and it wasn’t identified in an IRL. So, it could be that whatever that ride-through capability of the cooling load potentially just rode through because it wasn’t close enough to critical fault. Yeah. It’s not entirely – the 282 is pretty strict. It rides through a certain portion. It’s not entirely not compliant. It’s semi-compliant. Okay. So, I think we’d have to evaluate that internally a little further to see if it’s really just these one-offs. Yeah. Maybe we can evaluate the impact of those individually and see where they go. Because the concern is if we follow through with this NOGR, we’re really opening the gates for a lot of people to make these exemption requests. And that’s the concern. I think we discussed this last time. I think the way to mitigate that is we’ll have a deadline, right? So, people who are trying to energize after that, let’s say mid of next year, they would have to be compliant. I think that was the mitigation that we thought of placing to stop the floodgate, right? I see the comments fine, but I think I would still request to have a deadline, maybe August or September of next year, so that projects which are trying to meet the requirements go through the energization and get some time to go and have solutions in place. Yeah. See, putting that deadline middle of next year, that was the evaluation we did. And there are potentially 17 gigawatts of additional load that could be requesting energization next year. And that’s what would open it up to have a significant impact on the IRLs, as we submitted in our comments. So, even pushing that date to middle of next year could have significant impact. So, that’s really the concern. So, if we’re talking about maybe limiting this just to facilities that have already gone through the QSA, I think that’s something we could take back and look at. Yeah, and I think that we can continue to discuss that internally, but I do want to emphasize, you know, what Patrick brought up, that our concerns with this proposal go beyond just the ability to reflect it accurately in the QSA. There’s also, you know, the sort of open question of how would this be managed, especially for loads that might receive this exemption but are located in an IRL group, or if they received the exemption, would require the creation of a, you know, new IRL group. And in those cases, you’re adding a portion of the facility’s consumption is no longer able to ride through or is not able to ride through. And so, because we are having to monitor the overall consumption within that group of load that is unable to ride through a disturbance, we would need the additional telemetry in order to accurately reflect how much load is, you know, currently at risk and how close we are to the operating limit if one were established. So, you know, I think I just want to emphasize that the QSA is only one piece of the concerns here. So, it seems like a potential solution to this is the telemetry could split the IT and mechanical portion and provide that response to the QAC, and that could be a solution for this, so that our court has visibility and QAC has visibility into it.

If I could say something. So, this is Freddie with our operations. So, that would resolve the situational awareness problem, but that facility would still be subject to curtailment as part of the IRL. And I think one of the key questions that we have that Patrick raised is, at least I don’t think that you can decouple the cooling load from the IT load. So, if you’re curtailing the cooling load, I would assume the IT load would also need to be reduced as well. So, I guess the point is that you’re just, you would, your entire facility would be potentially subject to curtailment as it was part of an IRL.

Okay. Okay. Understood. So, our court is going to go back and look at the exceptions, right, ones that went through the QSA and trying to energize. So, you guys are going to go and discuss about it, right? I mean, again, I think at least ERCOT’s preference is that we don’t have these exceptions because of the reasons we just listed, because you already have a very complex mitigation plan that we’re having to coordinate with all the transmission operators and QSEs. I think this only adds to that complexity, and that’s really where our concern is ERCOT’s visibility to manage and then the PSPs and the QSEs ability to manage and monitor this. So, at least from ERCOT’s perspective, our preference would be to not do this, but we’re willing to have those conversations. Okay. Thank you. The good news, ERCOT, is nobody else put their name in the queue. So, this does seem like a pretty isolated issue. So, that’s at least somewhat encouraging at this point. Patrick, could you pull up our next presentation, please? Next presentation is going to be on PCLR dynamic bid capping by Mohamed from EPE. Mohamed, are you on the line? I am on the line, yes. Can you hear me? We can. Fantastic. And just to confirm, Patrick, the version that you have, is it 21 slides?

Yes. One second. Let me get it pulled up. Perfect. And right on that, we do have 30 minutes for this presentation, including questions. So, those of you with questions, try to keep them short and concise, because time is going to become not our friend on this one. Thank you. Let me just verify. Yes.

Okay. Fantastic. So, first of all, thank you so much, LLW. Sorry. Can you hear me? Yes, we can.

Okay. So, I would just thank everyone to give me the chance to talk today. And to be honest, I have to give kudos to Baba and Patrick, because this was very, like, a last minute thing. We discovered that there is a slot available in this meeting on October 15th, and we decided to took it. So, I would like first of all to apologize, because I am overseas. I’m in Dubai, and literally in the last six days, I slept not more than 12 hours. So, I’m putting this as a disclaimer, but I will try to do my best. Okay. So, this presentation, we wanted just to share with the LLWG a try of answering a question that we received a lot from the developers, load developers, that how they can quantify the risk of the proposed BCLR from AERCONSIG. And I have also to put another disclaimer that I am coming, my background, I’m coming from academia, and I always tell my students, and I tell also my team now that all the models are wrong, but how wrong they are. And we tried here in this presentation that I’m going through today is that to find a way to be able to quantify the curtailment risk of the loads, given the fact that now we are moving towards the same concept that ERCOT used for years for generation, which is connect and manage, that concept now is inherited to the loads, and we are getting that question over and over, what can we do to be able to kind of evaluate the curtailment risk? With that, can we go to the next slide?

Fantastic. So, I just put the slide, and I’m sure everybody on this call is way more experienced than me on this thing, but I just wanted to put the slide to make a common base for those that also not deep in this area as well. So, as part of the BCLR, the current process would be that the load submits an application, that application, like let’s give an example, could be 500 megawatts, and ERCOT will do, as part of the batch process, they will do the assessment for this load, and then they come back and say, okay, you have a minimum floor, which is, we’ll call it LPC, or lower power consumption, and this could be, let’s say, out of the 500 megawatt, you have 150 megawatt, it’s considered as a firm load. So, that is guaranteed by the system, the system condition can allow it, it will not create any problems, and this can be connected right away. The 350, you can still, developers can still connect, but they are bearing the risk of that 350 will be only supplied when there is availability in the system, and the security-constrained dispatch can allow them to get those 350. So, that raised, which is called MPC. So, between LPC and the MPC, whatever in between, between 150 and the 500, that’s up to subject to risk of being curtailed. So, right away, when ERCOT communicated this, and as we are a consultant, they came to us and say, okay, do you have something that we can weigh that risk? So, the way that we actually do, we run SCADA analysis, you can actually put a load with a bidding price, but what was interesting is the proposal from ERCOT, which is the adjusted production cost. I’m sorry, because I’m not controlling the slides. I’m so sorry. We should, sorry, let’s go to the next slide, Patrick. Sorry, I’m so sorry. I thought that, okay, here we are. Yes. So, the question that kept being asked, actually, okay, so how we can evaluate the risk, given the fact that the batch process will not identify that risk. It will tell you what is the LPC, and the value that has been submitted as per the application would be the MPC, but in between, what will be the frequency of being curtailed, what is actually how much megawatt hours it will be curtailed, that needs an extra step. So, what I’m going through the agenda for today, it’s mainly four parts. The first part is the concept or the construct of the PCLR in general, and then the concept of the APC, or the adjusted pricing cap, and then how we did, came up with a proposal to help solving this issue, which we call it multi-SCAD, and then we will move a little bit to show this actually also on a map, because that map could help a lot to identify what are those upgrades that actually preventing or creating a problem for those things. We can move to the next slide, Patrick, sorry, and actually one more as well. So, basically, so this is the main idea that I was trying to explain, is that the dark blue, this is actually the value of the LPC, which is the firm load, but all the light blue, this is actually what has a risk of being curtailed.

So, the blue, we usually put it in our SCAD as a firm load, but all the light blue is a dispatchable thing, and with that, that dispatchable thing under the risk, if they are part of, responsible to some of the binding constraints, which is, I’m going to talk about what is the condition that they actually be flagged to be tested or actually updating the price, those actually, when you start trying to bid cap them, actually the curtailment will be changing a bit, and that’s why we tried to solve this problem in layers, actually. First layer, we tried to identify the frequency of this event, and the frequency, how can we get it? We can actually, when we solve the SCAD using your offered price, like the load will bug their offered price, we solve the system. From the system, we can identify the binding constraints, and we can identify the binding constraints that have a high shadow price, more than 90% of the maximum shadow price. So, any load contribute that binding constraint, it will be subject to be changing the price. That helped us to communicate to our clients how the frequency will be, how many hours you will be tagged for price for the bidding caps. But it still, it does not answer the other question, which is how much megawatt I will be losing. So, yes, you can tell me you are under the risk of, let’s say, 10 hours a year. Why? Because in those 10 hours, there is a binding constraint that has a higher than 90% shadow, the maximum percent, shadow price has 90% of the maximum shadow price, and you have a shift factor higher than 0.02. With that, you know, okay, I am part of the problem, and I will be flagged for, if we can call it mitigation, or flagged for this bidding price, bidding caps. But how this will affect me, how actually this will be resulted in a curtailment for my load, that’s what make us think deeper one level. And just also to share with the group, if you don’t mind, if we move to the next slide, Patrick, we were actually thinking along the line, what would be the best approach before we came with this multi-scale idea? What would be the best approach of bidding? Because, you know, sometimes in curtailment analysis in general, we like to take a couple of scenarios to show you the lower bound and the upper bound of curtailment, and you see what our things looks like. So there’s a couple of ideas we were always discussing with clients. Okay, you know what, we can put you very high prices, like 4999.

Yes, that could be an option, but this is definitely could be subject to the bidding caps. And again, this could be realistic from reliability. And last column, by the way, last column here in this realistically reliable, that’s not from ERCOT perspective, that’s from the load perspective. Okay, so the load will be reliable because it’s almost a firm load, that’s good. But definitely, it’s not good from a pricing, like usually we see in these cases, pricing goes up. Maybe the other side of the game that, okay, now I will be bidding very low, at $100, for example. And if I bid on $100, yes, it’s more of realistic prices, but definitely it’s not good because the frequency of curtailment is really high. Or you can come up with something, a magic formula in between, could be 1000, could be 2000, which is, let’s say, okay, I bid a 5, and it took me back to something between the 100 and the 5000. But again, like this is very kind of that we are throwing here, like that’s in the wall, like, is there a way that we can do better than this? That’s what we were thinking about. And that’s what made us think about the method as well, that I’m going to present. So if you don’t mind, go to the next slide. And the following slide, sorry. So basically, this is what is presented as, I think it was in June, or maybe not, sorry, maybe May, is the proposal for how we calculate the adjusted bidding cap. So the way that this EPC will be calculated, it has to go through one first step, which is, we can call it like restricted competition step or identifying the loads that have contributed to the problem. So you do SCAD run. And based on that SCAD run, you have actually prices and schedules and binding constraints. So we do actually monitor those binding constraints, identify those binding constraints that have shadow price more than 90% of the maximum shadow price, and then identify those loads that are contributing to that binding constraint, which could be part of the problem now, more than 2%. So at that stage, you know how many, as I mentioned before, this is the frequency. But what Erkut is proposing is that we can actually now try to solve the problem by coming, what I can call it more of a ranking algorithm. So ranking algorithm, how we can actually be fair from a bidding price perspective to change the offered price to something related to something following this formula, which is the EPC, which in other words, here, as you can see, you take the system lambda minus the maximum shadow price times the shift factor times just an epsilon. The idea here, when you look at this middle term, maximum shadow price times the shift factor, it will actually rank lower those loads that are contributing more to the congestion on that line. So let’s say if there is three loads, each one of them was bidding 5,000. And the shift factor is 50%, 20%, 10%. So the 10% would be have higher price, the 20 would be have middle price, and the 50 would be have lower price. And with that concept, we use that concept to be able to, okay, so now we can, now we have an updated pricing. It’s not like the previous slide, which is take 1,000, take 100, take 5,000. No, we can definitely now get an updated list of prices. And then we go to what we call it SCAD step two. And in this case, we use this updated prices that came from the formula, the APC, and actually use those updated prices to run the SCAD one more time and tell you more realistic measure of how much bigger what will be curtailed from your load. And I’m so sorry, I should have asked it at the beginning. Are we, like, I’m so sorry for my ignorance. This is my first time to present. So is it, like, are we entertaining questions at the end? Or maybe that’s a question for- Yeah, we’ll take questions at the end. Okay. Sorry. Okay. Okay. Thank you so much. Okay. So if you don’t mind, can we go to the next slide then?

So when we did this, actually, we did a lot of simulations in this. And definitely, maybe this slide is not bringing, like, it’s all intuitive. Because definitely, the capping is very location specific. Like, we did a lot of testing with a lot of loads in different locations. But definitely, things are very much dependent on the location. It’s also very much dependent on interval. So basically, in each interval, definitely, the binding constraints are different. From each location, the shift factor and the binding constraint that being affected by that location is different. And also, it’s very much dependent on what you have on your neighbors. So we did a couple of, like, testing whether loads nearby, not nearby. And definitely, this is a big factor of the analysis that we have.

Okay. Sorry. Do you mind, Patrick, if you move to the next slide? And this slide, maybe just to answer some of the questions where we are getting our data from. So basically, and I will refer to what I mentioned at the beginning. Because definitely, there is some of assumptions when we do this analysis. And I would say one of the biggest assumptions is the loads that we are considering when we do this analysis. Like, as everybody knows, like, there is some things that we, like, public, it’s already on, and is this WG or could already be communicated. But a lot of things that are still missing, and that’s why we come up with a couple of scenarios for the loads. But at the end of the day here, I am just talking about, in this slide, I’m talking about whatever I explained in the previous slide, how we actually execute it in the system. So basically, the list of the inputs to the APC in general, it’s what are the constraints that are binding, whether they are more than, their shadow price is more than 90% of the maximum shadow price, is shift factors from the PCLR, the system lambda, and actually, so what basically other PCR are doing as well. So where do these, each one of those come from? So definitely the binding constraint, that’s one of the things that come from the SCAD analysis altogether. We also, the SCAD gives you the shadow prices, so we can compare the shadow price of each constraint with the maximum shadow price, and confirm whether it’s 90% or not. And also, we go based on the topology and the network, and based actually on each hour, if there is any outages in the system that is considered part of the SCAD. So we have an hourly shift factor for each load for every constraint, so we use those shift factors as well. And then the lambda is also from the first step, we got this. And then we, the idea is that what is available, like even if you would like to back cast out some of this, definitely some of the information are known, some are not, and I would say this is, like, I brought this point actually also be discussed, like, if ERCOT would be open for that, because the idea is that moving forward, each load can identify what binding constraint harmed them the most. So it could be triggering some of the concept, because given the fact that within seven years, the LPC go to the MPC, we know, that’s the roadmap, but at least if there is some economic analysis that can be done for some specific binding constraint to prove that there is, has higher value or something, this can be done, this can be done as well. And we had out of all of that, like, we had everything is already included here in the normal SCAD, other than this, I would call it post-processing after the first SCAD and before the second SCAD. So this is the main added, or the new thing here is actually how we can mix these things together, put it in the formula of the APC, come up with an updated prices using in the second run of the SCAD to be able to identify actually the curtailment in this case. And one thing also I would like to emphasize that one of the things that we’ve been asked a lot, like the values that come out of this analysis, which is the curtailment, either hours or value of curtailment, can help the load developers a lot to know how big is the problem. Because some of the outcomes could maybe a storage can solve the problem. No, no, no, no. It’s actually more than two, three, four hours a day. So I need to go more than that. It could be, it has to be a gas or whatever, whatever solution that can help the load developers to reduce the curtailment, it will be informed based on the results of that.

Okay. So Patrick, if you don’t mind, if you go to slide 12 now.

Just a quick time check. We’re about halfway through your presentation, about halfway through the time. No questions in the queue. Thanks. Thank you. Okay. So just to put this in the workflow that we are using.

So usually with our clients, what we do, and just here connecting the dots between the table that I showed before, and then what we do next. And I have to put a caveat here, by the way, because we tested this a couple of times as well. One of them is, we believe, and I’m not sure if this would be the case or not, but I believe if somebody is PCLR, most probably they will bid at 5,000 altogether. Like the first run, I will take my chances, put 5,000. But I would like also to share something that that bidding behavior itself could affect the shadow price of the binding constraint that you are behind. Like in other words, if, again, I don’t think the loads will agree together on a bidding price, but let me give an example. If there is three loads nearby and, okay, I want to get most of the megawatt, all of the three of us, we will bid 5,000. Or the other scenario, let’s bid each one of us 1,000. And we tested those two scenarios, by the way. The idea is that the bidding behavior itself could be one of the triggering factors of, that you got, you got, I don’t want to say mitigated, or that you could be subjected for the APC. Like, but definitely this is something we cannot control. Like, so what we do normally now in our process, we put everybody bidding at all the loads, we bid at 5,000. That’s the first. And then we do that kind of what we call it a screening. So what do we do in the screening? We identify the binding constraint, we identify those that has shift factor, sorry, that has 0.9% of the maximum shadow price, identify those loads that has more than 2% shift factor, and then we calculate in the third stage, we calculate actually the capped bids. And then we take those capped bids into the second SCAD. In the second SCAD, we do that analysis using the bid cap, and then we get what the outputs, it actually will give you how many hours, how much megawatt that you need, because we believe that this type of analysis is very important for developers, again, with the caveat, a lot of assumptions around the modeling itself. But these results at the end will help to identify how big the problem is, first of all. And the second of all, how, what is needed to improve? Is it very contained, like 10 hours a year or something, where I can solve the problem, I don’t have to go and invest in a gas turbine? Or no, no, no, this is something consistent, and I have real issue, and I need something different than just a battery. Okay. So if you don’t mind, Patrick, go to the next slide, slide 13 now.

So this is also how we set up the model. So we take actually definitely the SSWG from ERCOT, we change the generation accordingly, and then, so, and then we do the large load adding the base case. And this is where, again, this is, this one is, is tricky a little bit, because the information is not known what will be firm, what will be the MPC? That’s also another question. In our analysis, to be honest, knowing that we don’t know the LPC, we don’t know the firm, we assume now that the whole range for now for the loads that we’re putting in the model is actually the whole range is this batch.

And then we put a set of, like, hourly profile for different things, and then definitely we define the monitor constraint that we are going to consider for our skid analysis.

Okay. And just to give you, sorry, Patrick, if you go to slide 14 now, for slide 14, one of the things that we found very interesting, and this is what I was trying to suggest if that could be something that, I don’t know if it’s contemplating, like, sharing something like this, but this would be actually all the level of details that happened behind the scene to complete the ABC. This is based on, like, what are the constraint that has been triggered, what was the shadow price for this one, what’s the shift factor for that load on that constraint, and then actually what will be the price that you have. But by knowing that level of information, the good thing is that you can identify which one is that harm you the most, and which one, if any, that you would like to consider another avenue using economic analysis or something to improve or to upgrade that circuit or convince the TSPs to parameterize things to do that circuit, that level of information will be very helpful for doing this. Okay. So Patrick, if you don’t mind, go to the slide 15 now. I hope we’re good from a time perspective. So basically, this actually, the outputs, so the outputs, as I said, there is a lot of containment things. There is also, give you how the LMPs will be changing based on that bidding cap behavior, and also what are the constraints that are included and harm you the most. One of the things also I would like to highlight here, which is, I touched base a little bit about it, which was very interesting when we do this thing for this, is the bidding behavior itself could shift things around, which was really interesting. Like sometimes, if all the loads decided to go very high, that could trigger more cases for ABCs, different than if everybody is bidding at 1,000 or 2,000, because it’s, again, because once you bid more, the optimization will see that this point is favorable, and the shadow price on the line that’s connected to that point will be high. With that, I will move to my last part. So if you don’t mind, Patrick, if you go to slide 17.

So it’s also good that within EP, we have a very good GIS map for ERCOT. So what we do, actually, we use that map to identify also how far, because we know that in PSSE, when you expand the network in PSSE, you don’t get the geographical location of these elements and where they are, because also there could be some questions about right of way. Is this constraint, can we upgrade the circuit altogether, or we have to go with GATs or something? Definitely the right of way or where this line is is really important. And if you don’t mind, Patrick, if you go to slide 18, that shows some of the capabilities of what we do. So in this case, for example, as you can see, the dots on the left, this is where the load is. And the line that is drawn a little bit on the right, this is actually the line that got affected by this load. And you can definitely, this tool can show you also how many hours, how much actually the load got curtailed due to that line, which is something that definitely will be important for developers to understand how bad the situation and for different constraints. With that, I can wrap it up with slide 19. So if you don’t mind, Patrick, go to slide 19, which is, I would like just to put this forward. This is, we tried to come up with an algorithm that can help to evaluate curtailment under the PCLR, but definitely there is a lot of uncertainty on a lot of things. I would say the biggest question mark we have is the loads in the model, like, and which, what has LPC and what is the range of the dispatchability? I’m assuming once we get more information about the batch zero results, we can definitely do a better, because the feature is there now, we have the feature. We are overcoming these uncertainties by doing multiple scenarios for now, but definitely with better inputs or better data inputs, we can definitely do better than this. And the last slide, slide 20, if you don’t mind, Patrick, if you go to that slide, so this is like kind of just a summary to take away. So definitely the caps moves the risk, like if you think about, okay, I would be bidding 5,000 and I’ll get around the curtailment, that’s not the case anymore. There is actually changing that bidding price as per the APC concept. We need to do two runs rather than one to be able to evaluate that. I would like also to throw something. In one of the simulation cases that we did, when you change the bidding caps and you run things, actually some of the binding constraints not binding anymore and some of the non-binding constraints were not binding before becomes binding again. So are they only two? What Erko proposed in the workshop was two, but will be the two is the optimum decision or we need more. That’s also something we contemplating as part of the analysis. And again, the list of the constraints that actually harm you, the developer the most, I think that would be a very good piece of information for developers to try to find something else around those constraints, not to wait for the seven years. Like now, if there is something in between, okay, we identify a value or a line that if we upgrade it, it will add a huge economic value to the system that can actually up to the TSPs and to Erko to get this circuit upgraded before other circuits. With that, I would like to thank everyone for giving me the opportunity to present, and please, if anybody has any questions.

Thank you very much. That was informative. I’ve been hearing a lot from folks that thought $5,000 would just make them be okay. I think this presentation really drives home the point that no, just bidding $5,000 is not going to get you where you think it’s going to get you. So do appreciate it, and you managed to fit it in time. Got one comment, but I haven’t read it yet. This is fantastic to see. Thanks for your presentation. Can you please speak to when and where this model will be available? Will it be public information?

The model is, like, we have it at EPE, but I’m sorry, I don’t know, I don’t understand how, what public. This presentation, it’s public. I’m sorry, I just don’t understand what the public is. Yeah, the presentation is public and posted on the website. The solution is proprietary to EPE. They’re demonstrating what it could do. There are others that do a similar thing. We’ll probably hear from them at some point in the future, but yeah. And then one more. Oh, that’s from a different deal. All right. Thank you very much, Mohamed, and we are. Thank you very much. I appreciate it. Thank you. Schedule. Thank you so much. Thanks. Thanks. Thank you so much for giving me the opportunity. Right. Thank you, Sam. You too have 30 minutes, and if you’re late, you’re delaying people’s lunch, so do at your own risk. Yeah, and I’m very aware of that, so I’ll try to speed around this. And otherwise, I think we’re going to be talking about these concepts in the afternoon. I was happily, I was happy to see that in the ERCOT content, they have the BYOG not at the same location as a near-term and long-term goal that’s generally supported by the market. So, in either case, just kind of following up on some of the contents that I’ve shared previously, I think it was at the last batch meeting. And so, one of the four initiatives that we are really focused on is this notion of being able to produce some form of deliverability attribution for new loads when you are commercially sponsoring generation that is going to be added to a steady-state model that will determine deliverability to serve new load that may not be co-located with the generation or the load that you’re developing. And so, with that, this is kind of a high-level summary of how we view kind of the planning friction today and the opportunities and objectives going forward. You know, basically, there’s the reality of speed to power with grid connection, there’s complexity in the planning process, there’s a physical reality to the transmission construction timelines, and the customers always want to see these loads turned on as soon as possible. So, to the extent that we can afford speed to power with privately assumed risk, that’s, you know, one of the core pillars we’re focused on. And then, otherwise, there’s this other issue that we’ll be talking about right now, which is there’s no direct firm service attribution for a sponsor of grid-connected generation. And so, that is ultimately contributing to this dynamic we’re seeing where everybody’s trying to build behind the meter generation rather than, you know, really supporting grid-connected assets, which, frankly, could, you know, be better for everybody. It’s a better, you know, cost and reliability paradigm for the loads and the grid operations. And so, with those two concepts, you know, speed to power with private risk and then some form of attribution for sponsoring new generation, I think that can change what is, you know, suboptimal system buildout today and also less certain study assumptions and hopefully convert that into more certain study assumptions for planning, for system planning, while also producing better outcomes for the private loads and the grid as a whole. So, anyways, like I already said, in today, in system planning, you don’t really have a way as a load to sponsor a non-co-located generator and get attributed any firm service deliverability created by that load when it’s added to the model. And so, as a consequence, you know, there’s a lot of behavior in the market that could, in theory, be a lot more efficient from an economic and reliability and speed to power perspective. So, we are proposing this concept that we call load-sponsored generation. It’s essentially just saying that if you are a load that is commercially sponsoring a new grid-connected generator, then we at least believe that there could be a way to create this multi-step system planning process to add that new generation, attribute to the sponsor load whatever firm deliverability is created by that generator, and then after that initial attribution, the rest can be allocated to serving deliverability to any other unaffiliated loads. And so, this will hopefully create a very rational mechanism for including sponsor generation in the batch studies, which improves the planning assumptions as well as creates this commercial incentive for loads to sponsor grid-connected generation, and then also creates this mechanism to kind of shift the risk of these planning assumptions away from the system and towards these private generation sponsors, which I’ll talk about in a second. So, yeah. And so, when we talk about firm load service, just to make sure it’s abundantly clear, we’re talking about load that is granted uninterrupted service from the grid because system planning can satisfy all the NERC, TPL, and ERCOT planning guide requirements in the steady-state analyses to serve the load. And so, it grants – if you have a 100-megawatt load request, you get those 100 megawatts, and you don’t – there’s no obligation to behave in a certain way from the grid from, like, a curtailment standpoint. It’s the grid’s ability to serve you 24-7, 365. And so, from a sponsor loads perspective, you want to get grid-connected because that’s the best way to have the most reliable power, and you don’t want to do it fast. And then, from a system planning perspective, there’s this issue with – or at least we perceive it to be an issue – is that PGR 127 essentially creates this permitted cadence by which we are going to add premature generation interconnection positions to these models in order to produce feasible planning solutions. Because if we just use the generation that typically is included in these models, the ones that are past planning guide 6.9, it’s not going to be enough generation to actually serve the full scope of batch zero or maybe any batch going forward. And so, that is a logical thing to do, but it also creates this issue of we’re now relying on potentially premature generation assets to produce a firm planning outcome. And so, if those generators do not come to fruition, that might invalidate those results. And so, there’s potentially some instability in the viability of these results if we’re relying on these premature assets that have no commercial tether to loads that are being served by those assets. And so, here we’re just showing that for the scope of batch zero and what is in the queue, there’s more studied load than there is generators that even have a complete FIS. So, there’s a lot of generation that has an FIS underway, but otherwise, this is also nameplate generator capacity. So, a big portion of that is solar, and 100 megawatts of solar does not produce 100 megawatts of deliverability on a firm planning basis. So, yeah, we have a generation problem as much as a transmission problem for being able to produce viable results here.

And I should also say – I should have said at the top, like, you know, obviously, we’re kind of communicating our views about a lot of this stuff, and what is most important for us right now is getting as much critical feedback as possible. That’s been super productive for all of our conversations so far, and we’re talking about these concepts inside ERCOT mostly, but also outside of ERCOT. So, we’re getting a lot of great feedback, and so, I always enjoy people telling us exactly how we’re wrong about how we’re thinking about any of this stuff.

So, as an example, this is just a really simple dummy grid that we’re using to show, you know, if you assume that, you know, the firm planning criteria can be simplified into a G minus one and N minus one, as well as an N minus two firm planning criteria, then you can see that this grid here is capable of serving firm service to these two loads from these three generators and this network topology, because for any of the loads, if one of the – if the largest generator and the large – and, you know, the most impactful transmission element fails, or if two transmission elements fail, both loads can still be served their full nameplate load from the existing topology of the grid. And so, if you add – in this scenario, assume that load three in that bottom left-hand corner is sponsoring the new generator in the right-hand corner, and so, ultimately, that new load three is paying or, you know, has a PPA with gen four, and so, it’s therefore instantiating the existence of that generator, and then, if that generator is added to the planning case, that deliverability that is now created by the of that generator is largely socialized to all the new loads being studied. At least that is our interpretation. You know, always very curious to hear planning feedback on the way that we’re thinking about all this. But in either case, as of today, this is how we understand the planning process to work. So, even though there’s one specific load that’s sponsoring that new generator, the firm contribution is being spread to all the loads.

And so, in theory, you could introduce this concept of load-sponsored generation, where the load that is sponsoring the generator that is being added to the case gets studied first before the rest of the load class is studied. And so, in this example, you can see that, because of the network topology, if you add the generator and add the load, 40 megawatts of that incremental deliverability could be attributed to that load. But it’s not everything. It’s not the full nameplate of the generator, because there’s a binding transmission constraint that is highlighted there. And so, for all these examples, we’re also assuming that they’re just perfect capacity from the generation. So, you know, if it’s a 60-megawatt generator, that is largely creating 60 megawatts of deliverability, aside from the transmission constraints. So, in this example, you know, you can allocate 40 megawatts to that sponsor load, and then after that, then you can study the incremental contribution that can be added to these other loads. And so, therefore, there is a mechanism by which the sponsor creating the existence of that generator can be, you know, appropriately allocated the contribution that is created by that generator, while also preserving, you know, the opportunity for kind of socialized benefits from the grid design. So, to reiterate our concern from before, you know, if we’re just taking PIGAR 127 resources, adding them to the model, and there’s no commercial tether between the loads that are being added and studied and the generators, then there could become, you know, pivotal assumptions in the model where if that generator doesn’t come to fruition, you know, say I’m assuming I’m building a 10-gigawatt nuclear facility outside of Dallas. If that 10-gigawatt nuclear facility didn’t come to fruition, that might invalidate a whole lot of the deliverability that’s been assumed in these models. And so, in an LSG context, if new loads are sponsoring generators, and, you know, that means, like, these loads or these generators, the LSG, could be very premature positions. They might just have an FIS kicked off. But if there’s a load saying I am sponsoring that, and I’m willing to have my firm deliverability conditional on the commissioning of that generator, then that becomes a much, much more reliable study assumption, because not only do you have one of the new loads speaking on behalf of that generator, but then you could also say, okay, well, the load is not going to receive their firm service until that generation comes to fruition. And so, that creates, you know, not only a more reliable assumption, but it also creates this mechanism to basically push the risk away from the bulk power system and onto the sponsor generators or sponsor loads themselves. Bob, I see you have a question. I’m not sure if I should just wait to the end, or… No, let’s wait till the end. Cool. So, in its simplest sense, kind of in a vacuum, it’s basically like a two and a half step process, and there’s actually more steps than that. But in either case, the idea is that if there is a sponsor load and an LSG, then before any new deliverability is allocated to the kind of whole class of new study loads, you first just add the LSG and the sponsor load and determine what sort of incremental deliverability is created for that sponsor load at that location. And then after that, you study all sponsors and all of the LSGs together, because there could be, you know, constraints on the transmission system that limit how much you can attribute to this kind of class of LSGs. And then after you take those two studies, you take the lesser of what is deliverable to the sponsor loads from the whole class of LSGs. And then after that lesser of calculation for the LSGs, you can then allocate the remaining deliverability and plan network upgrades. So, as an example here, the reason why it’s lesser of is for these examples here. So, say you had two LSGs and two sponsor loads. In this case, the combined sponsor study is limiting, because if you studied each of those by themselves, you would see that you would be able to allocate 40 megawatts of deliverability to each load from their new generators. But then if you studied them together, because they’re co-located, they would be constrained along the same contingencies or transmission paths. And so, you’d have to basically, you know, take the lesser of those and allocate that deliverability in an equitable fashion.

Alternatively, you know, a scenario like this could equally – or sorry, and then after the fact, you can allocate the remainder of the capacity or the deliverability to other unaffiliated loads. And so, in this scenario, the unaffiliated loads actually get a sweet deal because of the transmission topology for the sponsor loads. But in this example, the individual sponsor studies are limiting, because, you know, if load – you know, if these two sponsors and LSGs are studied by themselves, that’s where the transmission system binds. But if you combine the two, all of a sudden, you can deliver the full deliverability to each of these loads. So, just highlighting the fact that that’s why there’s these two steps in the LSG sponsor load study step, because it has to be the lesser of to acknowledge the transmission limitations. And then after, you know, that step’s complete, then you can allocate to the remainder of unaffiliated load. So, in reality, I think that the – you know, if there is a feasibility to this approach, then it would look something like this, where you first start with allocating the – you know, kind of the baseline deliverability. So, everything that is existing on the system, given an existing transmission and an existing generation, and then generation that is past planning guide 6.9, that could just be allocated on a traditional basis. And then after all of that capacity is exhausted, that is where we’re introducing this notion of load sponsor generation and sponsor loads. And so, those are the two steps to determine which one is more binding. And so, that is what introduces more reliable planning assumptions ahead of using Picker 127 assumptions for all the remaining generation in the queue, as well as unaffiliated loads. So, we, you know, do the LSG step and then complete the batch as currently contemplated.

Perhaps where we have the least kind of well-formed thoughts is, like, how there could be basically a recursive iteration after that, where once we’re proposing new transmission, if that transmission allows for the load sponsor generation to improve its direct deliverability to the sponsors, then I think it stands to reason that those sponsors should still be entitled to the incremental deliverability that’s created for those loads by the transmission upgrades. But I think, you know, we’re very, very much looking for as much feedback as we can get on these concepts. And not to, you know, overburden the conversation or the focus here, but this is where I think that there actually could be a really nice marriage of some of these open-season competitive concepts for allocation of transmission capacity and pair that with some of these concepts around LSG or non-co-located BYOG. So, potentially some collaboration with some of the other concepts that have been proposed. So, in summary, I think what’s most important to highlight is that this would be a planning-only concept. Unless I’m missing something, I don’t think anything about ERCOT operations would change at all. This is just something that would happen in the planning paradigm. And then once assets are added to the grid, you’re going to be, you know, rocked or, you know, dispatched by SCED in all the conventional processes. And this is really, you know, only to determine where the buckets of deliverability are allocated in the planning cases rather than, you know, trying to create any sort of changes to the operational paradigm. So, what do we see as the positive sum benefits? Because, you know, I think these sorts of conversations really do have an opportunity to make everybody’s lives better. We can get private development to achieve speed to power and give private developers more optionality. So, that will certainly make customers happy. The transmission planning paradigm gets more stable expansion assumptions. And therefore, I think that that could really materially improve our social license to operate. If we can reliably demonstrate that the study assumptions that are going into the proposal of new transmission are extremely credible and trustworthy, then that allows us to kind of, you know, iterate at a faster clock speed for transmission planning. And then also, by encouraging large-scale efficient grid-connected generation at, you know, systemically valuable locations on the transmission system, that is a much more reliable and kind of grid-aware topology compared to if everybody is building behind-the-meter solutions that, you know, might lack visibility for ERCOT grid ops or, you know, lead to a less efficient system build-out. So, I think we’re all pretty much aware with, like, you know, how these conversations are going and what the timelines are. I think TAC meeting later in this month is the focus for trying to take a lot of these ideas and concentrate them into, you know, what are the highest-value, highest-priority efforts. But otherwise, these are a lot of the questions that we’re kind of thinking through. We’ve gotten a lot of great feedback already, and we’re in the process of trying to kind of tick through it all and keep the conversation going with the engaged parties. So, these are, you know, a lot of the big questions that we have floating in our heads right now. And what else? I guess this is a slide I’ve shown a bunch of times, but it’s basically just saying, like, the genesis of these concepts really come from the PUN plus or the BYOG plus concepts that we had floating around in batch zero, where, you know, if you had a co-located set of generation and you can build a transmission – or if you build gen sets that could theoretically suffer a G minus one and still deliver full capacity to the load, then, you know, it certainly stands to reason that that incremental firm deliverability should be allocated to that co-located load. But there’s no reason to just have that be co-located gen in load. You could completely kind of abstract this concept to a system planning philosophy that doesn’t have to be co-located at all. And then on the right-hand side, we’re just showing that if you don’t have a G minus one, you know, design, then besides getting your firm deliverability from whatever is created by the load-sponsored generation, the remainder could operate as a PCLR, and then you’re just privately wearing the curtailment risk. And so, that’s the load taking on the contingency risk rather than the grid under the traditional firm planning standards.

I’m not going to talk about this stuff in depth, but this is just some of the, you know, thornier issues we’re trying to think through, which is, you know, if you have a class of LSG that are being studied before the, you know, all unaffiliated generation, then there’s a reasonable case to be made that, you know, you might need to reserve some of the transmission network capacity to be available to that unaffiliated kind of full class of loads rather than the LSG class because then the LSG class could take up all the transmission capacity, which might not be an issue because this is an entirely, you know, technology-agnostic and load-agnostic concept. Like, really, all loads could be, you know, sponsoring new generation and then benefiting from this paradigm. But otherwise, you know, one of the arguments that could be made is, you know, maybe we just, you know, derate the capacity of transmission elements for the LSG allocation study for the sake of making sure that the unaffiliated – you know, the loads that do not have sponsored generation still get an equitable chance to be allocated network capacity. Yeah, that’s it. Cool. All right. That was pretty fast, but otherwise, very much look forward to the conversation this afternoon, and otherwise, I’m always happy to talk about this stuff, and like I said, very interested in everybody’s critiques. I think that’s the most important feedback. All right, Sam, we have a short queue. I’m first.

Were you here this morning when I talked about what we’re doing with NOGR 1348? Nope. Okay. So, we have been – or the chair has accepted the challenge to work on all of the NPRRs kind of related to bring your own generation, I think?

So, we will need to kind of talk with Jesse over here on his and see if any of this can be merged into one and how all of that’s going to play out. So, I guess my first question, though, related to your presentation, congestion. You are not looking for a hedge against congestion in any way. This is a planning model. If your generation is located some distance away and there’s congestion that’s causing a price separation, that’s on the load, right? Yep. Totally agree. Any sort of economic implications from the design of the grid is a completely separate issue. And then let’s skip over before you get to EEA. If we’re in EEA, do we assume the load still gets this generation or do we assume the state gets this generation in the event of an EEA? Yeah. I’ve been working with the assumption that, you know, Senate Bill 6 is still going to apply. So, yeah. Backup is protected, but if it’s real generation, it’s not. Okay. Yeah. All right. Next up in the queue, Joel, you’re up. Yeah. Have you considered or thought about applying this same concept to transmission where you could have load-sponsored transmission upgrades where, you know, a load goes and pays the TSP to move the project that enables them up in the queue?

In short, yes. I think that that could be kind of the perfect future state of the market. I guess from our perspective, we’re focused on crawling before we walk, before we run.

And that’s where perhaps some of these open-season transmission concepts could come into play. Yeah. Otherwise, very much, you know, as a developer, that’s what agentic infrastructure is. We’re a load and generation developer. Yeah. Very much like the idea of load-sponsored transmission as well. Yeah. And then just a comment for all of us, we have to get this right. I mean, there is 17 gigawatts worth of generation being built east of Amarillo that the grid is not going to get access to because of this.

Sorry. You mean west of Amarillo or east of Amarillo? East of Amarillo.

Gotcha. Otherwise, we’ll hardly agree.

All right. Thank you, Joel. And I completely agree. It is critical we get this right. Next up, Harsh, you’re up. Sam, a few questions. So when you talk about individual studies and say there’s a transmission constraint that limits that generation getting delivered to that load that you’re pairing, do you then expect that transmission line get upgraded or you limit the load or limit the generation? So the way that we’re thinking about it is in this first kind of LSG step, you’re just looking at the deliverability that’s created without any sort of transmission upgrades. And then after the step four, where before any transmission upgrades are proposed, you’re kind of allocating the remainder of LSG and PIGR 127 capacity. Actually, now I’m showing my ignorance because I don’t know from a planning perspective how PIGR 127 and network upgrades are going to work sequentially. I don’t know if you add all the generation and then propose transmission. So in that case, yeah, our current thought is that all this PIGR 127 generation is added after the LSG class for all the unaffiliated loads. And then network transmission upgrades can be made so that they’re – as a load sponsoring generation, I would certainly want to be able to support transmission upgrades both financially but be able to contribute to the planning process about how we get firm service to our sponsor loads. But otherwise, I fully acknowledge that there’s probably a way to plan the network transmission that is to maximally efficiently serve everybody rather than just the LSG load. So – Yeah, and that’s what I was trying to get at, that it depends on what other loads show up. There could be a load that locates next to the generator and then that overload goes away. But it could also be that load shows up on the other side. So then who pays for that upgrade? Is it you as a sponsored pair or is it the new customer? So that’s one thought that occurred to me. Second thing was are you sort of thinking just thermal generation for this concept or all-generation type? And where I’m going with that question is it depends on what time of the day we are talking about. The answer is going to change. Thermal generation, it doesn’t change as much unless you think of the outage, but – which is a follow-up question. But were you just focused on thermal generation here? Yeah, so I’m using a generic perfect capacity resource for the sake of these very simple examples.

Maybe it’s optimism or naivete, but I believe that this could be completely agnostic to generation resources, whether it’s energy storage or the contribution that’s created from renewables. And I think that that would maximally align the market, because then this becomes an entirely technology-agnostic mechanism that works for batteries, could potentially work for VPPs. And so – and then I think otherwise it could work for thermal generation as well. But yeah, we’re thinking about it completely technology-agnostic. And again, I think where we need the most help and input is how this is traditionally done for the different planning cases. Like, we’re always thinking about summer peak, but if there then becomes limiting constraints for the off-peak cases or the higher renewables, low load, or the no-solar case that’s coming down the pike, then I’m not sure exactly how firm service is kind of allocated based off of those different cases today. So yeah, I think that that’s definitely worth discussion. Yeah. So if it’s non-thermal, then you also have to think about all the different variations and how that changes math, specifically solar. You’ll be zero megawatt at some point, so then there is no pairing of generation and load at that point, right? So beyond that then, so what happens – so let’s say you study the pair, but then you need an outage on the generator. Now that produces constraints. You think that would get identified through the studies? Yeah. So from our perspective, just because you add a generator next door or in a strategic location, that does not absolve you of the G-1 and N-1 planning cases. If taking that generator out, it doesn’t yield any sort of incremental deliverability based off the network topology, then you’re still not going to be allocated that firm service. So going down that path, let’s say you pair a generator and a load. The generator goes out. In that one study you do, you identify transmission upgrades that’s not there otherwise, or it’s there just because of the load. With the generation, the transmission upgrade’s not there. In a way, if you do your one-off study, then you would say, well, your one load is causing that issue, right? So technically, you would be allocated the capacity upon completion of the transmission based on that one-off study. When you do batch, there is second load at the same location. You run the same sensitivity of that generation not being there. So with the second load that has no sponsored generation, would that load right through for free? Because you already committed for that transmission up front. And this can work opposite, where you get a free ride because somebody else showed up after. So I think this is one scenario that where you would be the first in the line to get that upgrade and potentially pay for it. So something to think about. Yeah, I might try to chase you down at lunch about that. The other thing I had was, if the load engine are not connecting at the same time, you have to mandate syncing the ISD. Do you agree with that? So I always think about, we’re developing all of our loads as PCLR. So we’re happy to have PCLR capacity until the generation is commissioned. So that is what becomes a really helpful de-linking of those two service timelines. But otherwise, yes, you would be basically waiting until that generator is commissioned, and you get the blessing from your team. So there’d be a PCLR or sync the dates. Okay. And the last question is, you talked about one-off studies and then a batch just for these pairs, and then eventually the ERCOT batch. Batch as is, it’s a one-year time frame. So have you thought about how much extension that would get as a result of this proposal? Yes. And this is where I’ll probably sound really dumb, but I feel like there are software or maybe even AI-enabled software solutions that could allow for these iterative solutions to be done very quickly. If we can sufficiently define the constraints and the cases. So I would hope that it, I mean, I think of folks like Tapestry or other such software providers that might be able to help. Okay. I don’t think ERCOT has that today that I know of, but that’s something needs a discussion. Thank you all. Thank you. All right. So we are over time. Did get one question with some additional comments. ERCOT, any initial thoughts on this presentation? Anybody have anything to say? Ah, here comes Mr. Moranis to the microphone.

Sam said it well. He’s been working with ERCOT. We’ve done a couple of meetings on these concepts. This is idea number 18.1 in the list and we’re not to that point in the list to triage. And honestly, what we’re trying to do is triage. When we have this many ideas, we’re actually trying to do miniature impact analysis to see what’s feasible, what has gaps or scary things in it. And we haven’t gotten to this one yet. I still wonder how this works in real time with the loss of the paired generator. So it’s not to say it’s not answerable. It’s just, we don’t know yet. So there just hasn’t been enough time to get through this one yet. All right. Thank you very much, Matt. With that, we are… I’m just going to ask this question because I’m going to ask it otherwise off the mic. But I guess, do you see a difference in these concepts compared to like the non-co-located BYOG? Because that was highlighted in the ERCOT deck as both a short-term and a long-term priority. Right. And that was for the market. That’s what they want. And we’re saying we’re trying to look at those as soon as possible. Today we’ll unpack the battery. We’re not ready to unpack all the other ones yet. Gotcha. Okay. That’s helpful. Thanks. All right. Thanks everyone for your attention. We do have a one o’clock on comprehensive transmission planning. So we will see you back at one. Everyone race off to lunch. Thank you very much. We are adjourned.

LLWG Meeting – 10/15/26 – VIDEO

Table of Contents

The following text has been copied to the clipboard

Take the Guesswork Out of ERCOT

Navigation

Data and Software

consulting

Meet the Experts

Steve Reedy

Greg Graham