Large Language Models (LLMs) have attracted enormous attention in industry. Most demonstrations focus on asking an AI to interpret data directly or allowing it to make operational decisions.
This demonstration explores a different idea.
Rather than replacing engineering with AI, we use AI to accelerate engineering discovery.
The LLM acts as an engineering analyst: suggesting hypotheses, testing ideas, rejecting those that don't work, and helping identify measurements that genuinely distinguish healthy equipment from faulty equipment.
Once that discovery is complete, the AI steps aside.
The production system contains no trained model, no neural network, and no black box. Instead, it runs deterministic analytics that every engineer can understand, validate, and trust.
That distinction is important.
The AI discovers the analytic.
The analytic performs the monitoring. A video of the application can be found here CNC Analytics
Industrial facilities generate vast amounts of time-series data from sensors, machines, PLCs, historians, and control systems.
Traditionally there have been two common approaches:
Both approaches have drawbacks.
Manual analysis is slow and requires significant expertise.
Machine learning can achieve impressive results, but the reasoning behind a prediction is often difficult to explain. Training data must be maintained, models eventually drift, and engineers can struggle to understand why a particular decision was made.
There is a third approach.
LLMs make remarkably capable engineering assistants.
They can rapidly explore hypotheses, write analysis code, compare results, suggest alternative explanations, and help engineers navigate enormous datasets.
Instead of replacing engineering judgement, they amplify it.
This demonstration uses a public CNC machining vibration dataset published by Bosch researchers.
The objective is simple:
Can we reliably detect a damaged cutting tool from vibration measurements?
At first glance this appears to be an ideal machine learning problem.
The original paper investigates ML techniques because the data contains:
Instead of training a model, we approached the data conversationally.
The LLM proposed ideas.
Some worked.
Many failed.
Every failure taught us something about the data.
Rather than asking an AI:
“Which runs are damaged?”
the conversation looked much more like an experienced engineer working with another engineer.
Questions included:
Most of these ideas were tested and rejected.
Eventually one feature consistently separated damaged tools from healthy ones.
Importantly, the feature wasn't invented by AI.
It already existed in the physics of rotating machinery.
The LLM simply helped find it much faster than a human analyst would normally manage.
The final production detector is remarkably simple.
It measures how much vibration energy appears around the spindle's once-per-revolution frequency compared with the rest of the vibration spectrum.
That's it.
There is:
Just conventional engineering mathematics based on the frequency content of the vibration signal.
Imagine listening to an orchestra.
Measuring the total loudness tells you very little about which instrument is playing.
The same is true for machinery.
A damaged tool often doesn't make the machine dramatically louder.
Instead, it changes where the vibration energy appears.
Looking only at overall vibration amplitude is like measuring the orchestra's volume.
Looking at frequency shows which instrument is producing the sound.
In this case, the important “instrument” is the spindle rotating once every revolution.
That small change is almost invisible in the raw signal but becomes obvious when viewed in the frequency domain.
This is perhaps the most important point in the demonstration.
The AI never decides whether a tool is damaged.
Instead, the AI helped answer a completely different question:
“What should engineers measure?”
Once that question had been answered, the production system became ordinary analytics.
That means:
It does not control production.
The demonstration was implemented using MIStudio's Feature Extractor and Comparator components.
The Feature Extractor performs the signal processing and generates engineering features from the vibration data.
Those features are then ranked, compared, visualised and reported automatically.
The Comparator produces evidence showing exactly why one run differs from another, allowing engineers to move beyond simply saying “this looks different” and towards explaining how it differs.
The same analytics that produce the visualisations also generate structured numerical results that can trigger alarms, maintenance workflows or engineering reports.
This demonstration is really about a broader pattern.
Time-series analytics already contains decades of engineering knowledge.
LLMs make it dramatically easier to explore that knowledge.
Rather than expecting an AI to reason directly over millions of raw sensor samples, we can combine:
The LLM helps engineers discover better analytics.
The analytics produce explainable features.
Those features become reliable inputs for operational dashboards, maintenance systems, digital twins, MES applications and even later LLM conversations.
Each technology contributes what it does best.
The workflow becomes:
Rather than asking an LLM to analyse millions of sensor values every day, production systems execute simple, explainable calculations while AI continues helping engineers discover the next improvement.
For readers interested in the implementation details:
The most interesting outcome wasn't that AI detected damaged tools.
It didn't.
The interesting outcome was that conversational AI dramatically accelerated the process of discovering an engineering measurement that humans can understand, trust and deploy.
That points toward a different future for industrial AI.
Instead of replacing engineering knowledge, AI can help create better engineering knowledge.
And once those discoveries have been made, conventional analytics remain the best way to deliver them reliably, transparently and at industrial scale.