Dave retires in November. He has run the centerless grinder on line three for twenty-two years, and he can tell from the sound across the aisle when the wheel is about to load up and start burning parts. He knows that this machine likes to be warmed up for forty minutes on a cold morning or the first dozen parts come out oversize. He knows that when the surface finish goes hazy in a particular way, the upstream heat-treat oven is drifting and the metallurgy lab should be called before anyone touches the grinder. None of this is written down. It lives in Dave's hands and Dave's ears, and on the last Friday of November it walks out the door with him unless someone captures it first. The plant has tried. Last year they handed a retiring tech a blank form and asked him to "document his knowledge." He wrote four bullet points and left. The form approach fails because expertise is not a form; it is a conversation that has to be drawn out, one specific failure at a time. This lesson is about using AI to run that conversation, structure it, transcribe it, and turn twenty-two years into something the next shift and the next AI tool can both actually use, all before the last Friday in November.

The Retirement Wave Is the Real Emergency

Every plant has a Dave, and the clock on every Dave is running. The forcing function for the whole AI-on-the-floor movement is not the technology; it is the talent cliff. Roughly 2 million manufacturing workers need reskilling by 2026 against about 500,000 unfilled roles, and 85% of manufacturers say staffing shortages are already hurting product quality. The most experienced people are leaving fastest, and when they go they take the only sensor that could hear a bearing going bad and the only eyes that could read a subtle finish defect at line speed. The new crew has never seen this machine fail this way before, and there is no written record that it ever did.

Knowledge capture is the highest-return move a thinning plant can make, and it is the one most often skipped because it feels less urgent than the fire of the day. That is a costing error. Put a number on Dave. Suppose his tribal knowledge prevents, in a typical year, two scrap events worth 12,000 dollars each and one half-shift of avoided downtime worth 20,000 dollars. That is 44,000 dollars a year of losses Dave quietly stops just by being there. The day he leaves uncaptured, that 44,000 dollars a year of protection leaves with him, and the green crew starts paying it back in scrap and downtime while they relearn what he already knew. Capturing Dave is not a soft HR project. It is a six-figure-over-three-years risk sitting on a calendar with a November deadline.

AI matters here for a reason that is easy to miss: AI is only as good as the institutional knowledge you feed it. Every quality-AI and maintenance-AI tool the plant might deploy is starving for exactly the labeled, plain-language failure knowledge that lives in Dave's head. The grounded root-cause model from the previous chapters cannot reason about "the upstream die is worn" if no one ever wrote down that this defect means the upstream die is worn. Capturing the experts is not a side quest from the AI program. It is the fuel supply for the AI program. The plant that captures Dave before November is the plant whose AI tools will actually work next year.

Capture the expert's knowledge before they leave; it is the highest-return move a thinning plant can make and the fuel every floor-AI tool needs.

Why the Blank Form Fails and the Interview Works

Hand an expert a blank documentation form and you will get four bullet points, because experts do not know what they know. Their knowledge is compiled, automatic, and invisible to them. Ask Dave to "write down how you run the grinder" and he writes "warm it up, watch the finish, change the wheel when needed," because to him the rest is just obvious. The gold is in the exceptions, the failures, the "this one time," and those only come out when something specific pulls them.

The interview works where the form fails because a good interviewer asks about specific incidents, not general practice. "Tell me about the last time this grinder made bad parts" gets a story. "Document your process" gets a shrug. The story is where the knowledge is: what Dave saw, what he heard, what he checked first, what he ruled out, what he did, and how he knew it worked. The art of knowledge capture is the art of asking the next question, and asking it specifically enough to surface the compiled expertise the expert cannot summarize.

This is where AI earns its place, in two distinct roles that should not be confused. AI as interview designer and structurer is the safe, high-value role: before the interview, the model drafts a question guide built around specific failure modes; during or after, it transcribes the recording and organizes the rambling, jumping-around conversation into a structured knowledge record. AI as the live interviewer is possible and useful in some settings, where the model asks follow-up questions in real time, but it carries a risk: a model that does not understand the domain can ask shallow follow-ups or, worse, accept and record a vague answer as if it were precise. The reliable pattern in 2026 is a human interviewer, ideally a respected peer Dave will open up to, with AI structuring the questions beforehand and the transcript afterward. The human reads the room and asks the sharp follow-up; the AI removes the drudgery of preparation and transcription that usually stops these interviews from happening at all.

Why a peer, not a stranger, runs the room

Experts open up to people who speak their language and respect their craft. Dave will tell a fellow grinder hand the story about the haze and the heat-treat drift that he would never tell a clipboard-carrying consultant, because the peer asks the question that proves they understand the machine. The AI cannot replace that trust. It can, however, hand the peer a sharp set of questions so the conversation goes deep fast, and it can free the peer from taking notes so they can actually listen.

