HyperQ and the PJM Queue Reform: What the Moratorium Years Changed, and What It Means for Site Control

The queue that stopped accepting applications

There was a period — spanning roughly 2022 through early 2026 — when PJM’s interconnection queue was effectively closed to new entrants. Not slow. Not backlogged. Closed. If you tried to submit a new interconnection request during that window, there was no path. This fact surprises many developers encountering the queue for the first time today, and it explains a great deal about why HyperQ exists and why its evaluation logic is structured the way it is.

The proximate cause was volume. By 2022, PJM’s interconnection queue had grown to over 260 GW of pending requests — a figure that dwarfed PJM’s installed capacity of roughly 180 GW and made meaningful study timelines impossible under the existing serial, first-come-first-served process. The median time from interconnection request to commercial operation date in PJM had extended past five years. Projects entered the queue speculatively, sat for years, and then withdrew — triggering restudies for the projects behind them. The cascade was self-reinforcing. Every withdrawal required PJM engineers to rerun the system impact study for the remaining cohort. The backlog was not a staffing problem or a budget problem. It was a structural problem with the rules.

In January 2022, PJM filed with FERC to formally suspend acceptance of new interconnection requests. FERC accepted the suspension as part of PJM’s broader reform plan. The queue did not reopen for new standard-path applications until Cycle 1, whose application window opened in early 2026 with a deadline of Sunday, April 27, 2026. For approximately four years, there was no conventional route into PJM’s interconnection process for a project that was not already in the queue.

What happened to applications during the moratorium

Projects already in the PJM queue at the time of the suspension were not abandoned. They were bifurcated into Transition Cycle 1 (TC1) and Transition Cycle 2 (TC2), which processed legacy queue applications under modified versions of the pre-Order-2023 rules. TC1 covered projects that had already received System Impact Study results. TC2 covered earlier-stage legacy projects that had received queue positions but had not yet progressed through study. Both transition cycles applied a modified readiness-screening framework: projects that could not meet the new commercial readiness milestones within defined deadlines were withdrawn.

The transition cycle process was also where the site control evidence bar began its evolution. TC2 applicants faced the first wave of Manual 14H site control requirements that prefigured what Cycle 1 would eventually enforce at full intensity. PJM’s July 2025 Manual 14H update (FERC Dockets EL25-22-000 and ER25-1544-000, accepted June 10, 2025) codified the density rules and parcel-modification grammar that the transition cycles had stress-tested in practice.

New projects that had not entered the queue before the suspension had no path whatsoever through the transition cycles. They had to wait for Cycle 1. For many developers, this meant four years of land control under option without a queue position — a carry cost and optionality risk with no process to mature into. Options expired. Land positions had to be re-secured. Projects that had committed to lease payments in 2021 expecting a near-term queue path were still paying land holdover costs in 2025. The moratorium years created a generation of developers who have never operated under the pre-reform serial process and whose entire queue experience is built around the Cycle 1 framework. HyperQ is the only interconnection review infrastructure they have ever encountered.

The Reliability Resource Initiative: the one exception

The moratorium had one operational carve-out that matters: the Reliability Resource Initiative (RRI). PJM launched RRI in 2024 as a one-time expedited path for a curated set of mature projects that could realistically reach commercial operation within a near-term reliability window. FERC approved the RRI framework in Docket ER25-712-000. PJM selected 51 projects totaling 9,361 MW UCAP from a larger applicant pool based on construction readiness, commercial viability, and location relative to identified reliability gaps.

RRI projects bypassed the standard Cycle 1 queue path and ran on an accelerated study timeline under Tariff Subpart C, Sections 305–306. The 51 selected projects entered a study process during 2025 while Cycle 1 was still in its pre-application window. This means that by the time Cycle 1 opened in early 2026, PJM was simultaneously running RRI study work and Cycle 1 application review — two overlapping evaluation processes governed by the same tariff but with different timing and eligibility rules. For a fuller treatment of the RRI site control obligations, see our article on PJM RRI site control and the TC2 interaction.

The RRI selection process is itself instructive for understanding HyperQ. The selection rubric scored projects on factors including site control completeness, deposit posting status, off-take agreements, and construction readiness. That scoring logic — a structured, weighted evaluation of developer-submitted evidence — is a direct preview of how HyperQ approaches the Application Review Phase. RRI was PJM running the algorithm by hand; HyperQ is the algorithm running it at scale.

