Why Your Pump Trip Investigation Takes 11 Days (and How to Cut It to Seconds)
"Why did pump B7 trip last Tuesday?" That question should take seconds to answer, not 11 days of emails across three teams — here's what compute-down industrial time-series analytics changes about the investigation.
"Why did pump B7 trip last Tuesday?"
That's the question. An operator asks it in a hallway. A plant manager asks it after a customer complaint. A reliability engineer asks it before a maintenance review.
It sounds simple. It isn't.
At most industrial sites, that one sentence kicks off an 11-day chain of emails and Slack messages across three teams before anyone has a real answer. By the time the answer arrives, the next run has already started, the context is stale, and nobody is sure the fix actually addressed the root cause.
The 11-day loop, step by step
Here's what that investigation actually looks like inside most plants:
- The question gets asked. Someone notices pump B7 tripped. They don't know why yet.
- The data team gets pinged. Raw time-series data lives in a historian only they know how to query.
- The data team runs a query, or five. Each iteration takes a day because the request goes into a queue behind other ad hoc requests.
- Maintenance gets looped in. Was there a work order? A technician intervention? That log lives in a different system entirely.
- Quality gets looped in. Did the trip correlate with a batch or product change? That's on paper, or in a third system.
- Someone tries to line up timestamps by hand. Across three systems, three formats, three owners.
- A theory forms. Usually a partial one, because nobody had the full picture at the same time.
- The answer finally ships. Eleven days later, on average, according to the pain teams describe over and over.
This isn't a people problem. It's an architecture problem. The data that would answer the question in seconds exists. It's just scattered, siloed, and gated behind the one team that knows how to query it.
We've written before about why 95% of raw industrial data remains untapped because only the data team can query it. The pump B7 question is that problem playing out in real time.
Why you can't just "feed it to an LLM"
The obvious-sounding fix is to point a large language model at the historian and let it answer questions in natural language. It doesn't work at industrial scale, and the reason is math, not ambition.
One heat pump over one week of raw time-series data is 5 to 30x larger than the biggest context window on the market today. A single pump, a single week. Now multiply that by a fleet.
Re-ingesting billions of raw points into an LLM burns tokens, blows past context windows, and adds latency the investigation can't afford. It also invites a worse problem: sampling. When you can't fit the full history into context, the model summarizes, and summarizing raw time-series data means guessing at what to leave out.
We go deeper on this failure mode in why re-ingesting time-series data into an LLM fails at industrial scale. The short version: shipping the data to the model is the wrong direction.
Compute-down: send the math to the data
Spocky flips the direction. Instead of shipping billions of raw points into a context window, compute-down architecture sends the query to where the data already lives, queries it in place, and returns a deterministic, explainable answer.
No ingestion pipeline. No new data warehouse. No re-platforming the historian.
This is the difference between:
- Ingest-up: move the data to the model, hit context limits, get an approximate summary.
- Compute-down: move the question to the data, run the math where the data lives, get an exact answer.
For pump B7, that means Spocky can cross-reference the trip against maintenance logs, prior interventions, and operating history automatically, in the same query, without a human manually lining up three spreadsheets.
The result: ask Spocky why pump B7 tripped, and get a deterministic, explainable answer in 7 seconds, cross-referenced automatically with maintenance logs. Not a summary. Not a best guess. An answer built on the full raw history, computed at query time.
What changes for the data team
The data/analytics lead doesn't disappear from this picture. Their role changes.
Today, the data team is the bottleneck: every operational question routes through them because they're the only ones who know how to query the historian. That's not a good use of a skilled team, and it's not sustainable as the number of questions grows.
With natural-language, compute-down analytics, operators ask questions directly. No SQL. No dashboard request ticket. No waiting in a queue behind five other requests. The data team shifts from being the query bottleneck to governing the system: validating logic, refining agents, and making sure the answers stay accurate as new equipment, sensors, and edge cases get added.
That's a better trade. It's also the pattern we've seen play out with industrial data historians when natural-language query agents get layered on top — the historian doesn't go away, it becomes more useful.
Why the answer has to be deterministic, not probabilistic
There's a temptation, once you're using AI for anything, to accept a little fuzziness in exchange for speed. In industrial operations, that trade doesn't hold.
An answer to "why did pump B7 trip" gets used to justify a maintenance decision, a warranty claim, or a safety review. It has to be explainable, and it has to be repeatable. If you ask the same question twice, you should get the same answer twice, with the same math shown.
That's why Spocky's agents are built to be deterministic and explainable, full stop, not sampled or approximate. The 1,300+ analytical functions built over fifteen years of time-series R&D exist to compute exact answers against raw history, not to generate plausible-sounding summaries of a sample.
A human still signs off before anything acts on the fleet. Spocky answers the investigation and surfaces the recommendation; the decision to act stays with the operator or engineer.
From one investigation to the operating loop
The pump B7 question doesn't have to be a one-off. Once an agent can investigate it, the same investigative logic feeds forward:
- Explore: ask the question, get the deterministic answer.
- Automate: turn the recurring version of that question into a standing report or alert.
- Act: support a supervised action, with a person still signing off.
- Document: capture what happened so the next investigation starts from more, not less.
- Predict: accumulate enough validated pattern history to flag the next B7-style trip before it happens.
This is the operating loop. It's the same loop that lets a two-person detection team supervise 400+ heat pumps and catch issues before a customer does, and the same pattern behind a 75% reduction in site visits for one connected-assets deployment — fewer truck rolls because the diagnosis happens before the technician is dispatched, not after.
If your team is running predictive maintenance pilots and struggling to get past exploration, the order matters: validate the pattern first. We cover this in why predictive maintenance IoT programs fail without natural-language analytics.
The metrics recap
- 11 days → 7 seconds: the pump B7 investigation, before and after.
- 5–30x: how far one heat pump's weekly time-series data exceeds the largest LLM context window — the reason ingest-up approaches fail.
- 400+ heat pumps: supervised by a two-person detection team using fleet-wide visibility.
- 75% fewer site visits: in a connected-assets deployment using remote diagnosis before truck rolls.
- 1,300+ analytical functions: built over fifteen years of time-series R&D, available at query time.
- 3 weeks: typical time to deploy a customized production agent.
Where to go from here
The 11-day chain isn't a training problem or a tooling gap on any one team. It's what happens when raw data, work orders, and tacit knowledge live in different systems and only one team can query any of it.
Compute-down, conversational analytics closes that gap by answering the question where the data already lives, in seconds, with a deterministic trail anyone can check.
Talk to our team, or read more customer stories, to see what this looks like on your fleet.
FAQ
Why does investigating a single pump trip take so long today?
Because the evidence lives in three separate systems: raw machine data in a historian, work orders in a maintenance system, and quality findings on paper. Answering "why did pump B7 trip" means manually lining up timestamps across all three, which routes through email and Slack chains across teams and typically takes about 11 days.
Why can't you just load all the sensor data into an LLM to answer these questions?
Context windows can't hold it. One heat pump's raw time-series data over a single week is 5 to 30x larger than the largest LLM context window on the market. Re-ingesting billions of points burns tokens, adds latency, and forces the model to summarize rather than compute against the full history.
Is a compute-down answer a probabilistic guess or an exact calculation?
It's deterministic and explainable. Spocky sends the math to the data instead of shipping data into a model, so the same question run twice returns the same answer with the same underlying calculation, not a sampled or approximate summary.
Does this replace the data team?
No. It removes the data team from being the query bottleneck for every operational question. Operators get natural-language, self-service access to raw data, while the data team shifts to governing and refining the agents alongside Forward Deployed Engineers.
Does the system take action on equipment automatically?
No. Spocky supports investigation, recurring reporting, alerting, and supervised action, but a person always signs off before anything acts on the fleet.