From Level 2 to 3: When to Let the System Act

A plant that already knows what is happening in real time sits at level 2 of the Physical AI Ladder. The next rung is not about buying anything: it is about letting the system act. This guide covers the engineering of that step. Which actions can be automated and which cannot, with a risk matrix by reversibility and cost of error; the three actuation patterns and when to use each; how the guardrail that contains the system is designed; what record every automatic action needs; what European regulation says and on which dates; and how to measure whether the loop was worth anything.

What a supervised closed loop is

A supervised closed loop is the full cycle of perceiving, deciding, acting and measuring the effect of what was done, with a person who authorises, watches or can revert the action. All four stages are necessary, and the fourth is the one that almost never gets implemented. A system that perceives, decides and writes a setpoint but never looks back at what happened does not have a closed loop: it has an order emitter.

That distinction is exactly the boundary between level 2 and level 3 of the Physical AI Ladder. At level 2 the plant knows what is happening: OEE, energy, downtime and quality in real time per line. At level 3 the system decides and executes under supervision, and therefore has to be able to answer whether its action improved the variable it claimed to pursue. If it cannot answer that, it is still at level 2 with one more integration.

Two terms are worth pinning down before going further, because the rest of the text uses them precisely. A policy is the function that turns the estimated state of the plant into an action, subject to declared constraints and aimed at a declared objective. The technique used to implement it is secondary: a rule written by an expert and a learned model are the same thing from a governance point of view, as long as both have a written objective and written constraints. A system that emits suggestions with no written objective does not have a policy, it has opinions, and it cannot be evaluated.

The second term is acting. Writing a setpoint is not acting. Acting is writing and then checking in the measured signal that the equipment accepted the setpoint and executed it. Without that check, what exists is an open loop that looks closed, and its failure mode is silent: the system believes the plant is in a state it is not in. Every action therefore needs three pieces: a confirmation from the equipment, an owner accountable for it, and a record of what caused it.

What can be automated and what cannot: a risk matrix

The question of what to automate is not answered by technology, it is answered by consequences. Two axes are enough to order almost any plant action.

The first is reversibility: how much it costs and how long it takes to undo the action, and what trace it leaves. Lowering a fan setpoint is reversible in seconds and leaves no mark. Resequencing production is reversible, but with intervention and cost. Releasing a batch to a customer is not reversible within any useful window.

The second is the cost of error: what happens if the action executes when it should not have. Here you count the worst case, not the average case, and you separate economic cost from cost to people, which money does not compensate and which therefore does not belong in the matrix: any action that could affect the safety of a person stays outside the scope of automation and is handled by the deterministic safety envelope, not by a policy.

There is a third axis that does not fit in a two-dimensional table and that decides as much as the other two: frequency. A reversible, cheap action executed forty times per shift cannot be confirmed by hand, because the confirmation degrades on its own into a reflex click. An expensive action executed twice a month can be confirmed calmly and does not deserve the engineering of full automation. The practical rule: frequency pushes towards automation, consequence pushes towards supervision, and the chosen pattern is the point where the two balance.

The three actuation patterns

Between doing nothing and acting fully automatically there are three well-defined patterns. They are not phases of a project, they are valid destinations: some actions should stay in the first one forever.

The three failure modes in the last column share one cause: the pattern was designed looking at the case where the system gets it right. The cost of a false positive is not zero, it is the attention of the operator, and that attention is a finite resource consumed whether or not anyone bills for it. A useful criterion when choosing thresholds: if the number of alerts per shift exceeds what one person can genuinely examine in that shift, the right move is not to ask for more confirmations, it is to raise the threshold and accept that some cases escape, or to move to actuation with veto for the actions the matrix allows.

On the order of adoption, the practice that breaks the fewest projects is to start with recommendation on the middle row of the matrix, measure over weeks the acceptance rate of the proposals and the effect of the accepted ones, and promote to confirmation and then to veto only those actions whose acceptance rate is high and stable. That record is also the evidence needed to defend the change of authority in front of production, maintenance and safety.

Designing the guardrail

The guardrail is the set of constraints that keep the worst possible behaviour of the system acceptable. It is designed before the policy, not after, and it is verified independently of it. It has five components.

Hard limits. Absolute ranges no action may cross, enforced at the lowest possible point of the architecture, ideally in the controller and not in the platform. If the limit lives in the same software that decides, it is not a limit, it is an intention. Hard limits are not negotiated against the objective of the policy: they are declared separately and tested by forcing their violation.

