30 July 2026
RAG for technical manuals: 7 controls before rollout
RAG for technical manuals should shorten the path from a technician’s question to the correct, current passage — with the document number, revision and section shown. It does not control machines, predict failures or replace an authorised person’s decision. It is an information system: retrieve, answer from evidence, and refuse when evidence is missing.
On a plant floor, the problem is rarely a total lack of manuals. More often there are three revisions, a scan without OCR, a vendor bulletin in another folder and a local procedure that changed the order of work. A language model cannot decide which source is binding. That is why RAG for manufacturing starts with source control and accountability, not with choosing the largest model.
Table of contents
- What RAG can do with technical manuals
- 1. Per-role permissions
- 2. Manual revision and authoritative source
- 3. Citation down to revision and section
- 4. Refusal without evidence
- 5. A golden set built from real questions
- 6. Human approval
- 7. Change monitoring
- Risk–control–evidence matrix
- The automation boundary
- How to start with a bounded scope
- FAQ
What RAG can do with technical manuals
RAG can connect equipment manuals, service instructions, maintenance procedures, vendor bulletins and quality documentation through one retrieval layer. A technician asks a question in ordinary language, the system finds the relevant passage and drafts an answer with a citation. Instead of a list of ten PDFs, the technician receives a point of verification: equipment identifier, document, revision, section and quoted passage.
This is not “ChatGPT that read the catalogue”. Production RAG on company documents must know which source takes precedence, who may see it and when an answer is not allowed. If documentation lacks an owner, revision and access rules, the model merely serves disorder faster. Start by checking data readiness for RAG, not by tuning a prompt.
1. Per-role permissions
An answer must not reveal a document the user is not allowed to read. Access filtering has to happen before generation, not as a sentence in the prompt. A maintenance technician, controls engineer, operator, external service provider and quality auditor will usually be entitled to different sources.
Every indexed passage should inherit access metadata from the source. Retrieval filters documents using the requester’s identity and role, while the log records which permission admitted each citation. Negative tests matter as much as positive ones: a contractor for machine A must not retrieve an instruction restricted to line B. Acceptance evidence includes the role-to-source matrix and the results of unauthorised-access attempts.
2. Manual revision and authoritative source
RAG should prefer the effective revision while preserving enough history to explain the result. A file timestamp is not sufficient. At minimum, keep the document number, revision, effective date, status, machine model or serial range, owner and a “supersedes” relationship.
During ingestion, the system can reject a duplicate, flag a conflict or route it to the documentation owner. It must not assume that the newest file wins when a plant-approved local procedure takes precedence over a generic vendor manual. Source priority is an organisational decision. RAG enforces it and leaves a trace of the rule it applied.
3. Citation down to revision and section
A citation must let a person verify the answer quickly in the original. “Source: manual.pdf” is too weak. A minimum technical citation includes the document name and identifier, revision, section or page, and a deep link where the document system supports one.
The interface should distinguish text found in the source from the model’s short summary. It should also show whether two passages agree or whether a local procedure conflicts with the manufacturer’s instruction. When sources conflict, the system does not select the more convenient one. It exposes the conflict and routes it to the process owner.
4. Refusal without evidence
“I found no basis in the approved documentation” is a correct result. RAG must not fill the gap with general model knowledge, experience from another machine or a plausible procedure. The refusal rule should trigger when no source is relevant, retrieval confidence is too low, revisions conflict, or the question falls outside the approved scope.
A good refusal is not a dead end. It states what is missing, identifies the scope searched and proposes an escalation to a shift lead, process engineer or documentation owner. Refusal correctness has to be measured separately. A system that answers everything can feel helpful while increasing operational risk.
5. A golden set built from real questions
The golden set should represent questions and failures that actually occur on the plant floor. Collect questions from operators, maintenance and quality; assign the expected source passage; and mark cases where refusal is correct. The set should include old machine names, plant shorthand, spelling mistakes, revision conflicts and questions with no documented answer.
Measure retrieval and generation separately. First ask whether the correct passage appeared in top-k. Then test whether the answer follows from it, whether the citation supports the claim, and whether the system refused correctly. Our RAG evaluation guide contains a scorecard and a worked go/no-go example. Thresholds are approved before testing and depend on the impact of error; they are not universal benchmarks.
6. Human approval
RAG supports a technical decision; it does not take that decision. An answer about service work, energy isolation, equipment release or departure from a procedure requires review by an appropriately authorised person. The interface has to display the source and support rejection, rather than offering only an “execute” button.
Human approval does not mean clicking through every answer without thought. The organisation defines which question classes are informational, which require confirmation, and which must always escalate. The log retains the approver, source revision and decision time. That produces operational evidence rather than the appearance of oversight.
7. Change monitoring
RAG quality ages with its documentation. A new manual revision, safety bulletin, procedure update or access change should trigger controlled ingestion, a regression test and a recorded index version. Silently replacing files without re-evaluation destroys the ability to reconstruct an answer.
Monitoring is broader than uptime. Track refusal rate, frequently cited sources, queries without coverage, revision conflicts, access-filter violations and golden set results. The documentation owner owns the sources, the system owner owns the pipeline and evaluations, and the process owner decides whether performance is sufficient for use.
Risk–control–evidence matrix
The table below is a standalone acceptance minimum. Every control must leave an artifact that can be inspected after an incident or a change.
| Risk | Control | Audit evidence |
|---|---|---|
| Disclosure of a restricted instruction | per-role permissions before retrieval | role matrix, filter policy, negative tests and access log |
| Answer from an obsolete manual | revision, status, effective date and “supersedes” relationship | document register, conflict result and index version |
| Citation does not support the answer | document, revision and section citation | per-question citation-correctness result |
| Model guesses without a source | refusal and escalation without evidence | out-of-scope cases, refusal rate and error samples |
| Demo works only on easy questions | golden set from real questions and revisions | versioned set, expected sources, thresholds and results |
| Answer is treated as a command | human approval for high-stakes categories | decision rules, approver identity and approval log |
| A document change breaks answers | change monitoring and regression testing | ingestion event, diff report and go/no-go decision |
The automation boundary
This scope does not control machines and is not predictive maintenance. It does not send commands to a PLC, change process parameters, release equipment or predict failures from sensor data. Those use cases need a separate architecture, data, validation, safety case and accountability model. Accurate retrieval from a manual is not evidence that a model can control an industrial process.
mojApteczka appears here only as an architectural analogy: it shows why RAG, citations, evaluations and refusal have to work together in a knowledge system. It is not a manufacturing case study, and its results say nothing about RAG performance on one plant’s manuals. We state the absence of a first-party manufacturing case openly rather than transferring evidence between domains.
How to start with a bounded scope
A safe proof of concept covers one equipment family, an approved set of manuals and procedures, a few explicit roles, and a real golden set. Before ingestion, remove ownerless documents, identify effective revisions and agree source precedence. Only then choose chunking, a model and an interface.
Acceptance ends with a decision, not a demonstration. If retrieval misses the right passages, refusal fails or permissions leak, the result is no-go or a continued test-only mode. If the gates pass, expand by controlled batches. This is the process we set in an audit and implementation, with owners, evidence and operating costs defined from the start.
FAQ
Will RAG replace an experienced technician?
No. RAG shortens search time and shows the source, but interpretation in the machine context, risk assessment and the decision remain with a competent person.
Can we put every PDF into one index?
Not safely. Without revision, status, owner, permissions and source-priority rules, the index preserves the disorder. Document control is a prerequisite for answer quality.
What should the system do when two instructions conflict?
Show the conflict, cite both sources and route the case to the procedure owner. It should not select a revision based on model probability.
How do we test RAG before it reaches the plant floor?
Use a versioned golden set containing answerable and unanswerable questions, access tests, citation checks, refusal cases and revision conflicts. Record the thresholds and critical-error rule before the run.
Does this type of RAG fall under the AI Act?
Classification depends on the actual use, the system’s role and the impact of its output. An informational knowledge base is not automatically high-risk, but it still needs transparency, appropriate oversight and a scoped assessment. We verify that during the audit rather than inferring it from the label “RAG”.