What HyperQ actually is

HyperQ is PJM’s interconnection queue management platform, built to support the cluster-era process that FERC Order 2023 mandated. It handles queue intake, application tracking, deficiency generation, milestone management, and the automated screening pass that powers the Application Review Phase. It is not a black box: every evaluation criterion HyperQ applies is published in Manual 14H or the OATT Tariff. The platform is the enforcement mechanism for rules that are fully readable before you submit.

This is the fundamental change from the pre-moratorium era. Before 2022, the interconnection evaluation process was human-driven from the first touch. A PJM staff reviewer opened your evidence binder, interpreted your instruments, and issued deficiencies based on judgment that could vary across reviewers and review periods. Developers who had long-standing relationships with PJM project management understood which interpretations were firm and which had flexibility. That informational asymmetry no longer exists in the Cycle 1 process. HyperQ applies the same rules to every submission in the same order on the same day. There is no reviewer discretion at the screening layer. There is no relationship to invoke. The algorithm either passes your package or it does not.

This is not a complaint. It is a specification. Deterministic evaluation is only a liability if you do not know the specification. If you know exactly what HyperQ checks and you pre-flight your package against those checks before submission, deterministic evaluation is an enormous advantage: you get a reliable signal before the 10-business-day cure clock starts running.

What HyperQ evaluates in your site control package

The HyperQ evaluation of a site control submission runs through several distinct check layers, in roughly this order. Each layer corresponds to a specific Manual 14H section and a specific deficiency code in PJM’s notice templates.

Layer 1: Completeness and attachment presence

Before evaluating content, HyperQ verifies that the required attachment types are present. At minimum: an executed instrument schedule (listing parcels by APN or legal description, instrument type, execution date, term, and coverage acreage), copies of the instruments themselves, and a completed Officer Certification signed by an officer of the applicant entity. Missing any of these results in an immediate completeness deficiency before content evaluation begins. The completeness check is the least forgiving layer precisely because it runs first: a project that has executed leases covering 100% of its footprint will still receive a deficiency notice if the Officer Certification attachment is missing or uses the wrong template version.

Layer 2: Instrument eligibility

HyperQ cross-references each instrument listed in the schedule against the eligibility rules in Manual 14H Section 7.1. The key disqualifying conditions:

• LOI/MOU instruments. Letters of Intent and Memoranda of Understanding are not eligible site control instruments under Manual 14H Section 7.1.1. A schedule that lists an LOI alongside executed leases will receive an instrument-eligibility deficiency for the LOI parcels. The coverage math then runs against only the eligible instruments — and if the LOI parcels are needed to reach the density threshold, the application is deficient on coverage as well.
• Options without executed lease authority. An option to lease is eligible only if the option itself grants exclusive negotiating rights, specifies a defined term that survives the project’s estimated Commercial Operation Date, and is executed (wet or qualified electronic signature) by both parties. An unsigned option, an expired option, or an option that terminates before the projected COD is ineligible for the parcels it covers.
• Verbal or informal agreements. No verbal or informal agreement of any kind constitutes site control evidence under the post-Order-2023 framework. If it is not in a written, executed instrument, it does not exist for HyperQ’s purposes.

Layer 3: Coverage math

The coverage calculation is the layer most developers think of first when they think about site control deficiencies, but it is structurally the third check — which means a coverage-deficient project may actually have multiple deficiency findings (completeness, instrument eligibility, and coverage) all generated from the same submission gap. Coverage math under Manual 14H Section 7.1.6 runs as follows:

HyperQ sums the acreage of all eligible instruments, computes the coverage percentage against the project’s proposed footprint, and flags any shortfall as a coverage deficiency. Projects claiming higher-density configurations must submit a PE-stamped Site Plan from a Professional Engineer licensed in the state of the facility. A PE stamp from a neighboring state does not satisfy the requirement. HyperQ does not grant partial credit for a stamp in process; either the stamp is present in the submission or it is not.