Designing the Interview with AI

A captured-knowledge interview should be built around the plant's actual losses, not around generic prompts. Start from the data: the downtime Pareto for Dave's line, the scrap codes that recur, the work orders that mention his machine, the defects the customer has complained about. Feed that to the model and ask it to draft an interview guide organized by failure mode, with specific, incident-based questions and follow-ups that drill from symptom to sensory cue to action to verification.

A strong prompt looks like this in spirit: you are designing a knowledge-capture interview for a centerless grinder operator with twenty-two years of experience who retires in two months. Here is the downtime Pareto, the top scrap codes, and the recurring customer complaints for his line. Draft an interview guide with one section per major failure mode. For each, write an opening incident question ("tell me about the last time..."), then follow-ups that surface the sensory cues he uses, what he checks first, what he rules out, the exact action he takes, and how he confirms it worked. Include questions about warm-up, changeover, and the upstream and downstream machines he watches. Do not assume any answer; the questions should draw out his answers, not lead them.

What comes back turns a vague "interview Dave" into a focused two-hour session. Instead of starting cold, the peer interviewer walks in with thirty sharp questions aimed at the exact failures that cost the plant money. The model might surface a section the team would have forgotten: questions about the upstream heat-treat oven, because the scrap data shows finish defects clustering after oven maintenance, which is the haze-equals-heat-treat-drift knowledge nobody knew to ask about. That is AI doing what it does best, reading the loss data faster and more completely than a busy team, and aiming the human conversation at the highest-value gaps.

The economics of preparation are simple. A well-prepared interview is the difference between capturing Dave's twenty-two years and capturing his four bullet points. If the prepared session surfaces even one failure mode that would otherwise have caused a 12,000 dollar scrap event next year, the hour the model spent drafting questions paid for itself many times over, and the real prize is the dozens of cues that compound over years.

From Recording to Structured Knowledge Record

The interview produces a recording: ninety minutes of Dave jumping between machines, trailing off, picking up an old story, using shorthand only a grinder hand understands. Raw, that recording is nearly useless to the next shift; nobody will listen to ninety minutes to find the one cue they need at 2 a.m. The capture only becomes an asset when it is transcribed and structured, and this is the second place AI carries the load.

Transcription first. A model turns the audio into searchable text in minutes, a task that used to be skipped entirely because no one had hours to type it. But a raw transcript is still ninety minutes of rambling on the page. The structuring step is what creates value. Feed the transcript back to the model with a target structure and ask it to organize Dave's knowledge into that structure, quoting his actual words and flagging anything ambiguous for human follow-up.

A useful structure for floor knowledge has consistent fields per failure mode: Symptom (what you observe), Sensory cues (the sound, look, smell, feel Dave uses), Likely causes in order (what he checks first and why), Ruled out (what looks similar but is not it), Action (the exact steps), Verification (how he knows it worked), and Related machines (upstream or downstream signals). The model maps Dave's stories onto these fields. The haze story becomes: Symptom, hazy surface finish on ground parts; Sensory cue, a specific dull look distinct from a normal finish; Likely cause, upstream heat-treat oven drift, not the grinder; Action, call the metallurgy lab before adjusting the grinder; Verification, lab confirms hardness back in spec. That is now a record the night shift can read in thirty seconds and act on.

Two non-negotiable rules govern the structuring. Quote, do not paraphrase the technical content. The model should preserve Dave's actual numbers, sequences, and cues verbatim, because a paraphrase is where a fabricated torque value or a softened tolerance sneaks in. Flag every ambiguity for human resolution. When Dave said "warm it up a while," the record should not invent "forty minutes"; it should flag the gap so the interviewer goes back and asks Dave exactly how long. The AI organizes and quotes; it does not fill in the expertise it does not have.

Verify Before You Enshrine

Here is the trap that turns a knowledge-capture program into a liability: a captured myth is worse than no record, because the green crew will trust it. Experts are not always right. Some of Dave's habits are hard-won wisdom; some are superstition that happened to coincide with good outcomes; and the AI cannot tell the difference, because the AI only knows what Dave said and how to organize it. Verification before enshrinement is therefore mandatory, and it is a human and physical step, not an AI step.

The danger compounds in two directions. First, Dave might be wrong: his "warm it up forty minutes" might really need to be twenty, or the haze might sometimes be the grinder after all. Second, the AI might subtly distort what Dave said, smoothing a "usually" into an "always" or attaching a number to a vague cue. Both failure modes end the same way: the next operator trusts a confident, well-formatted record that is partly false, and the plant has automated a mistake at scale.

