I want interconnection software to make it easy to challenge a recommendation. That requires more than a convincing application summary. A planner needs to know whether the recommendation comes from missing intake evidence, a network constraint or a configured prioritization rule. Each calls for a different response.
This is why I keep model-assisted intake advisory in GridLens, our planning demonstration at Veriprajna. The model can help extract application fields. It cannot change the saved queue-screen recommendation or study order. Deterministic extraction, a DC thermal calculation and configured policy produce the queue screen.
The separation matters when a well-prepared request still needs an upgrade study.
Readiness cannot clear a thermal constraint
Consider Tessera Compute, a synthetic 750 MW request in GridLens's seeded queue and synthetic network. Its readiness score is 0.92, a configured heuristic based on application evidence. That score says nothing about whether transmission equipment can accommodate the modeled flow.
For this illustration, requested MW is treated as an injection balanced at a reference bus, including this large-load request. It is not an operational study of a load withdrawing power. Within that convention, the worst attributable base-case loading is 92.3% of the relevant thermal limit. The single-monitored-line-outage screen reaches 112.4%, introducing an overload and producing an upgrade-study recommendation.
A base case describes the modeled network before the outage. The outage calculation asks what happens to surviving lines when a monitored line is lost. The difference is consequential: a request can look acceptable in the base case while creating a constraint in the outage case.
The deciding record names branch 548 to 247 and the loss of line 1 to 248. Those identifiers earn their place because a planner can examine the specific overloaded element and the outage that exposes it. A summary saying the application is well prepared cannot answer that engineering question.
The synthetic request receives an upgrade-study recommendation. The binding table ties the 112.4% loading to a named branch and outage; visible upgrade costs are heuristics, not engineering estimates.
Match the challenge to the evidence
Suppose a planner disagrees with this recommendation. I want the next action to depend on what they dispute.
If the point of interconnection was extracted incorrectly, the intake record needs correction before a new screen can be trusted. If the input is correct but the thermal result is disputed, the review needs the network case, injection convention, branch, outage and applicable limit. Rephrasing the application summary does not resolve that disagreement. If the calculation is accepted but the study route is disputed, the question shifts to the configured policy that maps those constraints to an upgrade study.
That is a design standard I would apply beyond this demo: preserve the path from source fields through calculation to policy, so a reviewer can challenge the relevant step. One combined score would hide whether the remedy is better application evidence, a different engineering assumption or a different study rule.
The paired recording illustrates the boundary directly. Its application analysis reuses a saved real model response. That advisory extraction leaves the saved physics verdict and study order unchanged. A fluent explanation can support intake review without gaining authority over the network recommendation.
Keep the recommendation within its scope
Even the calculation has a boundary. GridLens screens newly attributable DC thermal constraints on a monitored transmission subset. Existing baseline overloads are excluded from project attribution. The screen does not establish AC voltage or reactive-power feasibility, transient stability or islanding resilience.
An upgrade-study route therefore identifies work to investigate; it does not specify an approved engineering solution. A clean screen is also a bounded study recommendation, not permission to connect or a claim that the whole network is secure.
The GridLens breakdown shows the workflow and its limits. My criterion for planning AI is whether it helps a reviewer locate the evidence that could change a recommendation, while leaving decisions outside that evidence's scope open for the engineering work they require.