Who owns the relationship between knowledge and a process?

Consider a hypothetical service business that supports both the setup of new devices and the handling of later faults. It maintains instructions for both tasks. The fault-intake process, however, still links to the setup instruction. A new colleague follows the link and works through its questions, collecting details about installing the device. The next person instead needs to understand what fault was observed during operation.

A review of the content alone might miss the error because the setup instruction remains accurate. Its use during fault intake is what does not fit. If that relationship is left unchecked, improved search could even make the unsuitable instruction easier to find. Resolving the problem therefore requires someone to compare the documented relationship with the task actually being performed.

The content owner can assess whether the instruction correctly describes setup. Whether it helps with fault intake is a judgment for the person responsible for that procedure. Both tasks may belong to the same person in a small business. Even so, a review should make clear whether it covered only the content or also its use in the particular process.

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.

The distinction becomes particularly clear when the organisation performing the work changes. Suppose the service business hands fault intake to an external partner. The technical description of the device may remain correct, but the new procedure needs a reviewed agreement about which information the partner may use, what it passes to internal service and who receives incomplete reports for clarification.

A document-change notification would not necessarily trigger that review, because the instruction’s content may not have changed. What changed was who uses it and in which procedure. Reviewing relationships only after a new document version would overlook this trigger. Appropriate changes to roles, applications and processes therefore also belong in the maintenance agreement.

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.

In practice, this needs an available person with a clearly described decision to make. If a problem with the instruction appears during the handoff to the partner, intake needs to know where to direct the question. That person reviews its use, consults the content owner where necessary and records the result against the relationship. This turns a general wish for “ownership” into a route through which a specific uncertainty can be resolved.

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