Industrial AI Can't Just Predict: Ontology Platforms Enable Semantic Safety Loops

Previous articles have discussed ontology, OPM, MBSE, and the industrial AI semantic foundation. If left at the theoretical level, these concepts can seem abstract. But when placed in a real industrial site, they correspond to a very concrete problem:

AI cannot just predict a number; it must understand which equipment, process, state, risk, and disposal action that number occurs in.

I previously participated in a monitoring and early-warning project for a large manufacturing enterprise. A typical scenario was the temperature warning for activated carbon box groups in a painting workshop.

This case illustrates that the difficulty of industrial AI is not only training a prediction model, but putting the model back into the equipment, process, spatial structure, safety rules, and disposal loop.

How the Scenario Works

The painting workshop produces exhaust gas and dust. For environmental compliance, the enterprise uses activated carbon box groups for adsorption treatment.

Activated carbon box groups are not disposable. After adsorption saturation, they can be regenerated via high-temperature desorption or catalytic decomposition and then reused.

Multiple box groups handle indoor gas adsorption. When a group becomes saturated, it enters a regeneration process. During regeneration, a heating chamber heats and transports high-temperature gas or steam through pipes to the catalytic chamber containing the activated carbon boxes for high-temperature treatment.

A critical risk exists: temperature must stay within a safe range. Too low, catalytic decomposition is ineffective; too high, the activated carbon boxes may ignite, causing a safety accident.

Therefore, multiple temperature sensors are placed in each box group — typically top, middle, and bottom — to judge whether the internal temperature meets process requirements.

The enterprise experienced multiple incidents where internal temperature sensors failed, causing the system to misjudge the box temperature as insufficient, continue heating, and ultimately overheat and burn the box group.

In other words, once a temperature sensor fails, the system may think the internal temperature is still too low and keep heating. The heating chamber continues outputting high-temperature gas, but the actual internal temperature may already be very high, creating a fire risk.

Previous Approach

The approach at the time was to train a machine learning model on historical data.

The model used data including:

Heating chamber outlet temperature;

Activated carbon box group top, middle, and bottom temperatures;

Heating duration;

Historical temperature curves during regeneration.

The model's goal was not to directly judge "whether it will burn," but to infer the expected internal temperature range based on heating chamber temperature, heating time, and historical patterns.

Then the predicted temperature was compared with the actual sensor readings.

If the predicted temperature and a sensor's reported temperature deviated significantly over time, that sensor was likely distorted, and the system would alarm for on-site inspection.

This solution was effective at the time. It solved a key problem:

When a sensor may be distorted, you cannot continue to blindly trust its readings.

But there is an easily overlooked detail.

The site has multiple box groups, each connected to the heating chamber by pipes of different lengths, bends, insulation, and heat loss. The same heating chamber outlet temperature of 220°C may affect box group 1 and box group 6 differently.

Therefore, a single global model could not be used; instead, a separate model (or at least independent calibration parameters) was needed for each "heating chamber – pipe – box group" combination.

This shows that industrial AI is not just an algorithm problem, nor is "more data, one bigger model" always better.

For a model to be accurate, it must first know which equipment object, pipe path, spatial location, sensor group, and operating state it faces.

If this information is scattered across equipment ledgers, piping diagrams, point tables, and historical data tables, a machine learning model cannot automatically understand it.

A semantic layer is needed to organize the relationships among "equipment – pipe – box group – sensor – process – heat loss."

Ontology Platform Supplies Business Semantics

Machine learning models excel at learning patterns from historical data. In this scenario, they can judge:

Whether the current temperature trend is abnormal;

Whether a sensor may be distorted;

Whether predicted and measured temperatures deviate excessively;

Whether the current process carries potential risk.

But the models do not natively understand:

Which workshop and which box group this is;

Which pipe connects this box group to the heating chamber;

The pipe's length, bends, and heat-loss characteristics;

Which equipment combination and operating condition range the model applies to;

Whether the box group is in adsorption, regeneration, heating, or cooling state;

Whether this anomaly should trigger a reminder, shutdown, work order, or manual confirmation.

The ontology platform does not replace the machine learning model; it puts the model into real business semantics so the model's output can return to equipment, process, rules, and disposal actions.

More precisely:

Machine learning models detect anomalies;
Ontology platform understands anomalies;
Business systems dispose anomalies;
Closed-loop feedback continuously optimizes anomaly detection.

Organizing Site Semantics with OPM and Ontology

