Recommendations: the operating actions module in Captia.ai

How the recommendations module works inside Captia.ai

The module sits in a very specific place in the platform: after dashboards, rules and alerts, and before action. An alert says something is outside what was expected. A recommendation goes one step further and says what can be done about it, on what grounds, and with what priority against everything else open on the shop floor at that moment. That distinction between warning and proposing is the reason the module exists.

It draws on two things. The first is current state: the signals Captia Connect acquires at the edge over the protocols available in the installation (MQTT, OPC UA, Modbus TCP, Modbus RTU over RS-485, OpenWebNet, IEC 870-5-102, REST API, webhooks or CSV files), normalised into time series and sent with local buffering. The second is the historical behaviour of each line, already consolidated in the platform. The module compares what the line is doing now with what that same line has done before under comparable circumstances, and it does so on top of the Captia.ai industrial models, which supply the representation of the process: which assets exist, how they relate to one another and which operating ranges are admissible.

The output is not a setpoint pushed down to the PLC. It is a proposal that appears in the platform Operator Layer, addressed to a person with a defined role, and it only becomes an action once that person accepts it. From there, execution uses the mechanisms already present in Captia.ai: a rule, a workflow, a maintenance notice or simply a manual change the operator records. Acceptance or rejection is stored as an event in the history, so the way the plant responds to recommendations becomes a data point in its own right.

What a recommendation contains, and why traceability matters

A recommendation without its reasoning is an anonymous instruction, and in an industrial environment an anonymous instruction is either ignored or, worse, obeyed without judgement. Each proposal from the module therefore carries the elements needed to audit it later: the observation that triggered it, the historical reference it is compared against, the industrial model involved and the operating margin within which the action is admissible. If six months later somebody asks why a start-up sequence was changed, the answer sits in the history, not in the memory of whoever was on shift.

Data requirements: what is needed before switching it on

The first requirement is not about data, it is about governance: a role has to exist that receives recommendations and holds the authority to accept or reject them. Captia.ai user and role management solves the technical half, but the organisational half is decided by the plant. A module proposing actions to nobody in particular produces an inbox that fills up and never empties.

The second is a continuous history per line. The module compares the present against the past of that same line, so with no past there is no term of comparison and the proposal degrades into a generic rule, which the platform can already deliver without an AI module. Continuity matters as much as volume: a history with gaps tends to leave out precisely the anomalous episodes, which are the most informative ones. This is where Captia Connect local buffering stops being an infrastructure detail and becomes a data quality condition.

The third is that the industrial models are built. The module does not infer the structure of the plant from raw signals: it relies on the representation already held in the platform, with its assets, lines and relations. A loose signal with no associated asset can be watched with an alert, but it cannot generate an interpretable recommendation, because there is nothing to act upon.

The fourth is operating context: shift, calendar, machine state, recorded production and, where relevant, whatever arrives by API from ERP, MES, CRM or SAP. Without that context the module can detect that something is behaving differently, but it cannot judge whether to act or wait, which is exactly what is being asked of it.

The fifth is more awkward to assemble and is usually forgotten: the constraints. What must not be touched, in which time windows, with whose authorisation. Without that set declared, the module will propose actions that are formally correct and operationally unacceptable, and two or three of those are enough for the plant to stop reading it.

Industrial application cases

The most direct case is shift prioritisation. In a plant with several lines there are always more open warnings than capacity to attend to them, and the real decision is not what is wrong but what gets attended to first. The module orders what is open according to the current state and the historical behaviour of each line, and that ordering is itself the recommendation. It is the case where the module is felt earliest, because it demands no change to the process.

The second is responding to a deviation already detected. When the anomaly detection module flags behaviour outside pattern, the shift manager immediate question is what to do. The recommendations module retrieves what was done on previous occasions on that same line and how each of them ended, and proposes the course of action the history supports.

The third is adjusting operating parameters within already authorised margins: start-up sequences, staggering of auxiliary equipment, setpoints that admit a range. Here the recommendation sits alongside the production and consumption optimisation module, which searches for the operating point, while the recommendations module makes sure that point reaches a person as a concrete action with its justification attached.

The fourth is preserving operating judgement. In plants facing a generational handover or high shift turnover, much of the know-how lives in the heads of a few people. Once decisions and their outcomes are recorded, the history stops being only a series of measurements and starts to contain what was done and what worked. The module leans on that record so a new shift does not have to rediscover what the plant already learnt.

If the aim is to understand the discipline before the module, the guide on how to apply artificial intelligence in a factory sets out the full decision framework; this page is limited to what the module does inside the platform.

How it is deployed in phases

Deployment follows the general platform phases described in the industrial data platform hub. This module arrives late on purpose: it is the last one switched on, because it consumes the output of all the others.

1. Diagnosis. Alongside the inventory of signals and protocols, this is where the decision map is drawn: what is decided on the floor today, who decides it and on what information. Without that map there is no way to know which recommendation would have a recipient.
2. Edge deployment. Captia Connect on the floor, acquisition, normalisation and buffering. From here on, history per line exists.
3. Platform go-live. Dashboards per asset, line, role or plant, users and roles, rules and alerts. The plant sees its state and defines who answers for what.
4. Industrial models. Representation of assets, lines and relations, with their admissible ranges. This is the requirement specific to this module and the step most often underestimated.
5. Recommendations in observation mode. The module starts proposing while nothing depends on its proposals. The plant reads them, accepts or rejects them, and that contrast is used to tune the scope before anyone relies on it.
6. Operationalisation. Accepted recommendations are wired to workflows, reporting and API integration with ERP or MES, so the decided action needs no manual transcription steps.

Designing that decision chain, where it goes beyond what the platform resolves out of the box, is engineering work we run as our operational automation service; where the need is an agent with a bounded scope over a specific process, the fit is AI agents.

Limits and when it does not apply

This is the module most easily oversold, so it is worth bounding it without ambiguity. It does not apply, or adds little, in these scenarios:

• When closed-loop automatic control is expected. The module proposes; it does not act on the process by itself. If what is needed is a setpoint that changes on its own within milliseconds, that is control, it lives in the PLC or the control system, and it is not what this module does.
• With no history per line. With freshly connected signals there is nothing to compare the present against. During that period the value sits in dashboards and rules, not here.
• With no industrial models built. If the platform does not know which assets exist or how they relate, a proposal cannot refer to anything concrete. What is missing then is modelling, not analytics.
• When the decision has no owner. A recommendation addressed to a non-existent role, or to one without authority to accept it, never turns into action. This is the most common reason a technically sound deployment produces no change at all.
• When there is no operating margin. If the process cannot vary sequence, schedule or setpoint because of quality, safety or contractual constraints, there is no room to recommend. The information still helps justify investment, but not to operate differently tomorrow.
• When the problem is equipment or design. No operating recommendation compensates for an undersized asset or a badly framed installation. The module will make the symptom visible; the correction is engineering work.
• When the question being asked is genuinely new. The module relies on the historical behaviour of the plant. Faced with a situation with no precedent in the history (a new product, a recent refit, a machine just commissioned) its proposals lose their backing and should be read as such.

And the limit that shapes all the others: a recommendation is not an instruction. The platform is built so the decision stays with the person answering for the line, and the trace of that decision is part of the product, not an optional extra.