How It Works

The question the tool answers

When you pick a substation, the raw PJM queue shows hundreds or thousands of megawatts in the interconnection pipeline nearby. Most of it will never get built. The question Queue Reality Check tries to answer is: how much of the queued capacity near this POI is realistically likely to interconnect ahead of my project?

That is a different question than "how many MW are in the queue," and the answer is meaningfully smaller. The tool gives you a probability-weighted total — and a scenario layer where you can override individual projects with your own intelligence — to help you think about that more realistically.

The probability model

Each queued project near your chosen POI receives a build-probability score between 0 and 1. That score is the product of three independent lookup values: a base rate tied to study phase, a modifier for technology type, and a modifier for queue age.

The formula is:

P(build) = base_rate(phase) × tech_modifier(type) × age_modifier(years_in_queue)

The probability-weighted total for a given scenario is then:

weighted_MW = Σ [ nameplate_MW(i) × P(build)(i) ]   for all active projects i

Projects you mark as "definitely builds" or "definitely withdraws" in the Scenario panel are locked to 1.0 or 0.0 respectively and bypass the formula.

Base rate by study phase

Technology modifier

Note: The current prototype is calibrated for the technology categories that match SlackWatt's target users — solar (PV), onshore wind, battery storage, and hybrid solar+storage. Gas, hydro, and nuclear are out of scope for V0.

Age modifier

The age modifier is floored for projects that have already cleared Facilities Study. For GIA-signed projects the floor is 0.85; for projects under construction it is 0.95. Once a project has executed its interconnection agreement or broken ground, queue age is no longer a reliable signal of staleness — a 7-year-old project under construction is being actively built, not lingering speculatively. Applying the raw age decay at that stage would impose a penalty that the underlying data do not support, since the LBNL cohort shows very high completion rates for projects that reach construction regardless of how long they spent in the queue.

Where these numbers come from

The base rates and modifiers are calibrated against PJM-specific completion-rate data from Lawrence Berkeley National Laboratory's Queued Up – 2023 Edition (August 2023). The LBNL dataset tracks build outcomes for projects that entered U.S. interconnection queues between 2000 and 2018 — roughly 30,000 projects across all major ISOs — and includes PJM-specific breakdowns by study phase and technology type.

The phase-level base rates reflect PJM completion percentages at each study stage, as reported in the LBNL 2023 analysis. The technology modifiers are derived from PJM-specific technology completion rates normalized to solar as the reference technology: solar completed at approximately 16%, onshore wind at 22%, and standalone storage at 8% for PJM projects in that cohort. The age modifiers reflect PJM's characteristically long study cycles (typically 2–3 years per phase), which mean that projects persisting in the queue beyond three years without advancing face disproportionately high withdrawal risk.

Because the LBNL cohort covers projects entering through 2018, it does not fully capture the large wave of solar and storage filings that entered PJM under the FERC Order 2023 transition. Completion rates for those more recent cohorts are not yet observable. The model's base rates and technology modifiers should be treated as historical calibration points, not predictions about the current queue composition.

Why a simple lookup, not machine learning

A few honest reasons:

• The training data problem is real. PJM publishes queue data in a format that changes over time, has gaps, and requires significant cleaning to use for prediction. Fitting a machine-learning model to noisy, inconsistently formatted historical data would produce false precision.
• Interpretability matters for this audience. Developers and analysts who use queue tools need to understand and audit the numbers they are given. A lookup table is transparent. You can see exactly why a project was assigned the probability it was assigned and disagree with it productively.
• The Scenario panel is the real feature. The probability defaults are a starting point. The tool's value comes from letting you override individual project assumptions with your own intelligence — developer relationships, news about permitting delays, your knowledge of who is actually serious. The default model is scaffolding, not the conclusion.

A production version of this tool would benefit from a richer statistical model trained on PJM-specific data, with more features (project size, transmission owner, injection zone, cluster membership). That is not what this prototype is.

Data sources for queued projects

The list of queued projects shown in the tool comes from a static snapshot of PJM's public interconnection queue, last refreshed in early 2025. Project locations are geocoded from substation names and PJM zone data; geocoding is imprecise for some entries, which means a small number of projects may be incorrectly placed within or outside the search radius for a given POI.

The tool does not connect to a live PJM data feed. PJM updates its queue continuously; withdrawals, new entries, and study phase transitions that occurred after the snapshot date are not reflected. This is a significant limitation for production use (see below).

Limitations

• Static data snapshot. The queue data is not live. Withdrawals and new filings since early 2025 are missing. If a large project near your POI withdrew after that date, the tool will still show it competing.
• Geocoding errors. Substation locations are approximated. For POIs near grid boundaries or with multiple substations sharing a name, the radius search may include or exclude projects incorrectly.
• Historical cohort. The probability inputs are calibrated against PJM projects entering queues between 2000 and 2018. The current PJM queue is dominated by solar, storage, and hybrid projects that entered post-2018 under different market and regulatory conditions; actual completion rates for these cohorts are not yet observable.
• No project-specific information. The model knows nothing about a specific project's developer, financing, land control, permit status, or offtake agreements. Two projects at the same phase and technology with the same queue age get the same probability, even if one has a signed PPA and one is purely speculative.
• Study phase data quality. PJM's public queue records the current study phase, but transitions between phases are not always reflected promptly. Some projects may be classified at an earlier phase than they actually are.
• Independence assumption. The model multiplies three independent factors together. In reality, these factors are correlated — old projects that reached the Facilities Study stage are a different population than old projects stuck at Feasibility. Treating them as independent understates uncertainty.
• No network constraint modeling. The tool does not model transmission headroom, injection limits, or curtailment risk. Two projects at the same substation may not both be able to interconnect even if both complete the queue process, depending on available network capacity.

What changes in a production version

If this tool were to become a production product, the highest-priority improvements would be:

• A live connection to PJM's public queue API or a regularly refreshed data pipeline, so the project list is current.
• Updated calibration against post-2018 PJM cohorts as those completion rates become observable, to better represent the current solar- and storage-dominated queue.
• A richer feature set for the probability model: project size (larger projects complete at lower rates), injection zone, cluster membership, and transmission owner.
• More granular geocoding, cross-referenced against PJM's published substation coordinate data and FERC's eLibrary filings.
• Network headroom modeling integrated alongside queue competition, so that the tool shows not just competing MW but available injection capacity at the POI.
• Saved scenarios and shareable links, so that developer teams can collaborate on POI analysis without rebuilding assumptions from scratch each session.