Most operational technology risk registers are full of technical items: unsupported versions, single points of failure, ageing hardware. The most serious risk in a great many estates is not on the register, because it has a name and a retirement date.

Someone configured the system. They know which interfaces are fragile, which tags lie, why that calculation has an odd constant in it, and what to check first when something looks wrong. None of it is written down, because it never needed to be while they were there.

Why this is worse than it sounds

A documented system with a departing expert loses efficiency. An undocumented one loses capability. The difference shows up roughly six months later, when something breaks in a way that is not covered by the obvious checks and nobody knows where to start.

It also constrains everything before that point. Teams avoid changing systems they do not understand. Upgrades get deferred. Analytics programmes stall because nobody can answer what a tag actually represents. The knowledge gap becomes a brake on the whole estate long before anyone retires.

What is actually worth capturing

Not everything. Most of what matters fits in a surprisingly small set of artefacts.

• Architecture as built. What runs where, what talks to what, which accounts, which dependencies. Almost always different from the design document.
• Interface inventory. What each one connects to, how it is buffered, what its failure mode looks like, who to call at the other end.
• The exceptions. Every estate has them — the tag that reads in the wrong units because a downstream system expects it, the analysis with a hard-coded correction. Undocumented exceptions are where incidents come from.
• Runbooks for the rare procedures. Restoring a backup, failing over, recovering an interface. The things needed once a year, forgotten by then.
• Why, not just what. The reasoning behind the compression settings and the model structure. Without it, the next person will either preserve decisions that no longer apply or undo ones that still matter.

How to do it before it is urgent

Documentation projects aimed at capturing everything generally fail. What works better is attaching capture to work that is happening anyway: when an audit is run, when a migration is planned, when a model is rebuilt. The knowledge surfaces naturally during that work, and writing it down is marginal effort rather than a separate initiative.

Pairing is the other reliable mechanism. A second person involved in real work, not shadowing — doing the next interface change with the expert reviewing rather than the reverse.

A note on consultancies

There is an obvious commercial incentive for a firm like ours to leave clients dependent. We think it is a bad trade. Templates, standards, runbooks and training are deliverables on our engagements by default, and we would rather be called back for the next project than retained because nobody else can operate what we built.

If your historian knowledge sits with one person, that is worth addressing while they are still there to ask. How we approach enablement.