The coverage check also runs a cross-queue parcel check. PJM holds APN records for all active queue tracks — Cycle 1, RRI, TC1, TC2. If a parcel you list in your instrument schedule also appears in another active queue track’s site control record, HyperQ flags the overlap. Exclusive site control cannot be claimed by two projects simultaneously. Double-counting across a developer’s own multiple queue positions is also caught here: a parcel serving Project A cannot be used to satisfy coverage for Project B in the same RTO footprint.

Layer 4: Officer Certification template and content validation

The Officer Certification is PJM’s structured sworn statement, defined in OATT Attachment Q and Exhibit A thereof. HyperQ checks three things about the certification:

• Template version. PJM has issued updated Officer Certification templates following each Manual 14H revision. A certification prepared on the pre-July-2025 template is non-conforming for Cycle 1 applications submitted after the effective date of the July 2025 update. HyperQ identifies template version by document structure; submitting an older template version triggers an Officer Certification deficiency regardless of the content’s accuracy.
• Wet or qualified electronic signature presence. The certification must carry a wet-ink or DocuSign-equivalent electronic signature. A typed name in a signature block without a digital certificate, a scanned signature page without the underlying certificate chain, or a PDF created by printing and re-scanning a word processor document all fail this check. The officer must be an officer of the applicant entity — not an agent, attorney-in-fact, or project manager unless specifically authorized by corporate resolution attached to the certification.
• Content completeness. The certification must identify the applicant entity by its full legal name as registered, recite each parcel covered by site control with APN and acreage, identify the instrument type and execution date for each parcel, and confirm that the instruments grant rights through a date beyond the projected Commercial Operation Date. A certification that lists parcels without APNs, or that uses a county assessor’s description rather than the APN, creates a cross-reference gap that the automated check cannot resolve.

Layer 5: Section 7.2 parcel-modification grammar

Developers who have submitted in a prior cycle and are now modifying their parcel set face an additional layer: the parcel-modification grammar defined in Manual 14H Section 7.2. The grammar governs which modification types are permissible and which require supplemental justification or a PE-stamped layout. Three operations are recognized:

• Supplement. Adding parcels to increase coverage. Always permissible. No justification required.
• Substitute. Replacing one parcel with another of comparable or greater acreage at the same project footprint location. Permissible with documentation showing the substitute parcel is adjacent or contiguous and serves the same project area as the removed parcel.
• Expand. Enlarging the project footprint beyond the previously defined boundary. Requires PE-stamped layout showing the expanded configuration is technically necessary and feasible. Expansion cannot be used to cure a coverage gap on the existing footprint — it is a project-scope change, not a site control fix.

HyperQ applies the grammar check by diffing the current APN set against the prior submission’s APN set. Parcels that appear in the new set but not the prior set are supplements. Parcels in the prior set but not the new set trigger a substitution or removal evaluation. Parcels that extend the project boundary in a GIS sense trigger an expansion flag. An expansion submitted without a PE stamp fails immediately; a substitution submitted without adjacency documentation fails the grammar check even if the replacement parcel covers equivalent acreage.

The enforcement gap: why the moratorium era changed expectations

Developers who submitted applications in the pre-moratorium serial queue operated under a fundamentally different evaluation environment. PJM’s review staff was smaller relative to queue volume, and the review process was iterative: a deficiency notice in the old system was often the start of a conversation rather than the start of a countdown clock. Reviewers would email applicants directly with informal clarifications. Multiple rounds of informal back-and-forth — “we need a little more detail on parcel X” — were normal before a formal deficiency was issued. The process rewarded teams with strong relationships at PJM and penalized teams who were new to the footprint.

None of this exists in the HyperQ world. The Application Review Phase clock starts the moment a deficiency notice is issued. The 10-business-day cure window is a hard cap defined in OATT Tariff Part VII, Subpart C, Section 306(B). There is no informal communication layer before the clock starts. If HyperQ’s automated screening layer cannot validate your submission, the notice goes out and the clock runs. PJM staff cannot pause the clock informally because they do not own the clock — the tariff does.

This is the enforcement gap that developers returning to PJM after the moratorium are most likely to underestimate. They remember the pre-moratorium process. They expect the informal conversation layer. It is gone. The first signal they receive from PJM about their site control package will be a Notice of Deficiency with a timestamped 10-BD countdown. There is no advance warning, no informal preview, no “heads-up from your project manager.” If you are not pre-flighting your package independently before submission, you are discovering your deficiencies at the worst possible time.

