An AI Copilot in Protection Engineering: The Tools, the Gate, and the Failure Modes

Most AI features in engineering software are a text box in a corner that can discuss your work but not touch it. That design is easy to ship and almost useless, and it is worth being precise about why — because the reasons point at what a useful design would have to look like, and at the boundaries it would have to respect in a discipline where a wrong number becomes a wrong trip time.

Key takeaways

• A chat window can only talk about your work. An agent with registered tools can read the settings model, run a module, search the manual you ingested, and draft the report — which is where the actual time goes.
• The agent advises; deterministic code owns verdicts, and energizing tools require explicit isolation confirmation.
• Retrieval over your relay manuals replaces the model’s recollection with a page you can open.
• The curve mathematics, tolerance comparison and pass/fail assessment are deterministic code. The AI never decides a verdict.
• Provenance is recorded: what was sent, what came back, what the engineer changed.
• Your own provider key, encrypted at rest locally, traffic only to that provider — and the product works with no AI at all.
• Models are confidently wrong. Reviewing their output is real work. Anyone who tells you otherwise is selling something.

Why a chat box is close to useless

Consider a concrete afternoon. You have a settings export for a distance relay, its manual, a test set, four hours, and a report to produce. The work is: get the settings into a usable form; establish which zone characteristics and reach settings apply; look up how this manufacturer defines the reset characteristic; compute expected values; build the plan; run it; interpret three results that look wrong; write the report.

A chat box helps with roughly one of those, weakly. It cannot see your settings model, so it cannot tell you that your Zone 2 reach and your line impedance are inconsistent. It cannot open your manual, so its answer about the restraint definition is a recollection about relays in general, dressed as a fact about yours. It cannot run the module, so the numbers stay in your head. It cannot write into the report, so you retype whatever it produced.

Every one of those limits is the same limit: the model has no access to the objects the work is made of. Better prose does not fix it. Tools do.

What a tool-using agent can do

ProtectionAI’s copilot has registered tools. Concretely, it can:

• Read and edit the working settings model, so it operates on your actual values rather than a description of them.
• Execute a test module and see the results, so “run the timing points across the working range and tell me which are outside tolerance” is one action rather than a conversation about how to do it.
• Drive output phasors, for manual injection and investigative work.
• Generate and import test templates, including a first draft built from a settings export or a manual.
• Search the PDF relay manuals you have ingested, and cite what it found.
• Draft the report from real results rather than a summary you typed.

The difference is not eloquence. It is that the agent and the engineer work on the same objects — which is precisely why the approval model has to be serious.

The authority model

ProtectionAI uses two concrete boundaries. Pass/fail remains deterministic application code, outside the language model. Separately, every registered tool capable of energizing test outputs is refused at one central enforcement point until the operator explicitly confirms the test setup is isolated.

That is narrower than claiming a universal approval dialog for every state-changing tool, and the distinction matters. Settings edits, generated templates and report drafts still require engineering review under the user’s working procedure; the current product does not claim a generic named approval workflow around every such action.

The corollary is uncomfortable, and we would rather state it than let a customer discover it: reviewing the agent’s output is real work. It is not a rubber stamp, not faster than reading, and it does not become safe through familiarity. The agent removes the typing, the lookup, the transcription and the arithmetic. It does not remove the engineering judgement, and any vendor implying otherwise is selling something.

Grounding: your manuals, not the model’s memory

Ask a language model for the constants of an IEC Extremely Inverse curve and you will get an answer, usually right, because those values are published everywhere. Ask for the restraint definition a particular manufacturer uses on a particular differential relay, or the reset behaviour of a specific firmware revision, and you will still get an answer — same confidence, now resting on nothing. That asymmetry is the whole problem: the failure is invisible at the point of use.

So the copilot’s retrieval runs over the PDF manuals you ingested, and points you at passages in the document that governs your relay. This matters more here than in most domains because of what the errors turn into: a wrong k or a wrong exponent does not produce an error message, it produces a curve that is confidently plotted, plausibly shaped, and wrong by a factor that surfaces years later as a coordination failure. IEC 60255-151 fixes the equations; the manufacturer’s manual fixes what the standard leaves to implementation; a model’s recollection fixes nothing.

