Published up front so data readiness can be planned before the project starts. Open any item for the detail: what exactly we need, in which format, and what happens if you don't have it. If most of this list is covered, a PoC will produce meaningful results. If not, the usual starting point is grid state estimation.
What we need: the connectivity model of the study area — nodes, lines and cables, transformers, switches, loads and generators — with element IDs that match the IDs used in your measurement systems. We read CIM/CGMES (preferred), NEPLAN and PowerFactory exports, pandapower, OpenDSS and PSS/E directly. No network model yet? A GIS extract with feeder topology is enough to build one; we list what is missing. Typical PoC scope: one substation with its MV feeders, or two comparable areas.
Every element that can change the topology — sectioning points, ring couplings, tie switches, transformer feeders — with its normal (default) state and, where known, whether it is remotely operable, manually operable or locked. Why it matters: topology optimisation searches exactly this set, and envelopes and congestion management need to know which alternative paths exist and how fast they can be switched.
Per line or cable: length, type, R, X and B (or per-km values) and rated current. Per transformer: rated power, voltage ratio, short-circuit impedance, tap-changer range and step. Where values are missing, the manufacturer type designation is enough — we fill gaps from type libraries with documented assumptions, and every assumption is listed in the PoC report so your engineers can correct it.
Anything you already know the model gets wrong: temporary configurations, customer installations not yet mapped, reinforcements in service but not in the model, meter-to-node assignment issues. Documented deviations shorten back-testing; the rest surfaces automatically when estimated and measured grid states are compared during calibration.
Active power or energy (reactive power if available) per metering point at 15-minute resolution, plus the mapping from metering point to network node. Twelve months capture all seasons; three months are enough for a first pass. If individual meter data cannot be shared, profiles aggregated per node or per LV transformer work.
Time series from secondary substations and SCADA: voltage magnitudes, currents, active and reactive power at the measured nodes, switch states and alarms. Historian exports (CSV or Parquet) or an API, with timestamps in a known time zone and the measured node identified in the model.
Generation units in the area with installed capacity, connection node and type (PV, wind, hydro, CHP, battery). Metered feed-in time series where they exist; for unmetered PV, installed capacity and orientation are enough to model production from irradiance.
Load or generation forecasts you already produce or buy, with their horizon and update frequency, so the PoC can compare against them. If none exist, weather data and standard profiles are the starting point — FLEX brings its own forecasting where the use case needs it.
Data quality issues are expected. Send the data as it is and tell us what you already know is wrong. Plausibility checking — measurements that contradict the physics are flagged and reconciled — is part of the product and often the first useful output of a PoC.
Per asset: type, connection node, rated power, energy capacity for storage, technical limits (minimum and maximum output, ramp constraints), ownership and contractual availability, and the control path — SCADA setpoint, aggregator API or a phone call. The control path decides what a PoC can simulate and what it can actually test.
Agreements that already limit or condition a connection: connection limits, curtailment rules, notification lead times, compensation terms and their end dates. They define the boundaries an operating envelope has to respect and the baseline it is compared against.
Records of past curtailments: which unit, when, how much, for what reason (voltage, thermal, N-1, external instruction) and how the decision was taken. This is the baseline against which curtailment minimisation is measured — without it the business case stays an estimate.
One technical counterpart who knows the grid and can answer why a feeder is configured the way it is. Typical effort: a kick-off day, then short weekly sessions. Decisions about data access and scope should sit with this person or one step above.
Weekly working sessions in the analysis and validation phase: reviewing intermediate results, sanity-checking switching or flexibility proposals against operational experience, and confirming that estimated states match what the control room sees.
We provide a template agreement. Data can be pseudonymised (metering points, customer references), and processing can run on-premises or in an EU-hosted environment if data cannot leave your perimeter.
Before kick-off we agree the metric the PoC will quantify — capacity recovered, curtailment avoided, connections enabled, estimation error reduced — and how its baseline is measured. This is what the final report and the business case are built around.
Bring this checklist to the scoping call — thirty minutes are enough to define what the PoC can quantify on your data.
