A knowledge management process is the repeatable loop your organisation uses to turn what people know into artefacts other people, and now retrieval systems, can find and trust: trigger, capture, contract, circulate, retire. Five stages. The last one is the one almost nobody runs, and it is the one that decides whether the corpus is safe.
Our position is that the classic knowledge management process spends most of its effort in the wrong place. Textbook versions allocate the bulk of the work to organising: taxonomies, folder hierarchies, tagging schemes, naming conventions. That allocation made sense when a human with a browser had to navigate to an answer. It stopped making sense when a vector index started answering on their behalf. A retrieval pipeline does not walk your folder tree, so the structure buys you almost nothing; what it cannot do on its own is tell a current runbook from an abandoned one. So the effort has to move: less into where a page sits, more into who owns it, what status it claims, and when it stops being true.
On Hacker News in July 2025, a user posting as NanaAmun opened a thread asking whether every company's internal wiki is broken by default. They were trying to make documentation work at a company where, as they put it, "scale's the issue, there are over 10k engineers at my current company." Further down the same thread another commenter, toast0, wrote the sentence that explains most of it: "What is everyone's responsibility is no one's responsibility."
The short answer: Build the process as five stages with an owner and an expiry date attached at capture time, and treat retirement as a scheduled stage rather than an occasional cleanup. Everything else is negotiable; those two fields are not.
Last updated: July 30, 2026.
We have not run this process inside a client organisation and this article reports no benchmark we measured. Every external claim below is read from a primary source and linked; every number we generate ourselves is arithmetic with its assumptions written out, so you can substitute your own.
The loop, with the intake contract as the gate between capture and everything downstream.
What a Knowledge Management Process Has to Produce Now
A knowledge management process has one output that matters: a body of written material where every item has a person answerable for it and a date after which nobody is allowed to assume it is true. Titles, tags and folder structure are instrumentation. The output is a corpus whose claims can be attributed and whose age can be checked, because those are the two properties a reader cannot recover on their own.
That framing is narrower than the field's usual one, and deliberately so. The standard definitions are broad. ISO 30401:2018, Knowledge management systems — Requirements, published in November 2018 by ISO/TC 260, "sets requirements and provides guidelines for establishing, implementing, maintaining, reviewing and improving an effective management system for knowledge management in organizations." It runs to 20 pages. ISO's own record puts it at stage 90.92, "International Standard to be revised", and states it is expected to be replaced by ISO/DIS 30401 within the coming months. A 20-page management-system standard drafted in 2018 is not a process design, and it was not written with a retrieval pipeline in view.
The academic root is older still. The SECI model, described in Farnese and colleagues' 2019 operationalisation study in Frontiers in Psychology, "depicts the four Socialization–Externalization–Combination–Internalization conversion modes generated by the switching process from one type of knowledge to another." It remains the best available account of how knowledge moves between people. The same paper is candid about its practical limits, noting that "owing to its tacit component, the model can be particularly elusive and difficult to test" and that the original author "tended to adopt a philosophical perspective, which made it difficult to actualize the model into a measurement instrument."
So the field has a standard under revision, a theory that is hard to measure, and a large population of vendor guides repeating a seven-stage list. What is missing is an operational spec: what event starts a capture, what a captured item must carry, and what ends its life.
What changed about the reader
For three decades the consumer of an internal knowledge base was an employee with a login. Every control assumed that reader. A page nobody opened was inert, and a stale runbook did no damage until someone found it, at which point they usually noticed the 2019 timestamp and asked around. Retrieval removed both safeguards. Nothing is inert in an indexed corpus, because every passage participates in every semantically adjacent answer, and the timestamp disappears, because what reaches the reader is a paragraph of prose rather than a page with a header. DORA's capability guidance on AI-accessible internal data describes the practice as securely connecting AI systems to "an organization's proprietary information—such as codebases, documentation, and operational metrics—to provide context-aware responses," and reports that doing so "amplifies the positive impact of AI adoption, serving as a statistically significant multiplier for individual effectiveness and code quality." The multiplier runs in both directions. Connect a corpus nobody retires, and the amplifier is pointed at your worst pages.
| Property | Human-era knowledge base | Retrieval-era knowledge base |
|---|---|---|
| Who reads it | An employee with a login | A retrieval service acting for an employee |
| What gets read | A page, opened deliberately | A passage, pulled by similarity |
| Visible age | Header timestamp the reader sees | Usually stripped before the answer is composed |
| Cost of a stale page | One person wastes ten minutes | Every adjacent answer inherits the error |
| Cost of a missing page | Someone asks a colleague | The system answers anyway, from something else |
| Who is accountable | Whoever wrote it, if you can find them | Nobody, unless capture recorded it |
The last row is the whole argument. A knowledge management process that does not record ownership at capture time cannot produce it later, because the person who knew is the person who left.
Why the Classic Cycle Under-Delivers for Retrieval
The classic knowledge management process is not wrong. It is misallocated. Walk the published guides and you find the same seven or nine stages, with the heaviest prescriptive detail landing on organisation: taxonomy design, hierarchy, tagging, naming conventions, folder structure. Ownership gets a line. Expiry gets a bullet inside a "review periodically" step, if it appears at all.
That allocation was rational under browse-and-navigate retrieval. If a human has to find a page by walking a tree, the tree is the product. Every hour spent on the taxonomy was an hour bought back in navigation time.
Semantic search changed the return on that hour. When the index is embeddings, a query lands on a passage whose meaning matches, regardless of where the page sits, so the taxonomy stops being the primary access path. It keeps two jobs: scoping permissions, and giving humans somewhere predictable to put things so duplicates do not accumulate. Neither justifies the share of effort it usually receives, while the two things retrieval made critical are the two the classic cycle barely names. One honest exception: if your organisation's search is keyword-only and no semantic layer is planned, the hierarchy is still doing real navigation work and the classic allocation is closer to correct for you than ours is.
| Effort area | Classic cycle allocation | What retrieval actually rewards |
|---|---|---|
| Taxonomy and hierarchy | High. Often the largest single workstream | Low to moderate. Useful for permission scoping and duplicate control |
| Format and template standards | Moderate | Moderate. Consistent structure helps chunking |
| Ownership per artefact | Low. Usually a programme-level role, not per item | High. It is the only route to correction and to accountability |
| Expiry and retirement | Low. A "review periodically" bullet | High. It is the only defence against confidently wrong answers |
| Contribution incentives | High. Culture, gamification, recognition | Moderate. Necessary but insufficient without a trigger |
The evidence that the corpus, not the pipeline, is the bottleneck
The strongest available evidence for this comes from teams who built retrieval systems and wrote down what broke. In Seven Failure Points When Engineering a Retrieval Augmented Generation System, Barnett, Kurniawan, Thudumu, Brannelly and Abdelrazek report an experience study across three domains, first posted in January 2024. Their first failure point, FP1, is Missing Content: the question cannot be answered from the available documents, and the system may answer anyway. Their case study notes flag the structural problem directly, describing a pipeline with "no quality control possible at development time." Two of their headline lessons are that validation of such a system "is only feasible during operation" and that robustness "evolves rather than designed in at the start."
Read those together and the implication for a knowledge management process is uncomfortable. You cannot inspect your way to a trustworthy corpus after indexing it. Whatever quality control exists has to happen at the moment of capture, because that is the last point at which a human who understands the content is holding it.
The downstream symptom is now well measured on the consumption side. In the 2025 Stack Overflow Developer Survey, the single largest frustration reported with AI tools, cited by 66% of roughly 31,500 respondents, is "AI solutions that are almost right, but not quite." The same survey found more developers actively distrust the accuracy of AI tools (46%) than trust it (33%). Almost-right is the exact output signature of a corpus containing a superseded document that nobody retired.
The counterargument, stated properly
The reasonable objection is that this is a tooling problem, not a process problem. Retrieval stacks can filter on metadata, prefer recent documents, and cite sources so a reader can check the date. Reranking has improved. Some platforms surface freshness scores.
All true, and none of it survives contact with the input. A recency filter needs a reliable modified date, and a wiki where people edit typos on a 2021 page produces a 2026 timestamp on a 2021 claim. A metadata filter needs metadata that someone actually set. Citation needs a page whose title honestly describes its status, so that "Payments runbook" is not in fact a superseded draft. Every one of those controls consumes a field that only the capture stage can produce truthfully. The pipeline can enforce a contract. It cannot write one.
The Five-Stage Loop: Trigger, Capture, Contract, Circulate, Retire
The loop we recommend has five stages, and the names are chosen so a team can remember them without a diagram: trigger, capture, contract, circulate, retire. It is not a new theory of knowledge. It is the classic knowledge management process with a defined entry event added at the front, an explicit exit added at the back, and the organisation stage reduced to its two remaining jobs. Read left to right, these are the knowledge management stages a team actually has to run each week.
| Stage | The question it answers | Output | Typical owner |
|---|---|---|---|
| Trigger | What event obliges someone to write? | A capture task, attached to a work item | The team doing the work |
| Capture | What decision or procedure is being recorded? | A draft artefact, written by whoever knows | The person closest to the work |
| Contract | Who owns this, what does it claim, who may read it, when does it expire? | Four required fields | The named owner |
| Circulate | Who needs to know this exists, and what may retrieve it? | Routing plus an access tier | Knowledge lead plus IT |
| Retire | Is this still true, and if not, does it get corrected or removed? | An updated, superseded or deleted artefact | The named owner |
Two design choices in that table are worth defending, because they are where this differs from the guides you will find alongside it.
Retirement is a stage, not a maintenance activity. Most published processes end at application or reuse, with review folded in as continuous improvement. Continuous improvement is an intention; a stage has a queue, an owner and a due date, so it can be measured and can fail visibly.
Contract sits before circulation, not after. In the classic cycle, metadata is applied during organisation, after content exists and often by someone who did not write it. Moving it earlier means an artefact that has not declared an owner and an expiry does not get published, indexed, or read by a retrieval system. The gate is what makes the field non-optional.
Prerequisites: What Has to Be True Before You Start
Every guide on how to create a knowledge management process opens with a platform or a taxonomy. Start here instead. Do not begin until four things are settled, because each of them will otherwise stall the rollout somewhere between week three and month four. None require budget. All require a decision someone is empowered to make.
1. A named accountable person for the programme, with the authority to refuse content. Not a committee. A committee can agree a taxonomy; it cannot say no to a director who wants their deck in the knowledge base. The refusal power is the whole job. If nobody has it, the corpus grows without limit and stage five becomes unrunnable.
2. An inventory of where knowledge currently lives, including the places you would rather it did not. Wiki, tickets, shared drives, chat channels, personal notes apps, recorded meetings, the senior engineer's local markdown folder. You are not migrating any of it. You need the list so you can decide, per source, whether it is in scope, out of scope, or read-only archive.
3. An agreed definition of what counts as knowledge for your organisation. The most useful test we have seen in the field is whether the artefact would change what a competent newcomer does. A decision with a rationale passes. A meeting recording usually does not, until someone extracts the decision from it. Chat threads almost never pass. Write the test down in one sentence and apply it mechanically, because everyone will otherwise apply their own.
4. Access tiers that already exist, or can be created in the first fortnight. At minimum: open to everyone, restricted to a function, restricted to a named group. If you cannot express those in your current tooling, fix that before you start capturing, because retrofitting permissions onto an indexed corpus is substantially harder than setting them at intake. This is the point where a knowledge management process becomes an access-control problem, which we treat in more depth in our earlier analysis of knowledge management governance for AI that retrieves.
What you do not need before starting: a platform migration, a taxonomy, an executive sponsor deck, or a vendor. Each of those is a common reason a rollout spends its first quarter on preparation and never reaches capture.
Stage 1. Trigger: Bind Capture to Work Events, Not Calendars
A trigger is the named event that obliges someone to write something down. None of the published guides we surveyed for this article name it as a stage, and its absence explains most documentation failure. When capture is scheduled rather than triggered, it competes with delivery work and loses, every time, on every team, in every organisation we have read about.
The Hacker News thread that opens this article is full of people describing that loss. One commenter, al_borland, tried to build the habit by example and reported: "I tried to lead my example, but no one else ever joined in." A trigger removes the contest instead of trying to win it. You name the work events after which an artefact is required, and the work is not finished without it.
A starting trigger list
These are the triggers we would put in a first version. Adapt the vocabulary to your function; the shape holds across engineering, operations, finance and support.
| Trigger event | Artefact required | Owner assigned | Typical size |
|---|---|---|---|
| A decision is made that constrains future work | Decision record | The decider | 200 to 400 words |
| An incident is resolved | Cause and fix note, linked to the incident | Incident lead | 300 to 600 words |
| A recurring manual task is performed a third time | Runbook | The performer | Procedure plus prerequisites |
| A customer question is answered from scratch twice | Support answer | The answerer | 150 to 300 words |
| A person changes role or leaves | Handover artefact per owned area | The leaver, before last week | One page per area |
| An exception to a policy is approved | Exception record with expiry | The approver | Short, always dated |
| A vendor, model or connector is approved for use | Approval record with scope | The approver | Short, always scoped |
The strongest of these is the decision trigger, and it has a mature precedent. The architecture decision record was popularised by Michael Nygard in 2011, and the community reference at adr.github.io describes it as capturing "a single AD and its rationale," which "can help you understand the reasons for a chosen architectural decision, along with its trade-offs and consequences." That format has survived fifteen years because it is short, fixed in shape, and written while the writer still remembers why.
The rule of three
The third trigger encodes a rule worth naming: write it on the third time, not the first. The first time, you are still learning the task and whatever you write will be wrong. The second time, you might be about to automate it away. The third establishes it as recurring while the first two attempts are still in memory. Document on the first occurrence and you get a corpus of one-offs; wait for the fifth and the details are gone.
Stage 2. Capture: Write the Decision, Not the Document
Capture is the stage where a person who knows something writes it down, and the single most useful constraint you can place on it is a length ceiling with a required shape. Knowledge capture fails at long-form because a long document takes an afternoon nobody has, and because its length hides which sentence is actually the claim. This is the stage of the knowledge management process where quality is decided, since it is the last moment a person who understands the content is holding it. A decision record with five headings takes twenty minutes and puts the claim in the first line.
The shape we recommend, adapted from the decision-record tradition and applicable well beyond engineering:
- Context. What was true that forced a choice. Two to four sentences.
- Decision. One sentence, in the active voice, naming who decided.
- Alternatives considered and why they lost. One line each. This is the part that saves the most time later, because it stops the next person relitigating.
- Consequences. What is now harder, what is now easier, what has to be maintained.
- Status. Proposed, accepted, superseded by, or deprecated. Never blank.
That fifth heading does a job most templates miss. A status field written at capture time turns the eventual retirement into an edit rather than an archaeology exercise, and it lets a retrieval system distinguish an accepted decision from a rejected proposal, which is precisely the distinction that produces almost-right answers when it is absent.
Tacit knowledge, honestly
The SECI literature is right that the most valuable knowledge is tacit, and that externalising it is difficult. That difficulty is real and no process removes it. What a process can do is narrow the target. Do not attempt to capture how a senior engineer reasons. Capture the specific judgement calls they made, in the moment they made them, as decision records with the alternatives written out. The reasoning is not transferable in prose; the accumulated decisions largely are.
For the residue that genuinely will not write down, pairing and recorded walkthroughs are the mechanisms the field keeps returning to, and their output is a training input rather than a corpus entry. One caution, since teams increasingly reach for transcription: a recorded meeting is not a captured artefact. It is raw material. Indexing raw transcripts is a fast way to fill a corpus with conversational hedging and abandoned proposals, which is a direct route to the missing-content failure mode above. Extract the decision, then discard or archive the transcript outside the retrieval scope.
Who writes it
The person closest to the work, not a technical writer, and not the manager. Central writing teams produce better prose and worse accuracy, and accuracy is what a retrieval system consumes. A technical writer earns their keep by editing, owning the templates, and running the stage-five queue, which is a full-time job at scale and a poor use of an engineer.
Stage 3. Contract: The Four Fields Every Artefact Carries
The contract stage is a gate, not a task. Before an artefact is published or indexed, it declares four fields, and an artefact missing any of them does not pass. We call this the intake contract, and it is the smallest intervention in this process with the largest effect, because every downstream control in the knowledge management process depends on fields only this stage can produce.
| Field | Values | Why it exists | What breaks without it |
|---|---|---|---|
| Owner | A named person, or a named role with a current holder | Someone answerable for correctness | Nobody can be asked to fix an error; corrections stall |
| Status | Current, superseded, deprecated, draft | Distinguishes a live claim from a historical one | Retrieval cannot tell a rejected proposal from policy |
| Audience tier | Open, function-restricted, named-group | Scopes who and what may read it | Permissions are retrofitted onto an index, badly |
| Review by | A date, never blank, never "annual" as a concept | Forces an exit decision | The artefact lives forever by default |
Four fields, roughly ninety seconds. Everything else your platform offers, tags, categories, related links, is optional and can be added later by anyone. These four can only be set by someone who understands the content, at the time they understand it.
Owner: a person, not a team
"Owned by the Platform team" is the most common failure of this field, for the reason toast0 gave in that Hacker News thread. A team can hold an area; an artefact needs a person, with a role-based fallback that has a current named holder. When that person leaves, the handover trigger fires and reassignment happens then, not eighteen months later when someone notices the page is wrong.
This matters more once agents enter the picture, because a retrieval service is itself a reader that needs an accountable party. The same discipline that gives a document a human owner should give a non-human identity an owner, a scope and an expiry, which is the argument we made in owner, scope and expiry for AI agents.
Review by: a date, chosen on purpose
Uniform annual review is the same as no review: a single queue of everything due in January will not be worked. Set the interval from volatility.
| Content type | Suggested review interval | Reasoning |
|---|---|---|
| Pricing, rates, commercial terms | 3 months | Changes without announcement; wrong answers are costly |
| Runbooks and operational procedures | 6 months | Tracks infrastructure change |
| Policies and standards | 12 months | Deliberate change cadence, usually versioned |
| Decision records | Never expires; status changes instead | The decision was true when made; supersession is the correct edit |
| Onboarding material | 6 months | Highest read volume, highest cost of being wrong |
| Exception approvals | Set to the exception's own end date | Expiry is the point of the artefact |
Decision records earn the exception in row four. A decision made in 2023 is a fact about 2023 and should not be deleted when it stops being current. It gets a status change to superseded and a link to the record that replaced it, which preserves the reasoning trail that makes the corpus worth having.
Stage 4. Circulate: Findability Is a Routing Problem
Circulation has two jobs that are usually confused: telling the specific people who need to know that an artefact now exists, and scoping what may read it. Neither is search, and neither is solved by putting the page in the right folder.
Push and pull do different work. Search answers a question someone already knows they have. Routing tells someone about a change they did not know had happened, which is the failure behind most "we had that documented and they did it wrong anyway" incidents. A superseded pricing page needs a note to sales, not a silent edit.
Scoping the retrieval surface
The second job is where a knowledge management process stops being a content discipline and becomes an access one. The default in most rollouts is to index everything and filter at query time, if at all. DORA's guidance on AI-accessible internal data recommends the opposite posture. On access it is blunt: never connect AI tools to internal data using a "super user mode" or shared service account, and instead implement a "least privilege" model "where the retrieval mechanism operates with the user's own credentials". On retrieval it recommends pulling "only the specific chunks of relevant data (a practice emerging as “context harvesting”)" rather than raw documents. And it puts the corpus before either of those: "you shouldn't connect it to information that is wrong. High-quality documentation is a primary driver of AI adoption."
That ordering is the part most teams invert. Connecting an assistant to the wiki takes an afternoon. Making the wiki worth connecting takes a quarter. Doing them in the wrong order produces a fluent system answering from documents nobody has vouched for, which is the specific way knowledge management pilots fail, a pattern we examined in why AI pilots stall between demo and production.
A workable rule: an artefact enters the retrieval scope when its status is current, its owner is a current employee, and its review date has not passed. Fail any of the three and it stays in the human-browsable archive, findable by a person who navigates deliberately, invisible to the index. That is one query against your four contract fields, and it is the highest-value automation in this entire process.
Stage 5. Retire: The Stage Almost Nobody Runs
Retirement is the scheduled review of every artefact whose review-by date has passed, ending in one of four outcomes: confirm, correct, supersede or delete. It is a stage with a queue and a due date, not an aspiration to keep things tidy. Most knowledge management process designs give it a single bullet. Skipping it is why the phrase "documentation graveyard" exists, and in a retrieval-connected corpus it has stopped being a tidiness problem at all.
The clearest statement of the stakes came from freedomben in that same thread: "Out-of-date documentation can be worse than no documentation at all." Under human browsing, that is a strong claim. Under retrieval it is arithmetic. A missing document produces an unanswered question. A wrong document produces an answered one, delivered with the same confidence as a correct answer, attributed to your organisation, with the date stripped out.
The four outcomes
| Outcome | When | Cost | What the reader sees afterwards |
|---|---|---|---|
| Confirm | Still true; owner re-signs and sets a new review date | Two minutes | Same artefact, newer review date |
| Correct | Mostly true, specific claims changed | Ten to thirty minutes | Updated artefact, same location |
| Supersede | A newer artefact replaces it | Five minutes plus the link | Status "superseded by", removed from retrieval scope |
| Delete | Was never right, or the subject no longer exists | Two minutes | Nothing. Log the deletion, not the content |
Confirm is the most common outcome and the one that makes the queue affordable: most reviews are a two-minute yes. A steady-state process reviews a predictable trickle rather than an annual mountain.
Retirement has a legal edge, too
If any part of the corpus contains personal data, retirement is not optional hygiene. Article 5(1)(d) of the GDPR requires personal data to be "accurate and, where necessary, kept up to date", adding that "every reasonable step must be taken to ensure that personal data that are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay." Article 5(1)(e) adds storage limitation: personal data must be "kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed."
An internal knowledge base full of customer examples, escalation notes and named case histories sits inside that scope. A review queue with a delete outcome is the operational answer to both principles. A knowledge base with no retirement stage has no mechanism to satisfy either, and the gap becomes visible at exactly the wrong moment.
Why the queue must be small
Retirement rarely fails because people refuse to review. It fails because the first queue contains everything ever written, and a queue that size is abandoned within a fortnight. Three mechanics prevent that.
Stagger the initial dates. Retrofitting contracts onto an existing corpus, do not set every review date to the same day. Spread them across the interval, highest-traffic artefacts first.
Make the consequence automatic. The reason review reminders fail is that ignoring one costs nothing. Wire the retrieval-scope query in stage four so that an artefact past its review-by date leaves the index on its own, with no human in the loop and no approval. The owner then finds out because someone tells them the assistant stopped answering questions about their area, which is a far more reliable prompt than an email. This also fails safe: the worst outcome of a neglected queue is a smaller corpus, not a more confident wrong one.
Bound the backlog explicitly. Everything written before the process started goes into an archive tier that is human-browsable and outside retrieval scope, and it comes out of the archive only when someone actively requests it and an owner claims it. Pull, not push. This is the single decision that makes a legacy corpus tractable, and refusing to make it is why "we will clean up the old wiki first" is where rollouts go to die.
A Complete Worked Example: One Team's Intake Contract
Here is the artefact assembled, so the knowledge management process above is concrete rather than described. This is a fictional but realistic example written to illustrate the format; it is not a client engagement and no numbers in it were measured. A twelve-person payments team is closing an incident and the incident-resolved trigger has fired.
The artefact, as written into the knowledge base:
Title: Card settlement mismatch after provider retry storms Owner: M. Osei (Payments, staff engineer). Fallback role: Payments on-call lead. Status: Current Audience tier: Function-restricted (Payments, Finance Ops) Review by: 2027-01-15 (6 months, runbook interval) Context. On 2026-07-11 our settlement reconciliation flagged 340 mismatched card transactions over four hours. The provider had retried a batch after a timeout on their side; our idempotency key was scoped per request rather than per transaction, so retries created duplicate settlement rows that reconciliation read as mismatches. Decision. M. Osei decided to scope idempotency keys per transaction identifier rather than per HTTP request, and to add a reconciliation pre-filter that collapses duplicate rows sharing a transaction identifier before the mismatch count is computed. Alternatives considered. - Ask the provider to stop retrying. Rejected: their retry behaviour is contractual and documented, and we cannot depend on it changing. - Widen the reconciliation tolerance window. Rejected: hides real mismatches, which is the failure this job exists to catch. - Deduplicate at the reporting layer only. Rejected: leaves duplicate rows in the settlement table, which Finance Ops reads directly. Consequences. Reconciliation now depends on transaction identifiers being present on every settlement row, so the ingest path must reject rows without one. Finance Ops queries against the settlement table no longer need their own deduplication step and should be simplified; that is tracked separately. The provider integration document needs the retry behaviour written into its assumptions section. Related artefacts. Provider integration overview (owner: same); Reconciliation runbook (owner: Payments on-call lead), which is now inaccurate at step 4 and has been flagged for correction.
What the process did around that artefact:
| Stage | What happened | Elapsed |
|---|---|---|
| Trigger | Incident closed; capture task auto-created on the incident record, assigned to the incident lead | 0 minutes, automated |
| Capture | M. Osei wrote the five sections | 25 minutes |
| Contract | Four fields set; review interval chosen from the runbook row of the interval table | 2 minutes |
| Circulate | Posted to the Payments channel and to Finance Ops, because the consequences section named them. Tier set to function-restricted, so it enters the retrieval scope for those two functions only | 5 minutes |
| Retire | Review queued for 2027-01-15. Separately, the related reconciliation runbook was flagged inaccurate, which pulls its review forward to now | queued |
Total human cost: about 32 minutes. The part most teams skip is the last line of the circulate row and the last clause of the retire row. Flagging the neighbouring runbook as inaccurate is what stops a retrieval system confidently returning step 4 of a procedure that no longer works, three months from now, to someone who was not in the incident.
What this example is not
It is a format demonstration, not evidence that the process works. Any vendor showing you a tidy percentage improvement from a knowledge management rollout should be asked what the baseline measurement was and who took it.
What the Process Costs, in Hours You Can Count
The steady-state cost of running this knowledge management process is about 7.3 hours a week for a forty-person department, which is roughly half of one percent of that department's working hours. That figure is arithmetic from stated assumptions, not a measurement, and the assumptions are where you should argue with it.
Assumptions. A 40-person department in 8 teams. Each team hits a capture trigger about once a week, giving 8 new artefacts per week. Capture averages 25 minutes, as in the worked example. Contract fields add 2 minutes. Circulation adds 5 minutes. Reviews run at a 6-month average interval, so steady-state weekly review volume equals weekly intake, 8 reviews, at an average of 8 minutes each once the mix of two-minute confirms and thirty-minute corrections is blended.
| Line item | Calculation | Weekly hours |
|---|---|---|
| Capture | 8 artefacts x 25 min | 3.33 |
| Contract | 8 x 2 min | 0.27 |
| Circulate | 8 x 5 min | 0.67 |
| Retire (steady state) | 8 reviews x 8 min | 1.07 |
| Programme coordination | Fixed, one person part-time | 2.00 |
| Total | 7.34 |
At a fully-loaded cost of 80 US dollars an hour, that is about 587 dollars a week, or roughly 30,500 dollars a year, for a 40-person department. Substitute your own rate.
The one-off setup cost is separate and larger. Retrofitting contracts onto an existing corpus is the expensive part, and it is why the archive-tier decision in stage five matters so much. Contracting 500 legacy artefacts at 3 minutes each is 25 hours. Contracting 5,000 is 250 hours, close to seven full weeks of one person's time, and at that scale the correct answer is to contract only what people actually retrieve and archive the rest unclaimed.
Break-even, stated as arithmetic rather than a claim. The process pays for itself if it saves more than 7.34 hours a week across 40 people. That is 11 minutes per person per week. We are not asserting it does; we have no measurement and neither, in our reading, does anyone publishing a percentage. What we can say is that the threshold is low enough that the honest question is not whether the arithmetic works but whether the process is actually run, which is a management question rather than an economic one. If you need evidence before committing beyond a pilot, the cheapest instrument is a repeat-question count in one team's support or engineering channel, taken for two weeks before the pilot starts and again at week twelve. It is a weak measure, it will not isolate the cause, and it is still better than the vendor percentage you would otherwise be quoting.
Measuring It: Four Numbers That Move First
Measure the knowledge management process before you measure the outcomes, because process metrics move in weeks and outcome metrics move in quarters, and a programme that reports nothing for two quarters is cancelled in the second. Four numbers, all countable from your platform's own fields.
| Metric | Definition | What it tells you | Healthy direction |
|---|---|---|---|
| Contract completeness | Share of retrieval-scoped artefacts with all four fields set | Whether the gate is real or waved through | Above 95%, or the gate is not enforced |
| Overdue review rate | Share of artefacts past their review-by date | Whether stage five is being run | Below 10%, and stable rather than growing |
| Orphan rate | Share of artefacts whose owner has left or changed role | Whether the handover trigger fires | Near zero; a rising number predicts corpus rot |
| Retirement mix | The split of confirm, correct, supersede and delete outcomes | Whether reviews are real | A queue that is 100% confirm is being rubber-stamped |
The fourth metric is the one that catches the failure the other three miss. al_borland described it precisely in that Hacker News thread: formalising review produced "nothing but lazy rubber stamps, even from people who typically did excellent work." An all-confirm queue looks like a healthy process and is not one. Expect something in the range of a majority confirms with a visible minority of corrections and supersessions, and investigate if corrections never appear.
Outcome metrics follow later: time to first productive week for new joiners, repeat-question rate in support channels, and the share of retrieval answers whose cited source is current. That last one is only measurable if your retrieval layer records what it read, which is a logging decision rather than a knowledge one, and the subject of our separate work on audit trails that prove what an AI system actually did. Two metrics to avoid: page count, which rewards the behaviour you are trying to stop, and contribution leaderboards, which produce volume and not accuracy.
Common Mistakes That Kill a Knowledge Management Process
Most of the failures below were described publicly by practitioners in threads like the one this article opens with; the last two are our own reading rather than anyone's testimony. None are exotic, and all are structural.
Starting with a platform migration. The tool is rarely the problem, and a migration consumes the political capital the process needs. Run the process on whatever you already have for two quarters. If it still fails, the tool is a defensible diagnosis rather than a guess.
Making knowledge capture everyone's continuous obligation. This produces the responsibility diffusion described earlier. Bind it to triggers with named owners instead.
Assigning ownership to teams. Teams reorganise, and ownership evaporates without anyone deciding it should. Names with role fallbacks survive that.
Designing the taxonomy first. Categories should emerge from about a hundred real artefacts, then be formalised.
Cleaning up the old corpus before starting. This is the most common way a rollout spends a quarter and produces nothing. Archive it, exclude it from retrieval scope, and pull items out on demand.
Indexing raw transcripts. Recording is cheap and extraction is not, so the tempting move is to index everything said. The result is a corpus dense in hedging and abandoned suggestions, which is the missing-content failure in a different costume.
Treating "AI will fix it" as the process. A commenter in that thread, nlpnerd, connected these directly, observing that knowledge management is a popular target for LLM proof-of-concepts and, for the same reasons, one where "POCs don't progress into something more permanent." Retrieval is a consumption improvement layered on a capture discipline. It does not substitute for one.
Letting personal AI assistants become the knowledge base. This one is newer and worth naming. When individuals build good prompts and personal context files that encode how the work is really done, that knowledge leaves with the individual and is invisible to everyone else. It is tacit knowledge in a new container. We treated the promotion path from personal prompt to owned company asset in turning personal prompts into shared, owned agents.
Skipping the refusal. A knowledge base that accepts everything cannot be reviewed, because the review volume scales with acceptance. The accountable person's most valuable act is declining content that fails the newcomer test.
Where This Is Still Uncertain
Several parts of this are argued rather than demonstrated, and it is more useful to say which than to write around them.
We have no controlled evidence that this arrangement of knowledge management stages beats the seven-stage textbook version. Nothing we found compares a knowledge management process with an enforced retirement stage against one without, in the same organisation, on the same corpus. The components have support, per-artefact ownership, decision-record capture, and scheduled review all appear in practitioner literature with long track records. The claim that reallocating effort from taxonomy to contract and retirement improves retrieval quality is our inference from the RAG failure literature and DORA's capability guidance, not a finding either source states.
The cost model is arithmetic, not measurement. Every figure in that table is a stated assumption multiplied out. Real capture times vary by domain, and a regulated environment with review sign-offs will run considerably higher.
Tacit knowledge remains substantially uncaptured under this or any process. The SECI literature's honest position, that the tacit component makes the model "elusive and difficult to test", still holds. We have narrowed the target to decisions rather than reasoning, which helps, and which also concedes that the reasoning does not transfer.
Retrieval technology may move the boundary again. If freshness and contradiction detection improve materially, some of what we assign to the contract stage could migrate into the pipeline. Unlikely for ownership, which is a social fact no model can infer; plausible for staleness, which has observable signals.
Sources a reader would expect that we could not verify. Several widely-quoted knowledge management statistics, particularly the frequently-cited figures on hours per week lost to searching for information, trace back to vendor surveys or to studies now more than a decade old, and we could not verify a current primary source for them. They are excluded rather than repeated. The Microsoft 2025 Work Trend Index special report, published 17 June 2025 from Microsoft 365 telemetry, does document the surrounding condition, reporting that employees are interrupted every two minutes during core working hours, 275 times a day. That is adjacent evidence about fragmented attention, not a measurement of search time, and we are not going to present it as one.
Turnover is the pressure behind all of this and it is measurable. US Bureau of Labor Statistics data released 26 September 2024 put median employee tenure at 3.9 years in January 2024, down from 4.1 years in January 2022 and the lowest since January 2002, with 22% of workers having a year or less with their current employer. What that does not tell you is how much undocumented knowledge each departure removes, because nobody measures that, and any article that hands you a dollar figure for it has made it up.
Where LeapForce Fits
This article is about the human process, and most of it runs on tools you already own. LeapForce does not sell a wiki, a knowledge base or a documentation platform, and a knowledge management process does not need us to work. Where we become relevant is the moment the corpus you have just contracted gets connected to something that reads it on an employee's behalf, because that is when the four intake fields stop being metadata and start being access-control input: which agent may read the function-restricted tier, under whose authority, and what did it retrieve. LeapForce is the governed layer for that connection, covering connector scoping and credential brokering and identity for the non-human readers, and our published rollout model for that layer is deliberately staged in the same spirit as the process above: observe first, enforce second, optimize third.
Frequently asked questions
It is the repeatable loop by which an organisation turns what its people know into artefacts that others can find and trust, with a named owner and an expiry attached to each one. The version we recommend has five stages: trigger, capture, contract, circulate and retire. The distinguishing feature is that entry is bound to work events and exit is a scheduled stage rather than an occasional cleanup.
Published guides list five to nine stages, typically some ordering of discover, create, capture, organise, store, share, apply and review. The five we use are trigger, capture, contract, circulate and retire. Two differences are deliberate: an explicit trigger at the front, so capture stops competing with delivery work for discretionary time, and retirement as a stage with a queue and a due date rather than a line about continuous improvement.
The strategy decides what the programme is for, which domains matter, what outcomes justify the spend, and who sponsors it. The process is the machinery that runs weekly regardless of who the sponsor is. A strategy without a process produces a deck and a platform purchase. A process without a strategy produces an accurate corpus about things nobody needed documented. Write the process first if you must choose, because redirecting a running process is cheaper than starting one.
Two to three months to a working loop. Most published advice on how to create a knowledge management process implies a year, and that estimate is usually measuring the two things that consume quarters rather than the loop itself. Roughly: two weeks to settle the four prerequisites and name the accountable person, two weeks to agree the trigger list and the capture template with one pilot team, six to eight weeks running it in that team while the contract gate is enforced, then expansion. What turns this into a nine-month programme is starting with a platform migration or committing to clean up the legacy corpus first. Both are avoidable, and both are the usual answer when someone tells you a knowledge management rollout takes a year.
One named person with the authority to refuse content, reporting somewhere with cross-functional reach: operations or the COO's function in most organisations, engineering enablement in technology-led ones. Not a committee, because committees agree standards but cannot decline a senior stakeholder's contribution, and the refusal is the load-bearing part of the role. At the artefact level, ownership belongs to the person closest to the work, with a role-based fallback that always has a current named holder.
For a 40-person department, roughly 7.3 hours a week in steady state on our assumptions: 8 new artefacts a week at 25 minutes to capture, 2 to contract and 5 to circulate, plus 8 reviews at an average 8 minutes, plus about 2 hours of part-time coordination. At a fully-loaded 80 dollars an hour that is around 30,500 dollars a year. That is arithmetic from stated assumptions rather than a measured figure. The larger and more variable cost is the one-off retrofit of existing content, which is why we recommend archiving the legacy corpus outside retrieval scope and contracting items only when someone actively requests them.
Narrow the target. You will not capture how an experienced person reasons; the knowledge-creation literature has been candid for thirty years that the tacit component is, in the words of one operationalisation study, "elusive and difficult to test". What you can capture is the judgement calls they make, at the moment they make them, in decision-record form with the rejected alternatives written out. Accumulated decisions with their rationale are a workable proxy. For the genuine residue, pairing and recorded walkthroughs have a track record, and their output is training material rather than a corpus entry.
Yes, but for two narrower jobs and with much less effort than the classic process allocates. Semantic search finds passages by meaning, so the hierarchy is no longer the primary access path. The taxonomy still scopes permissions, since access tiers have to attach to something structural, and it still gives people a predictable place to put things so duplicates do not pile up. Design it after roughly a hundred real artefacts exist, because a taxonomy designed up front encodes the org chart you had at design time.
Move it to an archive tier that humans can browse and retrieval systems cannot read, and leave it there until someone requests an item and a named person claims it. Orphaned content is the single largest source of confidently wrong retrieval answers, because it is old, unmaintained and indistinguishable from current material once a passage is pulled out of its page. Deleting it wholesale is politically difficult and occasionally destroys something valuable. Excluding it from the retrieval scope achieves most of the benefit with none of the argument.
Change the question. Contribution incentives, recognition and gamification are the standard answer and they under-deliver, because they ask discretionary time to win a contest against delivery work. Triggers remove the contest: name the work events after which an artefact is required, and treat the work as unfinished without it. Incentives then do useful secondary work on quality rather than carrying the whole load on volume. The corollary is that leadership has to accept the trigger as part of the work's definition of done, which is a real cost and the point at which most programmes discover whether they have sponsorship.
Three reasons, in our reading of the practitioner accounts. The pilot spends its first quarter on preparation, a platform choice or a legacy cleanup, and produces nothing anyone can see. Or capture is scheduled rather than triggered, so contribution decays as soon as the launch attention fades. Or review is formalised without being sampled, and degrades into rubber-stamping, which looks like a healthy process on a dashboard. The measurable early warning for the third case is a retirement queue that is close to 100% confirm outcomes, with corrections and supersessions never appearing.
For drafting and reformatting, genuinely useful. For deciding what is true, no. A generated draft still needs the person who did the work to confirm the decision, name the rejected alternatives and accept ownership, and those parts carry the value. There is also a compounding risk: generated content that is indexed and then used as retrieval context for further generation degrades quietly, because nothing in that loop re-checks the claim against reality. Keep a human in the confirm step of stage five, even if drafting is automated.
If the corpus holds personal data, retirement becomes a legal obligation rather than good practice. GDPR Article 5(1)(d) requires personal data to be accurate and kept up to date, with inaccurate data "erased or rectified without delay", and Article 5(1)(e) limits how long identifiable data may be kept. A review queue with a delete outcome is the operational mechanism for both, and a knowledge base with no retirement stage has no mechanism at all. The EU AI Act's data-governance obligations bite on high-risk AI systems specifically rather than on internal knowledge bases in general, so check whether your use case falls in scope before assuming it applies. Either way, the four intake fields are what make an evidence request answerable.
Ready to Govern Your AI?
Talk to LeapForce — one controlled layer for every AI tool, connector, model, and agent.
Comments