Who owns the relationship between knowledge and a process?

Consider a hypothetical service business. It maintains one instruction for setting up a device and another for handling a reported fault. Both are up to date. The fault-intake process, however, still links to the setup instruction. A new colleague follows it carefully and collects information that does not help with the fault.

The error is neither in the wording of the instruction nor in the sequence of process steps. It is in the relationship between them. A review focused only on outdated documents could miss it. Better search would not necessarily resolve it either: it might make the wrong instruction particularly easy to find.

The content owner can confirm that the instruction is correct. The process owner also needs to judge whether it belongs at this point in the work. In a small business, those responsibilities may sit with the same person. They are still two separate decisions.

There is a reasonable objection: good knowledge management already deals with this. It considers the use, exchange and maintenance of knowledge, rather than merely the storage of files. An organisation that handles this well does not need to rename the work.

I see little value in reducing knowledge management to documents just to position a broader category alongside it. Context management is a useful term to me where it makes an unresolved responsibility visible: maintaining the relationships between knowledge, activities, roles and systems.

In “Prozesse hier, Wissen dort”, I use context governance as a working term for this responsibility. It means agreeing who reviews and maintains those relationships. It does not establish a new standard or necessarily call for another committee.

Return to the service business. Fault intake is now being handed to an external partner. The internal instruction may remain perfectly correct. Its new use raises different questions: what information may the partner access? Who receives incomplete reports? Does an internal review step still need to take place?

An automatic “document updated” notification would not help, because no document necessarily changed. The trigger was a change in use. Changes to roles, systems and processes therefore belong among the review triggers alongside new knowledge versions.

For this particular relationship, I would make the arrangement explicit: the service lead is responsible for deciding which instruction applies during fault intake. The content owner keeps that instruction accurate. If the delivery partner or the process step changes, the service lead reviews the relationship again. That is a small decision someone can act on.

A blanket entry such as “Owner: IT” would be too vague. IT can configure access and enable the link technically. Judging whether the instruction fits the work requires business responsibility.

It would be possible to link every knowledge page to every role, process and system. That would quickly create another documentation workload. A relationship that nobody uses or revisits after changes contributes little to the working foundation.

My test is a specific decision: does this relationship help someone carry out a task correctly, assess a change or direct a question to the right person? The purpose is clear for fault intake. An additional relationship for a general reading recommendation in the team wiki may be unnecessary.

A clearly recorded open question can also be useful. If two teams consider different instructions authoritative, an inventory should preserve that conflict. Choosing an arbitrary link would make the diagram look more complete while making the work less reliable.

An experienced colleague might recognise that a setup instruction does not fit a fault report. We cannot assume that experience is present in an AI response. If the relationship is supplied as context, the incorrect connection can find its way into a convincing answer.

Making more text available does not settle the business decision. My first question before connecting such information is whether we can explain why this source is authoritative for this particular task. If the answer is simply that it lives in the same folder, the foundation remains unresolved.

In the service example, it would already be valuable for the next person to find the appropriate instruction, its scope and the responsible role directly from fault intake. That helps people and gives later AI assistance a dependable relationship to refer to.

The context inventory turns this relationship into a single row that can be reviewed. Record one useful relationship