Designing a Manufacturing Knowledge Assistant That Cannot Overrule Your Systems

The problem: retrieved text is not a record

Retrieval-augmented generation, or RAG, is described in NIST-hosted research as a technique that incorporates external knowledge sources into the prompt. RAG retrieves supporting documents from an external knowledge source and passes them as context with the original input to the text generator. That is useful, but it also means the assistant's answer is only as sound as the documents it was handed.

The same research explains why manufacturers reach for it: general GenAI models are prone to hallucinations, and RAG is meant to reduce the likelihood of incorrect data. Note the wording. Grounding reduces a risk. It does not turn generated text into a controlled record. For an executive, the practical consequence is that a grounded answer still needs a rule for when it may be trusted, when it must be checked, and which system wins when they disagree.

Causes and constraints

The mechanics explain where authority leaks. In the general RAG pattern described by NIST researchers, raw data is cleaned, segmented into chunks, encoded into vectors, and stored in a vector database. At query time, the user query is matched with the most similar chunks, which become context for generation.

This suggests several design questions to ask of any proposal, framed here as checks rather than findings. Chunking separates a statement from the record, revision, or effective date around it, so ask whether provenance travels with each chunk. A copy in the index may lag the source system, so ask how freshness is established. Finally, ERP, MES, WMS, QMS, and PLM each hold different kinds of truth: transactions, execution status, inventory, quality dispositions, and engineering definitions. Ask who owns each corpus and who is accountable when it is wrong.

Approaches to compare

There is no single right architecture, and the assignment should not assume one. Several options deserve a fair comparison for a given environment:

• Extend existing systems. Use search or assistant features inside the system that already owns the data. This keeps permissions and authority in place but limits cross-system questions.
• Targeted integration. Connect only the specific sources a defined question needs, such as work instructions plus quality dispositions, rather than indexing everything.
• Reporting or portal patterns. If the need is a status lookup, a governed report or portal view may answer it with no generative layer at all.
• No platform change. Improving document ownership and naming may solve part of the problem before any AI is introduced.
• A governed RAG assistant. Worth building where questions genuinely span corpora and the controls below can be met.

NIST-hosted research also shows a more structured variant. Ontology-based RAG integrates structured domain knowledge into retrieval and generation, and is intended to improve the accuracy of retrieved information and the consistency of responses. That research is framed around additive manufacturing data analytics tasks. Evaluate it as a design option before assuming it fits your own environment.

Tradeoffs

Each option trades effort against control. A governed assistant over many systems requires data ownership decisions, permission mapping, integration work, evaluation, and ongoing support, and the quality of its answers will depend on the quality of the underlying records. Research on multi-stage retrieval pipelines also illustrates the cost of thoroughness: one NIST-hosted TREC paper notes that each additional retrieval round incurs retrieval and LLM inference overhead, and that off-topic documents can accumulate and corrupt later stages, which is why that system filters between stages. More retrieval is not automatically better.

Next steps

These steps are Metrotechs recommendations for sequencing the work.

1. Define approved corpora. List which documents and record types may be retrieved, who owns each, how fresh it must be, how long it is retained, and what question the assistant is allowed to serve.
2. Separate kinds of information. Keep stable reference material, current operational records, live research, user instructions, and authoritative transactions distinct. The assistant may explain a transaction but should not be the place where it is created or changed.
3. Require citations and uncertainty handling. Every answer should point to its source record and revision, say when sources conflict or are missing, and route to a named person when it cannot resolve the conflict.
4. Build an evaluation set. Test with real questions from planners, buyers, quality staff, and supervisors, including questions designed to surface stale or conflicting content.
5. Limit action boundaries. Start read-only. Any write-back or approval stays in the source system under existing controls.

Applying this to your decision

For an executive deciding how to proceed, the question is not whether to have an assistant but what it is permitted to be. Treat it as a finding aid that points to governed records, never as a replacement for them. Use these checks to decide whether and how to proceed:

• Name the questions. Which three questions would save the most time, and do they genuinely span more than one system? If they sit inside a single system, extending that system may be enough.
• Name the owner of each answer. Which system of record owns the data behind each question, and who signs off when the assistant and that system disagree? If nobody can answer, fund ownership and data quality before funding a model.
• Test the controls before the build. Can your team show, for a sample question, the source record, its revision, its freshness, and the permissions that applied? If not, provenance and access mapping come first.
• Set the boundary. Is the first release read-only, cited, and limited to approved corpora? If those answers are clear and the questions cross systems, a narrowly scoped pilot is a reasonable place to start.