"Just point an LLM at the historian" doesn't survive contact with real fleet data. One heat pump and one week of readings can already exceed the largest context window by 5-30x.

"Just point an LLM at the historian" doesn't survive contact with real fleet data

An Industrial Data/Analytics Lead hears the pitch every quarter: connect your historian to an LLM, ask it questions in plain English, get predictive maintenance out the other end.

Then someone tries it on one asset. Not a fleet. One heat pump. One week of raw time-series data.

That single asset, single week of readings is 5-30x larger than the largest context window on the market today. Multiply that by a fleet of hundreds of pumps, compressors, or heat pumps running continuously, and the math stops being theoretical. It's a wall.

This is the part generic AI predictive maintenance demos skip. They show a clean chart and a chatbot answer. They don't show what happens when you try to re-ingest billions of raw points into a model that was built to read documents, not reason across a fleet's operating history.

Where the naive approach breaks, step by step

The failure mode is consistent across teams that try to bolt a generic LLM onto industrial time-series data. It shows up as a loop that never closes:

Someone asks a real operational question. Something like "why did pump B7 trip last Tuesday."
The data team tries to hand the model everything. Raw sensor tags, months of history, maintenance logs, all pushed into the context window at once.
The context window overflows. Not by a little. By 5 to 30 times, for a single asset over a single week.
The team downsamples or truncates to make it fit. This is where accuracy quietly erodes, because the patterns that matter, a slow drift, a rare fault signature, often live in the exact data that got cut.
Latency and token costs climb. Every re-ingestion of raw data into the model burns tokens on data the model doesn't need to reason well; it needs the result of reasoning over that data.
The answer arrives late, or not at all. The question that started as "why did pump B7 trip" turns into the kind of 11-day email chain across three teams that a data platform was supposed to eliminate.

The root cause isn't the model's intelligence. It's the architecture. Sending billions of raw points to the model, instead of sending the model's questions to the data, is backwards for industrial scale.

Compute-down: send the math to the data, not the data to the model

Spocky's agents don't re-ingest raw time-series into a context window. They send the computation down to where the data already lives, and bring back only what the operator's question actually needs.

That single design decision is what keeps answers deterministic and explainable instead of a guess dressed up as an answer. A model that has to sample, truncate, or summarize billions of points before it can respond isn't reasoning across your fleet's history; it's reasoning across whatever fraction fit.

Compute-down changes what's possible:

Token use and latency drop by up to 90%, because the agent isn't shipping raw data back and forth to reason about it.
The full operating history stays in scope, instead of the slice that happened to survive downsampling.
Answers come back in seconds, not after a batch job or a context-window workaround.

This is also why the industry keeps circling back to why re-ingesting time-series data into an LLM fails at industrial scale as a pattern, not a one-off engineering mistake. The pattern repeats because the underlying math, asset count × sensor count × sampling rate × history length, always outruns context window growth.

Why this matters more as fleets get bigger, not less

A pilot on one asset can survive brute-force re-ingestion, at a cost. A fleet cannot.

The pain compounds:

95% of raw industrial data remains untapped, because only the data team knows how to query it. Every operational question routes through the same bottleneck.
Work orders, machine data, quality findings, and technician know-how live in separate systems, so nobody can trace one thread from a work order through to a maintenance fix without manual reconciliation.
Fleet-wide problems stay invisible until a customer or tenant finds them first.

None of this gets fixed by making the LLM's context window bigger. It gets fixed by changing where the computation happens. That's the difference between a chatbot wrapped around a historian and an industrial data historian paired with a natural-language query agent built for the scale of continuous sensor data.

Predictive maintenance is the destination, not the starting move

It's worth being direct about something the AI predictive maintenance pitch usually glosses over: prediction is the last step in a loop, not the first.

Before a pattern can be trusted enough to predict on, it has to be found, validated, and watched hold up across repeated cases. Teams that skip straight to "predict the failure" without first exploring the data, confirming the pattern, and validating what interventions actually worked tend to stall before they ever reach a working model. That's a large part of why predictive maintenance pilots stall before they ever reach prediction.

The practical order looks like this:

Explore: investigate raw history to find and confirm a real pattern.
Automate: turn the validated pattern into a recurring report or alert.
Act, with a person signing off: supervised actions on the fleet, never automatic action without a human decision step.
Document: capture what happened and what the fix was.
Predict: only once the earlier steps have produced enough validated cases to predict on with confidence.

Compute-down architecture is what makes step 1 possible at fleet scale in the first place. If exploring raw history requires overflowing a context window every time, teams never get far enough to validate a pattern worth predicting on. It's also why the difference between predictive maintenance and preventive maintenance matters more than the buzzword suggests: one is scheduled guesswork, the other requires evidence.

What to check before you evaluate any "AI predictive maintenance" tool

For an Industrial Data/Analytics Lead sitting through vendor demos, a few direct questions cut through the marketing fast:

Where does the computation happen: in the model's context window, or at the data layer? If the answer involves shipping raw time-series into a prompt, ask what happens past one asset, one week.
What happens to fidelity when data volume grows? Downsampling to fit a context window means the model is reasoning on a partial picture, not deterministic ground truth.
Is there a human decision step before any action touches the fleet? Supervised action, not autonomous action, should be the default answer.
Can it answer a question nobody anticipated? Dashboards and pre-trained models answer the questions they were built for. Raw-data agents answer the ones asked at 2 a.m. after a trip.

These aren't abstract concerns. They're the same questions that separate a predictive maintenance system that finds out why something happened from one that only tells you what happened.

FAQ

Will AI replace maintenance teams?

No. Spocky is built on the opposite premise: AI expands what an operator or technician can handle, more assets, more investigations, faster answers, without removing the person who signs off on any action taken on the fleet. Agents surface answers and support supervised action; they don't act on their own.

Is ChatGPT predictive AI or generative AI?

ChatGPT and similar general-purpose LLMs are generative AI, built to generate text from patterns in training data. Industrial predictive maintenance requires a different architecture: one that reasons deterministically over raw time-series history at the scale of a fleet, not one that generates a plausible-sounding response from a sampled slice of data.

Why can't I just feed my historian data into an LLM for predictive maintenance?

Volume. One heat pump over one week of raw time-series data is 5-30x larger than the largest context window on the market. Re-ingesting billions of points into a model burns tokens, adds latency, and forces downsampling that can hide the exact pattern you're trying to find. Compute-down architecture avoids this by sending computation to the data instead of data to the model.

What are real examples of predictive maintenance done right?

The pattern that works starts with exploration on raw, unsampled history to validate a real fault pattern, then moves to automated alerts, supervised action with a human sign-off, documentation, and only then prediction. Skipping straight to a predictive model without validated patterns is a common reason pilots stall.

AI Predictive Maintenance: Why Feeding Raw Time-Series Data to an LLM Doesn't Work