{"slug": "wiki-is-not-enough", "title": "Wiki Is Not Enough", "summary": "Google's Open Knowledge Format (OKF) standard enables LLMs to work with a wiki in a git repo without RAG, but the author argues that as knowledge accumulates, it rots due to LLM-generated content and context window limits, proposing a multi-repo architecture with permalinks to maintain coherence.", "body_md": "Google's [Open Knowledge Format](https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing) is quite a bombshell standard.\nNo RAG, no nothing, just a wiki in a git repo is enough to make LLMs work!\nSome progressive disclosure by very basic dir/file naming tricks and `index.md`\n\nfiles.\nSome minimal key-value metadata.\n\nThat is great, but the key limitation is still the LLM context window.\nThe [stream of LLM attention](./stream.html) has to be directed to useful and consistent work.\nSome say the \"smart zone\" is under 250K tokens, others prefer 200K or even 50K.\nIt can only do this much while staying in that zone.\nA smaller project can fit in the context window, sure.\nWhat if the project is big and ongoing?\n\nAs this *knowledge* accumulates, it **rots**.\nAn LLM-created wiki is particularly prone to that.\nAs things unfold, some decisions get course-corrected.\nSome code was just slop, but the LLM took it as an example for future work.\nSome random claims from random sources get into the wiki.\nOverall quality of LLM texts is *not good*.\nThe \"knowledge base\" accumulates contradicting, stale, or false claims.\nAn LLM is free to pick a side randomly there.\nSo, stale or false info gets smeared over the wiki and the codebase.\nIn the end, you no longer know what is in there and you no longer want to read it.\n\nThe ability to course correct is exactly the ability to absorb [feedback](https://replicated.live/blog/follow-up).\nFeedback leads to design and policy changes, code changes, bugs fixed, features added.\nA good product is a result of that steady process.\nGood architecture lets you accumulate more feedback without going into full entropy mode.\n\nMy current project structure is a stack of data tiers, which mostly live in git repos.\n\nGoogle OKF would only cover some tiers here. Basically, only the things I can put into one LLM-accessible wiki: (3)-(4). (1)-(2) may also go there, with some risk. I pack (5) with (1),(2),(3) now, but that is already a stretch. Volume, lifespans and the general genre are all different. Unlike the wikis, the ticket corpus is supposed to grow indefinitely. So is the chat archive. Adding 20-30 tickets a day is nothing special. Chat logs, same, and no one wants to read them all. As we go (1) to (7), the volume of data grows by a factor at every step. This cannot be the same repo. Not even two. Maybe three: wiki, code, and tickets/logs/facts. Four is even better and seven is even more so. That is, assuming you have one repo for the project's code. I have more, at least six: the system, the runtime, tests and key library dependencies.\n\nTo maintain coherence between all of those, I employ [permalinks](./link.html).\nThose differ from wiki links in three key aspects:\n\nThe syntax for permalinks is much more relaxed, e.g. `index/index.js:24`\n\nis valid.\nJust a path and a line and maybe a commit hashlet, `index/index.js:24:Mw`\n\n.\nThe hashlet helps to locate the line in any later version of the file,\nbe it shifted, re-edited or reformatted.\nThat *really* saves context: we pick the right snippets cheaply and in bulk.\nTo automate permalink use, `bee`\n\nhas two commands: `cite`\n\nand `cited`\n\n.\n`cite`\n\nshows a file interleaved with snippets it links to.\n`cited`\n\nshows it interleaved with snippets that link to it.\nThat way I solve both retrieval and coherence.\nThe latter becomes a much bigger task as the project grows.\nChecking the state of inbound/outbound links trivially exposes staleness.\n\nWe arrange texts, code and artifacts along the \"idea⟶reality\" axis.\nThe mission of [information architecture](https://www.oreilly.com/library/view/information-architecture-4th/9781491913529/) is to make information \"easy to find, navigate, and understand\".\nI can start by authoring the seed documents and then keep building into outer tiers.\nI build, I face difficulties, I fix and course-correct.\n\nThis architecture absorbs feedback, but does not devolve into slop.", "url": "https://wpnews.pro/news/wiki-is-not-enough", "canonical_source": "https://replicated.live/blog/wiki", "published_at": "2026-09-04 07:39:25+00:00", "updated_at": "2026-09-04 07:52:57.207539+00:00", "lang": "en", "topics": ["artificial-intelligence", "large-language-models", "ai-tools", "ai-research"], "entities": ["Google", "Open Knowledge Format", "LLM"], "alternates": {"html": "https://wpnews.pro/news/wiki-is-not-enough", "markdown": "https://wpnews.pro/news/wiki-is-not-enough.md", "text": "https://wpnews.pro/news/wiki-is-not-enough.txt", "jsonld": "https://wpnews.pro/news/wiki-is-not-enough.jsonld"}}