What this automation does
Most plants already collect the data needed to spot recurring quality problems. It sits in NCR forms, inspection sheets, 8D reports, supplier corrective action requests and customer complaint emails, written by different people in different words. This system reads all of it so patterns show up.
- Ingest records. Nonconformance reports, MRB dispositions, incoming and in-process inspection results, 8D and CAPA reports, supplier corrective action requests, and customer complaints or RMAs flow in from your QMS, SharePoint lists, Excel logs or email.
- Normalize each record. A language model reads the free text and maps it to your controlled vocabulary: defect code, part number, operation or work center, machine, supplier, lot or heat number, and detection point (incoming, in-process, final, customer).
- Index the history. Every record and its documented root cause and corrective action are embedded and stored so similar cases can be retrieved by meaning, not only keyword.
- Surface similar cases. When a new NCR is opened, the engineer sees the five most similar past cases, what was found then, and whether the corrective action held.
- Report trends. A weekly summary shows the top defect codes by count and by cost, new defect types, repeat issues on the same part or supplier, and CAPAs whose problem has reappeared since closure.
- Answer questions. Engineers can ask “What porosity issues have we had on the 6061 housings since last year?” and get an answer with links to the source records.
When it is worth building
This is worth building when your quality team suspects it is fixing the same problem repeatedly but cannot prove it, or when Pareto charts are unreliable because defect codes are chosen inconsistently. It also helps when experienced quality engineers retire and their memory of past failures goes with them.
It is not worth building if you have fewer than a couple of hundred quality records a year, since a well-kept spreadsheet and a monthly review meeting will serve you better. It is also not the first step if records are not being written at all. Fix the capture process before analyzing it.
Architecture
| Layer | What we use | Why |
|---|---|---|
| Sources | QMS exports or API, SharePoint lists, Excel logs, complaint mailbox | Meets records where they are today |
| Orchestration | n8n on a schedule | Pulls new records nightly and handles retries |
| Normalization | Claude or OpenAI’s GPT models with strict JSON output | Maps messy text to your defect codes and fields |
| Storage and search | PostgreSQL with pgvector | Structured fields and embeddings in one database you control |
| Trend reporting | Power BI on the normalized table | Quality teams already use it, and the numbers are computed in SQL, not by the model |
| Question answering | Retrieval-augmented assistant in Microsoft Teams | Answers cite record IDs so engineers can open the source |
If you already run an ERP such as Epicor, Plex, NetSuite or SAP Business One, part and supplier master data should come from there so names match. API access to manufacturing ERPs varies by vendor and license, so plan for an export-based connection as a fallback.
How to build it
- Fix the vocabulary first. Agree on the defect code list, work centers and detection points with the quality team. If your list has 300 codes, collapse it. The model can only be as consistent as the categories you give it.
- Export two to three years of history. Include closed NCRs, 8Ds and complaints with their root cause and corrective action fields. Remove or mask anything export-controlled or customer-confidential that should not be processed.
- Normalize and spot-check. Run the history through the normalization step, then have an engineer review a random sample of a few hundred. Adjust the code definitions and examples in the prompt until agreement is high.
- Build the index. Embed each record with its normalized fields as metadata so searches can filter by part family, supplier or date range before ranking by similarity.
- Wire the trend report. Build Power BI views on the normalized table. Counts, rates and costs are SQL; the model writes a short narrative on top that cites the numbers, never invents them.
- Add the similar-case panel. When a new NCR is created, post the similar cases to the engineer in Teams or in the QMS record itself if the API allows.
- Review monthly. Track where engineers override the model’s defect code, and use those corrections as new examples.
What breaks in production
- Codes drifting over time. New defect types appear and get forced into “other.” Review the other bucket monthly and add codes deliberately.
- Part number variants. Revision letters, customer part numbers and internal part numbers all refer to the same thing. Maintain a cross-reference table, do not leave matching to the model.
- Attachments that hold the real data. CMM reports, photos and dimensional layouts often carry the actual measurements. Decide whether to extract from them or link to them; do not pretend the text field is complete.
- Confident but wrong summaries. A narrative that says scrap fell 30% must match the dashboard. Generate numbers in SQL and pass them to the model as facts.
- Sensitive programs. Defense and some customer programs restrict where technical data can go. Tag those records at ingestion and exclude them from model processing.
Timeline and cost
A first version covering NCRs and customer complaints from one plant typically takes four to eight weeks, including the vocabulary work and engineer spot-checks. Lumeor builds this in the range of $15,000 to $40,000, depending on the number of sources, how much history needs normalizing, and whether the assistant is embedded in your QMS or runs in Teams. The retrieval pattern is explained in our guide to building a RAG knowledge assistant, and Pinecone vs pgvector covers the storage choice. For a broader view of where AI fits in your plant, start with an AI readiness assessment.
How to measure success
- Share of quality records with a consistent defect code, before and after
- Repeat NCRs on the same part and defect after a CAPA was closed
- Time from NCR opened to root cause documented
- Engineer agreement rate with the model’s suggested defect code
- Cost of poor quality (scrap, rework, returns) on the top recurring defects over the following quarters