So the structured record is a draft until it is verified, and verification has three moves. First, Dave reviews his own record. Read the structured fields back to him and let him correct the AI's organization and catch any place the transcription or structuring drifted from what he meant. This also resolves the flagged ambiguities: he confirms forty minutes, or corrects it. Second, check the captured knowledge against the plant's hard data where possible. If Dave says tonnage or temperature or a dimension matters at a specific value, confirm it against the historian, the spec, or the control plan, the same grounding discipline that governs every AI-touched record. A cue that the data contradicts gets flagged, not enshrined. Third, validate before you teach it. A claim that cannot be confirmed by Dave's own review and by the data is marked as unverified expert opinion, useful context but not an instruction, so the next crew knows the difference between a proven cause and a hunch.

This is the same cardinal rule that runs through the whole program, now pointed at knowledge instead of a single decision: verify every AI-touched spec, procedure, and root cause against the drawing, the standard, and the historian. The knowledge base ships under the plant's name; if it tells a new tech to set a wrong value, the accountability is the plant's, not the AI's and not Dave's. The verified record is the asset. The unverified record is a faster way to teach the whole crew the same mistake.

A Worked Capture, End to End

Run the full loop on Dave, with the calendar and the numbers visible. The deadline: the last Friday in November, roughly eight weeks out. The expert: twenty-two years on the centerless grinder. The risk: about 44,000 dollars a year of losses he quietly prevents.

Step one, mine the losses and design the interview. The CI lead pulls Dave's line downtime Pareto, top scrap codes, and recurring customer complaints and feeds them to the model with the interview-design prompt. The model returns a guide with one section per failure mode and, critically, a heat-treat section the team would have missed because the scrap data shows finish defects after oven maintenance. Preparation time: under an hour of model and review work instead of a week of nobody getting around to it.

Step two, run the interview. A respected fellow grinder hand interviews Dave for ninety minutes, recording with consent, using the AI guide but free to chase the stories. Because the questions are incident-based ("tell me about the last time parts came out oversize on a cold morning"), Dave tells stories, and the cues pour out: the forty-minute warm-up, the haze-equals-heat-treat tell, the sound of a wheel about to load up.

Step three, transcribe and structure. The model transcribes the ninety minutes in minutes and organizes it into the seven-field structure, quoting Dave verbatim and flagging six ambiguities, including "warm it up a while" with no number.

Step four, verify. Dave reviews his own record and resolves the flags: warm-up is forty minutes confirmed, the haze tell is real and he has called the lab on it twice this year. The reliability engineer checks two of Dave's numbers against the historian and finds them consistent. One superstition, a belief that running the machine slightly fast on Mondays helps, cannot be confirmed by data and is marked unverified opinion rather than instruction.

Step five, publish and ground the AI. The verified record goes into the plant's knowledge base, searchable by the next shift and available as grounding data for the maintenance and quality AI tools. Now when a green operator sees haze, the knowledge base, in Dave's verified words, tells them to call the lab before touching the grinder.

The payback. The capture cost a few hours of model work, a ninety-minute interview, and a verification pass: call it one focused day across a few people. Against that, the plant retained roughly 44,000 dollars a year of loss prevention that would otherwise have walked out in November, and it fueled its AI tools with exactly the plain-language failure knowledge they were starving for. Eight weeks before the deadline, with a thin and greening crew, the plant turned one man's twenty-two years into a shared, verified, machine-readable asset. That is knowledge capture as the real AI enabler: not a form, but a structured conversation, run by a trusted human, accelerated by AI, and verified before anyone is taught to trust it.

Key Takeaways

• The retirement wave, not the technology, is the emergency: a single retiring expert like Dave can quietly prevent tens of thousands of dollars a year in scrap and downtime, and that protection leaves uncaptured the day they walk out unless you capture it first.
• Knowledge capture is the highest-return move a thinning plant can make and the fuel every floor-AI tool needs, because AI is only as good as the institutional knowledge you feed it.
• Blank documentation forms fail because experts cannot summarize compiled, automatic knowledge; incident-based interviews ("tell me about the last time it failed") surface the cues, exceptions, and stories where the real expertise lives.
• Use AI in the safe high-value roles, designing the interview guide from the plant's loss data and transcribing and structuring the recording, while a respected human peer runs the live conversation that earns the expert's trust.
• Structure each failure mode into consistent fields (symptom, sensory cues, likely causes in order, ruled out, action, verification, related machines), quoting the expert's exact words and flagging every ambiguity for human follow-up rather than inventing values.
• A captured myth is worse than no record because the green crew will trust it; verify before you enshrine by having the expert review their own record, checking claims against the historian and spec, and marking unconfirmed beliefs as unverified opinion, not instruction.
• The same cardinal rule applies: the knowledge base ships under the plant's name, so accountability for a wrong captured value stays human, and verification against the drawing, the standard, and the historian is mandatory.
• Done well, an eight-week capture turns one expert's decades into a searchable, verified, machine-readable asset that the next shift can act on in seconds and the plant's AI tools can ground on, paying back its small cost many times over.