Power Diligence
Underwrite time-to-power before you underwrite the site.
A consistent screen across nine interconnection regions that returns a readiness band, a ranked bottleneck stack, and the diligence you are still missing.
Declared stage weights
Screen inputs, not black-box scores
- Site selection26
- Interconnection requested20
- Utility study14
- PPA negotiation12
- Permitted8
- Construction5
- Energized0
- 9
- ISO/RTOs weighted
- 7
- Development stages
- 10
- Site constraints
- 8
- Bottleneck classes
PJM, ERCOT, CAISO, MISO, SPP, NYISO, ISO-NE, WECC, Southeast, plus an Other fallback
Site selection through energized, each with a declared risk weight
Fixed vocabulary, so two screens of the same site are comparable
Every constraint resolves to one, and the stack is ranked by severity
The problem
The gap between an announced date and an energized site
A site arrives with a press release, a queue position, and a promised energization date. None of those is evidence, and nothing in a compute-price feed tells you whether the power will be there.
Queue position is not progress
Interconnection requests routinely outlive the theses built on them. The stage reached matters more than the date claimed, which is why the stage carries the single largest weight in the screen.
Site selection = 26 · energized = 0
The binding constraint moves
Transmission, substation capacity, permits, water, and transformer lead times affect different sites. Review them together before committing capital.
10 constraints, each mapped to a bottleneck class
Nobody records what was assumed
Six months later the question is which parts of the memo rested on documents and which rested on optimism. The screen labels every evidence item at the time it is run.
provided · missing · assumed
Method
How the screen scores a site
The same inputs produce the same result, and the screening weights are published on this page.
- 1
Declare the site
Region, ISO/RTO, utility, target megawatts, target energization date, workload type, and current development stage.
targetPowerMw ≤ 5,000 · date within 2020–2050
- 2
Score the structural risk
Published weights for the interconnection region, the development stage reached, the power scale, and the schedule remaining.
ISO 10–18 · stage 0–26 · scale 4–24 · schedule 3–24
- 3
Apply known constraints
Review up to eight site constraints, including transmission, substations, permits, water, and equipment lead times.
constraint weights 8–18 · max 8 declared
- 4
Credit the evidence
Supporting URLs, a named utility, and substantive notes reduce the risk score. Unevidenced inputs do not.
≤ 9 URL credit · 4 utility · 3 detail
Published weights
Every weight the screen applies
These are the actual numbers the screen applies, taken from the same constants the engine reads. ISO / RTO is the regional grid operator. A PPA is the power-purchase contract. Definitions live in the glossary.
| ISO / RTO | Risk weight |
|---|---|
| PJM | 18 |
| CAISO | 16 |
| NYISO | 15 |
| ISO-NE | 15 |
| ERCOT | 14 |
| MISO | 13 |
| WECC | 13 |
| Southeast | 12 |
| SPP | 10 |
| Other (fallback) | 10 |
| Stage reached | Risk weight |
|---|---|
| Site selection | 26 |
| Interconnection requested | 20 |
| Utility study | 14 |
| PPA negotiation | 12 |
| Permitted | 8 |
| Construction | 5 |
| Energized | 0 |
| Constraint | Risk weight |
|---|---|
| Transmission upgrade | 18 |
| Interconnection queue | 16 |
| Substation upgrade | 14 |
| PPA unsigned | 11 |
| Community opposition | 11 |
| Local permit | 10 |
| Water or cooling | 9 |
| Equipment lead time | 9 |
| Gas bridge | 8 |
| Unknown | 8 |
What a screen returns
Shaped to drop into a committee pack
Readiness band
One of likely, constrained, or blocked, with a low/mid/high probability band, not a single point estimate.
Bounded to 0.08–0.92 — the screen never returns certainty
Ranked bottleneck stack
Every constraint that applies, ordered by severity, each with the rationale that put it there. The primary bottleneck is named separately.
8 bottleneck classes across interconnection, transmission, utility service, permitting, procurement, cooling, equipment, execution
Evidence coverage score
How much of the screen rests on documents you supplied versus desk assumptions, so a reviewer can see where the answer is thin.
Each item labeled provided, missing, or assumed
Missing diligence list
The specific documents that would move the score — the follow-up list, generated for you.
Returned as required_document evidence items
Decision memo
A titled summary with next actions and an explicit caveat, shaped to drop into an investment-committee pack.
Title, summary, next actions, and caveat
Scenario handoff
A counterfactual the specialist agents can pick up, so a screen becomes the start of an analysis instead of a dead end.
Emitted as an agent_finding handoff
Access status
This page is public: the method, weights, and output fields are here so they can be reviewed before any engagement. Running a live screen happens inside Compute Desk and requires an approved organization account. There is no self-service purchase.
Questions
What underwriters ask
Is this a forecast of my energization date?
No. The screen returns a readiness range and a ranked list of likely constraints based on your inputs. It does not predict an energization date or claim a measured hit rate. Illustrative output. Not investment, financial, or tax advice.
Where do the weights come from?
They are published screening weights. The same inputs produce the same result. They are not derived from a measured history of project outcomes.
What does the evidence coverage score actually measure?
It measures how much of the screen rests on documents you supplied instead of desk assumptions. Every evidence item is labeled provided, missing, or assumed. A reviewer can identify weak parts before using the result.
How we source dataCan I run a screen without talking to anyone?
Not today. The screen runs inside Compute Desk, which requires an approved organization account. There is no self-service purchase. Access is granted through the design-partner engagement.
Design partner programHow is this different from a compute-price data vendor?
Price discovery tells you what a GPU-hour costs. Time-to-power tells you whether the megawatts behind it will exist when you need them. Both matter to the same decision, and the second one is the constraint that has been binding across the current buildout.
See the Compute IndexBring us a site.
Walk through a real screen on a live site, and see the bottleneck stack and missing-diligence list it returns.