Contextual AI vs. AI Slop: Building Explainable Manufacturing Intelligence Without 5,000 Lines of Code

“I used Claude Code to build an agentic manufacturing AI troubleshooting assistant… The project contains >5,000 lines of code, all written by Claude. I have no coding experience.”

— S.R. Duncan, LinkedIn

https://www.linkedin.com/posts/s-r-duncan_i-used-claude-code-to-build-an-agentic-manufacturing-ugcPost-7470116430101835777-3k3f

The LinkedIn demonstration is impressive.

It demonstrates that modern LLMs can assemble a sophisticated troubleshooting assistant capable of reasoning across historians, alarms, documentation, and process relationships. In this particular case the focus was an industrial boiler for steam generation.

However, it also highlights an emerging problem:

Who understands the resulting system?

If an AI generates more than 5,000 lines of code that nobody on the operations team can audit, maintain, or explain, then the resulting application becomes another black box.

This article demonstrates an alternative approach.

Instead of generating thousands of lines of application code, the same concepts can be implemented using three reusable, visual components inside MIStudio:

• KnowledgeBaseDevice
• KnowledgeBase
• FeatureExtractor

The result is an OT-friendly implementation that can be inspected, understood, modified, and audited by process engineers and controls personnel. You can see a short video of the application here: https://youtu.be/OktuIjskAUs

The term “AI Slop” is often used to describe large quantities of generated output that technically function but are difficult to understand, validate, or maintain.

In industrial environments this becomes a serious concern.

Questions that must be answered include:

• Who owns the generated code?
• Who validates that it is correct?
• How is it tested?
• How are changes reviewed?
• Can an engineer explain how the recommendation was produced?
• Can the application survive personnel changes?
• Will cybersecurity teams approve an unauditable codebase?

A 5,000-line AI-generated application may work today.

The concern is whether anyone can confidently operate it five years from now.

Instead of generating applications from scratch, MIStudio exposes industrial intelligence as reusable building blocks.

The engineer assembles known components visually.

The LLM reasons using those components.

The components themselves remain deterministic, testable, and understandable.

The implementation shown below consists primarily of three blocks.

The KnowledgeBaseDevice indexes plant knowledge. It performs RAG encoding of information such as:

• P&ID diagrams
• Instrument descriptions
• Tag definitions
• Equipment relationships
• Troubleshooting guides
• SOPs
• Datasheets
• Engineering notes

Unlike a traditional vector database containing isolated documents, the indexed information includes a full semantic description of the process.

For the boiler example this includes statements such as:

• TE_8332A is boiler outlet steam temperature.
• YJJWSLL is primary desuperheating water flow.
• TV_8329ZC regulates desuperheater outlet temperature.
• TE_8313B measures upper furnace temperature.
• Primary desuperheater influences outlet steam temperature.
• Superheater sections are upstream contributors.

In effect:

The P&ID becomes a knowledge graph.

No custom code is required.

The OT engineer simply selects the documents and diagrams to index.

Traditional RAG systems answer questions from documents.

Manufacturing problems require reasoning over data.

FeatureExtractor exposes historian analytics as an MCP tool.

Instead of teaching an LLM how to calculate statistics, MIStudio provides those capabilities directly.

Available features include:

count
mean
median
min
max
range
stddev
variance
first
last
delta
percent_change
slope
rate_of_change
duration_above_threshold
duration_below_threshold
excursion_count
dominant_frequency
dominant_period
top_frequencies
spectral_power
correlation_matrix
lag_correlation_matrix
missing_samples

This means the LLM can ask questions such as:

• Is the outlet temperature abnormal?
• What is the standard deviation?
• Is there a trend?
• Did spray flow increase?
• Are signals correlated?
• Were samples missing?
• Is there evidence of oscillation?
• Has control performance degraded?

The calculations themselves remain deterministic.

The LLM requests features.

FeatureExtractor computes them.

KnowledgeBase orchestrates the reasoning process.

It receives the operator's question.

It consults indexed knowledge.

It invokes FeatureExtractor as an MCP tool when data analysis is required.

It combines both forms of evidence into an explanation.

This produces recommendations such as:

• Summary
• Evidence
• Recommended actions
• Additional checks

All without requiring handwritten agent code.

The original LinkedIn example described the following sequence.

Operator asks:

“Have there been any steam temperature anomalies in the last 5 hours?”

KnowledgeBase asks FeatureExtractor for:

• mean
• stddev
• slope
• missing samples

Result:

Boiler outlet steam temperature over the last 5 hours shows stable behavior with minimal variability and no significant trend.

KnowledgeBase consults the indexed P&ID.

It determines that potential contributors include:

• Primary desuperheater
• Secondary desuperheater
• Superheater stages
• Furnace conditions
• Fuel feed
• Combustion air

FeatureExtractor retrieves supporting evidence.

Examples:

• Spray flow statistics
• Valve movement trends
• Correlations
• Excursion counts
• Missing samples

The LLM combines:

• Equipment relationships,
• Process behavior,
• Historical features,
• Documentation.

Possible conclusions include:

Elevated primary desuperheater spray flow is likely contributing to reduced outlet temperature.

or

No evidence of an abnormal event exists during the requested interval.

KnowledgeBase retrieves operational guidance.

For example:

• Verify secondary desuperheater instrumentation.
• Check intermediate steam temperature stages.
• Review fuel feed stability.
• Assess combustion conditions.
• Confirm pressure conditions.

Instead of thousands of lines of generated source code, the engineer sees:

• A KnowledgeBaseDevice connected to documentation.
• A KnowledgeBase block.
• A FeatureExtractor block.
• The question textbox.
• The resulting summary and recommendations.

Every connection is visible.

Every capability is explicit.

Every component can be individually tested.

The difference is not technical capability.

The difference is ownership.

• Thousands of generated lines of code
• Difficult to audit
• Difficult to maintain
• Hidden implementation details
• Dependent on generated logic
• Requires software expertise to validate
• High cybersecurity review burden

• Visual architecture
• Deterministic building blocks
• Explainable feature extraction
• Process relationships derived from engineering assets
• OT personnel can understand the workflow
• Easier validation and maintenance
• LLM used for reasoning, not application generation

The future of industrial AI is probably not:

“Generate an entire application from a prompt.”

The future is more likely:

“Allow engineers to assemble trusted capabilities while LLMs provide contextual reasoning.”

In other words:

Use AI to interpret industrial knowledge—not to replace industrial engineering.

The original LinkedIn prototype is valuable because it demonstrates what is possible.

The MIStudio implementation suggests something equally important:

The same outcomes can be achieved without surrendering explainability.

If a controls engineer can inspect the architecture, understand the evidence, validate the calculations, and explain the recommendation to an operator, then AI becomes another engineering tool rather than another black box.

Perhaps the real evolution of industrial AI is not Agentic AI.

Perhaps it is:

Contextual AI: intelligence that engineers can understand.

Machinery Fault Investigation Demo Using FeatureExtractor + FeatureComparator + LLM Coming Soon