Generation assets, photovoltaic, wind, hydroelectric, thermal, and storage, produce continuous telemetry that operators need interpreted, not just logged, without that interpretation ever gaining authority over plant control. This page sets out how such a workflow would be planned and run on inTheEU Assist, not a record of a completed deployment.
Telemetry from inverters, turbines, generators, or storage systems would be ingested and indexed on premises, feeding a knowledge pack scoped to the operator's own tenant. An agent configured for the workflow would compare current readings against approved operating history and propose candidate anomalies, each one tied to a specific asset and entered with a status of proposed. A request for closer inspection, such as a scheduled drone pass or a maintenance visit, would follow the same proposed-to-approved path.
Deterministic plant control, protection relays, turbine and inverter control, grid synchronisation, emergency shutdown, would remain entirely outside this workflow. The platform would never hold, request, or execute authority over those systems.
Every anomaly flag or maintenance recommendation would require explicit approval from a named engineer before it is treated as established or acted on. This is not a policy layered on top of the workflow. It is the mechanism by which the workflow proceeds at all: an unapproved stage simply does not execute the next step.
The anomaly-flagging workflow, the proposed-to-approved review lifecycle, and the signed audit chain behind every action are working parts of the platform. What is not yet part of this: an asset-specific model trained on a given operator's own inverter, turbine, or generator telemetry, which is exactly what an initial pilot would build. Plant control systems remain outside the platform's scope entirely, by design. The domain judgement in an energy deployment would remain with the operator's own engineers throughout, and any asset-specific analysis skill would be developed alongside them, not supplied as an off-the-shelf model.
Some of the architecture underlying this capability set is documented in filings still in progress. This page describes what the platform is designed to do, at a level appropriate for planning a pilot, not an implementation specification.
Platform features and interface are subject to continuous improvement. Descriptions in this guide may not reflect the exact layout or wording of the latest released version.