Large-load queue transparency: what each U.S. grid operator publishes

The public queue workbook NYISO-Interconnection-Queue carries a dedicated Load Projects tab alongside generation. In the file read from NYISO on 3 October 2026, whose rows carry updates through 30 September 2026, it holds 74 load interconnection requests, each with a queue number, developer and project name, submission date, peak MW, county, NYISO zone, point of interconnection, utility and a status value; withdrawn requests are kept and counted separately. A companion Load Project Tracking tab publishes the same population summarised three ways — by status, by end-use and by submission year — each broken out across the NYISO zones.

Status field. Yes — Project Status #, and the file carries its own key. The early rungs track the studies, from a scoping meeting through feasibility, reliability-impact and facilities studies, with withdrawal available throughout. The rungs that matter for this survey are the later ones, which we quote rather than paraphrase: 10 Accepted Cost Allocation/IA in Progress, 11 IA Completed, 12 Under Construction, and then 13, 14 and 15 for service, in test, commercial and partial. So the ladder names the executed interconnection agreement explicitly, and carries four further rungs beyond it.

• Our arithmetic reproduces theirs, and we show where the two populations differ. In that file the 74 rows total 17,672.0 MW; subtracting the 3,078.9 MW NYISO reports as withdrawn leaves 14,593.1 MW not withdrawn. NYISO's own MW By End-Use table totals 13,611.9 MW, and our reading of that classified population matches it to the decimal. The 981.2 MW difference is six rows that carry no end-use code — four of them already in commercial service and two awaiting a scoping meeting. We report the reconciliation rather than a single number because a survey that cannot reproduce an operator's own arithmetic has no business describing that operator's file.
• The end-use classification, which is the most specific disclosure in this survey. An end-use code appears on 51 of the 74 load requests — withdrawn rows are left blank, and a few others are — and NYISO publishes the taxonomy: DAT Data Center (general) · DAT-AI AI Datacenter · DAT-CM Cryptocurrency mining · M-CH Microchip fabrication · M-CG Consumable Goods · M-IN Industrial Goods · RD Research and Development · HP Hydrogen Production · O Other. In this file the three data-centre classes account for 11,887.9 MW of the 13,611.9 MW classified — 87% — of which 5,266 MW is declared AI datacenter, broken out by zone. We report that class, and the four things it cannot tell you, at index.loadstar.energy/ai-load.
• And here is the gap that survives all of it. In that file, four requests sit at 10, agreement in progress, and none sits at 11. Eight sit further along still — four under construction, four in commercial service — so those eight plainly cleared the agreement stage. And yet the IA Tender Date column is empty on all 74 rows, theirs included. The file therefore follows a large load from first study to commercial operation without ever recording when the agreement happened. We are describing the record, not the world: those agreements plainly exist. They are simply not in the file.
• The list is not a census. NYISO's interconnection rules reach load above a size threshold set in its tariff; requests below it fall to the transmission owner's own procedure and never appear in this file. We have not verified that threshold against the tariff, so we do not state it. The figure is not in doubt — it is written in the OATT; we simply have not read the section, and would rather leave a gap than publish a number we have not checked.
• Updated 3 October 2026. This entry previously described the edition dated 31 July 2026: 73 requests, 13,568.9 MW classified by the operator and 5,290 MW in the AI-datacenter class. The file read on 3 October 2026 holds 74 requests, 13,611.9 MW classified and 5,266 MW in that class. The earlier file carried its date in the name NYISO gave it. This one does not, so we give the day we read it and the latest update date on its rows.
• Corrections, 20 August 2026. An earlier version of this entry put load inside the generation queue rather than in its own tab, named the status column S, reported 51 rows and 12,670.1 MW, and said no row sat at 10 or 11. Reading the live file corrected all four — and turned up the end-use classification, which we had missed entirely. The custody note below explains how we came to be working from an archived copy in the first place.