For developers building queue tools: what HyperQ exposes

The shift to algorithmic evaluation has a concrete implication for anyone building software that touches the interconnection process: HyperQ’s evaluation criteria are a published specification. Manual 14H, the OATT, and the Officer Certification template together define every rule that HyperQ applies. That is unusual in the regulatory software space. Most compliance domains have rules that are partly discretionary, partly precedent-driven, and partly dependent on which human is reviewing the submission on a given day. The HyperQ evaluation layer has none of that. Its inputs are structured data (parcel APNs, acreage figures, instrument dates, template version identifiers) and its outputs are binary (pass or deficiency). That means you can build a pre-flight checker that replicates HyperQ’s first-pass evaluation with high fidelity — and you can do it entirely from public documents.

The technical surface breaks down into four components:

1. Parcel-level coverage engine

The coverage math is a join between the developer’s instrument schedule and a parcel GIS layer. The instrument schedule provides: APN, acreage, instrument type, execution date, term end date. The parcel layer provides: APN, county geometry, assessed acreage (for cross-referencing developer-reported figures). The coverage engine aggregates eligible-instrument acreage by APN, sums to project footprint, and checks against the Manual 14H Section 7.1.6 technology-specific thresholds. This is a well-specified spatial join + aggregation pipeline. The hard part is not the math; it is acquiring clean, current parcel data for every county in the PJM footprint (13 states + DC). County assessor parcel datasets vary substantially in update frequency, APN format conventions, and geometry quality. A pre-flight tool that cannot resolve an APN in a given county will produce false-pass results for parcels in that county — which is worse than no pre-flight tool at all, because it produces false confidence.

2. Instrument eligibility classifier

Given an executed instrument PDF, the eligibility classifier must determine: (a) instrument type (executed lease, option, LOI, ROW, easement, fee simple deed, other); (b) execution date and whether both parties have signed; (c) term end date and whether it survives projected COD; (d) exclusivity language (does the instrument explicitly exclude conflicting grants to third parties?); (e) parcel description cross-reference (does the instrument cover the parcel identified in the schedule by APN or legal description?). Each of these requires either structured text extraction from the instrument PDF or OCR + entity extraction from a scanned document. The instrument eligibility step is where the “PDF tax” is most expensive: a clean, machine-readable lease PDF with a well-formatted Exhibit A can be classified in under a second. A handwritten amendment to a 1991 lease recorded in the county deed book will require human review regardless of how good your extraction pipeline is.

The classification taxonomy matters for system design: executed_lease, option_to_lease, option_to_purchase, easement, row_agreement, fee_simple, and loi_mou are the primary types. The first five are eligible (subject to term and exclusivity checks). The last is not. Everything else (verbal, informal, mou_unsigned) is immediately disqualifying. A good classifier returns both a type label and a confidence score, because the downstream action for a low-confidence classification is human escalation, not automatic rejection.

3. Officer Certification template parser

The Officer Certification is a structured document, but it is delivered as a PDF. Parsing it requires identifying: the template version field (usually a footer or document reference number), the signatory name and title, the signature block (wet or digital certificate metadata), the parcel table (APN, acreage, instrument type, instrument date for each covered parcel), and the COD representation. The template version check is the most tractable: PJM’s templates are versioned by date in the document metadata and footer. A version string comparison against the current template version is a one-line check once the version is extracted. The parcel table cross-reference is more involved: the APN list in the certification should match the APN list in the instrument schedule. Mismatches (parcels in one list but not the other) produce Officer Certification content deficiencies that are often caught late because developers prepare the certification and the instrument schedule independently and do not do a final diff before submission.

4. Cross-queue APN deduplication

PJM does not publish the APN records of active queue applications. Cross-queue deduplication is therefore not fully replicable by a third-party tool using public data alone. What is replicable is internal deduplication within a developer’s own portfolio: if the same APN appears in two projects’ instrument schedules, both will fail the exclusivity check at HyperQ. A portfolio-level pre-flight pass that flags intra-developer APN overlaps before submission prevents a class of deficiency findings that otherwise only surfaces at submission time — when the cure clock is already running on both projects.

