findIQ industrial AI takes a specialised approach to one of manufacturing’s biggest challenges: making experienced technicians’ knowledge available when and where it is needed. When production equipment goes down, technicians need reliable guidance based on real machine knowledge, not simply a plausible answer generated from a prompt.
findIQ has taken a specialised approach to that problem. The company’s Industrial Knowledge Platform captures experienced technicians’ expertise and turns it into structured guidance for machine operators and service teams. Its diagnostic core uses deterministic AI, while generative AI is applied selectively to tasks where large language models are better suited.
We spoke with Sina Volkmann, CEO and co-founder of findIQ, about why the company built its own deterministic diagnostic core, how it achieves an 80 percent hit rate from day one, where its AI assistant Quinn fits into the platform, and how expert knowledge could eventually support industrial AI agents and robots.
How findIQ Industrial AI Approaches Machine Diagnostics
MTN: At IMTS you demonstrated how findIQ turns experienced technicians’ know-how into step-by-step guidance. Why did you choose a deterministic diagnostic core instead of letting a large language model diagnose faults directly?
Sina Volkmann: We didn’t just show that at IMTS – we show it everywhere, because it isn’t a passing phenomenon. It’s a fundamental decision we made years ago, and it came down to where we started: findIQ was founded during the COVID pandemic, when service technicians could no longer travel. We had to find a way to get specialists’ expertise to machines and equipment, for example to resolve downtime. We had a very clear problem, and we went looking specifically for the technology that would solve it best. We didn’t just go with whatever happened to be available, obvious, or trending.
The requirements for digital assistance systems in industrial production are completely different from those in a personal or office setting. The system has to be reliable and deliver precise results. Offline availability is also important, because there are still gaps in network coverage – especially in production environments. That’s still a problem for large language models that analyze huge amounts of data. Another requirement was that the entire learning mechanism be transparent and traceable. Language models don’t meet any of these requirements, so they weren’t our first choice for the core of our solution. Deterministic AI models, on the other hand, meet all of them – which is why they form the foundation of our diagnostic core.
MTN: You report that technicians can reach the root cause in an average of six steps with a hit rate of at least 80 percent. How is that performance measured, and how does it vary between machine types and customer environments?
Sina Volkmann: In most cases, we reach the 80 percent hit rate right away, the first time the software is used – no time-consuming training is needed: When we digitize technicians’ knowledge, we transfer it into a fixed structure. Simulation models in the background run through tens of thousands of cases and calculate the diagnostic quality in advance. We display it transparently – so you know how good the diagnosis is before you release it. The 80 percent is usually just the starting point. The system gets better with every use, because new content from active use flows back in and is transferred into the same structure.
The six steps describe how quickly a technician gets there: on average, findIQ guides them to the root cause in six steps, or six clicks, even in very complex cases. We determined this figure in field tests with real service cases. We measure the hit rate against reality: after each diagnosis, the technician confirms whether the suggested cause was the actual one. Every confirmed or corrected case is logged, so the hit rate is based on real service cases in the field, not on lab tests. Because the knowledge base keeps improving with this feedback, the hit rate typically rises to 90 percent and above over time.
Basically, quality doesn’t depend on the machine type or the industry, but on how cleanly and consistently each individual knowledge base is built. Whether we’re talking about entire production lines, highly complex equipment, or environmental factors that affect how machines and production behave: this information just has to be entered into the knowledge base correctly, and then it’s fully taken into account. Thanks to the structure of the findIQ software and its modular approach, the number of clicks to a diagnosis and the quality of the diagnosis stay the same.
MTN: Where does Quinn add the most value on top of the deterministic system, and which tasks have you deliberately kept away from generative AI because the risk of an invented answer is too high?
Sina Volkmann: As a rule, we always choose the best technology for the task at hand. The work involved in machine operation, service, and maintenance is wide-ranging, so it also calls for different AI approaches.
We use Quinn – various large language models – as an assistant wherever LLMs make sense and can play to their strengths. One area is reading and integrating existing data from a wide range of media, such as documents, videos, images, and drawings. The other is voice control: users can interact with the system by voice, both in expert interviews to capture knowledge and during diagnosis.
For the actual processing of the knowledge base into an assistance system, on the other hand, we rely on specialized industrial AI so that the drawbacks of LLMs don’t interfere with the results. These include hallucinations, the lack of offline capability, and above all the fact that feedback can’t be incorporated in a structured way. That, in turn, means it wouldn’t be possible to keep expanding the existing knowledge base. We developed our own models from the ground up for this.
MTN: Capturing tribal knowledge sounds simple until an expert has decades of intuition that is difficult to explain. How do you extract that knowledge and turn it into a diagnostic model that another technician can actually follow?
Sina Volkmann: From the very beginning, our approach was to capture exactly this implicit knowledge – the things that haven’t been written down anywhere. So before we develop a new module, it’s always important to us to understand the thought and decision patterns an expert follows for that particular task.
Take fault diagnosis, which is where we started. Experts think in terms of cause and effect, and that’s more complex than a simple step-by-step approach. These are exactly the relationships we map in our structure. So our job is to first capture the thought patterns in a structured way and then process them so they turn into step-by-step instructions for technicians.
We want to keep less experienced colleagues from having to search for a long time or write especially precise prompts, which most people find hard. That’s why we put just as much technological effort into delivering the knowledge as into digitizing it. Less experienced colleagues usually need this knowledge in the form of step-by-step instructions. So we have to translate complex thought patterns into a form that’s easy to understand.
Then there’s a second component: language and technical terminology. Experienced colleagues often use different terms than less experienced ones. Today, that’s easy to solve with glossaries, synonym databases, or even LLMs.
MTN: How does the platform learn from new service cases in the field without allowing unverified information to degrade the reliability of the existing knowledge base?
Sina Volkmann: To make sure knowledge actually flows back from the field, we built three success factors into our feedback model.
Probably the most important point for acceptance and use: it has to be as easy as possible for technicians to give their knowledge back. Once findIQ has diagnosed a fault and helped them at the machine, they can enter new insights directly in the software they’re already using. And they can do it in their own language.
Of course, it’s also crucial that the new knowledge doesn’t degrade the data, but improves it. This is where a human-in-the-loop principle comes in: all feedback is collected in a review area and checked weekly, monthly, or even just quarterly, depending on need. Cases can be accepted or rejected. This ensures that the knowledge base in the background only grows with meaningful data. It’s a white-box process – very different from most LLMs, which learn on a black-box principle.
Also critical: the need for training data has to be low. Industry doesn’t generate anywhere near as much data as the internet that you could use to train systems. Just a few dozen cases have to be enough to optimize the knowledge base.
MTN: What integrations are most important if findIQ is to move from guiding a technician toward the cause of a fault to automatically pulling the relevant machine data, alarm history or maintenance record?
Sina Volkmann: To begin with, findIQ works without any integration at all, simply “off the shelf.” All we need is an initial knowledge base, and then the system can be deployed on a tablet, for example. One vision for our software that comes up in many places, especially when we’ve been working with a company for a while, is integration into the existing system landscape. This is mainly about automation – making what we already do very well even more scalable and less labor-intensive to run.
Two important integrations already exist. The first concerns the start: fault diagnosis can be triggered by another system, such as a simple error code on a panel or maintenance software. Machine operators often use solutions like these anyway. When the diagnosis is triggered automatically from there, it also becomes easier to track fault and downtime, because it no longer depends on someone opening our software manually.
The second integration concerns the end of the diagnosis: the case that was worked through in the app can be documented as a structured ticket and then mapped in the maintenance software, for example. That covers both the start and end points on the system side. And instead of painstakingly cleaning up historical data – maybe to train an LLM with it – we generate new content going forward that’s structured from the start and flows back in that form.
The next step is to bring data into the diagnosis itself. Today, the technician answers the questions findIQ asks at the machine. Once the relevant machine data, alarm history and maintenance records are connected, many of these questions can be answered automatically: Has this alarm occurred before? When was this component last replaced? Which values were out of range before the fault? Steps the data already answers can be skipped, so the diagnosis gets even faster. We are already working on this with our first customers. What matters to us is that the data feeds into our structured diagnostic model rather than replacing it: the data provides the evidence, and the expert knowledge determines what it means.
An exciting new area is deeper integration into automation – that is, controlling machines and, at some point, robots too. Then it may no longer be about training people, but robots. It’s conceivable that a diagnosis could be started from their error messages in the future. Taking that a step further, one day the knowledge could serve not only fault diagnosis, but also training a robot. Integration into controls and automation is a natural part of our next steps.
MTN: For a manufacturer evaluating industrial AI, what is the fastest use case to prove value, and which metric tends to move first: mean time to repair, technician productivity, training time, uptime or knowledge-retention risk?
Sina Volkmann: There are two answers to that. The medium- to long-term metric is the most fundamental one of all: the survival of the company. That’s what we secure, especially in knowledge-intensive industries. Tribal knowledge is massively underestimated, because it’s rarely clearly documented. Yet it’s just as essential to productivity as digitalization, systems, or processes. It’s hard to imagine how a company could even survive without this knowledge. What happens when a long-time machine operator or service technician retires and literally takes their knowledge with them, so it’s no longer available to the company from that moment on?
And if we think very short-term, the metric that moves first is reduced unplanned downtime costs – through a shorter mean time to repair and less scrap. Manufacturers often face enormous downtime costs, especially from unplanned outages. If you break these situations down, you can see how much time is lost today to long diagnosis times – sometimes an entire shift is spent waiting for experts. On top of that, there’s unnecessary scrap: if you step into a faulty process too late, you produce poor quality – just because maybe no one knew what needed to be set differently on the equipment.
Our customer enercity, for example, achieved 75 percent faster diagnoses, zero misdiagnoses and an ROI of more than 200 percent within six months. Technician productivity and shorter training times follow, because less experienced colleagues can resolve faults on their own instead of waiting for an expert. The fastest use case to prove value is a single machine type with frequent, costly downtime. Capturing the knowledge takes about four hours of expert interviews, so results are visible within weeks, not months.
MTN: As industrial agents become more capable, do you expect findIQ to remain primarily an expert guidance system, or could it eventually trigger approved maintenance actions automatically once the diagnosis is sufficiently certain?
Sina Volkmann: Going forward, we’ll remain a specialist provider for making implicit knowledge – in other words, tribal knowledge – available. But no longer just for people; for agents, too. Wherever generic AI reaches its limits, they need specific models that act like an expert. That could be configuring complex production processes or equipment, or selecting the right spare part based on settings and dependencies.
In the future, agents will be able to access this knowledge, but so will machines and automation solutions like robots, directly. That’s why we’ll integrate findIQ into agentic systems where it makes sense, or have them trigger the diagnosis, as described earlier. And where even that is only an intermediate step, because there aren’t even any inexperienced employees on site anymore for a system like this to help, we’ll integrate directly – into the robots, for example. We see a lot of potential for findIQ here.
As for triggering maintenance actions automatically: technically, that’s a logical next step, and our structured diagnosis provides exactly the certainty it would require. But in industrial environments, the decision to act on a machine has consequences for safety, quality and liability. That’s why we believe the human should stay in control of the approval, at least for anything beyond routine actions. Just as with our feedback model, we see a human-in-the-loop principle here: findIQ can prepare and propose the right action with a clear confidence level, and an authorized person approves it. Where companies define certain actions as safe to automate, findIQ can support that. The decision about where that line is drawn should stay with the customer. Whether it’s a technician, an agent or a robot acting on it, one thing stays the same: reliable expert knowledge is what makes industrial AI work.
MTN Analysis: Industrial AI Needs More Than a Powerful Model
findIQ’s approach highlights an increasingly important distinction in manufacturing AI. The challenge is not simply choosing the most capable AI model. It is deciding which technology is appropriate for each part of an industrial workflow.
LLMs have clear strengths when dealing with unstructured information, natural language and voice interaction. Machine diagnosis introduces different requirements. Reliability, traceability, controlled learning and offline operation become much more important when the output influences how a technician responds to a production fault.
The next stage could be particularly significant. Connecting structured expert knowledge with machine data, alarm histories and maintenance records would allow diagnostic systems to answer more questions automatically before a technician intervenes. findIQ says this integration is already being developed with customers.
The longer-term direction goes beyond assisting technicians. As industrial agents and robots take on more operational tasks, they will also need access to the specialist knowledge currently held by experienced workers.
That makes the capture of tribal knowledge more than a workforce or training challenge. It could become an important part of the knowledge infrastructure required for increasingly autonomous manufacturing.
findIQ’s current platform reflects that focus, combining structured knowledge capture, guided troubleshooting and continuous field feedback, while supporting on-premise and air-gapped deployment options for industrial environments.
