Where an AI model's authority should end in grid planning

An interconnection study starts with a request to add a project to a power network. An AI model can help interpret that request. I want its authority to depend on the question it can actually answer. Reading an application and recommending what to study are different responsibilities, even when a single interface presents both results.

My design position is that an intake model should be allowed to propose an interpretation, with its source available for inspection. A network recommendation should retain the calculation and rule that produced it. This separation matters when the two outputs sound equally confident but rest on different evidence. It also creates a harder obligation: if the interpretation is wrong, the system needs a visible route to revise the inputs and reconsider the recommendation.

A well-described request can still need an upgrade study

Our GridLens demo uses synthetic applications and a synthetic power network to make this distinction inspectable. Consider Tessera Compute, a seeded 750 MW request with a high readiness score under the demo's configured intake rules. That score describes application readiness. It does not measure the network's ability to accommodate the request.

In the demo's direct-current thermal screen, the worst attributable base-case loading is 92.3% of the relevant line's thermal limit. The base case assumes the monitored lines are in service. After one monitored line is taken out, the worst attributable loading reaches 112.4%. The configured recommendation becomes an upgrade study.

The numerical difference has a practical meaning within this model: a result below the limit in the base case does not settle the outage case. The evidence identifies branch 548 to 247 as the worst binding branch, with the outage of line 1 to 248. A planner can challenge the specific network condition behind the recommendation instead of debating the tone of a summary.

This is a bounded illustration. The screen treats requested MW as a slack-balanced injection, including large-load requests; it is not a validated physical load-withdrawal study. It covers a selected set of non-radial transmission-line outages and excludes AC voltage and reactive-power feasibility, transient stability and islanding. Existing overloads are baseline conditions rather than attributed project constraints. Even a clean result would be a study recommendation, not permission to connect or a finding that the whole network is secure.

Within those boundaries, the example still answers a useful design question. The upgrade recommendation needs a network calculation. A more articulate account of site control or requested capacity cannot resolve the overloaded branch. Giving the intake model authority to rewrite the recommendation would let evidence about one question stand in for evidence about another.

Give assistance a defined effect

GridLens keeps optional model-assisted extraction advisory. The founder video shows an analysis that reuses a saved real model response. It can surface extracted application fields and readiness evidence, but it does not change the saved queue-screen recommendation or study order. The full queue screen uses deterministic extraction, network calculations and configured policy; it does not ask a language model to issue the planning verdict.

I prefer this boundary because a reviewer can tell what the assistance changed. When a model offers a new interpretation beside an existing result, the difference remains available for inspection. If the same action quietly changed a saved recommendation, the reviewer would also need to establish which inputs changed, whether the calculations were repeated, and which version the displayed study order represents. That is a larger claim than an extraction response can support on its own.

There are at least two plausible roles for a model in a planning workflow. It can explain a completed result using the retained evidence, or it can propose inputs for a new calculation. Both can be useful. The second role needs a stronger revision process because an input change can alter the downstream result. A changed point of interconnection, for example, is not merely a better sentence in an application summary; it changes where the request is represented in the network model.

For a fuller system, my design standard is to make that transition explicit. A proposed correction should identify the source passage, the old value and the new value. Once accepted through the relevant review process, it should become an input to a distinct calculation, whose result can be compared with the earlier one. This is a proposed design requirement, not a capability demonstrated by GridLens's advisory action.

The cost is additional review and version handling. An automatic overwrite is simpler to present and demands fewer visible steps. But it hides the very information needed to decide whether the new recommendation deserves reliance. I accept the extra work when the correction changes the physical question being studied.

A deterministic answer can be precisely wrong

Keeping the model outside the verdict is not sufficient by itself. A deterministic calculation can consistently operate on the wrong input. The right response to that complication is to inspect the input, rather than treat determinism as proof of correctness.

Suppose, hypothetically, an application ambiguously names two possible connection points. A summary could select one and sound convincing. Running the thermal screen repeatedly at that selected point would not resolve what the applicant meant. The ambiguity needs clarification before either calculation can answer the intended question. In GridLens, an unresolved point of interconnection or extraction confidence below the configured 0.60 threshold routes the request to human review. That is a route for unresolved evidence, not a completed engineer's decision.

The same separation applies to readiness. The demo's readiness score is a heuristic derived from application evidence. A high score cannot cancel a thermal constraint, and a low score does not establish wrongdoing. I want the recommendation to explain which kind of uncertainty remains. Missing application evidence calls for a different next step from a named overload under a specified outage.

This is why I do not want a single confidence number to carry the whole decision. It would force reviewers to infer whether a low value describes uncertain extraction, incomplete commercial preparation or a demanding network condition. Keeping those questions distinct lets the reviewer pursue the evidence that could actually change the result.

Judge the recommendation by its revision path

The GridLens explainer shows the recorded workflow and its evidence. The broader design criterion is to ask what would have to change for a recommendation to change: a corrected application field, a different network assumption or a different study policy. Each has a different source and a different reason for review.

Here is the founder walkthrough of this boundary in GridLens.

I judge an AI-assisted planning workflow by whether it makes those dependencies visible. A useful model response can direct attention to a missing fact or propose a correction. Reliance on the planning recommendation requires a record of the inputs, calculation and rule that support it. The system earns more authority when a reviewer can trace a disagreement to the evidence that would resolve it.