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.

Industrial facilities generate vast amounts of time-series data from sensors, machines, PLCs, historians, and control systems.

Traditionally there have been two common approaches:

* Engineers manually explore the data until they discover something useful. * Machine learning attempts to discover patterns automatically from large labelled datasets.

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:

* multiple machines * different cutting operations * changing conditions over several years * relatively few damaged examples

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:

* Does overall vibration amplitude separate good and bad tools? * Does energy move into particular frequency ranges? * Does the spindle speed matter? * Are the damaged tools exciting different mechanical behaviour? * Which measurements remain stable across different machines?

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:

• no training phase
• no statistical model
• no neural network
• no weights
• no inference engine

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:

• engineers can understand every calculation
• results can be independently verified
• thresholds can be tuned
• failures can be investigated
• behavior remains stable over time

The AI accelerated discovery.

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:

• engineering context
• deterministic analytics
• conversational AI

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:

• Collect operational data.
• Use conversational AI to explore hypotheses.
• Validate discoveries against real engineering data.
• Convert successful ideas into deterministic analytics.
• Deploy those analytics in production.
• Feed the resulting engineering features back into higher-level AI applications.

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 analysis uses public Bosch CNC vibration recordings sampled from tri-axial accelerometers described in this paper CNC Milling Machines: A New Benchmark Dataset for Data-Driven Machine Monitoring The data is available CNC Machining Data
• Vibration is transformed into the frequency domain using standard Fast Fourier Transform (FFT) techniques.
• Each machining run is scored by measuring the proportion of vibration energy around the spindle's once-per-revolution frequency.
• Runs are ranked automatically using MIStudio's Feature Extractor.
• The highest-ranked run is compared with healthy reference runs using the Comparator.
• Charts and reports are generated directly from the extracted features without custom processing.

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.