Every industrial company has a short list of people it cannot afford to lose. The chief estimator who can look at a mechanical set and tell you what the engineer left off. The process engineer who knows the bypass around the second exchanger went in during a turnaround and never made it onto the P&ID. The project manager who remembers why the engineer rejected the first chiller submittal on a job years ago. Many of them are within sight of retirement.
Companies usually treat this as a people problem: succession plans, retention bonuses, a knowledge-transfer project in the final months. We think it is a data problem. That framing changes what you do about it, and when.
Where the knowledge actually lives
Expert judgment in an industrial company lives in two places. One is the expert's head. The other, easier to overlook, is the margins of the documents. A few examples of what sits there:
- Redlines on a P&ID from the last turnaround that were never drafted into the CAD file.
- A note on a mechanical plan saying the existing duct size has to be verified in the field.
- A comment in an estimate workbook explaining why the labor factor on an occupied hospital renovation is higher.
- An RFI response that changed a job's scope and lives only in an email thread.
- A submittal markup recording why the engineer rejected the first selection.
- The MOC record explaining why a relief valve was resized, filed somewhere other than the P&ID it changed.
None of this is trivia. These are the reasons behind decisions, written down when the decision was made and attached, loosely, to the document it concerned. What the expert carries is the index: which notes matter, where they are, and what they mean together.
The expert's head is not where the knowledge is stored. It is the index.
When the expert leaves, the notes stay and the index goes.
Why interviews and wikis fail
The standard response is a knowledge-capture project. The expert sits down with a junior engineer or a consultant for a series of interviews, and the output is transcripts, slide decks and a binder. Little of it gets used, for three reasons.
- Expert knowledge is triggered by context. A senior estimator does not carry an abstract list of things to check on a lab building. They notice the missing exhaust fan when they look at the sheet. Asked in a conference room, they give you the general version.
- The output isn't attached to anything. A transcript that says to watch the condensate drains on rooftop units is nowhere near the rooftop units on the next job.
- It is a snapshot taken at the worst moment, when the expert is leaving and the list of things to explain is longest.
Wikis fail the other way around. They depend on experts writing continuously, outside their work, for readers they never see. The pages that do get written go stale, aren't tied to the drawings or assets they describe, and lose to the faster option of asking the person down the hall, for as long as that person is down the hall.
Both approaches try to pull knowledge out of the work and store it somewhere else. That is the mistake. Knowledge kept apart from the documents it concerns won't be found when those documents are open.
Make the documents computable
The alternative starts with the documents. When a P&ID is a typed graph rather than an image, each pump, line, valve and instrument is an object that can carry information: its tag, its connections, its revision history and the notes attached to it. When a mechanical set is read into quantities tied to the sheet and region they came from, a note about a duct run belongs to that duct run.
That changes where knowledge can live. The turnaround redline becomes a revision delta on a specific line. The reason the relief valve was resized attaches to the valve, with the MOC record linked. The estimator's warning about condensate drains sits on the rooftop units in the jobs where it mattered, where the next estimator can find it.
Take an example. Say a reliability engineer is scoping the replacement of that second exchanger. Today the first step is finding someone who was there for the last turnaround. On a computable set, the engineer opens the exchanger and sees its connections across sheets, the bypass captured from the turnaround redlines, the MOC behind it and the note left by whoever verified it. The expert is still worth a call. They are no longer the only way in.
Capture decisions, not interviews
The second half is capturing judgment where it is exercised. In a verified workflow, experts make decisions all day: accept this detection, correct that tag, this duct is existing and not in scope, this off-page connector points to the wrong sheet, this quantity needs an allowance because the drawings don't show it. Each decision is recorded with who made it, when, what changed and which region of which sheet it concerned.
Verification is the right place to capture judgment because it is work the expert already does. It costs them no extra time, it happens on the actual document, and it happens on every job rather than once at the end of a career.
Taken together, those decisions form an audit log. They are also a record of expert judgment applied to real documents, in context, at the moment it mattered, and over time they hold things no interview produces. For example:
- Which detections a senior engineer corrects on a particular owner's drawing conventions, and how.
- Which scope items a chief estimator adds that the drawings don't show, and on what kinds of jobs.
- Which revision deltas a reviewer treated as significant and which as cosmetic.
Recurring corrections can be turned into explicit checks. A junior estimator can see how similar jobs were verified, and by whom. Judgment stops being something you have to ask for and becomes something you can look up.
The best time to capture judgment is when it is exercised, not in the month before someone leaves.
What it means for owners
For an owner or operator, this is risk management in the plainest sense.
- Process safety. Under OSHA's PSM standard, the P&IDs are part of the process safety information, and management of change depends on knowing what a change touches. An undocumented modification that only one person knows about is a gap in both. Verified drawings, with the expert's corrections and the change history attached, close it.
- Margin. In a contracting business, estimating is the process that decides margin, and the judgment inside it is usually the least documented thing the company has.
- Onboarding. New engineers and estimators learn from the record of decisions on real jobs, not only from whatever time a senior person can spare.
- Succession. A retirement becomes a transition rather than a cliff.
What it means for acquirers
For a private equity firm buying an industrial services company, the retiring expert shows up in diligence as key-person risk, usually handled with rollover equity, earnouts and retention agreements. Those buy time. They don't transfer anything. When the earnout ends, the founder's judgment is either in the company's systems or it is gone.
The window is the first year of the hold, while the founder is still in the business and has every reason to make the transition work. Put the company's documents on a verified layer, have the founder verify the historical jobs that best show how the company estimates, and have them review live bids alongside the next generation. Key-person risk becomes a company asset while the experts are still there to do the verifying. We describe the sequencing in The first 100 days.
The question your diligence team asked at entry, whether the business depends on a few people, doesn't go away after close. It comes back at every operating review and every succession plan. A history of verified jobs and recorded decisions answers it with evidence. We cover how that fits a buy-and-build strategy in The missing layer in the industrial roll-up and on Operon for Private Equity.
Start before the farewell lunch
The usual moment to think about an expert's knowledge is when the retirement date is announced. By then, the best you can do is an interview. Start while they are still doing the work: put their documents on a verified layer, have them review what it reads, and the record of their judgment builds itself, one decision at a time. The platform shows how.