Using OPM and ontology, the scenario can be modeled in five categories:

Objects: painting workshop, exhaust treatment system, activated carbon box group, heating chamber, catalytic chamber, steam pipe, temperature sensor, alarm event, disposal work order, machine learning model, etc.;

Processes: exhaust adsorption, saturation judgment, regeneration switching, heating, catalytic decomposition, temperature collection, temperature prediction, deviation verification, anomaly alarm, manual disposal, etc.;

States: adsorbing, pending regeneration, heating, catalytic decomposing, cooling, sensor suspected fault, combustion risk present, alarmed, disposed, etc.;

Rules: catalytic temperature safety range, heating time upper limit, temperature gradient, prediction–measurement deviation threshold, risk level, manual confirmation requirement, interlock shutdown strategy;

Actions: alarm, prompt, stop heating, close valve, generate work order, notify duty personnel, on-site confirmation, reset equipment, record disposal result, feed back training samples.

After such modeling, the system understands not an isolated temperature curve but a running industrial process.

More importantly, each prediction model should not be just a model file but a manageable semantic asset, bound to explicit equipment combinations, pipe paths, applicable conditions, training data scope, and model version.

In the multi-box-group scenario, the model does not abstractly predict "box group temperature"; it predicts the box temperature for a specific equipment group, pipe path, and operating condition.

What the Warning Becomes

The original machine learning model retains its value. But within the ontology platform, it becomes a controlled analytical capability of the "activated carbon box group regeneration process."

A single warning can now look like this:

Box group #3 is in catalytic decomposition process;
Currently using the temperature prediction model for box group #3;
This model is bound to pipe path #3 and historical regeneration conditions;
Heating chamber outlet temperature keeps rising;
Model predicts middle temperature should reach around 210°C;
Middle sensor continuously reports 145°C for 5 minutes;
Predicted vs. measured deviation exceeds threshold;
Top and bottom temperature trends are inconsistent with middle;
Judged as middle sensor suspected distortion;
Heating process continues, overheat combustion risk exists;
Recommend stopping heating and generating on-site inspection work order.

This is fundamentally different from a simple alarm.

A simple alarm says: Temperature abnormal. A semantic alarm says:

Which equipment in what process;
Which model is used;
Which equipment group, pipe path, and condition the model applies to;
Which sensor may be distorted;
Why it is judged abnormal;
What the current risk is;
Who should take what action.

This is the key shift from "model prediction" to "business understanding."

AI Agents Must Also Be Semantically Constrained

If an AI Agent is introduced in this scenario, it should not face raw sensor data and database tables directly, but work through an industrial semantic service layer.

It sees not raw fields but equipment objects, pipe paths, processes, operating states, sensor points, model predictions, model applicability boundaries, safety rules, risk levels, executable actions, and historical disposal records.

Thus the Agent can answer:

Why is the middle sensor of box group #3 judged possibly abnormal?
Is the current prediction model applicable to box group #3?
Why has the risk level increased?
Is shutdown recommended?
Are there similar historical events?
Which test point should field personnel check first?
Can this disposal become a retraining sample for the model?

But the Agent must have boundaries. It can explain risks, generate disposal suggestions, organize similar historical cases, assist in generating work orders, but whether to immediately shut down, close valves, or resume production must still follow enterprise safety policies, field control system permissions, and manual confirmation mechanisms.

Industrial AI cannot bypass the safety control chain for the sake of "intelligence."

Summary

Many industrial AI projects start with prediction models — predicting temperature, faults, quality defects, energy consumption, equipment life. These are important, but with only prediction models the system can usually only answer: This number might be abnormal. What the business site truly needs is:

Which object in what process has an anomaly;
Which rule this anomaly violates;
What the current risk level is;
Which model the current prediction comes from;
Which box group, pipe path, and condition the model applies to;
What action should be triggered;
Who confirms;
How the disposal result feeds back into the model and rules.

In the activated carbon box temperature warning scenario, the machine learning model helps detect possible sensor distortion. But only by introducing an ontology platform that organizes equipment, pipes, sensors, processes, states, safety rules, model applicability boundaries, risk levels, and disposal actions can the system truly understand what the anomaly means.

This is the value I see in the industry AI semantic foundation:

Let models detect anomalies;
Let semantics understand anomalies;
Let business dispose anomalies;
Let feedback optimize models.

Only by reaching this step does industrial AI become not an isolated prediction model, but enter the real business operation and safety governance loop.