Short answer: generative AI earns its place on a plant floor wherever the work is text, and a beverage plant produces a lot of text nobody reads. It can draft the shift handover from the MES stop log, the alarms and the operators’ notes. It can answer SOP questions with the section cited. It can help a team through five whys and an Ishikawa diagram by proposing causes and pulling similar past incidents, while the team verifies. It can draft one-point lessons and translate for a crew that speaks several languages. In every case the pattern is the same: data from systems, words from the model, judgement and signature from a person.
Every plant I have worked in had a shift handover book. Most of them had the same three entries, night after night: “line ran OK”, “labeller issues”, “see maintenance”. The information the next shift needed was somewhere else, in the stop log, in the alarm list, in the head of the operator who had just gone home.
That is the problem generative AI is actually good at. Not controlling the process, not predicting failures (the previous post covered the models that do that), but reading and writing the text that holds a plant together. This is the sixth post in the series, and it covers five places where that pays.
Shift handover summaries
A useful handover answers four questions: is anything unsafe, is any product on hold, what is still broken, and what must the next shift do first. The data to answer them already exists:
- the MES stop log, with durations and reason codes
- the alarm history from SCADA, which a script can group so forty repeats of one alarm count as one issue
- the operators’ free-text notes
- quality holds from the LIMS or the QA system
A language model drafts the handover from those inputs in a fixed structure. Two rules make it trustworthy. Every number (stop minutes, hold quantities, batch numbers) is passed in from the systems, never written by the model from memory. And every line of the draft links back to its source, so the incoming supervisor can click through. The outgoing supervisor reads, edits and signs. The handover book gets better and the supervisor spends ten minutes instead of thirty.
SOP answers with citations
The second post in this series explained retrieval-augmented generation through a CIP example. On the floor, the use is simple: an operator asks “what is the torque setting for the 330 ml capper after a format change?” and gets the answer with the SOP number and section.
The value is not the chatbot. It is shortening the distance between a question and the controlled document. What makes or breaks it is the document library: one current version of each SOP, clearly titled, with superseded versions out of the index. A plant with a messy SOP folder will get messy answers, faster.
A root-cause assistant for five whys and Ishikawa
When a line stops for two hours, a good team runs a structured root-cause analysis: five whys to follow a chain of causes, an Ishikawa (fishbone) diagram to make sure no category is missed. The usual headings are man, machine, method, material, measurement and environment.
A language model is a useful facilitator here. Given the incident description, the stop data and the maintenance history, it can:
- propose candidate causes under each Ishikawa heading, so the team does not fixate on the first idea
- pull similar past incidents from the CMMS and the incident log, which is often the most valuable thing it does
- ask the next “why” when the team stops too early at “operator error”
- draft the incident report once the team has agreed the cause
What it must not do is conclude. A language model has never seen your filler. It will produce a tidy, logical chain of five whys that reads beautifully and is wrong, because plausible is what it is built for. Each link in the chain needs evidence from the floor: a photo, a reading, a worn part. The model proposes, the team verifies.
Training and one-point lessons
A one-point lesson is a single page, mostly pictures, teaching one thing: how to check a crown crimp, how to set a guide rail. They are among the best training tools in TPM and among the most neglected, because writing them takes time nobody has.
A model can draft one from the SOP section and a few photos taken by the operator who knows the job. The subject-matter expert edits and approves it. The same approach works for quizzes after training, and for turning a long SOP into a short checklist. Keep the approved version in the document system like any other controlled document.
A multilingual floor
Many beverage plants run in several languages at once. In an Indian brewery, an operator may write notes in Hindi, Kannada or Marathi, the supervisor may read English and the SOPs may exist only in English. Current models translate between these well enough to be genuinely useful for everyday notes and questions.
Two controls matter. Use a fixed glossary for hazard terms, chemical names and equipment names, so “caustic” never becomes a vague word for “strong”. And have a fluent person who knows the plant review translated SOPs and safety instructions before they are issued. Translation for reading is low risk. Translation of an instruction someone will follow near a hot caustic line is not.
Where this breaks
Garbage stop codes make garbage handovers. If half the stops are “other”, the handover will faithfully summarise “other”. The model cannot recover what was never recorded.
Fluent text hides missing information. A well-written handover that leaves out the one quality hold that mattered is worse than a scruffy one, because people trust it. Build a check that every open hold and every safety alarm appears in the draft.
Root-cause assistants anchor teams. If the model’s first suggestion is shown first, the team may never look past it. Show several candidate causes, from different headings, and ask the team for theirs before revealing them.
Controlled documents stay controlled. A drafted SOP or one-point lesson is not issued until someone with authority approves it. The model speeds up writing, not approval.
The bottom line
Generative AI in a plant is at its best with text: the handover nobody writes properly, the SOP nobody can find, the root-cause meeting that stops at “operator error”, the lesson nobody has time to draw, the note written in a language the supervisor does not read. In each case the systems supply the facts, the model writes, and a person checks and signs. That division of labour is not a limitation. It is the design.
Next: agentic AI for OpEx, an agent that watches OEE losses and drafts work orders, and the guardrails that keep it away from process control. For the earlier take on SOP search, see Knowledge Search Over Brewery SOPs With Gen AI. The full list is on the series page.
Frequently asked questions
How can generative AI help with shift handovers in a brewery or bottling plant? It can read the shift’s line stops from the MES, the alarms and the operator notes, and draft a structured handover: safety issues, quality holds, open faults, and what the next shift needs to do first. The figures come straight from the systems, the model writes the summary around them, and the outgoing supervisor checks and signs it before handing over.
Can an LLM do root-cause analysis? It can help, not conclude. A good assistant proposes candidate causes under each Ishikawa heading, pulls similar past incidents and asks the next why. It cannot see the machine, and it will happily produce a neat causal chain that is wrong. The team still has to verify each link with evidence from the floor.
Is machine translation safe for SOPs and safety instructions? It is useful for drafts and for everyday notes, and it needs control for anything safety-critical. Use a fixed glossary for hazard terms, chemical names and equipment names, and have a fluent person who knows the plant review translated SOPs and safety instructions before they are issued.