Manufacturing AI — What Factory Data Demands of Models
The difficulty of manufacturing AI lies not in the model, but in the nature of the data. Factory signals have almost no labels, their distributions change with operating conditions, and a missing value means something different from a zero value. The cost of a wrong answer is also asymmetric—a single missed failure and a hundred false alarms damage a factory in different ways.
This article starts with these characteristics and explains the resulting design choices. The examples come from the actual implementation of PlantPulse AI, but the principles apply to manufacturing AI in general, regardless of product.
Data scientists, equipment engineers, and technical personnel evaluating AI adoption. Terms such as time series, embedding, and RAG are used without explanation. For a list of product features, see AI Features; for the model itself, see the AURA Technical White Paper.
1. What Makes Factory Signals Different
Most assumptions in standard machine learning textbooks—independent and identically distributed data, abundant labels, and straightforward handling of missing values—break down in factories.
| Characteristic | What it means | Design impact |
|---|---|---|
| There are no labels | Failures are rare, and even when they occur, their causes are recorded even less often | Instead of supervised classifiers, the default approach is to learn normal behavior and measure deviations from it using reconstruction or prediction error |
| Operating conditions change | The shape of “normal” varies with load, product, season, and shift | Fixed thresholds flood the system with false alarms as soon as conditions change. Difficult normal conditions, such as high-load periods that resemble anomalies, must be handled separately |
| Zero and “unknown” are different | “0 work orders” is a measurement; “CMMS connection lost” is not | The moment missing values are filled with zero, equipment that nobody observed is reported as “normal” |
| Signals belong to a hierarchy | Each tag belongs under equipment, a line, an area, and a site | Converting a phrase such as “Line 3 compressor” into a node in the hierarchy becomes the first step of every query |
| The cause is in the sequence | The same two signals can indicate different failures depending on which rises first | Models that consider only correlation cannot distinguish failures. They must account for lead and lag relationships |
| The cost of wrong answers is asymmetric | Missed detections cost equipment; false alarms cost human trust | Count false alarms separately from missed detections, and provide operators with a way to silence alarms |
The last row is often underestimated. An anomaly detection system that accumulates false alarms is eventually turned off by operators. A detector that has been turned off detects nothing—even a model with 99% accuracy becomes 0% effective when disabled.
2. Separate the Layers—Do Not Solve Everything with One Large Model
Designing manufacturing AI as “showing sensor data to a large language model” causes three problems at once. Second-by-second waveforms are too long to represent as tokens, language models are not particularly good at detecting anomalies in numerical patterns, and most importantly, they plausibly invent values that were never measured.
The work must therefore be divided by its nature.
질문 「3라인 압축기 요즘 어때?」
│
┌──────────────────────────────▼──────────────────────────────┐
│ ④ 설명 — 언어모델 │
│ 도구를 골라 부르고, 결과와 문서를 읽고, 근거와 함께 답한다 │
└───────┬──────────────────────┬──────────────────────┬───────┘
│ 도구 호출 │ 도구 호출 │ 검색
┌───────▼────────┐ ┌────────▼────────┐ ┌────────▼────────┐
│ ③ 시계열 모델 │ │ ② 통계 · 규칙 │ │ 문서 검색 (RAG) │
│ 이상 · 예측 │ │ 기준선 편차 · 공식 │ │ 절차서 · 이력 │
└───────┬────────┘ └────────┬────────┘ └─────────────────┘
└──────────┬───────────┘
┌───────▼────────┐
│ ① 데이터 원장 │ 시계열 · 알람 · 작업지시 · 설비 계층
└────────────────┘
| Layer | What it does well | What it should not handle |
|---|---|---|
| ② Statistics and rules | Deviations from the equipment's normal baseline, engineering formulas such as OEE, MTBF, and bearing defect frequencies | Multivariate patterns |
| ③ Time series model | Anomalies in the overall “shape” formed by multiple channels, short-horizon trends | Root-cause explanations, document comparison |
| ④ Language model | Tool selection, result synthesis, comparison with procedures, explanations in human language | Generating numbers |
Anything that can be solved at a lower layer is not passed to a higher one. In actual cases, deviations from a baseline alone were enough to identify anomalous periods; those cases do not need a model. Formulas perform the calculations, and the language model reads and explains the results. The moment the language model “estimates” L10 life, the answer can no longer be verified.
3. Anomaly Detection—Learn Normal Behavior and Measure Deviations
Without labels, a “failure classifier” cannot be trained. Instead, use a model that reconstructs normal signals and treat the reconstruction error as the anomaly score. PlantPulse uses IBM Granite TSPulse.
Use Two Types of Error Together
| Score mode | What it measures | What it detects |
|---|---|---|
| Time-domain reconstruction | Difference between the original and reconstructed signals | Abrupt changes, spikes, and level shifts |
| Frequency-domain reconstruction | Difference between spectra | Changes in vibration patterns—cases where the mean remains unchanged but the “vibration” changes |
Early-stage rotating equipment faults often appear first in the frequency domain. The amplitude may still look normal while a specific frequency band begins to grow. Time-domain analysis alone misses this.
Some time series libraries pass validation if they support any one of the listed modes, then discard unsupported modes without an exception or warning. A system can run with a configuration that says “level deviation scoring enabled” while calculating nothing—this was confirmed through direct measurement (2026-09).
PlantPulse queries the library for each mode individually and rejects loading if even one configured mode will not be calculated by the model. Because each model supports a different set of modes—reconstruction and prediction models do not overlap—the same configuration can mean something different after changing the model.
Context Length and Short Histories
TSPulse takes a 512-step window as input. Newly connected equipment or equipment with a short history may not have enough data to fill the window. There are two options:
- Reject it—the new equipment receives no assessment for a while
- Pad on the left—repeat the oldest value until the window is full (edge padding)
PlantPulse chooses the second option when there are at least 32 rows and rejects the request otherwise. Padding produces an assessment, but the evidence is thinner in proportion to the amount of padding. Do not assign the anomaly score of equipment with a short history the same weight as that of equipment with a long history.
A Way to Silence Alarms Matters More Than the Threshold
No matter how well thresholds are selected, the field will still contain conditions that occur frequently but are not problems. The solution is not to tighten thresholds further, but to let operators silence them.
- Surface frequently occurring items with their count and most recent occurrence, then suggest “raise threshold / review mute” or “observe”
- Muting stops only notifications and incident escalation—the detection records remain. The evidence needed for later review must not disappear
- An acknowledgment can be made only once. The first person to acknowledge it and the time are retained
The interface is documented in TimeSeries-Insight.
4. Forecasting—Without an Interval, It Is Not a Forecast
Trend forecasting uses TinyTimeMixer(TTM). It has a 512-step context and forecasts up to 96 steps at a time. Because the model was trained for that horizon, requests beyond it are rejected rather than silently truncated. If the history contains fewer than 512 steps, the model runs with the available context and includes the reduced context length in the response.
Intervals Instead of Point Forecasts
“Next week's bearing temperature will be 78°C” is not very useful. Operators need: “The 10–90% quantile interval is 72–84°C, and the upper bound reaches the alarm threshold” (the default quantiles are 0.1 and 0.9). PlantPulse applies conformal calibration after prediction to produce the interval.
- Slide a window across historical data and generate the predictions that would have been made at each point
- Collect the residuals between those predictions and the values that actually occurred
- Use residual quantiles to determine the upper and lower bounds of the current forecast
Rather than asking the model to describe its own uncertainty, this method determines the interval from how wrong this model has actually been on this equipment. Because it makes no distributional assumptions, it is well suited to heavy-tailed data such as industrial signals.
Suppose a pressure tag averages 1500 kPa and a missing value is filled with zero. The residual for that window becomes |1500 − 0|. The quantile is then determined by the magnitude of the missing value, not the prediction error, producing an absurdly wide interval—while the system still displays “interval calculation succeeded.”
PlantPulse excludes windows containing missing values and trailing windows for which actual measurements are not yet available from the calibration set. If the remaining windows do not meet the required count, it does not produce an interval and states the reason in the response (“send more history”). No interval is better than a wrong interval.
5. Silent Failures—The Most Expensive Bugs in Manufacturing AI
Manufacturing AI incidents usually occur where no error is raised. The service returns 200, the health check is green, and the numbers look plausible. But those numbers were not produced by the model.
These are three forms encountered in practice.
| Form | What happened | How to prevent it |
|---|---|---|
| Fallback masquerades as the model | When there is not enough data to run the model, the system falls back to simple extrapolation (drift or seasonal-naive). The response is still 200 | Include model_used and fallback_reason in the response. The caller must read and record them—an increase in the NAIVE ratio is itself a signal |
| Random weights carry the model's name | Two generations of the forecasting model, R2 and R3, have no weight keys in common, yet each can load the other's checkpoint without an exception. The result is a model with all 445 parameters randomly initialized responding under the TTM name | During loading, reject the model if even one parameter is newly initialized because it was absent from the checkpoint |
| Configuration errors are absorbed as transient failures | The configuration error above was absorbed by fallback, leaving the system running as “healthy health check, forecast 200, every answer generated by simple extrapolation” | Divide failures into two categories. Return 500 or 503 for conditions that retries cannot resolve, such as configuration errors or GPU failure, and use fallback only for transient conditions, such as insufficient data |
The general rule is simple: every output must identify what produced it. State whether it came from the model or a fallback, whether the interval was calculated or skipped, and how many rows were used for the assessment. Without this information, nobody can verify whether the AI in production is actually AI.
Even when the forecasting configuration is wrong, the same process continues to provide anomaly detection, so /health remains healthy. A health check cannot also guarantee that “the answer is correct.” Therefore, write the model-loading result as a single startup log line ([MODEL_LOAD] · [MODEL_LOAD_FAIL] · [MODEL_WARMUP_FAIL]) and monitor that line.
6. The Cause Is in the Sequence—Failure Mechanisms
“There was a temperature increase” can have many causes: bearing wear, insufficient lubrication, cooling failure, electrical faults, or fouling. These are distinguished not by the magnitude of the values, but by what moved first and what moved together.
| Failure | Leading signal | Subsequent signal |
|---|---|---|
| Bearing wear | Increase in vibration | Temperature follows · defect-frequency harmonics |
| Insufficient lubrication | Decrease in lubricant flow | Rapid temperature increase from frictional heat |
| Cooling failure | Decrease in coolant flow | Only temperature rises; vibration remains normal |
| Electrical fault | Current imbalance | Power consumption and temperature rise together |
| Cavitation | Sudden increase in broadband noise | Reduced discharge → lower power consumption |
The interpretation rules are as follows. If vibration rises at the same time, the cause is likely mechanical. If only temperature rises, cooling or fouling is more likely. If lubricant flow fell first, the rapid temperature increase is a result, not a cause. And while every other mode increases power consumption, only cavitation reduces it, which distinguishes it from the others. The complete map—11 failure types × 18 equipment types—is available in Chapters 5 and 6 of the AURA Technical White Paper.
The key point is that simultaneous correlation alone cannot distinguish these cases—correlation is symmetric, while failures are asymmetric. Two approaches are therefore used together.
- Lagged cross-correlation. For tag pairs with high simultaneous correlation, tag relationship analysis shifts the time lag backward and forward, up to ±10 samples, to find the lag with the highest correlation. If it is not zero, the result is reported as a lead-lag pair
- Teach the structure of the mechanism. Instead of training the model on “symptom → answer” pairs, show it trajectories over time. Along with the assessment, require an evidence statement containing values and timing, such as “Temperature rose first at D+11, followed by vibration at D+19—thermal cause preceded the mechanical response.” The evidence must be verifiable by a person
If the entire table is converted to numbers before selecting the columns to analyze, timestamps become nanosecond integers and are mixed in as if they were tags. Because they increase monotonically, their correlation with almost anything approaches 1, and statements such as “timestamp leads temperature” can enter the diagnosis (2026-07). Remove time and identifier columns first, and also remove columns with no variation—their correlation coefficients are undefined.
Historical cases are used for the same purpose: determining whether an anomaly with the same shape occurred before (similar anomaly search), whether one unit behaves differently from other equipment of the same type (fleet outlier), and whether signals previously observed before a failure are appearing now (precursor inspection). All three methods use “this equipment's past” and “neighboring equipment's present” as baselines.
7. Explanation—Answer Only from Evidence
The language model's role is to read, select, and explain. A query flows roughly as follows.
① 이름을 ID 로 「3라인 압축기」 → 설비 계층의 노드
② 도구를 고른다 분석 · 이력 · 알람 · 문서 · 사진 중 무엇이 필요한가
③ 데이터를 가져온다 이상 점수 · 건강 지수 · 태그 이력
④ 문서를 더 본다 절차서 · 고장 이력 · 규격
⑤ 모아서 답한다 근거를 붙여서
Steps ②–④ do not finish in a single pass. The agent repeatedly reviews tool results and selects the next tool. Three factors determine quality in this structure.
① Tool schema. Answer quality directly depends on whether the model selects the correct tool and fills in its arguments correctly. Tools are disabled by default, and only enabled tools are visible to the agent. The more irrelevant tools are available, the lower the selection accuracy. Direct measurement also showed that models call tools less often as prompts become longer—adding more explanation is not always beneficial.
② Search quality sets the ceiling for answer quality. Industrial documents contain both strings that must match exactly, such as tag names, part numbers, and specification clauses, and semantically equivalent expressions such as “replacement cycle” and “maintenance interval.” Keyword search (BM25) and semantic search (embeddings) are therefore used together, and a reranker selects the passages that actually answer the question from the candidates. Embedding dimensions are fixed as a contract so that replacing the model does not require rebuilding the vector index. The pipeline is documented in RAG Algorithms.
③ Say when you do not know. Do not report uncollected values as “normal,” and do not state anything absent from the context. This cannot be achieved with a single prompt instruction—the training data must include questions where abstaining is the correct answer so that the model learns to respond that way. This is why one-third of the AURA training data consists of non-conclusive answers.
8. How to Evaluate—Without a Judge Model
Industrial AI has no leaderboard. And when another language model is used for grading, plausible but incorrect answers receive high scores. Evaluation must therefore be mechanized.
| What to evaluate | What to compare against | What to watch for |
|---|---|---|
| Industrial calculations | Formulas across 30 families of engineering equations | Exclude some families entirely from training to distinguish memorization from actual capability |
| Tool calls | The actual schema of the running system | Evaluate tool selection, arguments, and multi-step chaining separately |
| Grounding | The provided context | Any fact not present in the context is incorrect |
| Field diagnosis | Actual measurements and recorded failures | The only dimension where the answer comes from outside the system. Include difficult normal conditions, and count false alarms separately from missed detections |
Two additional principles apply.
- Set gate criteria “before” measurement. Criteria chosen after seeing the results are not criteria
- Reviewers must be able to verify for themselves that evaluation data did not leak into training. Instead of asking them to trust a number, provide a way to measure it again
9. Where to Run It—Why On-Premises Is the Default
Manufacturing data usually cannot leave the factory. Process conditions themselves are trade secrets, and many facilities operate on air-gapped networks. This leads to the following design.
- Bring the model to the data. The language model runs on a single GPU as a quantized checkpoint (NVFP4), behind an OpenAI-compatible endpoint. Even if the configuration says
gpt-4o, it is a compatibility name for the internal model - Use small models for waveforms. Time series models with around one million parameters run without a GPU, so they can be deployed at the edge. Adapting one separately for each equipment unit costs very little—10,000 models for 10,000 units is feasible at this scale (under research and not yet included in the product path)
- Separate inference from the gateway. Keeping a lightweight API separate from the GPU-based inference server allows inference to be moved to other hardware or scaled out without changing the address used by callers
- AI does not create its own database. Time series, relational data, and caches share the Platform's system of record. If two copies of the data exist, “the value seen by AI” and “the value shown on the screen” diverge
The deployment structure is described in AI Architecture, and how the four products work together is described in Overall Architecture.
What to Check Before Adoption
When evaluating manufacturing AI, these questions are worth asking regardless of the product.
| Question | What a good answer looks like |
|---|---|
| How are missing values handled? | They are not filled with zero. “Not measured” is reported separately |
| What is returned if the model cannot run? | Use fallback, but state in the response that fallback was used |
| How are false alarms counted? | Count them separately from missed detections. Operators can silence them, and the records remain even when silenced |
| Do forecasts include intervals? | Yes, and the intervals come from residuals against actual measurements |
| Does the language model generate numbers? | No. Formulas and tools produce the numbers; the language model reads them |
| How were the performance figures measured? | Without a judge model, with criteria defined first, and in a way that reviewers can reproduce |
| Does data leave the site? | No. The same configuration runs on an air-gapped network |
See Also
AURA Technical White Paper — How the model is built and evaluated · TimeSeries-Insight — Interfaces and tools for anomaly detection and forecasting · RAG Algorithms — Document search pipeline · Data Lake Technical White Paper — Data infrastructure supporting the model · Download Resources