A big documentation push, or a knowledge graph?
The documentation project is the reflex answer to a coming departure: hire a technical writer, book the expert's Fridays, write everything down. It produces documents; it rarely produces the knowledge. The expert can't articulate what he doesn't know he knows, the project freezes at its end date, and the result is organized by chapter rather than by question. A knowledge graph approaches from the other side: capture knowledge as connected, sourced, dated facts — and let the questions find the answers.
What a documentation project actually delivers
Documentation projects deliver real things: reference material, onboarding texts, process descriptions — artifacts that are readable without any system and satisfy certification needs. A documentation project is enough if the knowledge is genuinely explicit — describable procedures, specifications, configurations — and reasonably stable. For that material, a well-run writing project beats any graph: documents are the right container for linear, explainable content.
What a knowledge graph actually delivers
A knowledge graph stores knowledge the way experts actually hold it: as a web of facts, decisions, machines, clients and reasons, each with its source and date. It is built for the non-linear questions documentation can't anticipate ('what do we know about client X's line 2?' touches twenty documents or one graph query). It grows continuously instead of ending, and its temporal layer keeps history queryable instead of overwritten. Its honest cost: it is infrastructure plus a capture process, not a deliverable you can check off.
A documentation project vs a knowledge graph: at a glance
| Criterion | A documentation project | A knowledge graph |
|---|---|---|
| Output | Documents, organized by chapter | Connected facts, organized by relationship |
| Captures | What the expert can articulate on request | What surfaces in real use + guided intake |
| After the project | Freezes; decays from day one | Keeps growing from ongoing meetings |
| Answering questions | Reader searches and reconstructs | Query returns the connected answer, sourced |
| History | Latest version only | Temporal — the change and its why remain |
| Expert effort | High — writing/review Fridays | Low — speaking, in meetings and sessions |
| Failure mode | Stalls at 60%, unread afterwards | Needs sustained capture discipline |
When you need both
A fictional composite that will sound familiar: an equipment manufacturer budgeted six months of technical writing before its R&D lead retired. Month one and two went well — the explicit layer. Then progress crawled: the writer didn't know what to ask, the expert didn't know what was worth saying, and the drafts read like a manual for things nobody had questions about. The project shipped late at 60% coverage and was consulted, in the following year, roughly never — documents answer the questions their authors imagined. The graph approach starts from real questions (meetings, intake) — and where genuinely linear content emerged, writing it up as a document was the right call. The instruments complement; the mistake is asking either to do the other's job.
Where MentX fits
MentX is the knowledge-graph approach productized: meeting ingest and a guided intake feed a living, temporal knowledge graph with full source attribution — no writing Fridays involved. Existing documentation keeps its role as the explicit layer, referenced from the graph rather than replaced by it. What a knowledge graph is →
