I’ve been building knowledge-management products for a little over a year, from AILogora to Cairn, and I keep coming back to the same question: how should knowledge be organized, found and reused?
I love note-taking products. I’ve used Notion and Obsidian, tried spatial organization, and used LLMs to turn information into a wiki combined with vectors. Karpathy’s LLM Wiki recently blew up online, and I thought it was a good moment to write down my current understanding of the field, observations from having actually fallen into the potholes.
Let’s start with the methods themselves. I’m dividing them by underlying mechanism, not by “for individuals or for enterprises,” because how knowledge is processed shouldn’t change with the number of people.
Flat categories: tags and folders
The most traditional approach. Notion, Apple Notes, Bear, and enterprise tools like SharePoint and Confluence all have the same underlying logic: drop things into categories, tag them, set permissions. Enterprise KM just wraps another layer of versioning and compliance around it. At heart it’s still flat.
Tiago Forte’s PARA (projects, areas, resources, archives) is probably the methodology that takes this line furthest. But this year he launched an “AI Second Brain” course himself, which shows that even the most hardcore second-brain community has started moving toward AI-assisted organization.
Everyone knows the problem: once you have a lot of stuff, you can’t find anything, and you can never decide whether a note belongs under “AI” or “product design.” Neither is entirely right.
Emergent connections: bidirectional links
The wave Roam Research started in 2020: every card links to others with [[link]], there are no preset categories, and the structure grows on its own. Obsidian and Logseq follow this line too.
I used Obsidian for a while, and my experience was that once you passed a few hundred notes, the graph view became a ball of yarn. You can see the links but not what’s important; everything looks the same size. Roam blew up in 2020, but its share of attention was later clearly split among Obsidian, Tana and Heptabase. I used Roam for about three months in 2020 myself. It really did start this wave, but it’s a shame it didn’t hold its ground. Obsidian, with local Markdown and its plugin ecosystem, ended up on much firmer footing.
Spatial notes
Heptabase, built by a Taiwanese team, is the standout here, and I used it for a few months. The core idea is to put notes on an infinite whiteboard and express relationships by position. Not links, but “what you put next to what.”
Honestly, for fragmented information you don’t yet know how to classify, the whiteboard’s visual advantage is really strong. You can see intuitively which concepts belong together, which makes it great for early sense-making or brainstorming structure. I tried this at AILogora, and it was genuinely useful for an initial pass at organizing topics.
But it still hits a bottleneck at scale. As the whiteboard keeps growing, you eventually need some kind of “map” to tell you where things are.
Semantic search: vector embeddings
Mem.ai, Notion AI, ChatGPT memory, and on the enterprise side, Glean. Turn all content into vectors and search by semantic similarity. No categories, no links; just throw it in. Glean is more advanced, with a knowledge graph plus hybrid search (vector + keyword) underneath, and permission-aware mechanisms.
Hybrid search does improve retrieval quality, but it usually still doesn’t turn disagreement, authorship, and the relationships between claims and evidence into a knowledge structure users can navigate. Search gets more accurate, but what you see is still a pile of “most relevant passages,” not a map with context.
LLM compilation: wiki + graph
This is the newest line. In April this year, Karpathy posted the LLM Wiki concept on X: 16 million views, and 5,000 stars on the GitHub Gist within a few days.
It’s a three-layer architecture: raw (the source material, untouched), wiki (Markdown pages generated by the LLM) and schema (a CLAUDE.md file defining the maintenance rules). The LLM isn’t used for Q&A (that’s RAG); it’s used for continuous compilation. Every time you feed it new material, it automatically updates a dozen wiki pages, and good Q&A results can be written back as new pages.
At AILogora we independently arrived at a similar direction, using an LLM to organize information from the community into a wiki, combined with vector search. Having built it, we discovered something: the knowledge graph an LLM wiki produces is completely different from Obsidian’s graph view or a graph drawn from a vector DB. Obsidian’s graph shows “who links to whom,” and a vector DB’s graph shows “who’s similar to whom.” Both are hard to read. An LLM wiki’s graph has semantic hierarchy: pages relate as “this concept belongs to that topic” or “this evidence supports that argument.” The structure itself means something.
I think this direction is right.
But there’s a deeper problem here, I think.
Not every knowledge-management tool explicitly talks about a single source of truth (SSOT), but most share a common limitation: they’re good at preserving content, but bad at preserving “the shape between viewpoints.”
An article can go into a folder, a card can be linked to another card, a passage can be found by vector search, and an LLM can turn ten documents into a wiki page. But when three people say “RAG works really well” and another says “RAG keeps hallucinating for me,” the system can usually do one of three things: average them into one conclusion, pick the newest version, or treat them as a few similar passages of text.
What’s really valuable, though, often isn’t the averaged conclusion. It’s the shape of the disagreement: who succeeded in what context, who failed under what conditions, which evidence supports which claim. SOPs and API docs obviously need a single correct version, but one person’s hands-on experience and another person’s hands-on experience were never meant to be pressed into the same conclusion.
Wikipedia actually does better at this than most tools. Its NPOV policy presents major viewpoints in proportion to the prominence of their sources, rather than simply pressing them into one version. But it still folds multiple viewpoints into one editorially governed article, and in that process each viewpoint’s authorship, context and evidence relations get flattened.
Mem0’s memory mechanism is similar: when facts conflict, it automatically overwrites the old version. And because Karpathy’s LLM Wiki is a personal tool, it naturally keeps only one perspective’s organization.
Of course, I’m not the only one who thinks SSOT has limits. People in data engineering have started to reflect on it; one article is titled “Single Source of Truth — A Modern Data Myth?”, and in PLM this year someone wrote that “SSOT was never the final answer.” Their observation is that different departments have different legitimate views of the same product’s data, and forcing them into one version actually distorts it. The alternative they propose is interesting: instead of clinging to a single source of truth, move to a single source of change. Keep one control point for decision-making and propagation, but let the data itself live in multiple places.
Philosophy has a corresponding framework, epistemological pluralism, which holds that different kinds of knowledge may need different cognitive architectures. Even Wikipedia’s own SSOT entry admits that SSOT rests on an ontological assumption: that for any given fact, there is only one truth.
These critiques are currently scattered across data engineering and philosophy. No one has brought them into the product design of knowledge management yet.
If knowledge naturally has many sides, how should a system be designed?
Other fields have made some attempts. Academia has discourse graphs (pushed by Protocol Labs), which break research into atomic elements like claims, evidence and questions, use a graph to express support and rebuttal, and preserve authorship. Taiwan’s vTaiwan uses Polis for large-scale opinion mapping, aiming not for consensus but for the structure of opinions.
But the former is confined to academia, and the latter deals with opinions rather than structured knowledge. In ordinary tech communities or product teams, no one has yet combined these elements into a product.
That’s the background to my path from AILogora to Cairn.
AILogora originally did knowledge curation with cards and collection walls, a bit like Are.na, where each card can be placed on different collection walls. After running it for a while, we felt the AI side could go deeper. A hackathon came along at the right time, so we pulled out the part related to LLM knowledge organization and iterated on it quickly. That became Cairn.
At AILogora we had already validated that LLM → wiki works, but we hit a problem: when different people have different experiences with the same thing, a wiki can only present one organized version, and the other viewpoints get swallowed. What we really needed was no longer a single source of truth, but a map that shows multiple viewpoints and how they relate to each other.
So Cairn isn’t trying to be another AI wiki, or a memory layer like Mem0 that helps an LLM remember one user. What we’re building is a memory layer where multiple contextual truths can coexist, with the relationships between them preserved.
Concretely, we’ve redefined the MOC (map of content), a concept the PKM community has used for years:
- An atom is one person’s experience or viewpoint: written by one person, owned by one person, carrying authorship and context
- An L1 MOC is a topic-level structure: “these atoms are answering the same question”
- An L2 MOC is a theme-level structure: “these are the big directions this community cares about”
- The LLM (we call it Moss) drafts the MOCs, but people decide “what belongs together”
This mechanism isn’t only for communities. For an individual, it’s Karpathy’s LLM Wiki (schema → wiki → raw). For a team, it adds something Confluence doesn’t have: structure that’s maintained by AI and reviewed by people. For a community, it can preserve the shape of disagreement instead of pressing it into consensus.
This thesis could also be wrong. Maybe most people don’t need to see the shape of disagreement; they just want better search, more reliable summaries and a wiki with less friction. The core challenge Cairn really wants to validate is: “In which situations does preserving disagreement actually improve the quality of decisions?” That’s far more meaningful than proving that “multiple viewpoints are romantic and beautiful.”
Our MOC-gated retrieval has produced some good eval numbers so far (Moss shows a clear gap over ChatGPT and Perplexity on structured answers), but validation at community scale isn’t done yet. Data engineering talks about a single source of change; what we’re trying is to use MOCs as a single source of structure, letting multiple truths coexist with a structure you can follow.
Writing this, I went back over the past year or so, and realized that a lot of what Cairn does now really couldn’t have happened without the AILogora experience. We tried tags, we tried spatial organization, we tried LLM → wiki. Each taught us something, and each hit a ceiling. Those ceilings ended up pointing in the same direction: knowledge management is far more complicated than I first thought, and it can’t be solved by switching tools or switching classification schemes.
I’m not sure whether Cairn’s direction will turn out to be right. But looking back now, at least this past year wasn’t a wasted detour. 😅
If you’re researching similar topics, Karpathy’s LLM Wiki Gist, Protocol Labs’ discourse graphs and the vTaiwan Polis case are all well worth a look. Cairn is also looking for early testers this week, so come talk to us.