Building a Maintenance Copilot on OEM Manuals and Work Orders

A technician on night shift gets an alarm on a gearbox, pulls up a 600-page OEM manual, and spends forty minutes hunting for the right torque spec and the fault table. A maintenance copilot collapses that into one question: what is the torque spec for this gearbox, and what failed last time on this asset? The answer comes back with the manual page and the relevant past work orders attached. Building the chat box is trivial. Building the retrieval layer that makes it trustworthy is where the weeks go, so here is how we approach it.

The corpus is messier than you think

A maintenance copilot pulls from four very different kinds of source:

• OEM manuals — long PDFs, often scanned, full of tables, exploded diagrams, part numbers and multi-column layouts.
• SOPs — shorter, controlled documents with revision numbers. Only the current approved revision should ever be retrieved.
• Work orders — structured CMMS fields (asset ID, dates, failure code) plus free text like "replaced seal, running ok".
• Shift notes and non-conformance reports — free text, abbreviations, occasionally multiple languages.

Each needs its own ingestion path. Treating them all as "documents" and pushing them through one generic splitter is the most common reason these systems give confidently wrong answers.

Parsing: keep tables and diagrams intact

Torque values, clearances and fault codes live in tables. A naive text extractor flattens a table into a stream of numbers, and a model will happily pair the wrong value with the wrong bolt.

What works:

1. Use a layout-aware parser that emits tables as structured rows (Markdown or HTML), not flattened text.
2. Run OCR on scanned pages, then store a confidence score per page. Low-confidence pages should be flagged rather than silently indexed.
3. For diagrams, store the caption, figure number and page reference, plus a generated text description from a vision-language model. Link back to the page image so the technician can see the original.
4. Preserve section hierarchy (chapter → section → subsection) as metadata. It becomes your most useful retrieval filter.

Chunking by meaning, not by token count

Fixed 500-token windows split procedures in the middle of a step list. Chunk along the document's own structure instead:

• Manuals: one chunk per subsection or per table, with the full heading path prepended ("Gearbox GX-40 > Maintenance > Bearing replacement").
• Procedures: keep a numbered procedure together even if it is long. Half a lockout sequence is worse than no answer.
• Work orders: one chunk per work order, with a generated one-line summary (symptom, cause, action) embedded alongside the structured fields.

Attach metadata to every chunk: asset_ids, doc_type, revision, site, access_groups, source_uri, page. You will filter on almost all of it.

Retrieval: hybrid, filtered, asset-aware

Maintenance queries are full of exact tokens — part numbers, alarm codes, model designations — where pure semantic search drifts. Use hybrid retrieval (keyword plus vector) and resolve the asset first: if the technician is standing at machine 12, filter work orders to that asset and manuals to its model.

Permissions must be applied as a pre-filter on the query, not after generation. Once a restricted passage lands in the prompt, you cannot reliably stop the model from using it.

Generation: cite or refuse

The generation step is the least interesting and the most constrained. The rules we enforce:

• Answer only from retrieved passages; no outside knowledge.
• Every factual claim carries a citation to a chunk ID that maps to a page or work order.
• If the evidence does not cover the question, say so and suggest who to ask.
• Safety topics (lockout/tagout, chemical handling, pressure systems) always return the source procedure verbatim with a link, never a paraphrase.

Here is the shape of the orchestration, simplified:

def answer(question, user, asset_id=None):
    filters = {
        "access_groups": {"$in": user.groups},
        "revision_status": "approved",
    }
    if asset_id:
        filters["asset_ids"] = {"$contains": asset_id}

    hits = hybrid_search(question, filters=filters, k=12)
    hits = rerank(question, hits)[:6]

    if not hits or hits[0].score < MIN_EVIDENCE_SCORE:
        return Refusal("No approved source covers this. Ask the area lead.")

    if is_safety_topic(question):
        return VerbatimProcedure(hits[0])

    draft = llm.generate(
        system=CITE_ONLY_FROM_CONTEXT,
        context=[h.with_id() for h in hits],
        question=question,
    )
    return verify_citations(draft, hits)  # drop any claim without a valid chunk ID

verify_citations is the piece people skip. It parses the draft, checks that each cited ID exists in the retrieved set, and strips or flags uncited sentences. It is cheap and it catches a surprising number of confident fabrications.

Evaluate with real technician questions

Before rollout, collect a few hundred real questions from technicians and have a senior engineer write the correct answer and source for each. Measure retrieval recall (did the right page come back?) separately from answer quality. When answers go wrong, it is usually retrieval, and you cannot see that if you only grade final answers.

In production, log every question, retrieved set and answer, and give technicians a one-tap "wrong / unhelpful" button. That feedback, plus completed work orders flowing back into the index, is how the system gets better each week.

A production-grade first version grounded in manuals, SOPs and maintenance history typically takes around 10 to 16 weeks, and most of that time goes on parsing and cleanup rather than prompts.

For where copilots sit among the other factory AI categories — predictive maintenance, vision, scheduling and process optimisation — see the full guide: AI Automation Tools for Manufacturing. We build these systems as LLM integration engagements.

Frequently Asked Questions

Why not just upload the manuals to a general chatbot?

General chatbots flatten tables, ignore document revisions, cannot enforce who may see what, and will fill gaps from general knowledge. On a factory floor that produces plausible but wrong torque values, which is worse than no answer.

How should work orders be chunked for retrieval?

One chunk per work order, keeping the structured CMMS fields as metadata and embedding a short generated summary of symptom, cause and action. That lets you filter by asset and date while still matching free-text descriptions.

Where should access control happen in a RAG pipeline?

At retrieval time, as a metadata pre-filter on the search query. Filtering after generation is not a control, because once a passage is in the model's context it can influence the answer.

How do you stop the copilot inventing answers?

Constrain generation to retrieved context, require a chunk-level citation for every claim, set a minimum evidence threshold below which it declines, and run a post-generation check that removes any sentence without a valid citation.

How do you measure whether a maintenance copilot works?

Score retrieval and answers separately on a test set of real technician questions, then track time to diagnose and first-time fix rate in production. Retrieval failures hide inside answer scores unless you measure them on their own.