FLEX is a power-systems tool that uses reinforcement learning — not an AI product that happens to touch the grid. Every recommendation is computed on a full AC model of your network, checked against your operating limits and N-1 security, and handed over in the terms your grid engineers already use: loadings, voltages, switching states and margins.
One AC model of your grid, shared by planning and operations. Physics, limits and N-1 security enforced inside the search — not checked afterwards.
How the twin fits into the stack: Technology →Every recommendation FLEX makes is computed against a digital twin of your network: a full AC-formulation model — not a DC approximation, not a statistical surrogate. The twin ingests your grid model through open interchange formats and stays synchronised with your GIS and planning tools, so the grid the agent optimises is the grid you actually operate, down to circuit-breaker level. And it does not evaluate a snapshot but trajectories — what a switching sequence does at 18:00, at 18:15, and when the wind forecast is wrong.
Six things a recommendation has to respect before an operator ever sees it — modelled explicitly, not approximated away:
Full AC formulation on pandapower, OpenDSS and PyPowSyBl: active and reactive power, voltage magnitudes and angles, losses. No DC approximation and no statistical surrogate standing in for the physics.
Voltage bands per voltage level, thermal ratings of lines, cables and transformers, and your own planning margins — enforced as hard constraints inside the search, so an infeasible option is never proposed in the first place.
Every candidate action is evaluated against contingencies. A switching action that relieves one line but would create an N-1 violation elsewhere is discarded during the search — not flagged for someone to catch later.
Sectioning points, circuit breakers and disconnectors modelled down to breaker level. Feeder reconfiguration and load transfer between substations are explicit, discrete actions — the non-costly measures that come before redispatch or curtailment.
Batteries, power-to-heat, curtailable generation and controllable loads with their real constraints — capacity, state of charge, availability — so flexibility is only counted where it can actually be delivered.
Trajectories instead of snapshots: what a switching sequence does at 18:00, at 18:15 and when the wind forecast is wrong. Multi-period evaluation under forecast uncertainty is native to the twin, not bolted on.
FLEX does not bring its own proprietary grid model. It runs on the power-flow engines your planners already know, reads the model you already maintain, and writes results back in the same formats — so every recommendation can be re-run in the planning tool you already trust.
The twin computes on established open engines rather than a black box — the same physics your planning department can reproduce.
Grid models come in from your GIS and planning tool through open interchange formats, and results go out the same way — no manual re-modelling, no parallel data model.
A twin is only as good as the model behind it. Every FLEX engagement follows the same six steps before a single recommendation counts:
Import happens through open interchange formats — CIM/CGMES, pandapower, OpenDSS, PSS/E and GeoJSON — from your GIS and planning tool. Plausibility checking is built in: measurements that contradict the physics are flagged and reconciled instead of silently corrupting the model. And the twin stays synchronised with your GIS and planning tools, so the grid FLEX optimises is the grid you actually operate.
Planning margins, voltage bands, grid-code requirements and operating policies are encoded as explicit constraints — regulatory-in-the-loop. FLEX only recommends what you would be allowed to do.
Each recommendation ships with the load flow behind it: loadings and voltages before and after, the N-1 report, the margin to every limit — and it can be reproduced in your own planning tool.
Nothing executes automatically. FLEX ranks and explains options; the operator applies experience and takes the decision — human-in-the-loop by design, and the basis of our EU AI Act positioning.
A proof of concept starts with your network model and the measurements you already have. We show you what the twin sees — and what it would change.