Operating windows. An action that is valid in normal production can be unacceptable during start-up, changeover or maintenance. The window declares in which plant states the action is allowed, and it is evaluated on every execution, not once at deployment. This requires plant state to be a first-class piece of data and not a fragile inference, which is one of the reasons level 2 is a prerequisite.

Safe degradation and maximum data age. Every action declares how old the data justifying it may be. Past that limit, the action does not execute. The default behaviour when data is absent is not to act, and every exception is justified in writing. The rule looks bureaucratic until the first time a link goes down for twenty minutes and the system, without it, would have decided on a state that no longer existed.

Bounded latency, not merely low latency. The signal that triggers an action needs an end-to-end delay that is measured and has a known bound. A loop with variable delay cannot be tuned: either it is slowed down to stay stable, or it oscillates. In periodic industrial communication, typical cycle times run from 10 ms to 0.5 ms, according to the 5G-ACIA and ZVEI white paper of November 2019; and in the working clock domain, the one used by robots and motion control, the same document places the synchronisation requirement at 1 microsecond or better, trending towards 100 nanoseconds. Those are orders of magnitude no platform reaches across a management network, which is why the first architectural decision is where each decision lives.

Human in the loop and human on the loop. These are two different architectures, not two degrees of the same one. In the first, the person sits inside the action path: their authorisation is a condition of execution, and their response time is part of the total latency. In the second, the person sits outside the path: the system executes while they watch, veto within a declared window and revert afterwards. The second architecture is only honest if veto and reversion have actually been tested, with a real reversion recorded and dated. A veto button nobody has ever pressed is not a guardrail, it is decoration.

Energy and maintenance: the first safe loops

Two families of actions come up again and again as the first reasonable loop in a plant, and not by chance: they fall in the region of the matrix where the action is reversible and the effect is measured with what already exists.

Energy setpoints. Shifting a thermal load, matching compressed air ring pressure to real demand, staggering start-ups so a power peak is not repeated. These are actions reversible in minutes, with a target variable that is already instrumented and with an operating window that is easy to declare in process terms, for example a product temperature band or a guaranteed minimum pressure range. The effect is measured against a baseline and a comparable period. This is the family of loops behind the only result Captia publishes: over 30% energy savings in energy-intensive companies.

Maintenance orders. Turning a degradation signal into a work order with its asset, its symptom, its source data and its priority. The action is reversible by definition, because an order can be cancelled; the cost of error is technician time, not process integrity; and traceability comes naturally, because the maintenance management system already records who did what and when. The detail that decides whether it works is not the model: it is that the order is born with enough context for the technician not to have to rebuild it. How you get from the signal to that order is developed in the guide to industrial predictive maintenance.

What these two families share matters more than their content: the target variable was already measured before the loop was closed. That is the criterion for choosing the first one. If knowing whether the action worked requires instrumenting something new, then you are not closing the loop yet, you are finishing level 2.

Traceability of the decision

Every automatic action needs a record of the data that caused it. This is not an administrative requirement: it is the condition for the loop to be debuggable, defensible and improvable. When something goes wrong, the question is not whether the system failed but in which of the four stages it failed, and that question is only answerable if every stage left a trace.

The minimum record of an action has eight fields:

1. Input data with its source timestamp, not the ingestion timestamp, and with its quality flag.
2. Estimated state derived from that data, with its uncertainty if the policy handles it.
3. Version of the rule or model that decided, identified so that the exact logic running that day can be reconstructed.
4. Policy applied: objective and constraints in force at that moment, including the operating window that was evaluated.
5. Person who authorised, vetoed or supervised, with their role.
6. Command written: what was sent, to which equipment and to which point.
7. Equipment confirmation: what it replied and what was read afterwards in the measured signal.
8. Measured effect on the target variable within the time window declared for that action.

The first three fields are the ones that get forgotten and the ones that cost most. Without a source timestamp, the causal order of events is lost precisely when the network is worst, which is during failures. Clock synchronisation has had its own standard for years, IEEE 1588-2019 for precision time synchronisation, approved on 7 November 2019 and published on 16 June 2020 according to the IEEE Standards Association; and the time-sensitive networking profile for industrial automation, IEC/IEEE 60802, was published on 29 June 2026 according to the IEEE 802.1 TSN Task Group. Without a model or rule version, any later analysis compares results from different logic believing they are the same.

