Switching commands
Check which equipment the AI may operate before dispatching its command.
Solutions · Energy & infrastructure
An AI may be allowed to operate one feeder without having permission to switch another. See how an equipment check can stop a command before it reaches a protected destination.
Keep automated commands within the equipment permissions operations leaders approve.
This command stops here. The AI wants to open the hospital feeder, but it has no permission to control that equipment.
Think of it as a key that opens only certain doors. Operations leaders decide which equipment the AI can use.
This is just one example. Other workflows could cover switching equipment, adjusting battery output, or changing building temperature settings.
Each needs specific permissions, trusted equipment information, and a check before the command reaches the controller. Engineering and safety controls still apply. This browser illustration operates no equipment.
01 · AI asks to act
Switching request · open a feeder breaker
Selected equipment
Hospital feeder
02 · Your rule applies
Ready to check. No request has been evaluated in this example yet.
An equipment-permission example. Real switching also requires applicable engineering and safety controls.
See the underlying technology: live rover demoYou keep your AI and existing systems. We start with one workflow, configure checks around your approved rules, and connect them where the AI tries to act. Authorized requests can proceed. Other requests stop, with a record explaining the decision.
Your Grid Operations Manager or Director of Operations defines permitted equipment and operating limits, supported by safety and operational technology security leads.
Your control systems engineers connect the command workflow and trusted equipment identifiers.
Before a command reaches the connected equipment control system. The integration must prevent the agent from going around the check.
We scope one workflow, translate supported rules into a versioned, validated, signed policy package, and connect an adapter that supplies trusted facts such as identity, recipient, and approval status. We then test allowed requests, blocked requests, and attempts to bypass the check before enabling execution.
One maintained kernel can support different policy packages and system adapters. A JSON file alone is not a complete deployment. We confirm rule support and integration requirements for your systems during scoping; additional implementation may be needed.
These are typical ownership patterns; responsibilities vary by organization.
The instruction is to open a feeder breaker. The important question is which feeder. This example blocks the hospital feeder and permits the designated non-critical feeder. A real switching workflow must also satisfy the applicable engineering and safety controls.
The equipment-command example relates to GridGuard’s control boundary. Retrofit Guard addresses a separate workflow: checking electrification program requirements during field work. Switching permission and program compliance need different rules and integrations.
What it is
A deterministic enforcement kernel for grid operations, with cryptographically verifiable decision receipts.
The problem it solves
Grid actions are consequential and effectively irreversible in the moment. GridGuard evaluates each command against its authorized envelope before it is issued and refuses the ones outside it, then emits a signed receipt that a third party can verify independently.
What it is
Offline-first compliance enforcement for California electrification programs, including EBD, TECH, HEEHRA, and SoCalREN.
The problem it solves
Program compliance is usually reconstructed by a consultant long after the work is finished, which is when errors become expensive. Retrofit Guard evaluates program rules at the point of work, in the field, without a network connection, so compliance is established when the decision is made rather than argued about later.
For an integrated control workflow, the record should identify the requested command, the equipment, the permission checked, and the decision. The illustration operates no equipment. The live rover demonstration provides a separate way to examine an actual signed kernel decision.