Shop-Floor SOP Copilot
Answers shop-floor SOP, machine-setup and troubleshooting questions from your own approved manuals, work instructions and fault history — citing the source document and section on every step, and refusing when the documents don't cover it, so new starters stop queueing for the one veteran fitter.
It retrieves the answer from your own approved SOPs and work instructions, shows the source document and section it came from, and refuses rather than guessing when the corpus doesn't cover the question.
Where this works well
The slow, invisible problem this surfaces is the bottleneck of one veteran. On most shop floors the real answer to "what torque, what sequence, what's the reset rule" lives in a manual nobody can find, a maintenance log, or the head of one fitter — so everyone queues for that person, and when they retire the fault-finding leaves with them. This pattern earns its keep when your answers genuinely exist in writing but are slow to reach the person at the machine: a press-brake die setup torque sequence in a work instruction, the lockout steps before clearing a jam, a guard-interlock reset rule in the AS/NZS 4024 series. It pulls the right section, quotes it verbatim, and names the document — so a new starter gets the controlled answer in seconds instead of waiting at a bench.
It helps a multi-shift plant most, and the new-starter or apprentice most of all — the people who currently can't act without interrupting someone senior. The veteran fitter gets their day back for the diagnosis that genuinely needs judgement.
Where it works badly
The failure mode to take seriously is a confident, well-cited answer drawn from a superseded revision. If WI-12 has moved to v3 on the floor but only v2 is in the index, the copilot will quote v2's torque figure with the source shown and look completely trustworthy — the citation makes a stale answer more convincing, not less. It is also poor at anything that depends on what the technician can see, hear or feel at the machine: whether the tooling is actually seating, whether a noise is normal, whether this jam is the one the SOP describes. It retrieves text; it does not inspect plant.
The honest test: if your SOPs and work instructions are not under real revision control — if there's any doubt about which copy is current — this will amplify that mess at the speed of search, and the document-control work has to come first. If most of your fault-finding lives in one person's head and was never written down, there is little for it to retrieve yet, and the valuable first job is capture, not a copilot.
What it doesn't do — and shouldn't
It does not decide that a machine is safe to run, sign off that tooling is secure, or authorise resetting a guard interlock. It surfaces the relevant SOP section and quotes it; the technician judges whether the situation in front of them matches that section, and a person approves before the setting is applied or the cell is run. When a question falls outside the indexed corpus, it does not improvise a plausible figure — it refuses with an amber "not in your approved documents" notice and routes to escalate-to-Maintenance-Lead or log-the-gap-for-the-doc-owner.
That boundary is deliberate, and in a plant it is a safety boundary, not a nicety. A wrong coolant pressure can wreck a spindle; a missed lockout step under the WHS plant-isolation duties (Model WHS Regulations, plant management) can hurt someone. The point where a person confirms against the open source document is exactly where consequence concentrates, so that is exactly where the human stays.
What your data has to look like for this to work
This needs a defined, revision-controlled corpus — not "all the documents." Specifically: your SOPs and work instructions as discrete, current revisions (the superseded ones retired, not sitting alongside); the standards you actually work to indexed as approved references (e.g. the AS/NZS 4024 machine-guarding series, your lockout/tagout procedure); your quality manual; and — the part most plants haven't captured — the fault history that currently lives in maintenance logs and one fitter's memory, written down well enough to retrieve. Each document has to be machine-readable text, not a scanned binder image, and each answer's section has to be identifiable so it can be cited.
Most plants have some of this in good shape and a lot of it not: live and dead revisions mixed together, scanned PDFs that aren't searchable, and the most valuable knowledge unwritten. Getting that corpus clean and under control is usually a matter of how documents are captured and revised — not buying a new tool — and it is the work that makes everything downstream trustworthy. It is the part Real Minds AI helps with, and it is typically bigger and more valuable than the AI layer on top.
Could it give a wrong setting that damages a machine or hurts someone?
It only answers from documents you have indexed and approved, and it shows the source document and the exact section the answer came from so the technician can check it against the real SOP before acting. When a question falls outside the indexed corpus — say the commissioning manual for a new CNC cell hasn't been loaded yet — it refuses with an amber "not in your approved documents" message rather than guessing, and routes the question to a person. It accelerates the diagnosis; the fitter still makes the call and approves before anything is set or run.
Our SOPs are a mess — half are in a binder, half on a shared drive, some are out of date. Will this still work?
Not until the corpus is sorted, and that is the honest first job. The copilot is only ever as good as the documents behind it, so superseded revisions, scanned binders that aren't searchable, and tribal knowledge that was never written down all have to be dealt with before it can be trusted. We help you scope which SOPs, work instructions and standards go in, retire the old revisions, and capture the fault history that currently lives in one fitter's head. That document work is usually bigger and more valuable than the AI layer itself.
Does this replace our experienced fitters and the Maintenance Lead?
It does the opposite of replacing them — it captures what they know so it doesn't walk out the door when they retire, and it stops new starters queueing at their bench for answers already written down. The copilot surfaces and cites; the technician judges whether the situation actually matches the SOP, and the Maintenance Lead still owns anything the documents don't cover. The capacity it frees up goes back into the higher-judgement fault-finding only a person can do.
How current does the indexed content have to be?
As current as your controlled-document process keeps it. The copilot answers from whatever revision is indexed, so if WI-12 has moved to v3 but only v2 is loaded, it will confidently cite the superseded torque figure. Re-indexing has to be tied to your document-control workflow — when a SOP or work instruction is revised or a standard like the AS/NZS 4024 machine-guarding series is updated, the new revision replaces the old in the index, not alongside it.
Where does our data go — are our SOPs and fault history sent off to a public AI?
No. It runs as a private retrieval system over your own corpus — your SOPs, work instructions, standards and maintenance records stay in your tenancy (the demo pattern uses Microsoft Copilot inside your Microsoft 365 environment). Answers are generated only from documents you have loaded and approved; nothing is used to train a public model. We scope the data boundary with you up front so you know exactly what is indexed and where it sits.
Estimated build: 3–4 weeks. Most of it is template work we've already done.
Fixed scope, fixed price, fixed dates.
The cost band reflects the engagement shape, not a per-feature line item. We work on fixed scope, fixed price, fixed dates — see the services catalogue for what falls inside each band.
Considering this for your org?
The honest place to start is a bite-sized first piece — one contained change, low risk. Tell us where it hurts; we’ll play it back, scope it, and show you what’s possible.