PJM’s cross-queue check extends to RRI projects, TC1/TC2 legacy queue positions, and Cycle 1 applications simultaneously. A developer who holds a parcel under a TC2 legacy project and attempts to use the same parcel for a Cycle 1 application will fail the cross-queue check even if the TC2 project is still active. The exclusive-control requirement is portfolio-wide within PJM, not just within a single queue track.

Why HyperQ will get harder, not easier, over successive cycles

HyperQ is not static. PJM refines its evaluation criteria between cycles based on the deficiency patterns it observed in the prior cycle. The Manual 14H July 2025 update was specifically driven by TC1 and TC2 deficiency data: PJM analyzed which deficiency types were most common, which required the most cure-period back-and-forth, and which correlated with eventual project withdrawal, then tightened the rules to make those failure modes detectable earlier and more automatically. Cycle 1 will generate its own deficiency dataset, and that dataset will inform the Manual 14H update that governs Cycle 2’s evaluation logic.

The direction of each successive update is predictable: more deterministic, not less. Every ambiguity that required a human reviewer to resolve in TC1 or TC2 is a candidate rule for codification in the next Manual 14H revision. The Officer Certification template will add fields. The instrument eligibility rules will narrow. The parcel-modification grammar will gain more explicit constraints on substitution adjacency and expansion scope. PJM learns from every cycle what a bad submission looks like, and it encodes that learning into HyperQ’s next version before the next cycle opens.

The implication for developers is compounding: a team that has their site control evidence infrastructure in order for Cycle 1 will find Cycle 2 incrementally harder but manageable. A team that has not invested in evidence infrastructure by Cycle 1 will find each successive cycle’s evaluation criteria harder to meet with ad-hoc preparation. The gap between well-prepared and underprepared teams will widen cycle over cycle, not narrow.

The pre-flight imperative

The practical conclusion from the HyperQ architecture is simple: every Cycle 1 submission should be pre-flighted against the same evaluation logic before it reaches PJM. The criteria are public. The math is reproducible. The Officer Certification template is downloadable. There is no excuse for discovering a coverage gap, an instrument eligibility failure, or a template version mismatch in a deficiency notice issued under a 10-business-day countdown clock.

What pre-flight requires, in concrete terms:

1. An APN-keyed instrument schedule that accounts for every parcel in the project footprint, cross-referenced to executed instruments in your document package. Not a summary. Not a developer’s internal tracking spreadsheet with informal parcel nicknames. An APN-keyed schedule with instrument type, execution date, term end date, and covered acreage per parcel.
2. An instrument eligibility pass on every instrument in the schedule. For each instrument: is it executed? Is the term current? Does it cover the parcels it claims to cover by APN or legal description? Does it grant exclusivity or contain a subordination-and-non-disturbance provision where required?
3. A coverage calculation that applies the Manual 14H Section 7.1.6 density thresholds to the eligible-instrument acreage sum. The calculation should break down by technology type if the project is a hybrid configuration.
4. An Officer Certification template version check against the current PJM-issued template version before the officer signs. Preparing the certification on the correct template costs nothing. Receiving a template-version deficiency after the clock has started costs 10 business days of cure-window exposure.
5. A portfolio-level APN deduplication pass across all active projects in your PJM queue positions. Any APN that appears in more than one position must be resolved before submission.

This five-step pre-flight is not a luxury process. It is the minimum viable package preparation workflow for a deterministic evaluation environment. The pre-HyperQ queue made it possible to get away with informal evidence management because human reviewers would catch the gaps and work through them collaboratively. HyperQ does not work through gaps collaboratively. It issues deficiency notices.

What this means for Zonevex

Zonevex was built to be the developer-side mirror of HyperQ’s evaluation logic. The platform runs the same five-layer check — completeness, instrument eligibility, coverage math, Officer Certification validation, and portfolio-level APN deduplication — against the developer’s site control package before that package reaches PJM. The output is not a generic report; it is a deficiency simulation: the specific findings HyperQ would generate for the current package state, keyed to the Manual 14H section and Officer Certification field that would trigger each finding.

The investment logic is the same as every pre-flight tool: the cost of discovering a deficiency before submission is near zero. The cost of discovering the same deficiency inside a 10-business-day cure clock is measured in team hours, legal costs, and the option value of the queue position itself. For a project with meaningful network upgrade cost exposure — $30M, $80M, $200M+ depending on study results — the queue position is worth protecting. A pre-flight that prevents one cure cycle easily pays for several years of platform subscription.

