The paper in brief
Most knowledge-retention programmes begin with documents: procedures, checklists, process maps, and repositories. Manfred Bornemann's paper, A Decision-centric Knowledge Architecture for Knowledge Retention, starts somewhere more consequential: with the decisions an experienced employee knows how to make.
The distinction matters. A procedure can describe what normally happens. It is much less likely to explain how an expert recognizes that this case is not normal, which competing requirement takes priority, when an exception is acceptable, or when work must stop and be escalated. Those judgments are often what keep an operation safe, compliant, and effective.
Bornemann argues that the real object of knowledge retention should therefore be decision-making capability, not documentation alone. The paper develops a Decision-Centric Knowledge Architecture, or DCKA, for reconstructing expert decision logic and making it available to other people in a traceable form.
The paper is available through the ECKM proceedings and DOI record.
What disappears when an expert leaves
Experienced employees do not simply hold more facts. They have learned how to interpret a situation.
They notice weak signals. They recognize familiar patterns in an unfamiliar-looking case. They understand which formal rule governs the work, which organizational precedent matters, who has approval authority, and which apparently minor detail changes the decision. Much of that reasoning is applied quickly and may never appear in a process document.
This creates a dangerous illusion. An organization can have complete-looking documentation and still lose the ability to act consistently when a key person leaves. The files remain, but the interpretive layer that made them useful has gone.
Bornemann's framing sharpens the continuity question. It is not only, “Have we retained the expert's knowledge?” It is, “Can someone else reach a sound decision when the next ambiguous case arrives?”
Capture the decision, not only the outcome
The paper treats an operational decision as a connected structure rather than an isolated answer. DCKA reconstructs relationships among:
- the context in which a decision is being made;
- the signals an expert notices;
- legal, procedural, and organizational constraints;
- the evaluation logic used to weigh competing concerns;
- boundary conditions that define what is acceptable;
- exception patterns, stop conditions, and escalation points;
- historical precedents and lessons that influence the choice; and
- the likely consequences of alternative actions.
This is why capturing why is more durable than recording only what. An outcome describes one past case. The reasoning behind it helps a successor interpret the next case, even when the facts are not identical.
The architecture represents these elements in a knowledge graph. That matters because expert judgment is rarely a straight decision tree. One compliance rule can affect many situations; one contextual signal can change several possible paths; one exception can invoke a different authority or escalation route. A network is better able to preserve those overlapping dependencies than a folder of separate documents.
What the payroll case showed
The architecture was developed and evaluated in the payroll department of an international organization preparing for the retirement of a highly experienced expert. Payroll was a demanding test case: formal regulation mattered, but reliable decisions also depended on organization-specific interpretations, precedents, approval rights, and exception handling.
The researchers used structured expert interviews, supported by existing organizational material. They extracted candidate decision elements, organized them into categories, and repeatedly reviewed the reconstructed logic with the domain expert. Human validation remained authoritative; AI-assisted extraction was used to accelerate the work, not to decide whether the reconstructed knowledge was correct.
In onboarding-oriented scenarios, junior employees used the resulting prototype to explore unfamiliar cases. Rather than receiving a single answer, they could follow the relevant constraints, evaluation criteria, and escalation requirements. The evaluation found the reconstruction plausible enough to support expert transition and orientation, while also making an important limitation clear: the study's main empirical basis was one payroll setting. Applications in research, consulting, and education were exploratory rather than full cross-domain validation.
What this changes about a handover
A task inventory is useful, but it is only the outer shell of a role. The deeper handover sits inside the choices a person makes while carrying out those tasks.
For managers, that means asking questions such as:
- What tells you that a routine case is becoming an exception?
- Which factors do you weigh when two priorities conflict?
- Where can you exercise judgment, and where is the boundary fixed?
- What would make you pause, ask for approval, or escalate?
- Which past incident changed how you handle this work?
- What looks unimportant to a newcomer but changes your decision?
- What information must be available before you are comfortable acting?
These questions do more than produce richer prose. They reveal whether the organization understands the conditions under which its work remains reliable.
The Flamekeeper perspective
The paper reinforces a central Flamekeeper principle: a usable handover must capture reasoning, not just responsibilities.
Role-specific prompts can help an employee move beyond “what I do” toward the cues, trade-offs, exceptions, and escalation logic behind the work. A quality review can then look for the places where an answer names an action without explaining its conditions—for example, a process with no exception path, a decision with no criteria, or an escalation with no trigger.
Follow-up questions are especially important here. Experts often omit reasoning because it feels obvious to them. Asking why a choice is made, what could change it, and how a difficult case differs from a normal one helps make that invisible structure explicit while the expert is still available.
Flamekeeper is not an implementation of DCKA, and a handover document is not a complete model of organizational decision-making. The practical lesson is narrower and powerful: continuity depends on preserving how people interpret the work, not merely the record of what they did.