When Dave Retires

Part 3 of 10 – institutional knowledge

Capturing the knowledge that walks out the door.

Dave gave his notice on a Tuesday. Thirty-one years at Spiese Fluid Power, the last nineteen as a planner and buyer. He is retiring in March. Everyone is happy for him. A few people are quietly terrified, and they are right to be.

Dave is the person you ask. Why does that Kohler part carry a ninety-day lead time when the catalog says thirty? Because of a single-source casting and a supplier who shuts for the whole of August – Dave negotiated around it in 2015 and never wrote it down. Why is there a third status code on manifold work orders that the manual doesn't explain? Because a customer once needed segregated lot traceability, a developer added a flag, and the developer is also gone. When a planner stares at the morning's exception messages – and there are about 370 of them a day – Dave is the one who knows which six actually matter.

None of that is in the ERP. The ERP knows what is true. Dave knows why. And in March, the why walks out the door.

What it costs today – and why you can't put a clean number on it

Here is where this post is different from the last one. When a customer PO arrives as a PDF, you can measure the keying time and multiply. Institutional knowledge does not sit still to be counted, and any single dollar figure we published for Spiese would be false precision. So instead, here is how to size it for your own shop – which is the honest version, and the one you can actually act on.

There are two costs, and they behave differently.

The daily tax, while Dave is still here. Count the people whose work routinely stalls on a question only a veteran can answer – at Spiese that is roughly the operational core: the six planners and buyers, the eight in customer service, the inside sales desk, a couple in AP. Call it thirty people. Each of them hits a "I need to ask someone who knows" moment a few times a week. Every one of those is ten or fifteen minutes – the interruption, the wait, the context lost and regained – and every one is also an interruption to Dave. You can measure this in your own shop in an afternoon: ask five people to keep a tally for a week. Most are startled by the total.

The cliff, when he leaves. This is the real cost, and it is a step change, not a trickle. A replacement takes months to become useful and years to approach what Dave carried. In the gap, decisions get made without the why – a buyer trusts the thirty-day catalog lead time on that Kohler casting and promises a ship date the plant cannot hit. One such promise, to one good customer, can cost more than a year of the daily tax. That is the number that should worry you, and it is the one nobody budgets for because it arrives as a series of unrelated-looking mistakes.

The point of the sizing exercise is not a precise figure. It is to notice that both costs are real, both are invisible on any report, and one of them has a date on it: March.

Where the boundary sits

This is the cleanest boundary in the whole series, which is why it is the best place to start.

Dave's knowledge lives in language – in documents, in twelve years of help-desk tickets, in email threads, in the procedures nobody formalized, and in Dave's own head. Retrieving it, connecting a question to the three places the answer is buried, and explaining it in plain terms is exactly what a system of inference is good at.

And crucially, nothing here touches the system of record. The AI is not posting a transaction, not changing a status code, not adjusting a lead time. It is answering "why is this the way it is?" and "how have we handled this before?" It reads; it never writes. The ERP stays the single source of truth for every number; the inference layer becomes a source of explanation sitting beside it.

That missing write-back arrow is the whole reason this is the safe first project. The worst a wrong answer can do is mislead a human who is still in the loop – not corrupt a record.

What the AI does – and what it must never do

Does: takes a question in plain English – "why is this order on hold?", "how do we handle a drop-ship return?", "what's the story on Kohler casting lead times?" – and answers it from Spiese's own documented history, with a citation for every claim: this ticket, that procedure, this email from 2015. It says "here is what I found and where," so the human can judge it. When it doesn't know, it says so.

Must never do:

• Never answer without a source. An unsourced answer is a rumor. Every claim points back to a document a human can open. This is the single most important rule in the post.

• Never present its explanation as authoritative over the record. If the AI says the lead time is thirty days and the ERP says ninety, the ERP wins and the disagreement is surfaced, not smoothed over.

• Never invent a procedure. "I don't have anything on that" is a correct and useful answer. A confident, plausible, fabricated process is worse than silence, because someone will follow it.

• Never cross a permission boundary. If a warehouse clerk asks a question whose answer includes customer margin, the answer respects what that clerk is allowed to see. The retrieval layer inherits the ERP's entitlements – it does not invent its own.

That last one is easy to get wrong and expensive to get wrong. A knowledge system that ignores who's asking is a data-leak waiting to happen.

The plumbing

This is the one place in the series where the interesting data is not in the ERP database.

The transactional record is beautifully structured and already queryable. But Dave's knowledge is in the unstructured pile nobody indexes: the help-desk system, the shared drive full of procedures, the SharePoint nobody trusts, the config that only makes sense with commentary, and – for as long as you have him – Dave. The build is a retrieval layer over that corpus, not over your order history.

Which means the first real work is capture. The help-desk tickets are gold and already digital – twelve years of "here's the problem, here's what we did." The documents need gathering. The config needs a human to write down the why beside the what. And Dave himself should be interviewed while he is still here to answer – recorded, transcribed, indexed. That interview is the highest-return week of work in this entire post, and it has a deadline.

Architecturally: the retrieval layer sits beside the ERP, not inside it. It reads exported documents and tickets, and it can call the ERP's own APIs read-only to ground an answer in live data – "this order is on hold; the credit service says why" – but it never writes. The system of record is a read source here, nothing more.

Failure modes and guardrails

The confident fabrication. Asked something it has no source for, the model invents a plausible procedure. Guardrail: no answer without a citation, and an explicit, trained willingness to say "I don't have that." Measure the un-cited-answer rate; it should be zero. And know the limit of the citation: it makes an answer checkable, not correct – the model can still point at a real document and misread it. That is exactly why the source is shown, and why the human stays in the loop: so the miss can be caught, not trusted on sight.

The stale answer. A procedure changed in 2023 but the 2019 document still says the old way, and the model quotes the old one. Guardrail: date every source, prefer recent, and surface the date so the human sees they're reading something six years old.

The permission leak. The model retrieves an answer that quotes something the asker shouldn't see. Guardrail: entitlements enforced at retrieval, inherited from the ERP, tested adversarially before go-live – deliberately ask, as a low-privilege user, questions whose honest answers would cross a line.

The false anchor. People start trusting the explanation more than the record, because it is fluent and fast. Guardrail: every answer carries its sources and defers to the ERP on any number. The AI is a witness pointing at evidence, not the judge.

How you'd know it worked, and Monday morning

The metric is not deflection volume – it is time-to-answer and time-to-competence. How long does it take someone to get a reliable "why," and how fast does a new planner reach the point where they can work the exception list without tapping a veteran on the shoulder? If a six-month ramp becomes a six-week ramp, the system has paid for itself and then some.

Monday morning, before any software: capture, while you still can.

Interview Dave. Record it, transcribe it, and let him talk through the twenty things he thinks nobody else knows – the Kohler casting, the third status code, the customers who need special handling, the workarounds that have quietly held the place together. That week is the highest-value thing in this post and the only part with a hard deadline, because in March the source is gone.

Then point a retrieval layer at what you already have – the help-desk tickets first, because they are already digital and already written in the shape of question-and-answer. Get one team asking it real questions before you widen it. Measure whether the answers are right, and whether they cite their sources.

Everything else in this post can wait. The interview cannot. Start with what – and who – you have.

Spiese Fluid Power is fictional – a composite built from published industry benchmarks and anonymized operating ratios. Its full operating profile, with sources, is published separately.