Why knowledgebase projects stall
Consider what writing an article actually requires. Somebody must remember a problem they solved, recall the detail accurately, find time when nothing is urgent, decide where it belongs, and write it in a form somebody else can follow. Each step is a point at which the task loses to something more immediate.
The result is predictable: an initial burst of enthusiasm producing the articles for problems everybody already knows how to solve, followed by silence on everything encountered since.
The only moment documentation is cheap
There is exactly one point at which writing an article costs almost nothing: the moment the problem is resolved. At that instant the symptom, the diagnosis, the false starts and the fix are all in one person’s head and, if the incident was recorded properly, already written down in the ticket.
An hour later it is expensive. A week later it is a research task. This is why "we will document it later" never survives contact with a service desk.
If capturing knowledge is a separate task from resolving the incident, it will lose. Every time, in every organisation, regardless of how much everybody agrees it matters.
The structural fix
The change that works is making the article a by-product of resolution rather than a subsequent task. In practice that means the resolution notes on the incident are the raw material, and turning them into an article is an editing job rather than a writing job.
This is what makes AI useful here. The model is not being asked to know anything. It is being handed a specific incident with its symptom, diagnosis and fix, and asked to restructure that into a reusable article. That is a summarisation task, which is what language models are actually reliable at.
The technician then spends a minute correcting it rather than twenty minutes writing it. That difference is the entire reason the library keeps growing.
Why a human must still approve every article
Generated documentation is confidently written, which makes it more dangerous when wrong, not less. A subtly incorrect article does not sit inert - it gets found, followed and trusted, potentially for years.
Approval also serves a second purpose. The act of reading and correcting is when institutional judgement gets added: the caveat about the client whose configuration is different, the warning about the step that must not be run during business hours. That is the knowledge that matters most and no model can infer it.
Findability matters more than volume
A library of five hundred articles nobody can search is worse than fifty that surface reliably, because it creates the belief that the answer is documented while providing no route to it.
Keyword search is the usual failure. The technician searching "Outlook keeps asking for password" does not find the article titled "Modern authentication token expiry on hybrid mailboxes", because the two share almost no words. Semantic search matches meaning rather than terms, which is why it changes the outcome rather than merely improving it.
The stronger pattern is not to require searching at all: surface the closest previous incidents at the point a new one is logged, before anybody has decided to go looking.
Keeping it accurate over time
- Give every article an owner and a review date. Documentation untouched for two years should be flagged as suspect rather than quietly trusted.
- Record which incidents an article came from, so its evidence base can be checked.
- Scope client-specific articles to the client. One client’s quirk in the general library will eventually be applied to somebody else.
- Delete confidently. An article describing a system you decommissioned last year is worse than no article.
- Track which articles are actually opened. The ones nobody reads are telling you either that they are not needed or that they cannot be found.