One heat pump, one week of raw time-series data, is 5-30x larger than the biggest LLM context window on the market. Here's what that means for any team trying to bolt conversational AI onto a fleet, and what a compute-down architecture does instead.

"Just point the LLM at the historian"

That's the pitch a lot of teams hear. Wire up the historian, pipe the raw tags into a large language model, ask questions in plain English, done.

It doesn't survive contact with a real fleet.

An Industrial Data/Analytics Lead we talked to summed it up: "We tried feeding a week of data from one machine into the model. It didn't even get through ingestion."

That's not a tooling bug. It's math.

The numbers behind the failure

Take one heat pump. Standard industrial telemetry: temperatures, pressures, flow rates, compressor states, fault codes, sampled every few seconds across dozens of tags.

One week of that data, tokenized as text, lands at roughly 5 to 30 times the largest context window on the market today.

Not one fleet. Not one site. One machine. One week.

Now scale it the way an actual industrial operation needs to:

A fleet of 400 heat pumps, not one.
A year of history, not a week, because most useful comparisons (this winter vs. last winter, before the retrofit vs. after) require it.
Multiple sensor types per asset, not a handful of tags.

Multiply the overflow by fleet size, by history depth, by tag count, and the gap between "raw data in" and "context window available" stops being a rounding error. It's the difference between a demo and something that runs in production.

Why the workaround doesn't work either

The usual patch is to cut corners on the data before it reaches the model:

Downsample. Take one point out of every hundred. Now the model can't see the short transient that actually caused the trip.
Summarize with statistics first. Hand the model a mean, a max, a standard deviation. Now it's reasoning about a description of the data, not the data.
Truncate the time window. Give it three days instead of three months. Now it can't see the seasonal pattern that explains the anomaly.
Sample a subset of assets. Analyze 40 heat pumps instead of 400. Now the fleet-wide comparison the question actually needed is gone.

Each of these buys you a smaller token count. Each one also throws away exactly the resolution an operator needs to trust the answer. That's the trade nobody wants to make when the question is "why did pump B7 trip last Tuesday," and the honest answer requires looking at every second of raw data around the event, not a smoothed-over average of the week.

This is also where the banned move shows up in a lot of tools on the market: quietly turning a deterministic question into a probabilistic one, because the model is reasoning over a sample instead of the full signal. Spocky doesn't do that. Answers stay deterministic and explainable, cross-referenced against the actual history, not a compressed guess at it.

Compute-down: send the math to the data

Spocky's architecture inverts the pipeline. Instead of shipping billions of raw points into a context window, it sends the query logic down to where the data already lives.

The agent doesn't ask an LLM to hold a week of raw signal in memory. It asks a time-series engine, built over 15 years of R&D with a library of 1,300+ analytical functions, to compute the answer against the full history, then hands the result, not the raw feed, to the reasoning layer.

That's the difference between:

Ingest-up: raw data, tokenize, truncate/downsample, model reasons over a fragment.
Compute-down: question, math runs against full raw history at the source, model reasons over the actual answer.

The practical effect: latency and token use drop by up to 90%, because the model is no longer carrying the weight of the entire signal, just the result of interrogating it. A question that used to trigger an 11-day chain of emails across three teams gets a deterministic, explainable answer in seconds, cross-referenced automatically with maintenance logs. That loop is the subject of its own breakdown in why your pump trip investigation takes 11 days.

What this looks like on a real fleet

A two-person detection team supervising 400+ heat pumps isn't reading dashboards all day. They're getting flagged the moment an anomaly pattern surfaces, instead of it staying buried in raw data no one has time to query.

That only works because the querying doesn't route through a context window every time. The compute happens at the source, continuously, and the agent surfaces what matters. Fleet visibility built this way means the team catches issues before a customer has to report them, not after.

The same architecture is what lets an operator ask a question in plain English and get an answer without waiting on the data team. That matters because in most industrial organizations, 95% of raw data goes untouched simply because only the data team knows how to query it. A compute-down engine paired with a natural-language layer removes that bottleneck without adding a training requirement, a theme covered in more depth in predictive maintenance IoT programs and the missing analytics layer.

Where this fits next to your historian

None of this replaces a historian, a lakehouse, or existing IIoT infrastructure. It sits on top of it.

The historian stores the raw signal. Spocky's engine interrogates it at query time, at whatever depth the question requires, without a new data-modeling project for every new question. That's a different posture from dashboards that only answer the questions anticipated when they were built. See how this plays out concretely in industrial data historians vs. natural-language query agents.

The metrics, side by side

One heat pump, one week of raw telemetry: 5-30x the largest available LLM context window.
Compute-down architecture: up to 90% reduction in latency and token use versus shipping raw data into the model.
Two-person team, 400+ heat pumps, full fleet visibility.
Pump-trip-style investigations: from an 11-day, three-team email chain to a deterministic answer in seconds.

These aren't abstractions from a statistics textbook. They're what happens when the architecture question (where does the math run) gets answered before the AI question does.

Talk to our team

If your team has already hit the context-window wall trying to bolt an LLM onto a historian, we've seen that exact failure mode. Talk to our team to see how compute-down works against your own fleet, or read the offshore wind story to see it in production.

FAQ

What are some real industrial time series analytics examples, not just statistical ones?

A concrete example: one heat pump generating one week of raw telemetry (temperature, pressure, flow, fault codes) produces a dataset 5 to 30 times larger than the biggest LLM context window available today. Scale that to a fleet of hundreds of assets and a year of history, and the gap between raw data volume and what a model can hold grows accordingly. This is the practical, architecture-level example that pure statistics-textbook content on time series usually skips.

Why can't you just re-ingest raw time-series data into an LLM for industrial analytics?

Context windows aren't built to hold the volume industrial telemetry produces. One asset, one week, already overflows the largest context window on the market by 5-30x. Workarounds like downsampling, summarizing, or truncating the time window all discard the exact resolution needed to answer a specific operational question, like why a pump tripped at a precise moment.

What is compute-down architecture in industrial analytics?

Compute-down sends the query logic to where the raw data already lives, computes the answer against the full history at the source, and only passes the result to the reasoning layer. That avoids shipping billions of raw points into a context window, cutting latency and token use by up to 90% while keeping answers deterministic and explainable rather than sampled or approximate.

Does this replace our existing historian or IIoT platform?

No. It adds an operator-facing intelligence layer on top of the historian, lakehouse, or IIoT infrastructure already in place. The raw data stays where it is; the compute-down engine interrogates it at query time instead of requiring a new data project for every new question.

Why Re-Ingesting Time-Series Data Into an LLM Fails at Industrial Scale