Every engineering company has that one colleague. He knows why the circuit board was redesigned in 2011, which supplier caused the problem back then and why variant B should never be touched again. He answers questions in thirty seconds that would take the ticket system thirty searches. And he retires in four years.
In engineering, demographics are not an abstract statistic. The cohorts leaving over the next ten years carry, in many firms, the product and process knowledge of several decades — and successors who could absorb it are almost impossible to find on the labour market. What leaves the company with that colleague appears on no balance sheet, but it will be missing from every future project.
Why the conventional answer fails
The usual response is: “Then he’ll just have to document everything before he goes.” Anyone who has tried this once knows the outcome. Documentation written in advance fails on three counts:
Nobody has time to write it. The experienced colleague is the most sought-after person in the department right up to his last working day — precisely because he knows so much. The calendar never yields the weeks needed for the great knowledge write-up.
Nobody knows what needs writing down. The value of his knowledge reveals itself in the situation, not in advance. The decisive side note — “below minus twenty degrees the housing resonates” — appears in no table of contents planned up front.
Nobody can find it again. Even good documentation dies in the filing system. A wiki with ten thousand pages, half of them outdated, answers no questions — it hides answers.
What an AI knowledge base does differently
The decisive shift in perspective: most of the knowledge has long been written down — just not where anyone looks. It lies scattered across twenty years of Confluence pages, ticket histories, review comments, change requests, test reports and project folders. No human can read that volume. An AI can.
An AI-powered knowledge base — technically: a retrieval system that substantiates its answers from your own documents — turns this stock into a queryable memory:
- Questions in natural language. “Why did we change the connector on the previous project?” instead of five search terms across three systems.
- Answers with source references. Every answer points to where it was found — the change ticket from 2014, the minutes of the design review. Verifiable rather than merely plausible; no free invention by the model.
- On your own premises. Design knowledge is the most valuable trade secret an engineering company has. A knowledge base of this kind belongs self-hosted on your infrastructure — not in someone else’s cloud index.
The departing colleague is not copied by this. But the part of his value that reads “I know where it’s written and what happened back then” stays with the company — and is suddenly available to everyone on the team, not only to those who dare to ask.
Building it: four steps, no heroics
In practice we build knowledge bases along our staged approach — plannable and individually measurable rather than as one grand project:
1. Source inventory. Which repositories contain knowledge: wiki, ALM system, tickets, network drives, test reports? Which of it is legally and organisationally usable? Almost invariably this reveals: there is more there than anyone thought.
2. Establishing data readiness. The uncomfortable, decisive step — AI is only as good as the data beneath it. Clarify access rights, flag duplicates and outdated versions, make formats accessible. Skip this step and you build a machine that confidently quotes from obsolete revisions.
3. Build the knowledge base and go live with a pilot group. One team, one clearly bounded knowledge domain, real everyday questions. Retrieval quality is measured, not asserted — and the system is sharpened on the questions it gets wrong.
4. Capturing knowledge held in people’s heads, selectively. Only now is the conversation with the departing colleague worthwhile: the knowledge base shows where the gaps are. Instead of “write everything down” it becomes “tell us the story behind these twelve decisions” — structured interviews that flow straight into the corpus. That respects his time and targets the knowledge that is genuinely missing.
The limits — stated honestly
To avoid any false impression: a knowledge base does not replace experience. The judgement as to which of the three documented solutions fits the new situation remains engineering work. Three limits belong in any honest consultation:
- Quality depends on the sources. What was never documented, no system can surface. The knowledge base makes what exists findable — step 4 selectively closes the most important genuine gaps.
- Without a maintenance process it goes stale. New projects, new insights have to flow in. That is a defined process within ongoing support, not something that happens by itself.
- Governance is mandatory. Who may query what? Salary lists and design data do not belong in the same index. Access concept and release rules are drawn up before the first import — not after the first incident.
From our own practice
We recommend nothing we do not run ourselves: in our own organisation, a self-hosted knowledge base answers customer and internal enquiries daily — with source references, under human oversight at the critical points. We bring the same set-up into engineering departments before the knowledge there retires.
The uncomfortable truth to close: the best time for this project was five years ago — the second best is while the colleague is still there. After that, safeguarding knowledge becomes archaeology.