How we work: diagnosis, physics-based models, plant operation
You have to understand a process before you optimise it. That's why every project starts by measuring, continues with a model that carries the laws of the process and the knowledge of the person who runs it, and only then goes into production, with the operator in charge and the model's error checked every week.
Understand before you optimise
Most industrial AI projects fail because of the order they follow: the tool gets bought first and the problem gets found afterwards. We do it the other way round. First we pick a specific process (a furnace, a dryer, a line) and answer one question with data: where the margin is and why. Only if that margin exists and can be measured do we build the model.
Your team knows the process better than anyone; we bring the physics and the models. The project works when the two come together, and that combination runs through every phase that follows.
What makes the model different
The process physics, built in
The furnace's energy balance, the press's thermal dynamics or the tool's wear curve go into the model as constraints. The data fine-tunes what the physics doesn't fix. That's why the model works with less history and stays valid when the feedstock or the format changes.
Built on the data you already have
SCADA, PLC, historian, MES and ERP, over the usual protocols (OPC UA, Modbus, exports). No new sensors and no civil works, unless the diagnosis shows a signal is genuinely missing.
Explainable by design
Every recommendation and every alert carries the variable driving it and the physical reason behind it. Whoever receives it can check it against the process before acting on it, and question it.
Monitored after delivery
The model's error is checked every week against what actually happened. When the deviation crosses the agreed threshold, it's retrained. A plant changes; an unmonitored model ages in silence.
The four phases of a project
We pick the process with the most margin, review what signals exist, and decide whether it's worth a diagnosis. If it isn't, we say so.
Historical data, a plant visit and a conversation with whoever runs the equipment. The output is an estimate of the margin based on your own data and an agreed baseline to measure against later. The signals we review.
It's built with the process physics and the plant's history, checked against the operator, and goes into production on the existing signals. For the first few weeks it only recommends; after that, if the plant decides to, it writes setpoints within engineering limits.
Results measured against the baseline every month, using the plant's own meters. If it works, it's rolled out to similar equipment with the same method and the same measurements.
Where it applies
The method is the same; the question changes. In energy efficiency, how much gas or electricity is left over each shift. In predictive models, what fault, consumption level or reject can be anticipated. In planning, what order to produce in with the price of energy factored in. And by sector, all of the above applied to automotive, in welding, furnaces and presses, and to wind components, in blade curing, shaft forging and large-part machining.
The first project with each client is deliberately kept small: one line, one furnace, one product family. Trust is built by measuring, not by promising.
What we don't do
We don't deploy generic tools and look for a use for them afterwards. We don't promise percentages before the diagnosis: your team's margin is estimated from your own data, not someone else's. We don't replace the control system or the operator's judgement. And we don't publish result figures without saying what was measured, where, for how long and with what method.
Related: Glossary Frequently asked questions Team Industrial AI in Cantabria
Common questions about the method
Why “critical AI”?
Because the model is built so it can be questioned. Every prediction carries its physical reasoning and its margin of error, gets checked against what the operator knows before any alert fires, and is monitored every week against what actually happened. A model that can't be questioned doesn't deserve trust either.
What happens if my plant's data isn't good enough?
We say so at the diagnosis stage, before charging for a model. We review the SCADA or historian signals (consistency, gaps, sampling frequency) and, if something's missing, propose what to record and for how long. Starting a model with data that doesn't work is the most expensive way to find that out.
How long does each phase take?
The exploratory meeting, 45 minutes. The diagnosis, two to three weeks with historical data and a plant visit. The first model in operation, two to four months depending on the process. Measurement against the baseline starts in the first month of operation.
Who decides on the plant floor, the model or the operator?
The operator. The model recommends and explains; the plant accepts, changes or rejects it. If the plant and the model disagree, the plant wins and the model gets reviewed. It only writes setpoints when the plant decides to, within limits set by engineering.
How is the result measured?
Against a baseline agreed before starting: specific consumption, reject percentage or replanning hours from previous months, corrected for production and format. It's measured using the plant's own meters and records, not our estimates.
45-minute exploratory meeting
We pick a process, review what signals exist, and decide whether it's worth a diagnosis. No cost, no obligation.
Request the meetingFrequently asked questions