It’s two in the morning and the control room is lit only by monitor glow. An alarm chirps on a compressor that has run cleanly for six years. The night shift supervisor leans over the screen, scrolling through trend after trend, hunting for the thread that connects a dozen tags to one answer to one question: what’s wrong, why now, and what do i need to do to resolve it? 

What if the operator didn’t have to scroll at all? What if they just asked the machine a question directly? 

“Compressor 4, why are the vibration levels up today?” 

And the machine answers, not with a dashboard but with a sentence: “bearing temperature has drifted 3°C above baseline over the past six hours, I have been tracking the same pattern we saw eleven days before the March seal failure. I recommend an inspection within 48 hours”. 

I always wanted to be on the bridge of the Starship Enterprise, in Jean-Luc’s shoes being able to just ask simple questions that bely the complexity of the underlying assets that the computer was about to answer about. Thus, this is the question I have been musing on recently. What if you could ask your machine what’s wrong, or why it isn’t performing as well as usual? Is that even possible, and if so, how far away is that reality? 

Closer than it looks 

Many of the hard parts to solving that capability already exist, they’re just not talking to each other yet. 

Sentinel, IFS.ai Operational Intelligence’s (OI) anomaly detection engine, already runs continuous surveillance across every connected asset and flags a deviation before it becomes a failure. It already builds what the platform calls an event horizon: the sequence of readings that led up to the moment something went wrong. Shift Log, OI’s digital handover module, already keeps the institutional memory that a whiteboard previously lost at every shift change, whereas Case Management already integrates with EAM to route a detected event to a work order and a named technician. 

What none of these solutions do yet, for the most part, is let you ask about any of it in plain language and get a plain-language answer back. That, however, is not necessarily as much of a gap as it sounds, especially today. 

No longer is this a science problem. Large language models are already good at turning structured data and time-series trends into a coherent sentence, provided they’re given the right context to reason over. The context is the part that’s been missing: a live map of what an asset is, what normal looks like for it, and what’s happened to it and the rest of the fleet of assets before. The engineering design documents that identify how it works, the maintenance manuals which describe how problems should be resolved. Operational Intelligence and other similar platforms have spent years quietly building exactly that map, underneath the dashboards, without anyone asking it a question directly. 

In terms of what exists today, concretely: 

  • Sensor and OT data collection: done, at scale, for years 
  • Contextual data integrated into the solution 
  • Anomaly detection and root cause analysis: done, across several industries and thousands of asset classes 
  • Institutional memory of shift handovers and past events: increasingly complete, wherever digital logs have replaced paper 
  • A model that can turn all of that into a sentence: available today, in preview form, off the shelf 

What’s missing is the wiring between the first four items, and the last. Wiring however, unlike invention, is a project you can put a date on. 

In my opinion, this is a one-year problem, not a five year one. 

If I had to bet, the first genuinely useful version of this is a simple interface that lets an operator ask a real question about a real asset and get a grounded, evidence-backed answer. That is easily achievable within a one-year build for anyone who already has the underlying operational intelligence layer in place. The data model (and the data) exists. The detection and root cause analysis engines exist. All that is left is a retrieval layer that lets a language model reason over live time-series, contextual and historical case data without inventing an answer, plus enough guardrails that it says “I don’t know” rather than guessing. 

The five-year version of this tool is a different and harder problem to solve. Here, the machine doesn’t just answer, it acts upon the evidence, adjusting a setpoint, deferring a load, raising a work order and scheduling the technician, with something like the authority a senior reliability engineer has today. That version needs more than just a language model. It needs a validated closed-loop control system, a much deeper trust relationship between the workforce and the system, and a regulatory framework for safety-critical assets that doesn’t fully exist yet. It also needs the compounding effect of thousands of these conversations happening across an industry, each one teaching the system what a genuinely good answer looks like on the ground, not just a plausible one. 

One year therefore gets you a very good co-pilot tool. Five years gets you something closer to what you can call a teammate. 

We’ve imagined this before 

None of this should feel unfamiliar, because we’ve been imagining it for decades. Captain Jean-Luc Picard (of Star Trek fame) routinely  asks the computer a question and gets a straight answer, no menus, no ticket number. Luke Skywalker’s astromech whistles out a diagnosis of the hyperdrive before anyone’s opened a panel. Science fiction assumed, correctly as it turns out, that the hard part of running complex machines was never the machines. It was the conversation all along. 

The gap between Starship Enterprise’s computer and a real plant in 2026 was never really about raw capability, processing speed. It was about whether the assets had a detailed enough model of itself to talk about, and whether anyone trusted the answer enough to act on it. Both of those are solvable (and are being solved) this decade, not the next century. 

What it changes on the floor 

Get this right and the change is no longer just about the technology, its about who gets to be the expert in the room solving critical asset issues with only simple question and response conversations with a computer. An apprentice with three whole week’s experience with a good question can get the same depth of answer which today, would be reserved for the engineer who’s worked the plant for twenty years. Shift handovers stop being a race to remember everything and start being a conversation the next person can actually learn from when the next version of that problem surfaces the other side of the factory. Root cause analysis, currently a task that eats hours after the event, becomes a question you ask during the event (or better, before-hand), while there’s still time to change the outcome. 

This is the grand vision, where instead of spending hours manually chasing data, doing root cause analysis, validating previous outcomes, an engineer is provided all the evidence in one go and what the machine plans to do in order to get back to operational. And further still, at some point when the trust is earned, the machines become closed loop and can self-heal before downtime impacts operations. 

Where I’d like this to go 

I don’t think this is a moonshot, I think it’s a to-do list, and a fairly short one at that. A solution that sits on top of the Operational Intelligence capability that is already being used globally at scale. I’m curious what that list looks like from where you sit: what would you ask your machine if you could trust it to give you a straight answer back?