A grid interconnection request can look acceptable with every monitored line in service and still introduce an overload when one line goes out. For a planning team, the important question is which condition changes the recommendation, and whether the evidence is specific enough to direct the next study.
A base-case result alone cannot answer that question. An application summary cannot answer it either. We designed GridLens to keep the request, the network assessment and the study recommendation separately inspectable. Its synthetic example shows what that separation gives a reviewer: a reason to investigate a particular network constraint, rather than a reassuring overall label.
The outage changes what needs studying
Tessera Compute is a synthetic 750 MW data-center request in the GridLens fixture. Both the applications and the network are synthetic. Under the demo's illustrative DC thermal model, its worst attributable base-case loading is 92.3% of the line rating. Its worst attributable loading following a single monitored-line outage is 112.4%. The configured recommendation is an upgrade study.
The physical convention matters here. GridLens treats requested MW as an injection balanced at a designated slack bus, including these large-load requests. This is an illustrative screening convention, not a validated load-withdrawal study. The example teaches how to inspect a recommendation within that model; it does not establish that a real 750 MW data center can connect at the displayed location.
The network evidence identifies the surviving branch from bus 548 to bus 247 and the outage of the line from bus 1 to bus 248 behind the 112.4% result. Those references make the result reviewable. A planner can distinguish the element carrying the overload from the element whose loss exposes it, rather than treating an outage result as an unexplained score.
The synthetic request receives an upgrade-study recommendation. The binding table names branch 548 to 247 and the loss of line 1 to 248 behind the 112.4% loading.
The table contains three binding entries, including parallel branches with repeated endpoint labels. These are constraint records, not evidence of three distinct corridors. The screen also excludes pre-existing overloads from project attribution. A reviewer therefore needs to understand both what a row represents and why it is attributed to this application before using the count to describe the network impact.
That attribution rule limits the meaning of a clean result too. No new overload in the monitored set does not mean that the whole network is secure. Baseline conditions remain part of the engineering problem, even when they are outside the project's headline constraint count.
Readiness answers a different question
The same request has executed site control and a posted study deposit in its synthetic source application. GridLens gives it readiness of 0.92 under configured rules. That helps explain why it belongs in a priority study group. It cannot make the outage-driven thermal constraint disappear.
We keep those two judgments separate because they support different work. Readiness concerns whether the application's documented commitments support progressing its study. The thermal assessment concerns the modeled network response. A commercially well-prepared request can still need an upgrade study, as this case does.
The readiness score is a heuristic, not a calibrated probability of project completion or a finding about creditworthiness. Equally, an upgrade-study recommendation is a route for further investigation. It is not an approved upgrade design, a connection authorization or a price. The monetary figure visible in the screenshot is a voltage-based heuristic, not an engineering estimate.
Combining readiness and network evidence into one unexplained score would conceal that distinction. A reviewer would have less information about what needs resolving: the application's commitments, the binding network condition, or both. Keeping the evidence separate gives the next study a clearer starting question.
The model can assist intake without deciding the route
The accompanying company video shows an optional application analysis that reuses a saved real model response. It helps compare extracted fields with the submitted source. That advisory result does not change the saved queue-screen recommendation or study order.
The default full queue screen uses deterministic extraction, the DC thermal calculation and configured policy. No language model decides whether the request receives a clean screen, an upgrade study or a major-network-build recommendation.
That boundary lets a reviewer challenge each component on its own terms. An extracted field can be compared with the application. A loading result can be traced to a branch and outage. The recommendation can be checked against the configured policy. The model's fluency is not evidence that any of those checks passed.
Ask for the evidence that defines the next study
This DC thermal screen covers monitored non-radial transmission branches at 138 kV and above. It excludes AC voltage and reactive-power feasibility, transient stability and islanding contingencies. A clean screen is therefore a bounded study recommendation. Detailed engineering remains necessary before connection.
The GridLens breakdown shows this workflow and its limits. For planning teams evaluating a screening tool, we recommend asking for the source request, the binding element, the triggering outage and the rule that maps the result to further work. In this synthetic case, that evidence explains why a request with a normal base case still needs an upgrade study. A useful screen makes the unresolved engineering question easier to name.