The worked case: trace the recommendation to its evidence
Follow the synthetic Tessera Compute request from its submitted application to the evidence behind its upgrade-study recommendation. The contrasting cases show why readiness, thermal impact and study priority need separate explanations. All applications and the network are synthetic; applicant company names visible in screenshots are fixture labels, not customers, deployments or endorsements.
Select any screenshot to open the original at full size. These are product screenshots; the controls pictured belong to the recorded local workspace.
Follow the evidence
Inspect the request before trusting its recommendation
Tessera asks for 750 MW at point-of-interconnection bus 3. The submitted text describes site control and current deposit payments. The source view lets a reviewer compare those statements with the extracted fields, rather than infer completeness from a project name or requested capacity.
The intake view records confirmed site control and a posted study deposit. Those inputs contribute to readiness 0.92, displayed as 92 out of 100. This is a configured prioritization heuristic, not a probability of successful connection, a credit assessment or proof of engineering feasibility.
Optional model-assisted intake supplies an additional extraction for comparison with the source. The video walkthrough reuses a saved real model response. That advisory result cannot change the saved queue recommendation or study order, and the full queue run does not use the model. A reviewer still needs to check extracted fields against the submitted application.
Define the network the screen actually covers
The synthetic test case contains 2,000 buses and 3,633 branches. Screening monitors 976 non-radial transmission branches with both ends at 138 kV or above. Power transfer distribution factors estimate how an injection changes line flows; line outage distribution factors estimate surviving-line flows after a monitored line is removed.
Requested MW is treated as an injection balanced at a slack bus, including requests labeled as large loads. This is an illustrative modeling convention, not a validated load-withdrawal study. Existing baseline overloads are excluded from project attribution, so an absence of new project constraints does not establish that the whole network is secure.
Find the outage that changes the study route
Tessera’s worst attributable base-case loading is 92.3%, below the 100% thermal limit. After a single monitored-line outage, worst attributable loading reaches 112.4%. The recommendation is therefore upgrade study even though its application is ready and its base case stays below the limit.
The useful review question is which element binds, under which outage, and whether the overload is newly attributable to the request. The schematic gives connection context; the named branch, contingency and loading provide the deciding thermal evidence. An upgrade-study route calls for further engineering work rather than approving a particular construction design.
Compare a clean screen with a marginal review
Synthetic Apex DC also requests 750 MW and has readiness 0.92. Its worst attributable base loading is 79.7% and single-outage loading is 96.4%, with no new overload. It receives a clean screen: proceed to detailed interconnection study. That label does not authorize connection.
Synthetic Cortex Compute has no new overload either, but its 96.7% single-outage loading represents a new crossing above the 95% warning band. The configured policy sends that marginal case to engineering review. A value below the overload limit can therefore still require judgment, and a review route is not a completed engineer’s decision.
Distinguish reinforcement from incomplete intake
Synthetic Stargate Compute requests 500 MW and reaches 163.6% worst attributable base loading. It is routed to major-network-build study. In this configuration, loading above 135% or more than four new constraint records triggers that route. The label identifies a study need; it does not establish a legal violation or a finished reinforcement design.
Synthetic Helios Compute has a different problem. Its application lacks executed site control and a posted deposit; prior withdrawals and a shell or special-purpose applicant adjustment also lower the configured readiness score to 0.00. It moves from arrival position 1 to first-ready position 213, remaining in the queue for further intake.
Unresolved connection points, extraction confidence below 0.60 and unavailable physics also route requests to engineering review. That preserves the difference between missing evidence and a passed check. Each recommendation needs its reason; one composite score would hide whether the next action concerns intake, thermal analysis or engineering judgment.
Read the study-order comparison without turning positions into time
| Study recommendation | Synthetic applications | Interpretation |
|---|---|---|
| Clean screen | 84 | No new attributable overload and no configured review condition. |
| Upgrade study | 22 | New attributable overload requiring upgrade study. |
| Engineering review | 30 | Unresolved evidence, unavailable physics or marginal loading. |
| Major network build | 24 | Configured major-reinforcement study route. |
| Low readiness | 90 | Further intake before priority study. |
Clean-screen and upgrade-study routes together contain 106 applications and approximately 62.2 GW of requested capacity. The interface calls this study-ready capacity. Because it includes requests that need upgrades, it is not available or connectable capacity. Electrical-proximity clustering groups only these two routes; it does not settle regulatory eligibility or complete a combined engineering study.
First-ready order sorts by recommendation priority, descending readiness and then descending requested MW. Across the 106 clean-screen and upgrade-study applications, exact median position changes from 138.5 to 53.5; the interface truncates those medians. Tessera moves from position 9 to 92 while retaining its upgrade-study route, showing that readiness alone does not determine priority.
The visible restudy-exposure metric counts upstream low-readiness or major-build requests once for each subsequent clean-screen or upgrade-study application. It changes from 6,596 to zero because the configured ordering puts those upstream routes later. It does not simulate actual restudies, withdrawals, elapsed time, upgrade completion or engineering effort, and this comparison is not an optimization or fairness guarantee.
Inspect checks and preserve the exact study record
The runtime benchmark separates six physics-identity checks from six explicit policy cases. The physics checks test numerical relationships; the policy cases test configured routing boundaries. The captured run reports all twelve passed. This is implementation evidence on a fixed synthetic suite, not field accuracy, full grid feasibility or independent validation.
A run-specific study-plan JSON export retains queue evidence, while the printable project HTML carries the study identity, intake, recommendation and deciding constraints for one application. Benchmark JSON preserves the observed checks separately. These records let a reviewer identify which run supports a statement rather than rely on an isolated screenshot.
Downloaded files persist after server runs expire. The local workspace retains at most sixteen recent runs in memory; completed runs expire one hour after creation, and a server restart clears them. Production use would require separate decisions about validated network data, durable records, access controls, engineering authority and the studies needed beyond this screen.
