Who this is for: Plant quality heads, supplier quality engineers, manufacturing CIOs and QMS/ERP owners
Define one real exception type, not an AI feature
Select a recurring quality workflow, such as missing incoming inspection evidence, wrong drawing revision, supplier corrective action or incomplete lot release. Map the point at which a case is opened, where it waits, and which role can close it. Count recent cases, time spent searching for evidence and reopened exceptions. Record baseline delays and mistakes without assuming software can eliminate every case. An illustrative pilot should improve preparation for authorised engineering review, not replace the engineer or inspection standard.
Prepare a source-of-truth and permission register
List the QMS, ERP, MES, document management and supplier systems involved. For each source, identify the authorised record owner, stable identifier, version field, permitted read interface, retention policy and missing-data treatment. An integration catalogue is more useful than a vague claim that all plant databases can be joined. A practical starting table has columns for lot ID, part and supplier, specification revision, inspection batch, nonconformance ID, corrective-action owner and approval status. If the same identifier means different things in different systems, resolve it before training or prompting a model.
Assemble a small, permissioned historical sample
Choose around 30–40 representative closed or redacted historical quality cases for scoping if permitted. Include both complete and incomplete records, wrong revisions, supplier changes, ambiguous scan quality, duplicate attachments and instances where an exception was correctly escalated. Keep a separate set aside for evaluation. Record access authorisation and never upload confidential drawings or customer data to an unapproved AI service. A synthetic demonstration can explain a workflow, but it cannot establish real factory accuracy or integration readiness.
Design a traceable evidence pack
For each case, propose a reviewer screen that lists the source document, document version, relevant page or test result, lot/part context, missing items, conflicting records and uncertainty. Link every suggestion to a source available to the authorised user. Separate model-generated summaries from official inspection observations. Do not silently substitute a newer specification for the revision effective at the time of manufacture. If a document cannot be accessed or a link is stale, report an explicit evidence gap rather than an invented completion.
Keep quality disposition under named control
Only the authorised quality or engineering role can approve rework, scrap, concession, customer notification or case closure. The pilot should propose checks and route an exception; it should not execute irreversible QMS or ERP status changes. Test role-specific permissions, action logs, retry behaviour and what happens when an API or document repository is unavailable. A human reviewer must be able to reject the suggestion, cite an alternative source and explain the correction without rewriting the underlying source record.
Agree the go-or-stop scorecard before coding
Measure correct document-revision matching, missing-evidence recall, incorrect suggestions, false escalations, median review minutes and traceability of the final disposition. Segment by defect class and source quality. Compare against a documented baseline and have the quality team define intolerable errors. Expand only when data gaps, integration effort, accuracy and operating cost are acceptable. A faster summary with the wrong drawing revision is a failed pilot regardless of how fluent it sounds.
Finish discovery with four practical deliverables
Ask for an agreed workflow map, source/permission matrix, representative exception sample plan and a signed-off acceptance scorecard. These are possible outputs of a scoping engagement, not artifacts IRAH claims to have already implemented at your facility. A proposed two-week pilot should only be committed after the plant has confirmed scope, access, reviewing staff, security requirements and the existing system interfaces.
Make the next discussion specific.
Bring the current workflow, available records and the decision you need to improve. We can discuss an evidence-based assessment and sensible controls before proposing technology.
Discuss this workflow ↗