Every business
Capture expert knowledge before the expert leaves, as answers with a source on every one
The settings that are not in any manual, the noise that means stop, the supplier whose material behaves differently: that knowledge lives in a few heads and walks out with them. This turns it into structured, sourced answers that anyone in the company can query in plain language.
Why knowledge transfer before retirement almost never works
Someone in your company knows things nobody wrote down. Not because they are secretive, but because the knowledge has no obvious shape. It is a set of exceptions: this machine runs differently in winter, that customer never means what the order says, this material needs longer than the datasheet claims. Ask the person to write it down and they produce three pages of things you already knew, because the valuable part does not present itself as knowledge. It presents itself as normal.
So the usual plan is a handover period. Four weeks of shadowing, a shared folder, a farewell cake. What actually transfers is whatever happened to come up in those four weeks. The winter behaviour does not transfer if the handover is in June. The rare fault does not transfer because it is rare. The company finds out what it lost eighteen months later, at three in the morning, when the line stops.
The written attempts fail for a different reason. A document is only found by someone who knows it exists and knows what it is called. The people who need the answer are new, which is exactly why they do not know either. So the knowledge exists and is still unavailable, which from the shop floor looks identical to not having it.
- One person is called at home when a specific machine misbehaves, and everyone has accepted that as normal.
- The official procedure and the actual procedure differ, and nobody has written down why the difference exists.
- A retirement date is on the calendar and the plan is four weeks of shadowing.
- New hires learn by asking colleagues, so the quality of what they learn depends on who was nearby.
- The same mistake gets made every few years because the person who made it last time has moved on.
- There are shift logs, fault reports and handover notes going back years, and nobody reads them.
How expert knowledge gets captured, structured and made findable
The work has two halves. First the knowledge has to come out of the person, which is an interviewing problem, not a software one. Then it has to be stored so that the answer finds the question rather than the other way round. The system does the second half and supports the first.
- 01
Start from the record, not from a blank page
Before anyone is interviewed, the system reads what already exists: shift logs, fault reports, handover notes, maintenance records, old email threads. Most of the raw material is already there in fragments. What comes out is a map of recurring events and unexplained decisions, which becomes the list of things worth asking about.
- 02
Interview against that map
The questions are specific, because specific questions produce specific answers. Not what do you do here, but why does this fault appear every February, and why does the log show 124 bar when the procedure says 118. A person who cannot describe their expertise in the abstract can always explain a concrete case in front of them.
- 03
Turn every answer into a card with a source
Each piece of knowledge is stored as one question and one answer, with where it came from: which person, which date, which conversation, which document. An answer without a source does not get stored. That rule sounds bureaucratic until the first time someone disputes an answer and you can show exactly who said it and when.
- 04
Keep contradictions instead of resolving them
When the interview says one thing and seven years of logs say another, the system does not average them and it does not pick a winner. Both versions stay, the conflict is flagged, and a human decides. That is usually where the most valuable knowledge sits: the gap between what people believe and what actually happened.
- 05
Make it answerable in plain language
Someone on the shop floor asks the question they actually have, in the words they actually use. The system finds the right card, gives the answer and names the source. Nobody has to know the folder structure, the document title or the vocabulary the knowledge was filed under.
- 06
Keep it alive after the expert is gone
New shift logs and fault reports keep flowing in. When a new record contradicts a stored answer, the answer is flagged rather than quietly overwritten. Coverage per area is visible, so you can see which parts of the plant or the process are well documented and which are still one person deep.
- 07
Stop where a human is needed
The system stores, retrieves and flags. It does not decide which of two contradictory settings is correct, it does not invent an answer when no card covers the question, and it says so instead. Anything safety relevant, anything involving money and anything ambiguous goes to a person by default.
Take this with you
An interview prompt that gets real knowledge out of an experienced colleague
This is the interviewing half, in a form you can run today. It is a prompt that turns a chat window into a patient interviewer: one question at a time, always digging for the concrete case behind the rule of thumb, and at the end it writes every finding as a sourced question and answer card. Sit down with the colleague, share a screen, and work through it. It is worth doing even if you never build anything.
You are conducting a knowledge capture interview with an experienced
employee who is leaving, retiring or handing over an area. Your job is to get
out the knowledge that is not in any manual.
SUBJECT
Person: [NAME OR ROLE]
Area: [MACHINE, PROCESS, CUSTOMER GROUP OR TERRITORY]
Years of experience in this area: [NUMBER]
Who will take over: [ROLE, AND HOW EXPERIENCED THEY ARE]
RULES YOU MUST FOLLOW
1. Ask exactly ONE question per turn. Wait for the answer. Never send a list.
2. Never ask "what do you do here". Ask about signals, exceptions and
incidents:
- How do you notice something is going wrong before an instrument shows it?
- Which setting have you changed away from the official specification, and
why?
- What went wrong once that cost real money or real time?
- What does the written procedure say that is no longer true?
- Which case looks routine to a newcomer and is not?
- What behaves differently by season, by shift, by supplier, by customer?
3. When you get a rule of thumb, do not accept it. Ask for the specific
occasion behind it: when did this last happen, what were the actual
numbers, what did you do, what happened next. Keep asking until there is a
concrete case, or the person says they cannot remember one. Then note that.
4. When an answer contains a number, a temperature, a duration, a threshold or
a name, ask what happens if it is wrong in each direction.
5. If the person says "you just feel it" or "you can hear it", stay there.
Ask what it sounds like, what it felt like the first time, how a new person
could tell. That is the most valuable material in the whole interview.
6. Never guess and never fill gaps yourself. If something stays unclear, write
it down as an open question.
AFTER ABOUT 20 QUESTIONS, OR WHEN I WRITE "DONE"
Write the results as cards. One card per piece of knowledge, in this form:
QUESTION the question a newcomer would actually ask, in their words
ANSWER 3 to 5 sentences, concrete, including numbers and conditions
APPLIES when this is true and when it is not (season, product, machine)
SOURCE person, date, and that it came from this interview
CONFIDENCE stated as fact / rule of thumb / disputed
GAP what still needs checking against records, if anything
Then add two lists: OPEN QUESTIONS that need a second session, and
CONTRADICTIONS where something said now conflicts with something said earlier
in this same interview. Do not resolve contradictions. List them.- Book 60 to 90 minutes with the colleague. Do it at the machine or the desk if you can, because the surroundings prompt the memories.
- Fill in the SUBJECT block, paste the prompt, and let the model ask. Type the person's answers in as they speak, or dictate them.
- Resist summarising while you type. Half sentences and specific numbers are worth more than clean prose.
- When you are finished, write DONE and let it produce the cards. Read them back to the person the same day and correct them.
- Repeat per area, not per person. Six short interviews about six machines beat one long interview about a career.
What you get is a document. A good one, and better than most handover folders. But a human has to run the interview, a human has to keep the file, and a human has to remember it exists when a question comes up at two in the morning. It knows nothing about your shift logs, so it cannot check a single answer against what actually happened, and it will not notice when a stored answer stops being true. It also has no memory of the interview you did last month, so nobody will tell you that this expert and the last one disagree.
From an interview document to a knowledge base that answers on its own
The prompt gets the knowledge out of the person. The built system is where it lives afterwards, next to everything the company already recorded, findable by people who do not know it exists.
In the built version the interview is one source among several. Shift logs, fault reports, maintenance records and handover notes are read as well, and every card carries the source it came from. When the interview says a zone runs at 118 bar and seven years of logs say 124 since the rebuild, both stay and the conflict is put in front of a person. Someone asks a question in plain language and gets the answer plus who said it and when. New records keep arriving, and an answer that a new record contradicts gets flagged rather than silently replaced.
It is built to stop rather than guess, which is the only reason anyone on a shop floor will trust it. If no card covers the question it says so instead of producing something plausible. It does not decide between contradictory sources. Safety relevant answers and anything involving money go to a person by default. An answer without a source is not stored at all.
- Every answer carries its source: person, date, document. No source, no card.
- Existing shift logs, fault reports and handover notes are captured too, not just what one person remembers to say.
- Contradictions between people and records are flagged and kept, not averaged away.
- Anyone asks in their own words. Nobody has to know the folder, the file name or the official term.
- Coverage per area is visible, so you can see which parts of the business are still one person deep.
- Runs on your infrastructure, with your access rules, because this is the knowledge you would least like to rent from a vendor.
Frequently asked questions
How do you capture expert knowledge before an employee retires?
Not with a blank document and a request to write things down. You start from the records that already exist, find the recurring events and unexplained decisions in them, and interview against that list with specific questions. Then every answer is stored as one question, one answer and a source. The interview prompt on this page is the version of that you can run yourself this week.
What questions should you ask an expert before they leave?
Ask about signals, exceptions and incidents rather than duties. How do they notice a problem before an instrument shows it. Which setting have they changed away from the official specification and why. What went wrong once that cost real money. What does the written procedure say that is no longer true. Duties are already documented. Exceptions never are.
Can I not just do this with ChatGPT?
For the interview, yes, and that is exactly what the prompt above is for. What a chat window cannot do is remember. It has never seen your shift logs, so it cannot check an answer against what actually happened, it does not know what the previous expert said, and it is not there when someone on the night shift has a question. The built system is the memory around the interview, not a better interview.
We have years of shift logs and fault reports. Is that useful or is it noise?
It is the more reliable half of the material. Logs record what happened, interviews record what people believe happened, and the difference between the two is where the valuable knowledge sits. The system reads both, keeps them separate and flags where they disagree instead of merging them into one confident sentence.
How do we know the answers are correct and not invented?
Because nothing is stored without a source, and the source is shown with every answer. You can always see which person said it, on what date, or which document it came from. When no stored card covers a question the system says so rather than producing something plausible. Where two sources conflict, both are kept and a person decides.
Where does this knowledge live and who can see it?
On your infrastructure: your server or your cloud account, your backups. This is often the most sensitive material a company has, since it describes exactly how the work is really done, so it does not go into a vendor's shared system. Access is set per person and per area. If a language model is used anywhere in it, you decide which one and what it is allowed to see.
How much time does this take from the expert who is leaving?
Less than a shadowing handover, and it does not have to be continuous. Six short interviews of an hour, one per area, produce more usable knowledge than four weeks of watching, because the questions cover the rare cases that four weeks would never happen to include. The reading of existing records costs the expert nothing at all.
There is a date on the calendar
If someone in your company is retiring, changing role or is simply the only person who knows a thing, the interview prompt above is worth an hour this week. If what comes out of it makes you uneasy about where that document will end up, that is the project. Apply and tell us which knowledge you cannot afford to lose.
Apply