Knowledge has a departure date

Information is what has been written down. Knowledge is what lets somebody interpret it.

The distinction sounds academic until you watch it operate. An operator holding a complete drawing set, a full equipment schedule and every manual the contract required can still be unable to answer why a system was configured the way it was, what was tried first and rejected, or which of two apparently identical items is the one that keeps failing.

None of that is missing information. It was never information. It sat in the heads of perhaps six people, and it was transferred between them in conversation, and it left when they did.

A new clause with an unusual property

Clause 7.7, knowledge, is new in the second edition of ISO 55001. ISO lists it among the main changes from 2014, alongside the decision-making subclauses and the strategic asset management plan.

Currency is the word to hold on to. The clause is not satisfied by having captured knowledge once, which is how most handover processes would read it. It asks for knowledge that stays current, and that is a continuing obligation on the receiving organisation rather than a deliverable anybody can hand across.

It shares the support clause with resources, competence, awareness, communication, documented information, and data. What makes it different from all of them is that it is the only one with an external clock attached.

Competence can be built next year. Data can be verified next year, at a cost. Documented information can be reconstructed, painfully, from records that still exist. Knowledge cannot, because the medium it is stored in resigns, retires, demobilises or moves to another programme, and once that has happened there is no version of the exercise that recovers it.

Every other support requirement can be met late and expensively. This one can only be met early or not at all.

Five support requirements and how late each can still be met. Resources and competence can be addressed years later. Documented information and data can be reconstructed within months, at cost. Knowledge under Clause 7.7 has no recovery window at all: no later exercise recovers it.

Item	How late it can still be met	What recovery costs
7.1 Resources	Years	Fund it next year
7.2 Competence	Years	Train or recruit later
7.5 Documented information	Months	Reconstruct from records, painfully
7.6 Data	Months	Re-survey the asset, at cost
7.7 Knowledge	None. It goes when they go.	No later exercise recovers it

Four of the five can be fixed afterwards, which is why they get deferred. The fifth cannot be fixed afterwards at any price, and it is deferred on exactly the same reasoning.

Why the transition case is the acute one

For an organisation moving from delivering assets to owning them, the structural position is worse than the general case in a way that is easy to underestimate.

The people holding the knowledge are not employees whose departure the organisation controls. They work for the contractor, the designer, the commissioning agent, the specialist subcontractor. Their presence on the project is a contractual arrangement with an end date, and that end date is usually shortly after the thing they know about starts operating.

So the organisation is not managing a retention risk. It is managing a deadline it did not set and cannot extend, and the deadline is written into a contract signed years earlier by people who were thinking about delivery.

There is also a motivational asymmetry worth naming plainly. At the point of demobilisation, the party holding the knowledge is frequently in commercial discussion with the party who needs it, about final account, defects, or extension of time. Knowledge that would help an operator may also be knowledge that clarifies who was responsible for something. That does not make anyone dishonest. It makes candour expensive, and it means the window for a frank conversation closes earlier than the contract does.

The question that works

Most attempts to capture knowledge fail because they ask for knowledge, which is a request nobody knows how to fulfil. Lessons learned workshops produce generalities. Handover interviews produce a restatement of what the documents already say.

The question that works is narrow, specific, and slightly rude:

What was accepted rather than resolved?

Every large project ends with a list of things that were not fixed. Items closed out on a technicality, non-conformances accepted with a concession, a system that works but not in the way it was designed to, a temporary arrangement that became permanent because the alternative was a delay. That list is real, it is known to a handful of people, and it lives in their heads and in email.

It is also, reliably, the single most valuable thing operations could be given, because it is a map of where the asset will surprise them.

Asked directly, in writing, before demobilisation, people generally answer. The question is answerable, it does not require anyone to theorise, and it is specific enough that a considered reply takes twenty minutes rather than a workshop.

What the missing categories cost the people who inherit them

, read: Handover is where the cost lands, and the Gulf is now taking deliveryHandover is where the cost lands, and the Gulf is now taking delivery

Design intent, and why it is the expensive gap

The second category is why, as distinct from what.

Drawings record what was built. They do not record that the routing was chosen to avoid a clash discovered on site, that the redundancy was specified for a load case that no longer applies, or that a particular arrangement was a compromise between two requirements that could not both be met.

An operator who does not know why a system is the way it is faces a choice whenever they want to change something. They can leave it alone, which preserves a problem, or they can change it and discover the reason afterwards. Over a forty year operating life this happens repeatedly, and each instance is small enough not to be investigated and expensive enough to matter.

ISO/TC 251 describes Clause 7.7 as asking the organisation to determine the knowledge needed to operate its asset management system. For an asset base, this publication reads design intent as the clearest part of the answer and the one least likely to appear on a document schedule, because no contract deliverable is titled "why".

What examining this looks like

Four things, none of which requires a specialist.

Establish whether design intent is recorded anywhere other than in the drawings. Usually it is not, and establishing that is itself the finding.

Identify the individuals who hold undocumented knowledge, by name, and find out when their involvement ends. On most programmes this list is short and nobody has ever written it down.

Ask, in writing, what was accepted rather than resolved, and do it before the commercial position hardens.

Test whether the organisation has determined what knowledge it needs, which is what the clause actually requires, as distinct from having collected documents.

The framework for this stage sets out the domain and the neighbouring tests, including whether a competent stranger could operate the asset from what was supplied, which is the cheapest verification available and almost never run.

None of that is difficult, and all of it has to happen while the people who hold the answers are still being paid to be there.

---

Sources. ISO 55001:2024, second edition, July 2024, ISO standard 83054, Clause 7.7 on knowledge, new in the second edition and listed by ISO among the main changes from the 2014 edition, and Clause 7.6 on data and information. ISO 55012, people involvement and competence, published in the 2024 family. ISO 19650-3, information management during the operational phase of assets. FIDIC, Conditions of Contract, 2017 edition, Sub-Clause 10.1, which makes supply of as-built records and operation and maintenance manuals, where the contract calls for them, an express requirement of taking over. FIDIC, Rainbow Suite press release, March 2018, page 6, on Sub-Clause 10.1 across the Red, Yellow and Silver Books.