An AI system detects a deviation, proposes a measure and prepares the next step. In an industrial company, this transition determines whether useful assistance becomes a controllable process. Who may approve the measure? Which machine is affected? What information supports the decision? And what prevents an approved action from exceeding technical limits?
The public positioning of the SupraWorx security architecture therefore centres on a clear guiding principle: Human Approval + Technical Safety Envelope. Human responsibility and technically enforced boundaries form two independent layers of protection. This article describes the architectural principle and the requirements for its implementation. Available functionality must be checked against the specific integration and released product version.
Two layers of protection with different responsibilities
Human Approval means a conscious decision by the responsible person about an action presented in understandable terms. An approval should make clear the objective, the affected object, the resulting change and how long consent remains valid. A generic “Continue” without this information is insufficient for consequential actions.
The Technical Safety Envelope is the technically enforced set of permissible actions: approved interfaces, device identities, parameter ranges, operating states and execution conditions. It remains effective after human approval. Consent must never override technical protective functions.
To keep this model verifiable, five questions must be answered separately.
1. Action: What exactly should happen?
The action describes the intended change: for example, creating a draft maintenance order, approving an inspection report or handing over a defined device job. The target object, parameters, expected effect and possible side effects belong in a structured action description. “Arrange maintenance” would be too vague if it remained unclear whether this merely creates an order or already affects a machine.
2. Permission: Who is authorised to initiate this action?
Permission and consent serve different purposes. An authenticated user may be able to read a proposal without being allowed to execute it. A person responsible for a process may approve a report without being authorised to change device parameters. Identity, role, company context and the permitted scope of the specific action are decisive. The executing interface must check these prerequisites again immediately before execution.
3. Source: What is the decision based on?
Measurements, images, work instructions and historical events need traceable provenance. The decision basis therefore includes the source, timestamp, version and process context. An outdated inspection plan or a measurement from another machine can invalidate an otherwise convincing recommendation.
Content from documents or tool responses remains data. An instruction embedded in that content must not create permission or change an approval rule. Source quality does not confer authority to execute: even a correct diagnosis is not permission to intervene.
4. Device boundary: What can technically be executed?
For device actions, the permitted scope must be enforced outside free-form text generation. This includes binding the action to a specific target device, allowing only approved commands, validating parameters and checking the current operating state. A job for machine A must not be transferable to machine B.
Functional safety remains the responsibility of components intended and suitable for that application. Emergency stops, protective interlocks, and safe speed and workspace limits must not be bypassed by AI proposals or workflow approvals. This architectural principle does not constitute evidence of safety certification.
5. Audit: What was actually decided and executed?
A reliable record connects the proposed action, source versions, policy version, approval decision, executing identity and outcome. It distinguishes proposed, approved, handed over, confirmed and failed. Successful transmission to a device is not proof of successful execution.
Logging requires its own protection concept: restricted write access, traceable corrections, appropriate integrity protection and defined retention. Secrets and unnecessary personal information do not belong in an audit log.
Practical example: An unusual inspection result
A camera identifies a possible quality defect. The AI prepares an inspection report and proposes a follow-up inspection. A qualified person checks the original image and the valid inspection plan. Only a separately authorised and approved action may trigger a follow-up job. Whether this can result in device motion is additionally determined by the technical device checks. The audit records the decision and confirmed outcome separately.
SupraTix has already described the separation between AI assessment and actual motion authority in its article on agentic edge AI (German). The principle set out here makes the five areas of responsibility explicit and provides a framework for further productisation.
Your next step: Choose a specific process and document its action, permission, source, device boundary and audit on one page. SupraTix can help you structure this process as a clearly bounded SupraWorx use case.