MISO does not operate a load interconnection queue; large-load requests go to the transmission owner. What MISO publishes is a per-row table of Expedited Project Review cycles — transmission projects whose dominant driver is large load. The columns are EPR Cycle · Project ID · Project Description · MISO Region · Transmission Owner · Load Value (MW) · Current Status.

Status field. Yes, Current Status — and it does not answer the question. Its values (Under Study, Approved) track the progress of the transmission project's study, not the commercial maturity of the load behind it. An outside reader cannot use it to separate load with an executed agreement from a request without one.

• MISO publishes a page dedicated to large load, and it carries no per-request record. Read on 21 August 2026, the operator's Large Load Additions page sets out a three-part framework, a Large Load Working Group, workshops, and a formal Large Load definition. It names the accelerated paths by acronym: ERAS (Expedited Resource Addition Study), EPR (Expedited Project Review), ZGIA (Zero-Injection Interconnection Agreement), and a further study process it describes as under development. What the page does not contain is a list: the words status, queue and MW appear zero times on it. We report this because it is the operator's own page for the subject of this survey, and it is the strongest available basis for the verdict on this row.
• The operator reads the June 2026 FERC order as a directive. The same page states that on 18 June 2026 the Commission directed all RTOs and ISOs, MISO included, to update large-load tariff provisions, citing 195 FERC ¶ 61,212. We record the operator's characterisation and do not adopt it: our own reading of the orders, set out below, is that they are show-cause proposals and that nothing is required yet.
• Confidential load values are withheld — a footnote on every April 2026 slide states so, several rows carry a blank MW value, and cycle totals are therefore published with a trailing +.
• The unit is the transmission project, and the load customer is not identified. In the April 2026 cycle materials the project descriptions are codenames. MISO does also publish individual review request forms, and those name the transmission owner and the station — which is a real disclosure, and one about the transmission project rather than about the load behind it.
• A coverage gap by design. Under MISO's 2023 load interconnection whitepaper, if the transmission owner determines that no network upgrade is required, that request is not required to be included in the MTEP process — so load that needs no upgrade never appears anywhere.

A monthly public report on large-load interconnection requests, required by §3.2.7 of the ERCOT Nodal Protocols (created through NPRR1267). A public report on large load is therefore mandated here by rule, and that is what makes the case instructive: it shows what a mandate of this shape does, and does not, produce.

Status field. Not in this report. The dimensions the §3.2.7 monthly report is required to carry do not include a status or commitment field. Taxonomies ERCOT publishes beyond those dimensions are reporting practice rather than a protocol requirement — and what the Batch Study process publishes separately, we have not established.

• Aggregation is the rule for this report, not a choice. The protocol language requires the monthly report to aggregate large-load interconnection requests while maintaining the confidentiality of customer data, sets a floor of three customers per subcategory, and expressly permits ERCOT to round MW request sizes and dates, or take similar steps, to obscure customer-owned data.
• What we did not establish, and it matters on this row. Everything above concerns the §3.2.7 monthly report, which is the document we read. The Batch Study process publishes material of its own, and we have not established what those publications contain — whether they name projects, and whether inclusion in a batch is itself a readable status. Read as a claim about ERCOT disclosure in general, nothing on this row would be supported; read as a claim about the monthly report, all of it is.
• The framework changed in June 2026, and the dates matter. ERCOT's board adopted the batch rules on 2 June 2026 and they became final when the Public Utility Commission of Texas approved them on 18 June 2026. 10 July 2026 was the deadline for projects to submit their documentation, not the date the taxonomy changed, and on 7 August 2026 ERCOT was due to notify applicants of their classification. Any earlier five-stage taxonomy is superseded and should not be cited as current.
• What the batch process is scheduled to publish, in ERCOT's own words. The published output is a transmission plan — “Fall 2027 — A final transmission plan allocating the load and prescribing updates is published”. The per-project classification into base load, studied load or excluded load is described as a notification to applicants. We therefore still cannot say whether that classification is published per project — but the gap is now a specific one, and it has a date attached.
• Corrections, 20 August 2026. This row previously said the taxonomy changed on 10 July 2026 and that Batch Zero buckets were published on 29 July 2026. Reading ERCOT's own June 2026 explainer corrected both: the rules became final on 18 June 2026, 10 July was the deadline for applicants to submit documentation, and what ERCOT describes for August is a notification to applicants rather than a publication. Both wrong dates came from reading about the framework instead of reading it.
• Approval to energize is not a signed commercial agreement. It is an ERCOT operational approval, and equating it with an executed interconnection agreement on the generation side is a category error.
• Who counts as a large user, now from the source. ERCOT defines one as a single site with peak demand above 75 MW, and that is the eligibility floor for the batch process. We previously carried this figure without a primary source and left it off the page; it is now read from ERCOT's own June 2026 explainer.
• Commitment screens do exist — a financial guarantee per MW in Batch Zero, sample-based verification of documentation, and a commitment deadline — none of which appears in the monthly report on a per-project basis. ERCOT's explainer puts that deadline in June 2027, when Batch Zero developers must post financial security and prove site control, and states plainly: “ERCOT understands that not all connection requests result in built projects.” Whether any of it is exposed per project we did not establish.

