A fault code appears on the infeed servo at 2 a.m., and the technician who fixed the same fault last spring is not on shift. The manual is a scanned file somewhere on a shared drive, the old work order says "replaced seal, ran OK", and the only full account of what was actually done belongs to someone who is asleep. Maintenance troubleshooting in that situation is mostly a search, for who saw this fault before, what they tried and in what order, and it has to finish before anyone picks up a tool.
This article shows how a plant turns its repairs into a library a technician can search, and how an AI assistant can answer a technician's question from that library with citations, scoped to the right machine and running on the plant's own servers. It is also plain about the limits, because the assistant only knows what was recorded and the technician still checks each answer against its source. It belongs to our guide to predictive maintenance with video AI, which covers the camera side of a maintenance program alongside this knowledge side.
Why troubleshooting time is search time
When a machine stops with an unfamiliar fault, four sources of help usually exist, and in most plants they live in four different places. The fault code is on the machine's screen, the manual sits in a cabinet or a folder of scanned files, the repair history is in the maintenance system as short work order notes, and the person who knows the machine is on another shift, on leave or retired. Mean time to repair includes the time spent going through all four, and when the cause is new to the person on shift, that search can take longer than the repair.
The night shift feels this hardest, because the most useful of the four sources, the person, is the one it cannot reach. A phone call at 2 a.m. works once or twice, and after that the plant is relying on a few people's goodwill and on whether they remember a job from months ago. Recording what those people know while they are doing the job is the practical way to make it available at the hours they are not there.
Turning repairs into a library
The most useful record of a repair is the repair itself, filmed as it happens from the technician's point of view, with the technician saying what they are doing and why. Our article on capturing tribal knowledge on the plant floor covers how to film it, from choosing whose jobs to record first to the cameras and phones that work on a plant floor. Once the recording is uploaded, it is transcribed with every word aligned to the timeline, so a search for "overcurrent" inside a forty-minute repair plays from the moment the word was spoken, and a long repair can be divided into chapters by step, either generated automatically or set by hand.
Manuals, wiring diagrams and schematics belong in the same library, where the text on a scanned page is recognized and searchable and a result opens at the page it appears on. Text shown on screen during a recording, such as a fault message on a machine's operator panel, is searchable the same way and opens at the timestamp. A parts list or a torque table can be attached to the repair video at the step where it matters, offered for download at that point, and custom fields for line, machine and asset family let the library be filtered the way the floor thinks about its equipment. Past work order notes can sit alongside as documents, thin as they often are, since they still record when a fault happened and which part went in. Our article on just-in-time training at the machine covers how a technician reaches the right recording from the machine itself.
An assistant that answers from the plant's own repairs
Search finds a recording when the technician already knows roughly what to look for, while an assistant helps most when they do not. The technician asks in plain words, such as "the infeed servo throws an overcurrent fault after a jam, what did we do last time", and the assistant retrieves the passages that bear on the question from the plant's recordings, manuals and notes, writes an answer from them, and cites each source as a card the technician opens. A good answer might combine the repair video in which the senior technician cleared the jam and reset the drive, the manual's page on the overcurrent code, and a work order note recording a replaced coupling, none of which answers the question on its own.
Scoping matters more in maintenance than in most uses, because two machines from different makers can show the same fault code for different reasons. An assistant can be limited to the material for one asset family or one line, by folder, category, tags or a custom field value, so it answers from the right machine's manual rather than the closest match in the whole library. Retrieval also runs under the asking technician's own identity, with their access applied before anything is searched, so an answer can only draw on material that technician could have opened directly, and what the assistant returns is always the overlap of what that person may see and what the assistant was scoped to. Our article on generative AI for manufacturing knowledge explains how grounded answers are produced and why the citations matter.
What the assistant cannot do
The assistant answers only from what the plant recorded and wrote down, so a fault nobody filmed or documented has no good answer, and whatever comes back will be thin or generic. That is why capture comes before the assistant, and why the questions that get weak answers are worth keeping as a list, since together they are the plant's recording backlog. Our guide to knowledge transfer in manufacturing covers how a plant builds that library in the first place and keeps it current.
Citations identify the material an answer drew on, and checking that each step really follows from its source stays with the technician. A citation card opens the source material, and inside a cited recording, transcript search and on-screen text search take the technician to the moment the step is shown, so checking an answer takes seconds rather than a long scrub through the video. An answer that cites nothing relevant, or cites a source that does not say what the answer says, should be treated as no answer at all.
Lockout and tagout, energy isolation, guarding and every other safety step follow the plant's own written procedure for that machine rather than the assistant, and an answer that touches any of them is a pointer to the procedure, never a substitute for it. The assistant does not perform or authorize a repair either, since its job is to help a qualified technician find what the plant already knows.
Running the assistant inside the plant
Repair recordings show proprietary equipment, process settings and sometimes a customer's product, so the head of manufacturing IT and Operational Technology (OT) usually asks first where the models run. The language models that write answers can be served on the plant's own servers, alongside local speech recognition, vision and text recognition models, so transcription, indexing and answering all happen without a call leaving the deployment, apart from license verification, which needs outbound access of its own. The trade is hardware and model choice, since the plant needs Graphics Processing Unit (GPU) capacity for the models it hosts, and answer quality follows the models it chooses to run.
Whoever curates the library decides whether the assistant stays useful, so each asset family needs an owner who reviews new repair recordings before they are published. The assistant cannot tell an approved method from a workaround that happened to get a machine running, and only someone who knows the machine can decide which past fixes are good practice. When a machine is modified or a procedure changes, the recording should be replaced rather than added beside the old one, and replacing the file keeps the item's address, views and settings, so a code or link fixed to the machine keeps working while the old file goes to the recycle bin rather than being kept as a version. Getting technicians to record repairs at all is usually the hardest part, and it tends to depend on making recording quick and on supervisors treating a recorded repair as part of finishing the job.
How VIDIZMO fits
VIDIZMO Nexus holds the repair library, with recordings transcribed word by word, chapters, on-screen and scanned-page text that can be searched, files attached at the step they belong to, custom fields for line, machine and asset family, and file replacement that keeps a link on the machine working. AI Intelligence Hub answers technicians' questions from that library with citations, under each technician's own permissions and the scope set for each assistant, and both can run on the plant's own servers. When the job starts from a camera alert rather than a fault code, our articles on visual equipment monitoring on plant cameras and combining sensor data with video for maintenance cover how the clip reaches the work order, and our article on agentic AI for manufacturing investigations covers what an agent does when a question reaches beyond one machine.
A practical first step is to film the next ten repairs on one line's most troublesome machine, load its manual and schematics beside them, and ask the night shift to put their real questions to an assistant scoped to that machine. See AI Intelligence Hub in action and request a demo.
