General
October 19, 2026
10 min read
As AI moves into industrial operations, can we trust the data it receives? Thomas J. Schwieters examines how industrial data transformations can obscure original measurements—and why observational fidelity matters for trustworthy physical AI.
The model is only as good as the fidelity of the observation.
We don't go to a symphony wearing earmuffs while standing around the corner.
Yet we're asking AI to understand manufacturing processes using data that has already been filtered, scaled, normalized, averaged, and joined with information from other systems.
Somewhere along the way, we lost the very information the model needs.
We've spent decades connecting industrial systems. The tools have changed, but much of the underlying work remains familiar. Instruments connect to controllers. Supervisory systems provide operating information. Historians collect data. MES manages production activities, and enterprise systems use that information for planning and business decisions.
ISA-95 helped establish a common framework for these relationships. It has served industry well.
The difficulty comes from what happens to information as different systems and people put it to work.
Consider a pressure transmitter.
The instrument produces an electrical signal representing a physical measurement. The PLC programmer scales it into engineering units, perhaps applies filtering, and makes the result available to the control program.
A SCADA engineer develops tags and calculations for the operator interface. A historian collects the information according to its configured sampling and compression rules. A database developer joins it with production records. Someone creates a report and adds another calculation.
Each set of hands has a different idea of what that information should represent.
Most of these decisions make sense within the application being developed. The trouble comes later.
A technician replaces a 0–100 psi transmitter with a 0–150 psi unit. The PLC scaling gets updated and the control loop runs fine. But a SQL view downstream still takes the raw signal and scales it to 100. Nothing errors. The historian keeps collecting and the dashboard still looks reasonable. A true 75 psi now reads 50.
Some dependencies are documented. Others are buried in PLC code, SCADA scripts, SQL procedures, historian configurations, or spreadsheets.
Twenty years later, an engineer trying to understand one measurement has to work through several generations of modifications.
This creates extraordinary maintenance requirements. Changes in one system have consequences elsewhere, and the relationships aren't always visible.
We've encountered this throughout industrial modernization. The machinery may be sound, the controllers reliable, and the applications performing exactly as configured. Yet the information presented by different systems doesn't always agree.
A dashboard looks perfectly reasonable while reporting a value nobody can reconcile with the original instrument.
Now we're using these same datasets to train AI models and develop simulations.
An industrial measurement is more than the value stored in a database.
Consider the pressure transmitter again. Its measurement depends on the sensing element, calibration, physical installation, signal conversion, and the operating conditions at the time.
The controller filters the signal to stabilize a control loop. The historian samples at intervals suited to trending. A reporting application calculates an hourly average.
All three representations are useful. They serve different purposes.
They aren't equivalent observations.
A short pressure transient matters when you're investigating a valve response. It vanishes in the hourly average. A vibration signal carries frequencies tied to a developing mechanical condition, and a process trend doesn't preserve them.
Timing matters as well.
Two measurements look correlated after the join, even though different systems acquired them using different clocks, sampling intervals, and processing delays.
The join is correct by its own rules. That doesn't establish that the measurements describe the same physical event.
Noise is another consideration.
We often remove noise because it interferes with the measurement or the control function. But apparent noise can also contain information. Harmonics, oscillations, drift, and residuals often tell us something about the equipment or process.
Signal processing is a fundamental part of industrial automation. Filtering and normalization have legitimate purposes, and in many applications they're essential.
We need to understand what those operations preserve and what they remove.
Some transformations can be reversed. An average or a compressed record cannot. A timestamp adjustment helps only if we keep the basis for the correction.
The original signal and its transformations should remain distinguishable.
Otherwise, a model learns patterns introduced by the data-processing system rather than the physical process we're trying to understand.
The model can perform well against historical records and still produce incorrect conclusions about the equipment.
This is particularly consequential when those conclusions are used to recommend or authorize physical actions.
BC Automation's Manufacturing Intelligence Platform, MIP, grew from decades of work with industrial controls and information systems.
We know these systems and why they were built. PLCs provide deterministic control. SCADA supports operating personnel. Historians, MES, and enterprise applications serve different requirements.
Replacing them doesn't resolve the underlying information problem.
Our approach begins closer to the physical observation.
MIP operates in parallel with existing industrial infrastructure. SPA™, Symmetrical Parallel Aggregation™, provides a distributed operational-state fabric connecting instruments, machines, processes, operational information, and analytical applications.
Through IIoT Edge Nodes and Instrument Twins, we establish a contextual representation of each measurement near its source.
We retain the raw signal, engineering values, calibration and scaling relationships, timestamps, and operating context. How much we retain depends on the application, and that stays an engineering decision.
Every derived value stays tied to the observations and transformations that produced it.
A supervisory system needs a filtered temperature value for an operator display. A simulation needs the operating state, its timing, and historical behavior. An analytical model needs finer-resolution observations to examine a transient condition.
These applications have different requirements. We shouldn't force all of them to inherit the same processed representation simply because that is what an existing database happens to contain.
SPA™ makes operational state available across distributed systems while preserving the relationships needed to understand its source and context.
The original control functions remain in place. We begin with observation. No write access to the equipment.
This also allows modernization to proceed incrementally, extending the architecture as the application warrants.
Timing is one of the problems that conventional integration can conceal.
A controller, instrument, historian, database, and video system record different timestamps for related events.
Depending on the system, a timestamp marks acquisition, processing, receipt, or storage. The clocks drift and jitter differently.
Putting everything into one database doesn't resolve those differences.
Within MIP, clocks are Instrument Twins. We keep the raw timestamp, the corrected time, and the basis for the correction.
This allows us to characterize timing relationships instead of assuming synchronization that may not exist.
Consider a machine that begins to vibrate abnormally shortly before a protective shutdown.
The order and timing of the events matter. We need to know whether the vibration preceded the control response, occurred during the transition, or was recorded later because of the acquisition system.
If the timing relationship has been obscured, the model learns the wrong sequence.
Fractional Historization addresses another part of this problem.
Different observations require different resolutions and retention periods. A control transition warrants a detailed record around the event, while routine production reporting needs only a longer-term representation.
We preserve the evidence that matters without collecting and storing every signal the same way. We need enough information to reconstruct and evaluate the behavior we're studying.
Consider a production line with several machines connected by accumulation conveyors.
A simulation uses production counts, machine availability, operating speeds, and downtime records to predict throughput.
Those records are useful. They also come from different systems, each with its own method of collecting and interpreting the information.
An intermittent machine fault creates several short stops. The PLC records the transitions. The historian stores sampled operating values. MES assigns downtime according to production rules. A performance dashboard calculates an average.
The simulation receives the aggregated information and attempts to reproduce the line's behavior.
It produces a reasonable throughput estimate and misses the mechanism that caused the loss.
With observations available closer to the source, we can examine the equipment transitions, accumulation behavior, operating conditions, and timing relationships.
The simulation can still use MES and enterprise information. Production schedules, material requirements, and operating priorities are important context.
We can also compare the model's predictions against the physical events that occurred.
When the prediction differs from the observation, that residual deserves attention.
It might reflect an inaccurate model, a sensor problem, a missing operating variable, or behavior we haven't yet accounted for.
We've worked with residuals and closed-loop response for decades. The difference between what we expect and what we observe is often where the useful information begins.
We shouldn't automatically smooth it away or force the model to fit.
This becomes increasingly important as simulation and AI applications begin interacting with operational decisions.
A predictive model recommends a change in production sequence. An analytical application flags an equipment condition. An operator copilot suggests an intervention.
Those conclusions need to be traceable to observations and evaluated against actual operating boundaries.
ReflexIQ™ and the AI Trust Graph extend this work into the governance of intelligent applications, connecting observations, analytical results, and the basis for decisions.
The distinction between established control functions, analytical recommendations, and authorized actions must remain clear.
We have experience deploying deterministic and closed-loop industrial control. Expanding intelligent applications into coordinated or autonomous operation still requires application-specific engineering, validation, and safety review.
Most manufacturing facilities contain equipment that has been running for decades, through control upgrades, software revisions, instrument replacements, and changes of ownership and crew.
The people who run that equipment are also instruments. An operator hears a pump change tone before any alarm. A maintenance technician knows why a transmitter was mounted where it was. That recognition is an observation, and it almost never reaches the historian. When we lose it, we lose evidence the model never had a chance to see.
Much of that investment remains valuable. The equipment, control programs, instrument configurations, and operating practices contain years of engineering decisions and practical experience. The PLC program holds limits and operating responses established through years of production.
A useful industrial model has to account for the process, the control environment, and the people who know them.
We should be able to examine the source of a measurement, follow its transformations, and compare the resulting information with the actual behavior of the equipment.
That requires maintaining the engineering context as systems change.
ISA-95 remains useful for describing relationships among manufacturing and enterprise systems. Those systems will continue performing the functions they were designed to provide.
Our concern is the amount of work required to keep information correlated as it passes through decades of separate applications and transformations.
It matters most when that information is used to train models, predict physical behavior, and make operational decisions.
MIP and SPA™ provide a parallel approach to observing and connecting these environments. The architecture preserves access to physical measurements and their context while allowing existing applications to continue operating.
You don't have to start with a plant-wide program. Pick one asset and watch it in parallel, read-only, with no write access to the equipment. Keep the raw signal, the engineering values, the timestamps, and the context. Then compare the source measurements with the values your reports present. Where they differ, trace the transformations and assumptions. Where they agree, you have a documented starting point for further analysis.
We want to know what the instrument measured, what happened to that measurement, and whether the information presented to the model still represents the physical process.
Before trusting the intelligence, we need to understand the observation.
Ready to modernize your operations and unlock intelligent automation? Our team is ready to help.