Nothing per request. CAISO's PublicQueueReport.xlsx has three tabs, for active, completed and withdrawn requests, and all three are generation. Our reading of the file finds the word load zero times in the entire workbook.

Status field. Not applicable — there is no large-load list to carry one.

• The operator has asked the Commission for more time. On 3 August 2026, in Docket EL26-71-000, CAISO filed a Motion for Abeyance under Rule 212, asking that the show-cause proceeding be held in abeyance for 90 days from the deadline to respond, which it states as 16 November 2026. Its stated reason is to have time to develop, with stakeholders, the policies needed to address the Commission's preliminary findings. We record this because a reader assessing how quickly the gap described here might close should know that the operator itself has asked for the clock to be extended.
• The operator describes the gap itself. CAISO's Large Loads Straw Proposal of 12 August 2026 records at p.14 that the current process requires load interconnection requests to be submitted to the appropriate participating transmission owner under the PTO's own tariff; and at p.27 it encourages those PTOs to memorialize tariff requirements to adopt large load queue spreadsheets, as CAISO does for wholesale generator interconnection customers. A recommendation to adopt the spreadsheets would be unnecessary if they already existed.
• Where the record sits in California. By CAISO's own account the requests go to the participating transmission owner under that owner's tariff, which puts the record with the utility and the CPUC rather than with the ISO. We do not offer a jurisdictional explanation for why. Reviewers of this page gave us three incompatible accounts of the mechanism, we could not settle it against a primary source, and the survey does not need it: what matters here is where the record lives, and that is observable.
• Downstream of the ISO, the record thins out rather than improves. The transmission owner receives and studies every request under its own tariff rule and publishes none of it; CAISO's annual transmission plan shows concurrence projects once a year without a status column or a customer name; the CPUC record surfaces individual projects only through one-off resolutions; and the state energy forecast publishes confidence tiers in aggregate, with per-project submissions confidential.
• We read PG&E's Electric Rule 30 (Sheet 60532-E, effective 4 December 2025) in full, sections A through G: the words queue, post, status, website and transparen- occur zero times.

The only per-project large-load data published is a table of two projects included in the forecast — one 200 MW data center in the NEMA zone and one 85 MW electrification project in Connecticut — with the columns Load Zone · Project Type · Reported Nameplate · Timeline. There is no status column and no request identifier. It is a list of what has been folded into the forecast, not a queue.

Status field. No. And the omission is visible from the outside, because ISO-NE publishes the maturity ladder it uses internally — a stepped completion probability running from a signed study agreement, through a completed interconnection study and a construction agreement, to commercial operation. The ladder is public; which step a given project stands on is not.

