Inspection and industrial robots generate visual, thermal, and sensor observations that maintenance teams need interpreted in context, without that interpretation ever gaining authority over motor control or safety interlocks. This page sets out how such a workflow would be planned and run on inTheEU Assist, not a record of a completed deployment.
Observations collected by a robot, images, thermal readings, telemetry, 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 a new observation against approved maintenance history and propose a candidate finding, entered with a status of proposed and tied to the specific asset and mission it came from. A request for closer inspection would follow the same proposed-to-approved path before any repositioning is carried out.
The robot's own control system, motor and actuator control, collision avoidance, emergency stop, safety interlocks, would remain entirely outside this workflow. The platform would never hold, request, or execute authority over those systems, and no action reaches the robot until it has passed through an explicit approval.
Every finding or repositioning request 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 finding-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: a robot-specific perception model trained on a given operator's own equipment and environment, which is exactly what an initial pilot would build. The robot's deterministic control system remains outside the platform's scope entirely, by design. The engineering judgement in a robotics deployment would remain with the operator's own team throughout, and any asset-specific perception 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.