This record is also the raw material of level 4. A history that contains process variables but no interventions is observational data: it lets you learn what usually happens, not what happens if you intervene. The action and effect pairs produced by a well-recorded level 3 are what a world model needs and what no simulation can supply on its own.

Functional safety and regulation

There is one separation that should never be blurred: the safety function and the control function are different things, and the first does not depend on the second. A safety function is the one that prevents harm to a person when everything else fails: the emergency stop, the door interlock, speed limitation with separation monitoring in a shared cell. It is implemented with deterministic, verifiable and reproducible logic. A learned policy meets none of those three properties, because its output is probabilistic and its behaviour outside the training distribution is hard to bound formally.

The engineering consequence is direct: the model lives above the safety envelope, not inside it. If the model gets it wrong, the envelope still contains the process. This architecture is not a legal precaution, it is what allows the cell to be certified with the standards that already exist without having to prove formal properties about the model.

The timeline of the European artificial intelligence regulation deserves precision, because outdated dates circulate. According to the official European Commission timeline consulted in September 2026, the regulation entered into force on 1 August 2024, its prohibitions and general provisions apply from 2 February 2025, general application starts on 2 August 2026, the rules for high-risk systems under Annex III apply on 2 December 2027, and those for AI embedded in regulated products under Annex I, a category that includes machinery, on 2 August 2028. Those last two dates are later than the original ones because of the package known as the Digital Omnibus. There are legal readings arguing that AI embedded in products covered by the Machinery Regulation will be largely exempt from the obligations of the artificial intelligence regulation, but that claim is not confirmed in official sources and is best treated as interpretation, not as settled law.

That leaves cybersecurity, which changes nature at the exact moment the loop is closed. While the system only reads, the attack surface is one of confidentiality. As soon as a write path into the plant exists, the surface is one of process integrity and availability. The ISA/IEC 62443 series, according to ISA consulted in September 2026, organises the requirements into four groups, and its part 2-1, in the edition 2.0 of August 2024 according to the IEC Webstore, sets the security programme requirements for the asset owner. In practice this translates into strict separation between read and write permissions, named access control, approval of setpoint changes, versioning of rules and models, and a reversion path that has been tested. For information modelling of robot systems, the OPC UA companion specification for robotics is OPC 40010-1, in its version 1.02 released by the OPC Foundation on 8 September 2025.

How to measure whether the loop works

The comparison is declared before the loop is switched on, not afterwards. There are two defensible ways: a baseline with an explicit period, when the process is stable and seasonality can be controlled; or an equivalent control line that does not receive the action, when two comparable lines exist, which is the cleaner option because it absorbs the market and raw material changes a baseline does not capture.

Four indicators are enough to know whether the loop is alive and whether it is useful:

• Execution rate. Actions executed against actions proposed. If it drops below half, the system is proposing things the operator does not agree with, and the problem is in the policy or its context, not in the interface.
• Measured effect on the target variable. The difference against the baseline or the control line, within the time window declared for each action. It is the only indicator that justifies the loop in a cost review.
• Reversion rate. Actions reverted or vetoed against actions executed. A sustained very low rate is not good news: it almost always means nobody is watching, not that the system is perfect.
• Delay between signal and action, with its spread. Not the mean but the tail: the high percentile decides whether the action arrives in time in the bad case. A growing spread announces a transport problem that will later show up as oscillation and be wrongly blamed on the algorithm.

To those four, add one of hygiene: drift. A policy degrades when real conditions move away from those it was tuned against, and that degradation is gradual and invisible without a metric watching it and a threshold that triggers review. In a closed loop drift is more dangerous than on a dashboard, because the system does not merely report badly: it acts badly.

With those four indicators and the drift metric, the observable criteria of level 3 are met: there is at least one action recorded with its measured result, there is an identified supervisor and a reversion path that has already been used, what happens when data is missing is defined and tested, the effect is measured against a declared reference, and changes to rules or models go through versioning and approval. When those five points can be shown during a plant visit, level 3 is not an aspiration: it is a verifiable fact.

Frequently asked questions

The full five-level framework is in the guide to physical AI in manufacturing, and the capture, context and traceability architecture a supervised loop rests on is described in the industrial data platform. If you want to review which action in your plant is a candidate for the first loop, tell us what you measure today and what you would like to happen on its own.