• The operator told the Commission, in writing, that it does not forecast these loads yet. In a letter dated 18 September 2025, the Chairman of the Federal Energy Regulatory Commission asked ISO-NE four questions about large-load forecasting, among them how far prospective requests are subject to consistent, objective screening before entering a load forecast. He pointed to the commercial-readiness criteria already used in the generator interconnection queue, naming contracts, financial security deposits and site control. ISO-NE replied on 6 October 2025. Reporting the substance rather than quoting it: the operator states that its long-term load forecast does not explicitly account for step loads at present, and that it is researching methods with the aim of including a large-load component in the forecasting cycle beginning in September 2026. We read this as directly relevant to this survey, because a load that is not yet in the forecast is also not in any public per-request record.
• And the list may be short because the pipeline is short. In its 20 July 2026 informational report to the Commission in this proceeding, ISO-NE states that New England “has not yet encountered significant load growth attributable to the addition of large loads, such as data centers”. We report that alongside the thinness of the published record because the two are easy to confuse, and only one of them would be a disclosure failure.
• There is not yet a tariff definition of the thing being disclosed. The same filing says ISO-NE “anticipates defining ‘large loads’ in the Tariff”, and that it has been working with the region's transmission owners to develop protocols for tracking large loads. A category that has no tariff definition is hard to publish a queue of.
• Requests without a signed study agreement are invisible by construction. Entering the published table requires 20 MW or more and a signed study agreement — so a request that never signs one never appears.
• A trap worth flagging for anyone else looking. The Tariff §I.3.9 list carries an excellent status field (ISO Action: Approved, Notification, Approved Withdrawn, Approved with conditions, Not approved) and it is not a large-load list. We parsed 5,905 rows and found zero hits for data center, hyperscale, crypto or large load. It should not be described as one.

The revision requires an OASIS listing, and the unit it names is not the load. SPP's board approved Revision Request 696, Integrate & Operate High Impact Large Loads, on 4 September 2025. We read the revision in full. It provides, verbatim, that “HILLGA Requests shall be listed on the Transmission Provider’s OASIS along with all other Interconnection Requests”, and it creates a named agreement instrument for large load, the HILLGIA, executed copies of which are filed at the Commission.

Read against the revision's own definitions, that clause does not reach the load. The same document defines a HILLGA Request as an Interconnection Request made under the High Impact Large Load Generation Assessment procedures to interconnect a new Generating Facility, or to increase the capacity of an Existing Generating Facility. What section 3.5.1 posts to OASIS is therefore the on-site generation that supports a large load, not the large-load request itself, which the revision routes through a separate delivery-point study. We corrected this on 21 August 2026: an earlier version of this row read the clause as covering large-load requests, which the definition does not support.

Two things stop us calling it a finding. First, board approval is not an effective tariff: SPP's own comment record contains an intervenor objecting that SPP “will move forward with implementing RR 696 prior to FERC approval”, and we did not establish whether the Commission has accepted it. Second, OASIS refused our connection, so we could not look at what is actually listed there or whether it is reachable without an account.

Under the older tariff path, large-load requests are submitted by email, to a load studies mailbox, under Attachment AQ or AX, and study reports go to the customer — no queue file, no request identifier, no status ladder. That is not the whole picture, and we had it as the whole picture. SPP's board approved a dedicated High Impact Large Load (HILL) framework on 4 September 2025, through Revision Request 696, which folds transmission service, generation and load interconnection and reliability studies into one process with a 90-day study-and-approval clock. SPP's own announcement describes it as accelerating load interconnection through “integrated design, study, registration and operations” and names transparency among the benefits for developers.

Status field. Not established. The older tariff path produces no request record to attach a status to. The 2025 revision would put large-load requests on OASIS beside generation requests, which carry status — but we could not reach OASIS to see what is shown, and we did not establish that the revision is in effect.

