Most knowledge management is an archive: a folder that collects and a search box that forgets. The better model treats knowledge as infrastructure — every document, decision, and diff indexed, linked, and queryable in natural language. But to build that, it helps to know what we are actually managing, and why most attempts at "managing knowledge" have failed before the modern stack even existed.
The field is not new. As an academic and consulting discipline, knowledge management took shape in the 1990s, and its defining early text was Working Knowledge: How Organizations Manage What They Know, by Thomas H. Davenport and Laurence Prusak, published by Harvard Business School Press in 1998.[5] Davenport, a business-school professor specializing in analytics, process innovation, and knowledge management, essentially gave the discipline its name and its research agenda.[5]
The core idea was that organizations lose value every time a hard-won lesson stays inside one person's head. Knowledge management aimed to capture, share, and reuse what an organization collectively knows — not just to store documents, but to keep the organization from re-learning the same things, and from forgetting them when the holder leaves.
The classic framing is the DIKW hierarchy: data → information → knowledge → wisdom. Its exact origin is uncertain, but the model was popularized in the 1980s through the work of Milan Zeleny, Russell Ackoff, and Robert W. Lucky.[1]
The distinction that matters here is between information and knowledge. Information is the fact; knowledge is the framework for acting on it. Zeleny argued that once you capture knowledge in symbolic form, you have actually turned it into information — leading to his assertion that "all knowledge is tacit."[1] That single claim is the reason archives fail: if knowledge can't be written down without losing the knowing part, then a folder of documents is only ever an archive of information, not knowledge. Davenport's own much-quoted definition captures this: knowledge is "a fluid mix of framed experience, values, contextual information, and expert insight" that lives "in the minds of knowers" and often becomes embedded in documents and routines only partially.[1]
The deepest reason archives forget is that a large share of knowledge was never written down — and cannot be.[2] The philosopher and chemist Michael Polanyi coined the notion of tacit knowledge in Personal Knowledge (1958), and sharpened it in The Tacit Dimension (1966) with the assertion "we can know more than we can tell."[2] For Polanyi, tacit knowing is not merely knowledge that is hard to articulate — all knowledge is rooted in tacit knowledge, and most of it is not known "explicitly," even by skilled practitioners.[2]
You know how to ride a bicycle, judge a weld, or read a room, but you cannot fully encode that skill in a document. That gap is precisely why "write it down" is necessary but never sufficient.
How does tacit knowledge ever become organizational? That's the question Ikujiro Nonaka and Hirotaka Takeuchi answered with the SECI model of knowledge dimensions (SECI = Socialization, Externalization, Combination, Internalization), originally developed by Nonaka in 1990 and later refined with Takeuchi.[3] It explains how tacit and explicit knowledge are converted into organizational knowledge — and importantly, its aim is to cycle explicit knowledge back into the tacit knowledge of employees, so the knowledge actually stays in the organization.[3]
The four conversions are: tacit to tacit (socialization, sharing through practice), tacit to explicit (externalization, articulating what you know), explicit to explicit (combination, synthesizing documents), and explicit back to tacit (internalization, learning the docs into your own way of working).[3] The point for anyone building a knowledge system: a static archive only does "combination." It captures none of the socialization, externalization, or internalization loops — which is exactly where the horizontal, cross-document value lives.
Before knowledge becomes a document, it lives in a group. The community of practice concept, proposed by Jean Lave and Etienne Wenger in Situated Learning (1991) and expanded by Wenger in Communities of Practice (1998), defines a group of people with shared interests who learn from each other through regular interaction.[4] Wenger redefined its structure into three parts: a domain of knowledge that creates common ground, a community that provides a shared identity and belonging, and a practice that accumulates the actual ways of working.[4]
This is the honest origin of most org knowledge: it is produced in communities (teams, guilds, practitioner groups) through legitimate peripheral participation — newcomers learning by doing alongside members.[4] A retrieval system is not a replacement for this. It is a way to let the artifacts the community produces — the diffs, the decisions, the postmortems — be reused by the next community.
Folders and search boxes fail on all three of these theories at once. They treat knowledge as information (DIKW), assume tacit knowledge was made explicit (Polanyi), and skip the conversion cycle (SECI). And they present it as vertical-only structure.
Documents are a vertical structure — one topic, top to bottom. Entity extraction and clustering capture the horizontal re-occurrence of topics across many documents. That cross-document view is what turns a pile of files into an org-memory. A knowledge base that cannot answer "which three teams touched this service, and why is it flaky?" is still an archive.
The modern stack turns a question into a grounded answer by routing it through chunking, embeddings, and retrieval before generation. Retrieval-augmented generation (RAG) — the term introduced in a 2020 paper by Lewis et al. — grounds LLM outputs in external, frequently updated sources, includes the sources in responses so users can verify them, and reduces the need to retrain the model on new data.[8] This is the "CLI soul" part: instead of browsing a folder tree, you ask a question in natural language and the answer comes back attached to the documents it was built from.
But RAG has a known blind spot. Microsoft's GraphRAG paper (arXiv:2404.16130) shows that baseline retrieval struggles to "connect the dots" when an answer requires combining disparate pieces of information across a corpus, and it underperforms on holistic sensemaking questions.[9] Their answer is to derive an entity knowledge graph from source documents and pre-generate community summaries for groups of related entities, so that global questions get a synthesis rather than a pile of matching chunks.[9]
A knowledge graph is a knowledge base that uses a graph-structured model to represent and operate on data — interlinked descriptions of entities (objects, events, concepts) plus the semantic relationships between them.[7] Graph databases store connections as first-class citizens: data as nodes and edges, with relationships held directly so they can be traversed in a single operation.[14] Querying relationships is fast because they are perpetually stored — a property called index-free adjacency — which is why graph databases suit heavily inter-connected data.[14]
That structural honesty is exactly what organizational memory needs:
Neo4j is the flagship example of the commercial ACID graph database movement that made this practical from the mid-2000s onward.[14][15] And the vendor ecosystem has since moved its own line to "knowledge layer + GraphRAG" as an explicit product category.[15]
Every serious tool now claims the graph + retrieval pivot, but they sit at different places on the spectrum:
The honest reading: almost everyone sells a search box. The organizations that actually get org-memory are the ones that stop treating knowledge as a document repository and start treating it as a connected, queryable infrastructure layer — the "CLI soul" beneath the wiki.
Knowledge is not a folder. Polanyi knew it couldn't be fully written down; Nonaka showed it has to cycle through people; Wenger showed it is born in practice; DIKW shows the write-down is really an encode into information. The modern stack — embeddings, retrieval, and a graph — is the first honest attempt to make that organizational knowing queryable at all, without pretending a document dump is knowledge. Treat knowledge as infrastructure, not an archive. That's the org-memory with a CLI soul.
[1] https://en.wikipedia.org/wiki/DIKW_pyramid — DIKW pyramid [2] https://en.wikipedia.org/wiki/Tacit_knowledge — Tacit knowledge [3] https://en.wikipedia.org/wiki/SECI_model_of_knowledge_dimensions — SECI model [4] https://en.wikipedia.org/wiki/Community_of_practice — Community of practice [5] https://en.wikipedia.org/wiki/Thomas_H._Davenport — Thomas Davenport [7] https://en.wikipedia.org/wiki/Knowledge_graph — Knowledge graph [8] https://en.wikipedia.org/wiki/Retrieval-augmented_generation — Retrieval-augmented generation [9] https://arxiv.org/abs/2404.16130 — GraphRAG paper [10] https://www.notion.com/product — Notion product [11] https://obsidian.md — Obsidian [12] https://www.atlassian.com/software/confluence — Atlassian Confluence [13] https://en.wikipedia.org/wiki/Microsoft_Loop — Microsoft Loop [14] https://en.wikipedia.org/wiki/Graph_database — Graph database [15] https://neo4j.com/product — Neo4j product