Grounding narrows the failure mode without closing it. Retrieval can return a passage that reads as relevant but describes a different model, firmware version or setting group, and scanned manuals — a great many protection manuals in circulation are scans — are read imperfectly. A citation you can check beats an assertion you cannot; it is not a guarantee.

Determinism: the AI never decides pass or fail

This is the boundary we would defend most strongly.

The inverse-time curve equations, the expected-value computation, the per-point tolerance comparison and the resulting verdict are deterministic code in ProtectionAI. Given the same settings, the same injected quantities and the same measured times, they produce the same answer every time, and that answer does not pass through a model.

The copilot can draft the words around a result. It can point out that three timing points cluster at the edge of tolerance and suggest checking the pickup calibration. It cannot mark a test passed, cannot adjust a tolerance to make one pass, and has no access to the verdict at all.

The reason is structural rather than a matter of confidence in any particular model. A verdict has to be reproducible and explainable in the same terms three years later, to someone who was not there. Sampling from a distribution is the wrong mechanism for that, regardless of how good the distribution gets.

Provenance

If an AI touched the record, the record should say so, and say what. The copilot’s activity is recorded: what was sent to the provider, what came back, which tool calls were proposed, which the engineer approved, and what the engineer changed before approving. A report drafted by the agent and edited by an engineer carries that history rather than presenting itself as purely human or purely machine output.

This is the same instinct the NIST AI Risk Management Framework formalises around documentation and traceability, and it answers a question protection groups reasonably ask: how would I demonstrate, later, what the AI actually contributed? That answer has to be a record, not a reassurance.

The data boundary

Plainly stated:

• The copilot uses your Anthropic or OpenAI API key. There is no GridAPM key, and no GridAPM service in the path.
• The key is stored encrypted at rest on the local machine using Windows DPAPI, so it is protected by the operating system’s own user-scoped key material rather than by an application secret.
• Traffic goes only to the provider that key belongs to. Nothing is routed through us, and no customer’s data is pooled with another’s, because there is no pool to pool it in.
• The entire product works with no AI configured. Test execution, the settings model, the asset database, COMTRADE handling, reporting — all of it runs with the copilot switched off. AI is a feature, not a dependency.

That last point is the one OT security reviewers care about most, and it is deliberate. Software installed inside a substation’s trust boundary should be assessable on the assumption that its network features are switched off, which is easier to do with a tool that degrades gracefully to fully local than with one that will not run without an external service — the posture guidance such as NIST SP 800-82 on operational technology security encourages. The security page and /trust/ go through the specifics; the capabilities page states which features involve the provider at all.

The failure modes, without euphemism

• Models are confidently wrong. Fluency and accuracy are separate properties; tone does not vary with correctness.
• They fabricate settings values and standard constants — plausible numbers, right magnitude, right units. The hardest kind to catch.
• They mis-read scanned manuals. Table columns merge, subscripts vanish, a decimal point in a poor scan is a coin toss.
• Retrieval can mislead. The passage returned may be from the wrong model, firmware or setting group.
• They cannot hold an authority decision — not as policy, but because nothing in their construction supports reproducible, defensible engineering judgement.

None of this makes an agent unusable. It makes an unsupervised agent unusable. The engineering content of the design is in where the gates go.

One dated observation, and its limits

In our July 2026 review of the published protection portfolios of OMICRON, Doble, Megger, ISA/Altanova and EuroSMC, we found no AI-branded capability in any of them. That is our own finding, from public product material, on a date, and it may be out of date by the time you read it.

It is also not an argument. Being first is not the same as being right, and nobody else having shipped something reads at least as easily as caution as it does as opportunity. The narrower claim we will defend: a tool-using agent with per-step approval, grounded retrieval, deterministic verdicts, recorded provenance and a local data boundary is a defensible design, and it should be judged on those five boundaries rather than on the demo.

The same philosophy, the other product

None of this is specific to relays. AgenticGrid Pro, our power-transformer asset performance management workbench, rests on the same commitment: the AI drafts the reasoning, and a named engineer signs off before an assessment leaves the tool as an assessment. The engineering authority there is also deterministic and local, generative features also run on the customer’s own provider key with controlled egress, and the standards it cites are context rather than certification.

Two products, two asset classes, one position on what software may decide.