The compounding dynamic matters too. As HyperQ’s evaluation criteria expand cycle over cycle, the pre-flight specification grows with it. A platform built against the Manual 14H evaluation logic stays current automatically as the manual updates; a team relying on ad-hoc preparation has to re-learn the rules from scratch with each cycle’s revision. The value of a purpose-built compliance platform is not a one-time audit. It is continuous alignment with an evolving specification owned by PJM and encoded in HyperQ.

For developers building queue-adjacent software — project management platforms, permitting tools, land tracking systems, document management systems — the HyperQ transition represents a clarification of the compliance target rather than a complication of it. Before HyperQ, “site control compliance” meant “whatever the PJM reviewer accepts.” After HyperQ, it means “whatever passes a specified algorithmic check against published criteria.” That is a better integration target. Zonevex exposes the pre-flight check as a callable service so that upstream tools can surface site control status at the parcel and instrument level, in real time, without waiting for PJM to do it for them.

The moratorium as a forcing function

The four years during which PJM closed its queue were not wasted. PJM used them to build HyperQ, revise Manual 14H twice, run the transition cycles as stress tests of the new evidence requirements, and launch the Reliability Resource Initiative as a pilot of the scoring logic that Cycle 1’s Application Review Phase would run at scale. The moratorium was, operationally, the build period for the new queue infrastructure.

Developers who entered the industry during or after the moratorium have no experience with the pre-reform queue. For them, HyperQ is simply the queue — there is no alternative frame of reference. Developers who were active before 2022 carry institutional memory of a more iterative, relationship-driven process that no longer exists. The risk for the second group is assuming the old dynamics still apply. They do not. The enforcement gap between the pre-moratorium process and the HyperQ process is not a gap that relationship management closes. It is a gap that evidence management closes.

Cycle 2 is expected to open in late 2026 or early 2027. The Cycle 1 deficiency data — which types, which frequencies, which cure outcomes — will be available before Cycle 2 opens, and PJM will update Manual 14H accordingly. Developers who treat Cycle 1 as a learning exercise for Cycle 2 are making the right bet, but only if they treat it correctly: as a dataset about what HyperQ catches, not as a one-time compliance hurdle to clear and forget. The teams that will win in Cycle 2 are the ones who treat the Cycle 1 deficiency patterns as a training dataset for their own pre-flight infrastructure.

Glossary

• HyperQ — PJM’s interconnection queue management platform, which handles application intake, automated screening, deficiency notice generation, milestone tracking, and first-ready-first-served advancement logic for the cluster-era queue.
• Application Review Phase — The procedural window after application submission during which PJM may issue deficiency notices (15 BD) and developers may cure (10 BD hard cap), governed by OATT Tariff Part VII, Subpart C, Section 306(B).
• Cycle 1 — PJM’s first true cluster interconnection cycle under the post-Order-2023 tariff, with an application deadline of April 27, 2026 and a Phase 1 study period running into late 2026.
• Transition Cycle (TC1 / TC2) — PJM’s two legacy-queue processing cycles, which ran pre-existing queue positions through modified pre-Order-2023 rules during the moratorium period.
• Reliability Resource Initiative (RRI) — PJM’s one-time accelerated study path for 51 selected projects totaling 9,361 MW UCAP, approved in FERC Docket ER25-712-000, running in parallel with Cycle 1.
• Officer Certification — PJM’s structured sworn statement attesting to specific site control facts; the load-bearing artifact for automated screening in the Application Review Phase.
• Manual 14H — PJM’s operational manual governing interconnection procedures, including site control evidence requirements (Section 7) and parcel-modification grammar (Section 7.2). Most recently updated July 2025.
• APN (Assessor’s Parcel Number) — The county assessor identifier for a parcel. HyperQ uses APNs as the primary cross-reference key between the instrument schedule, the Officer Certification, and the parcel database.
• Section 7.2 parcel-modification grammar — Manual 14H’s rules governing supplement, substitution, and expansion of the site control parcel set across successive submissions.
• FERC Order 2023 — FERC’s July 28, 2023 final rule mandating cluster studies, first-ready-first-served advancement, and commercial readiness milestones (including site control) at every queue stage. The regulatory foundation for HyperQ’s evaluation logic.