• The operator publishes a page for this, and it is open to anyone. Read on 21 August 2026, SPP's High Impact Large Load (HILL) Integration page sets out the framework it is building and names its parts: CHILL, a conditional service offering faster access in exchange for possible curtailment, and HILLGA, an assessment that studies a large load and its supporting on-site generation in parallel. The page states a target of reaching interconnection agreements within 90 days. It also carries a running series of Large Load Processes Q&A meetings with published materials and transcripts, the most recent listed for 6 August 2026 and a further session scheduled for 17 September 2026. What the page does not carry is a list: the words status, queue and MW appear zero times on it. This does not resolve the row, because the obligation described above runs to OASIS and OASIS is what we cannot reach
• The one publication path in the tariff is conditional, and it filters out exactly the cases an outside reader needs. Under Attachment AX §2.4 the study report is published only if a network upgrade is identified and the customer elects to proceed. A request that dies before that point therefore never appears — the opposite of what transparency in this record would require.
• What we probed for, and what we found. We ran the same word probe over the revision that we ran over PG&E's tariff rule. The 73 occurrences of website are all rate and revenue-requirement filings; the 39 of queue are all transmission-service reservation timing. The listing obligation is not on SPP's website at all — it is on OASIS, which is a different kind of door, and the one we could not open.
• Two dates, and only one of them is the decision. SPP's news release is dated 16 September 2025; the board motion recorded in the revision package is 4 September 2025. We cite the record, not the announcement.
• SPP does publish a generation interconnection queue, with status values and a CSV download, and it publishes transmission plans. That is the source of most of the confusion about what is available for load.

PJM publishes a per-request queue — the Cycle Service Request Status table, with the columns Project ID · Name · State · Status · TO · MFO · MW Energy · MW Capacity · MW In Service · Fuel. Read live on 20 August 2026, its own Fuel filter offers sixteen values and every one of them is a generation fuel: biomass, coal, fuel cell, hybrid, hydro, methane, natural gas, not specified, nuclear, nuclear fusion, offshore wind, oil, other, solar, storage, wind. There is no load category, and the page returns no hits for large load, data center, crypto or hyperscale. That does not make PJM a “no”. This is the generation interconnection queue; a large load would not travel through it in the first place, so its silence is expected and answers a question we did not ask. Where a PJM large-load request would be recorded, and whether that record is public, is what we have not established.

Status field. Not established.

• What we did to try, so that our not-established means something. On 21 August 2026 we rendered the operator's public planning and markets pages in a real browser rather than reading raw HTML, because the site builds its navigation with script. Neither surfaced any large-load page. We also searched the public web archive for any pjm.com address containing large load in its path, back to 2025, and found none; the same query returns results for other operators, so the instrument works. Two addresses we guessed returned HTTP 200 with the title Page Not Found, which is why we report what we read and not what a status code implied. None of this establishes that PJM publishes nothing. It establishes where we looked
• This row is the reason the survey is worth reading. A negative finding and an unfinished search look identical from the outside unless someone labels them — and the whole value of this page depends on that label being honest.
• One claim about PJM, tested and dropped. A hostile reviewer of this page argued that PJM's public queue carries load rows alongside generation, with status values marking an executed service agreement — which would have made PJM a second operator publishing what the NYISO publishes, and would have changed the finding at the top of this page. We opened the queue and checked: the sixteen values in its own Fuel filter are all generation fuels, and there is no load row type. We record the claim and its refutation rather than quietly dropping it.
• What would settle this row, and how far we got. The question is whether PJM publishes a per-request record of large-load requests outside the generation queue — most plausibly under transmission service requests, which is what a large load would actually apply for. We went looking. PJM's OASIS redirects to a tool that requires an account. Queue Point, suggested to us as the public alternative, is by PJM's own description a tool that “allows interconnection customers to submit new interconnection requests” — a submission system, behind the same sign-in. Those are doors we could not open, not records that are missing, and we are not willing to report the second thing when we only established the first.