Grounding AI in Factory Data: How to Stop an Assistant from Making Things Up

An AI assistant that confidently gives the wrong yield figure is worse than no assistant. In manufacturing, people act on numbers — they order material, hold batches and plan shifts. So the core engineering problem is not making AI fluent; it is making it right, and making it obvious when it is not sure.

This article explains the techniques we use to ground AI answers in factory data.

Why models make things up

Language models generate the most plausible continuation of text. If they do not have the facts, they produce something that sounds right. Asking a model about your stock levels without giving it your stock data guarantees a confident guess.

Two kinds of questions, two techniques

Treating every question as a document search is a common mistake. Numbers should come from queries, not from text that happens to mention a number.

Permissions come first

The assistant must run as the user, not as an administrator. If a supervisor cannot see costing, the AI cannot show costing to that supervisor — even indirectly through a summary. Retrieval and queries pass through the same role and plant scopes as the application.

Show the source

Every answer carries links to the records or documents it used. Users learn to trust the assistant because they can check it, and errors are caught quickly when someone clicks through and sees the wrong batch.

A semantic layer reduces wrong joins

Raw database tables are full of cryptic names and edge cases. A semantic layer — business definitions of metrics, entities and relationships — lets the AI generate queries against ‘production quantity’ and ‘plant’ rather than guessing which of five similar columns to use. It also keeps definitions consistent with human reports.

Confidence and refusal

• Ask clarifying questions when a request is ambiguous (‘which plant?’).
• Flag low-confidence outputs for review rather than hiding them.
• Refuse questions the data cannot answer instead of improvising.
• Never present a draft action as completed — approvals are explicit.

Evaluate on your own questions

Before go-live, build a test set of real questions from your users with correct answers checked by people who know the plant. Run it on every change to prompts, models or data mappings. Track accuracy over time. This is the single most effective way to stop quality from slipping silently.

A worked example

Take the question: ‘Why was yield low on Line 2 last week?’ A grounded assistant does not answer from general knowledge. It first clarifies scope if needed (which plant has a Line 2?), then runs a structured query for stage-wise yield on that line for the week and the four weeks before. It compares batches, identifies the stage where the gap appears, and retrieves related records: raw-material lots used, quality results and any maintenance or deviation notes on that line.

The answer it returns is a short explanation with a table, each row linked to the underlying batches, and an explicit note of what it could not determine — for example, if moisture readings were missing for two lots. That last part is what makes people trust it.

Common failure modes we design against

Keeping humans in the loop

For questions, the human check is the source link. For actions — creating a purchase request, changing a schedule, drafting a recipe — the check is an explicit approval by a named person. The assistant prepares; people decide. This keeps responsibility where it belongs and makes AI adoption far easier for plant teams who rightly worry about losing control.

Log everything

Keep a record of prompts, generated queries, sources, answers, approvals and edits. It supports audits, helps debug wrong answers and shows where users need better data or definitions.