Every industrial AI tool promises better answers from your plant data. Almost none of them tell you what they did to that data before they gave you the answer. In safety-critical industrial environments, that silence is not a minor omission. It is the thing most likely to cause the tool to fail you at the moment you need it most.
Industrial AI · Data Fidelity · Process Safety · Historian Compression · ICS Data Integrity · Sasquatch Labs Industrial Series · July 2026
- The quiet assumption inside every industrial AI answer
- What lossless data fidelity actually means
- How industrial historians already compress data — and why that matters
- What AI summarization adds on top of historian compression
- The two-layer data loss problem nobody is accounting for
- When data fidelity matters most: three industrial scenarios
- What the research says about compression and analytical accuracy
- The safety-critical dimension: why this is different from enterprise AI
- What to ask any industrial AI vendor about data fidelity
- How Valak approaches this
- Frequently asked questions
The Quiet Assumption Inside Every Industrial AI Answer
When a plant manager asks an industrial AI tool “what was the discharge pressure on Compressor 4 between midnight and 6 a.m. last Thursday,” they are making an assumption so fundamental they have probably never articulated it. They are assuming that the answer they receive reflects what actually happened — that the number the AI returns is the number the sensor recorded, at the time it was recorded, without anything having been removed, averaged, smoothed, or approximated in between.
That assumption is not always correct. And in industrial environments — where the answer to that question might inform a maintenance decision, a quality hold, a safety intervention, or a regulatory record — the gap between what the sensor recorded and what the AI reported can carry consequences that a wrong answer in a marketing summary or a business report simply does not.
This article is about that gap. It is about why lossless data fidelity — the principle that an AI query layer should present plant data as it actually exists in the source system, without transformation, summarization, or filtering on the way to the answer — is not a technical nicety or a performance specification. It is a safety and operational integrity requirement that most industrial AI tools are not being evaluated against, and that most industrial organizations are not asking about when they evaluate vendors.
Lossless data fidelity in an industrial AI context means that the AI layer retrieves and presents operational data as it exists in the source system — the historian, OPC UA server, or SCADA database — without applying summarization, compression, averaging, interpolation, or any other transformation that removes or approximates raw data values before delivering an answer. The AI is a faster route to the truth, not a filter that decides what the truth was.
What Lossless Data Fidelity Actually Means
The word “lossless” has a specific technical meaning in data science: a lossless process is one that can be perfectly reversed — no information is destroyed, and the original data can be reconstructed exactly from the compressed or processed version. In contrast, a lossy process involves deliberate discarding of information, on the assumption that what is discarded is unimportant.
In the context of industrial AI query systems, lossless data fidelity means something slightly broader and more operationally specific: the AI layer does not apply any transformation to the data that could remove, approximate, or obscure signal that might be relevant to the question being asked. This includes:
- No statistical summarization — the AI does not average, aggregate, or compress raw data values before presenting them, even when those values are high-frequency time-series data from a process historian.
- No AI-generated smoothing — the AI does not apply its own filtering or noise-reduction logic to the signal before answering, even with the intent of making the answer “cleaner” or easier to interpret.
- No relevance filtering — the AI does not decide in advance that certain data points are “not relevant” to the question and exclude them from the answer without disclosing that exclusion.
- No interpolation substitution — the AI does not fill in gaps in the historical record with interpolated values and present them as if they were actual recorded data points.
- Transparent retrieval scope — when the AI retrieves data to answer a question, it is clear what time window and what sources were queried, so the operator can assess whether the answer is based on complete information.
This standard might sound obvious — of course an AI should tell you what the data actually says. But in practice, the data pipeline between a sensor reading and an AI-generated answer involves multiple layers, each of which can introduce data loss or transformation, and most industrial AI products do not give the operator visibility into what happened at each layer.
How Industrial Historians Already Compress Data — and Why That Matters
To understand the lossless data fidelity problem fully, you need to understand that data loss in the industrial data pipeline does not start with AI. It starts in the historian itself — and it has been there, by design, for decades.
Industrial process historians face a fundamental storage challenge: modern plants generate data at rates that, if stored in raw form, would consume storage at scales that were economically impractical for most of the historian’s history. A single sensor sampling at one-second intervals generates 86,400 data points per day. Multiply that by thousands of tags across a process plant, and the raw storage requirement quickly exceeds what spinning disk infrastructure could practically sustain.
The solution historians have used since the 1980s is data compression — and specifically, a class of algorithms designed to reduce the number of stored data points while preserving the visible shape of the trend. The most widely used of these is the swinging door algorithm, originally patented by EH Bristol in 1990 and since implemented in AVEVA PI, GE Proficy, Emerson DeltaV, and virtually every major industrial historian.
The swinging door algorithm evaluates whether each new data point can be predicted by linearly extrapolating from the previous stored point, within a defined tolerance band. If the new point falls within the predicted corridor, it is not stored — the algorithm continues tracking the trend. When a new point falls outside the predictable corridor, the algorithm commits the previous boundary point to the archive and resets. The result is that only the inflection points of a trend are stored, not every raw sample value. Compression ratios of 80 to 95% for typical process data are achievable, and in some configurations, compression ratios of 1000:1 or better have been documented.
When you retrieve a historical trend from a PI or Proficy historian, what you typically see is a reconstructed trend — the stored inflection points connected by interpolation, presented as a continuous line. For most process engineering purposes, this is entirely adequate. The overall shape of the trend is preserved, and the visual picture of what happened during a shift is accurate enough to support most analytical work.
Compression is not lossless in the engineering sense. Values between archive entries are reconstructed by interpolation when retrieved, not from stored actuals. For applications requiring every raw scan-cycle value — regulatory records with millisecond accuracy requirements, detection of brief transient events, or AI systems where the compressed trend is then further processed — compression deadbands must be set very tight or raw storage mode must be used for specific tags. The swinging door algorithm altered key statistical features of compressed datasets including average value and standard deviation, which in turn affected data-driven analyses performed on the compressed data.
Research published in a peer-reviewed analysis of compression effects on data-driven process analyses found that piecewise linear compression using the swinging door algorithm altered key statistical features of the data set such as the average value and standard deviation, and that other data-driven analyses were also altered. The paper concluded with a procedure for detection of compression during the pre-processing stage of a data-driven analysis. This research is from 2003 — the compression effect on analytical accuracy has been known for over two decades. It has not become less relevant as AI systems have added a second layer of processing on top of already-compressed historian data.
typical compression ratio achieved by swinging door algorithms in industrial historians for most process data
compression ratio achievable in some historian configurations — meaning 999 of every 1000 raw data points may not be stored
how values between stored archive points are reconstructed when retrieved — not from actual recorded data
What AI Summarization Adds on Top of Historian Compression
The historian compression described above is well understood, well documented, and in most cases well managed by industrial organizations that know what their deadband settings are and what the implications are for their specific use cases. It is a known quantity, with known trade-offs, that has been in production use for decades.
What industrial AI query tools add is a second layer of data processing — and this second layer is far less transparent, far less well characterized, and far less likely to be understood by the operators and plant managers who receive AI-generated answers.
Most industrial AI tools that answer natural-language questions about process data operate on a summarize-and-retrieve pattern: they retrieve data from the historian (already compressed), apply their own processing to make it suitable for the AI model’s context window or response generation, and then generate a natural-language answer that summarizes what they found. Each step in this pipeline can introduce additional data loss or transformation.
Context window constraints
Large language models have finite context windows — there is a limit to how much data can be included in a single inference request. When an operator asks about a six-hour trend across multiple tags, the raw compressed historian data may still exceed what can fit in the model’s context. The AI must select what to include and what to leave out. How that selection is made — and whether the selection criteria preserve the data points most relevant to the operator’s actual question — is typically not visible to the operator receiving the answer.
Summarization as a design pattern
Many industrial AI tools are explicitly designed to summarize data before presenting it — to find the relevant information and surface it concisely. In many use cases, this is exactly what users want. In industrial environments where an operator is asking about a brief transient event, an unusual spike, or a short-duration process deviation, summarization may be precisely the mechanism that removes the signal they needed to see.
Hallucination and interpolation risks
Large language models hallucinate primarily because the data used for training or fine-tuning is incomplete, noisy, or poorly contextualized. Missing context leads the model to fill in information, often incorrectly. In industrial AI applications, this risk takes a specific form: when the compressed historian data provided to the AI contains gaps, the AI may fill those gaps with plausible-sounding interpolated values rather than flagging the absence of data. The operator receives an answer that reads as authoritative and is factually incorrect in a way they have no way to detect from the answer itself.
The Two-Layer Data Loss Problem Nobody Is Accounting For
The industrial AI data integrity problem, when articulated precisely, has two distinct layers that compound each other — and that are almost never discussed together in vendor evaluations.
Layer 1 — Historian Compression (Known)
- Swinging door algorithm discards raw data points between inflection points
- 80–95% compression ratios mean most raw sensor readings are not stored
- Retrieved values between archive points are interpolated, not actual
- Statistical properties of compressed data differ from raw data
- Brief transient events shorter than the compression window may not be stored
- Well understood, often managed through deadband configuration
Layer 2 — AI Summarization (Often Unknown)
- Context window limits force selection of what data reaches the AI model
- Summarization logic decides what is “relevant” before the operator sees it
- AI may interpolate or fill gaps without disclosing the substitution
- Answer generation may compress multiple data points into a single statement
- Selection criteria are not visible or auditable by the operator
- Often undocumented, vendor-specific, and not disclosed in product evaluations
The compounding effect matters. A brief process transient — a pressure spike lasting 45 seconds, a temperature excursion that began and resolved within two minutes — may be smoothed out by the swinging door compression at layer one. If it survived layer one, it may then be further summarized away at layer two. An operator who asks “was there anything unusual in the pressure on Line 3 between midnight and 4 a.m.” may receive “no significant deviations were detected” as a perfectly generated, natural-language response to a question whose answer, in the raw sensor data, was “yes, there was a 23% pressure spike at 02:14 that lasted 48 seconds.”
The operator did not know to ask about a specific window. The AI did not know the spike was significant. Both acted in good faith. The signal was lost.
When Data Fidelity Matters Most: Three Industrial Scenarios
The situation: A heat exchanger experienced an unexpected fouling event that reduced throughput by 18% before the overnight team caught it. The day shift engineer is investigating what happened and asks the AI: “Were there any unusual temperatures on Heat Exchanger 7 between 10 p.m. and 2 a.m.?”
With a lossy AI system: The historian compression has smoothed the temperature curve because the deviation developed gradually over four hours and never produced a sharp enough inflection to trigger the swinging door. The AI summarizes the compressed data as showing “normal operating temperature range throughout the window.” The root cause investigation concludes with “no precursor identified in the data.”
With a lossless AI system: The AI queries the raw-resolution historian data for the relevant tags, identifies the 0.4-degree-per-hour temperature drift that began at 22:17 and continued through the night, and surfaces it as a trend deviation that warrants further investigation. The root cause is found, and the maintenance team knows what to look for in future shifts.
The situation: A pharmaceutical manufacturing plant is responding to a FDA data integrity inquiry about a specific batch produced six weeks ago. The quality manager asks the AI to retrieve the process parameter records for the batch window. The response will be used to support the regulatory submission.
With a lossy AI system: The AI retrieves compressed historian data and generates a summary of process parameters across the batch window. The summary shows all parameters within specification. However, a 7-minute temperature excursion during the sterilization cycle — one that the compression algorithm’s deadband settings had partially smoothed — is represented in the AI’s summary as a brief, minor variation within acceptable limits. The raw data, if retrieved with tight compression settings, would show the excursion exceeded the validated range for its actual peak duration.
With a lossless AI system: The AI retrieves the highest-resolution available data for the relevant batch window, presents the temperature trace as it was actually recorded (including the excursion), and flags that the peak values during the 7-minute window should be reviewed against the validated specification range. The quality team can make an informed decision about the regulatory response rather than submitting a record based on a smoothed approximation.
The situation: A maintenance supervisor asks the AI: “Has the vibration on Pump 12 been trending higher in the last 30 days, and does the pattern look like what we saw before the bearing failure in March?”
With a lossy AI system: The AI retrieves compressed vibration trend data for the 30-day window, compares it to a summary of the March pre-failure period, and reports that “vibration levels are within normal range with no significant trend detected.” The compression algorithm had eliminated the high-frequency vibration micro-events that were the actual precursor signature — they were brief, repeated spikes that the swinging door treated as noise rather than signal.
With a lossless AI system: The AI queries the raw-resolution vibration data, identifies the pattern of brief, repeated spikes occurring at increasing frequency over the 30-day window, compares their signature to the documented pre-failure pattern from March, and flags a probable match that warrants maintenance inspection before the next scheduled run. The bearing is replaced during a planned maintenance window rather than failing during production.
What the Research Says About Compression and Analytical Accuracy
The concern about data compression effects on industrial analytics is not a theoretical argument. It has been the subject of peer-reviewed research for over two decades, and the findings are consistent enough to constitute an established body of knowledge — one that the industrial AI industry has not yet fully integrated into how it describes or evaluates its products.
Thornhill et al. published a peer-reviewed analysis examining how swinging door compression affects data-driven process analyses. Their findings: piecewise linear compression altered key statistical features of compressed datasets including average value and standard deviation. Other data-driven analyses were also affected. The paper concluded that compression detection should be a pre-processing step for any data-driven analysis performed on historian data.
A 2025 paper examining the impact of data compression in real-time and historical data acquisition systems on the accuracy of analytical solutions found that common compression mechanisms used in data historians compromise the accuracy and reliability of engineering analytics that depend on the compressed data. The paper frames this as an essential trade-off to understand for organizations developing data strategies that support both operational efficiency and accurate, reliable analytics.
A structured qualitative synthesis of literature on AI applications in process safety found that practitioners and researchers still have limited consolidated guidance on the conditions under which AI methods may be considered credible for use in safety-critical industrial environments, with particular gaps around validation depth, uncertainty communication, lifecycle governance, and human oversight. The review identifies data governance — including data quality and provenance — as one of the key dimensions that AI safety applications must address.
The research consensus is clear: data compression affects the accuracy of analyses performed on compressed data, the effect is measurable and documented, and the implication for AI systems that operate on compressed historian data is that they inherit those accuracy limitations unless they specifically account for and disclose them. An industrial AI product that does not address compression effects in its data retrieval architecture is operating on a foundation with a known and documented accuracy limitation.
The Safety-Critical Dimension: Why This Is Different from Enterprise AI
The data fidelity problem exists in enterprise AI too — summarization affects accuracy in legal document review, medical record analysis, and financial reporting just as it does in industrial process data. But the consequences of a summarization error in an industrial safety context are categorically different from those in most enterprise applications.
The “deploy first, govern later” pattern is particularly dangerous in critical infrastructure, where unvalidated automation decisions can directly affect safety, uptime, and process integrity. This observation from the SANS Institute’s 2026 report is precisely the dynamic that makes data fidelity a safety requirement rather than just an accuracy preference in industrial AI.
When an operator makes a decision about whether to intervene in a process based on an AI answer, they are making that decision in a context where being wrong has physical consequences. A pump that should have been flagged for inspection but was not because the AI’s summarization layer smoothed away the precursor vibration signature does not fail in a way that produces a spreadsheet error. It fails in a way that may produce a production shutdown, an equipment replacement, or in a severe case, a process safety event.
A peer-reviewed synthesis published in May 2026 examining AI-enabled process safety across chemical, energy, and manufacturing industries identified that AI has emerged as a promising avenue for safety support, but that practitioners still have limited consolidated guidance on the conditions under which AI methods may be considered credible for use in safety-critical industrial environments. The review specifically identifies uncertainty communication and data governance as key gaps that must be addressed before AI systems can be considered credible for safety-relevant decision support.
Lossless data fidelity is a direct response to that gap. An AI system that presents data as it actually exists in the source system — without transformation, without smoothing, without relevance filtering — provides the operator with the raw material for a safety-relevant decision, not a pre-processed approximation that has already made judgments the operator cannot see or audit.
What to Ask Any Industrial AI Vendor About Data Fidelity
Most industrial AI vendor evaluations focus on capability questions: what systems does it connect to, what queries can it answer, how fast does it respond, what is the deployment model. Data fidelity is rarely on the evaluation checklist, because buyers do not know to ask about it and vendors do not volunteer to discuss it.
Here are the specific questions that every industrial AI evaluation should include:
- “What data does the AI retrieve from the historian, and at what resolution?” Does it retrieve raw scan-cycle data, or does it rely on compressed historian retrieval that returns interpolated values between archive points? What is the effective time resolution of the data the AI is working from?
- “Does the AI apply any processing to historian data before generating an answer?” If yes: what processing, and does that processing discard or approximate any data points? Is the processing disclosed to the operator in the answer?
- “How does the system handle brief transient events that may have been smoothed by historian compression?” Can the AI retrieve high-resolution data for specific tags when the question requires it, or is it limited to what the standard historian compression settings have stored?
- “What happens when the data the operator is asking about exceeds the AI model’s context window?” How does the system select what to include and what to leave out? Is the selection disclosed to the operator?
- “Can the system distinguish between an actual recorded value and an interpolated value?” Does it surface that distinction to the operator, or does it present both types of values identically?
- “Has the system been validated against raw sensor data for accuracy in brief transient detection?” What benchmark testing has been done, against what data, and is that documentation available?
A vendor who cannot answer these questions clearly is not necessarily producing a bad product — they may simply not have thought about the data fidelity dimension of their architecture in these terms. But that absence of thought is itself an answer: it means the product was not designed with safety-critical industrial data fidelity as a first-order design requirement.
How Valak Approaches This
Valak, built by Sasquatch Labs, was designed around lossless data fidelity as an explicit architectural principle, not a secondary feature. The principle is simple in statement and consequential in implementation: the AI query layer presents data as it exists in the source system. It does not apply its own summarization, smoothing, or relevance filtering to the historical record before delivering an answer.
In practice this means Valak queries the historian directly — via OPC UA or native historian interfaces for AVEVA PI and GE Proficy — and retrieves data at the resolution the historian has stored, rather than working from a pre-summarized or cloud-replicated version of the data. When the historian has compressed data using swinging door algorithms, Valak works from what the historian has stored, not from a further-processed derivative. When high-resolution retrieval is possible for specific tags or time windows, Valak queries at that resolution.
Equally important: Valak does not apply a secondary AI summarization pass that could remove signal between the historian and the operator’s answer. The agentic reasoning layer determines what data to retrieve and assembles the answer — but it does not apply the kind of summary-generation logic that would smooth, filter, or compress the process signal itself.
This architectural choice has a cost: it requires that the inference layer handle higher-resolution data than a summarization-first system would need to process. It also means that answers are grounded in the actual operational record rather than in an AI-generated interpretation of that record — which is precisely the property required for safety-relevant operational decisions.
- What Is Valak.ai? The Agentic AI Layer for HMI and SCADA
- What Is Agentic AI for Industrial Control Systems? A Complete Guide
- OT Cybersecurity in 2026: Why Air-Gapped AI Is Non-Negotiable
- From Alarm Fatigue to Answers: How Conversational AI Is Changing Plant Operations
- The OPC UA Moment: How the April 2026 Standards Announcement Changes Industrial AI Forever
Frequently Asked Questions: Lossless Data Fidelity in Industrial AI
1. What is lossless data fidelity in industrial AI?
Lossless data fidelity in an industrial AI context means the AI query layer retrieves and presents operational data as it exists in the source system — the historian, OPC UA server, or SCADA database — without applying summarization, compression, averaging, interpolation, or any other transformation that removes or approximates raw data values before delivering an answer. The AI is a faster route to the actual operational record, not a filter that decides what the truth was before the operator sees it.
2. What is the swinging door algorithm and how does it affect industrial AI accuracy?
The swinging door algorithm is the dominant data compression method used in industrial process historians — including AVEVA PI, GE Proficy, and most other major historian platforms. It evaluates whether each new sensor reading can be predicted by linearly extrapolating from the previous stored point within a tolerance band. If yes, the point is not stored. When a reading falls outside the predicted corridor, the previous boundary point is committed to the archive and the algorithm resets. Compression ratios of 80 to 95% for typical process data are common. Peer-reviewed research published in ScienceDirect found that swinging door compression alters key statistical features of compressed datasets including average value and standard deviation, affecting data-driven analyses performed on that data. Industrial AI systems that retrieve compressed historian data inherit these accuracy limitations unless they specifically address them.
3. Why does AI summarization create a second data loss layer on top of historian compression?
Most industrial AI tools that answer natural-language questions operate on a summarize-and-retrieve pattern: they retrieve historian data (already compressed by the swinging door algorithm), apply their own processing to fit the data within the AI model’s context window, and then generate a natural-language answer that summarizes what they found. Each step can introduce additional data loss. The context window constraint forces selection of what data to include. Summarization logic decides what is “relevant” before the operator sees it. AI may fill gaps with plausible interpolated values without disclosing the substitution. The result is a two-layer data loss pipeline where brief transients, short-duration deviations, and statistical anomalies are at risk of being eliminated before the answer reaches the operator.
4. Can industrial AI systems detect brief transient events in process data?
It depends entirely on the system’s data retrieval architecture. A system that queries compressed historian data using standard retrieval settings may receive interpolated trend data that has already smoothed away brief transients — events shorter than the compression window that the swinging door algorithm treated as not worth storing. A system designed for lossless retrieval queries at the highest resolution available for the specific tags and time windows of interest, giving it the best available chance of detecting events that standard compression would have discarded. Whether any given industrial AI system can detect brief transients is therefore a question about its historian query implementation, not just its AI capability, and it is one of the first questions that should be asked in any vendor evaluation for safety-relevant applications.
5. How does data summarization create safety risk in industrial AI?
When an operator makes a process decision based on an AI answer — whether to intervene, escalate, or monitor — they are relying on that answer to reflect what actually happened in the plant. If the AI’s answer was generated from summarized or filtered data that smoothed away the specific signal relevant to the decision, the operator is making a safety-relevant decision based on incomplete or incorrect information without knowing it. Unlike in enterprise applications where a summarization error might produce a misleading report, in industrial environments it might mean a bearing failure is not caught before the pump trips, a regulatory record does not reflect the actual process deviation, or a process safety precursor is missed because the AI compressed it out of the answer. The consequences are physical, not just informational.
6. Does historian compression mean industrial AI answers are always inaccurate?
No. For most operational questions — trend analysis over longer time windows, general equipment performance assessment, alarm history review, shift-level production statistics — compressed historian data is entirely adequate and the compression effect is negligible. The accuracy risk is specific to use cases involving brief transient events, precise statistical analyses where the mean or standard deviation of the compressed data is meaningfully different from the raw data, regulatory compliance records where the exact peak and duration of a deviation matters, and predictive maintenance applications where the precursor signature consists of brief, repeated high-frequency events. Organizations should understand their historian compression settings and their AI system’s retrieval architecture to know which use cases may be affected.
7. What is the difference between a lossless historian and a lossless AI query layer?
A lossless historian stores all raw sensor data without applying compression algorithms — every scan-cycle reading is preserved exactly as the sensor reported it. Canary Historian is an example of a historian specifically designed for lossless raw data storage. A lossless AI query layer, by contrast, refers to an AI system that retrieves and presents data from whatever historian it is connected to — lossless or compressed — without adding its own additional layer of summarization, filtering, or approximation on top of what the historian has already stored. Both concepts address data integrity at different points in the pipeline. The ideal combination for maximum fidelity is a lossless historian feeding a lossless AI query layer, but a lossless AI query layer on top of a compressed historian is still a meaningful improvement over a summarizing AI layer on top of a compressed historian.
8. How should organizations evaluate industrial AI vendors on data fidelity?
The key questions to ask are: what data resolution does the AI retrieve from the historian; does the AI apply any processing to historian data before generating an answer and if so does it disclose that processing; how does it handle brief transient events that may have been smoothed by historian compression; what happens when the data exceeds the AI model’s context window; can it distinguish between actual recorded values and interpolated values; and has it been validated for accuracy in brief transient detection against raw sensor data. A vendor who cannot answer these questions clearly has not designed their product with safety-critical industrial data fidelity as a first-order requirement.
9. Why do most industrial AI products not discuss data fidelity in their marketing?
Several reasons. First, the data fidelity problem is not immediately visible — systems that summarize data generate answers that look authoritative and are often accurate enough for the majority of use cases. Second, discussing compression and summarization effects requires technical honesty about limitations that vendors prefer not to highlight in competitive evaluations. Third, the buyers evaluating industrial AI products — even technically sophisticated ones — often do not know to ask about data fidelity specifically, because it is not part of the standard industrial AI evaluation checklist. The result is that a significant architectural difference between systems — one that has direct safety implications — is systematically excluded from the product evaluations that should be surfacing it.
10. Is lossless data fidelity required for regulatory compliance in industrial AI?
The regulatory landscape around industrial AI data fidelity is still developing, but several existing frameworks point toward data integrity requirements that have direct implications for AI systems. FDA 21 CFR Part 11 for pharmaceutical manufacturing requires complete, accurate, and attributable electronic records — an AI system that presents summarized or interpolated data as the official process record may not meet this requirement. ISA-18.2 for alarm management implies that alarm history used for analysis should reflect actual alarm events, not smoothed approximations. The NIS2 Directive’s process integrity requirements for critical infrastructure organizations raise questions about AI systems whose answers are based on processed approximations of operational data rather than the actual record. Organizations in regulated industries should evaluate their AI systems’ data fidelity posture against the specific record-keeping requirements of their regulatory framework.
Industrial AI That Tells You What the Data Actually Says
Valak queries your OPC UA, AVEVA PI, and GE Proficy systems directly — no secondary summarization layer, no cloud processing, no data leaving your plant. The answer you get reflects the record your historian actually contains.