An agent with abudget of authority.
The copilot can read the plant, author a procedure and ask for it to be run. What it cannot do is decide how far it is allowed to go — that is granted to it, in writing, with a ceiling and an expiry, and enforced server-side on every request.
AI is an accelerant, never a dependency
The closed loop is deterministic. Grounding, procedure authoring, compilation, validation, dry-run and execution all run with no external model in the path — so the plant does not stop when an API does. A language model can be attached to widen what the copilot understands. Nothing load-bearing sits behind it.
What actually happens between the prompt and the plant
- 01
Ground
The intent is resolved against the live twin: which assets, which tags, which limits, what is currently true. An intent that cannot be grounded is rejected here, not halfway through execution.
- 02
Author
A Process Intent Representation is emitted and compiled to BPMN. Static validation reports the required capabilities, the authority class the procedure would need, and its blast radius.
- 03
Prove
The procedure is dry-run on an isolated twin. Commands are intercepted. The scenario's assertions and the procedure's own acceptance criteria are both evaluated against measured aggregates.
- 04
Gate
A human sees the proposal, the proof and the authority class it needs, then approves or rejects. Approval is what turns intercepted commands into real ones.
Two dials, both server-side
Authority bounds what an agent may ever request. Autonomy bounds whether it may act on its own. They are independent, and both are checked on the server on every command — a client cannot talk its way past either.
Authority · what may be requested
- C0
- Read configuration
- C1
- Read data
- C2
- Propose
- C3
- Reversible configuration change
- C4
- Operational action
- C5
- High-consequence action
- C6
- Safety-relevant action
Autonomy · who may act
- L0
- Advisory only
- L1
- Propose — a human executes
- L2
- Execute on approval
- L3
- Autonomous, notify
- L4
- Autonomous, review after
The bundled grid copilot is granted C4 / L1: it may author and propose a protective procedure, and a human executes every field action. That grant carries a justification and an expiry.
Six things that stand between a request and a register
None of these are advisory. Each is checked on the server, on every command, whoever issued it.
Interlocks before every write
Each command is checked against the asset's interlock set before it is issued. A failed check raises an incident; it is never retried around.
Independent read-back
Confirmation reads an applied-setpoint echo written by the plant model or device, not the register the command just wrote. A tautological acknowledgement is not an acknowledgement.
Second-person approval
Safety-classified actions require a different person to approve than the one who requested. The requester cannot self-approve.
Kill switch
One control halts agent-originated execution across the deployment, without taking supervision or acquisition down with it.
Attribution end to end
Every command records who or what issued it — an operator, a process instance, the copilot, or an external OPC-UA session with its user name.
Audit events
Governed writes and method calls raise audit events carrying the client user id, delivered to subscribed clients as well as the local log.
A procedure's proof is kept, not remembered
Every dry-run is stored with its seed, its aggregates, its assertion verdicts and the commands it intercepted. Six months later the question 'was this ever tested' has an answer.
Decide how much rope your agent gets.
We will walk through the policy model against your own safety classifications and show you what an agent can and cannot do at each level.