Ritik Wiki
A pattern for building persistent personal knowledge bases with LLMs.
This is an idea file. It is meant to be copied into your LLM agent of choice (for example Codex, Claude Code, OpenCode, or similar) so the agent can help you build and maintain the system with you.
The purpose of this document is not to prescribe one exact implementation. Its purpose is to communicate the pattern clearly enough that an LLM can turn it into a working setup adapted to your domain, workflow, and tooling.
The core idea
Most document workflows with LLMs are basically retrieval systems.
You upload documents, the LLM retrieves relevant chunks at question time, and then generates an answer. This is useful, but it has a major limitation: the knowledge is reassembled from scratch every time. The model keeps rediscovering the same facts, the same relationships, and the same contradictions over and over again.
That means nothing really compounds.
If you ask a subtle question that requires reading across multiple documents, the LLM has to repeatedly find the right pieces and synthesize them again. Even if the answer is excellent, the work usually disappears into chat history. The system does not become meaningfully smarter from having done the work once.
ritik-wiki uses a different model.
Instead of relying only on retrieval over raw documents, the LLM incrementally builds and maintains a persistent markdown wiki that sits between you and the raw sources. When you add a new source, the LLM does not just index it for future retrieval. It reads it, extracts the important information, integrates it into the existing wiki, updates relevant pages, strengthens or challenges prior synthesis, notes contradictions, creates missing links, and keeps the structure coherent over time.
The wiki becomes a compiled knowledge layer.
This is the key difference:
knowledge is not re-derived from scratch each time. It is accumulated, revised, and maintained as a durable artifact.
The wiki compounds.
The cross-references are already there.
The summaries already exist.
The contradictions have already been noted.
The evolving synthesis is already built into the structure.
Future questions start from the compiled knowledge, not from raw rediscovery.
In this model, the LLM is not just a question-answering engine. It is the active maintainer of the knowledge base.
The human's role is to curate sources, guide attention, ask questions, and decide what matters.
The LLM's role is to do the maintenance work humans usually abandon: summarizing, updating, linking, filing, normalizing, revising, comparing, and keeping the whole thing coherent.
You rarely write the wiki directly. The LLM writes and maintains it. You read it, inspect it, redirect it, and improve the schema over time.
In practice, the wiki becomes a living intermediate layer between raw information and useful thought.
Why this matters
The main weakness of ordinary note systems and most RAG systems is not that they cannot retrieve information. It is that they do not preserve enough structured thinking.
A normal retrieval system answers the current question.
A persistent wiki preserves the answer, the context, the relationships, and the reasoning trail for future use.
That has several important consequences:
- repeated questions get easier to answer
- multi-document synthesis compounds over time
- the structure becomes more useful with every source added
- contradictions become visible instead of buried
- insights can be turned into permanent assets instead of disappearing into chat logs
- the knowledge base becomes something you can browse, inspect, and improve directly
The wiki becomes an actual working memory layer.
What ritik-wiki is for
This pattern can be used anywhere knowledge accumulates over time and needs to stay organized.
Personal
Journal entries, goals, reflections, health notes, self-experiments, books, podcasts, articles, and recurring insights can all be incrementally compiled into a structured self-knowledge system.
Research
When going deep on a topic over weeks or months, the LLM can maintain concept pages, entity pages, debates, timelines, source summaries, and emerging theses.
Reading
As you read a book or series, the LLM can maintain pages for characters, themes, chapters, ideas, plot threads, events, locations, and connections.
Business / team
An internal company wiki can be maintained from meeting transcripts, Slack threads, documents, customer calls, plans, and decisions. The LLM handles the maintenance work that teams usually neglect.
Projects
A long-running project can have a persistent memory: requirements, decisions, assumptions, constraints, issues, research, and change history.
General deep dives
Competitive analysis, due diligence, trip planning, coursework, technical learning, creative worldbuilding, or any other domain where information accumulates and structure matters.
The key shift
The important shift is this:
raw documents are not the final knowledge layer. They are the input layer.
The wiki is the main knowledge layer.
That means the system has two jobs:
- preserve the original sources as immutable ground truth
- continuously compile those sources into a better and better structured body of knowledge
The raw material remains important, but the wiki is where understanding is organized.
System architecture
There are three primary layers.
1. Raw sources
This is the source-of-truth layer.
These are the original materials:
- articles
- PDFs
- papers
- transcripts
- screenshots
- notes
- books
- data files
- images
- recordings
- anything else you want the wiki to learn from
The LLM can read these, but should not modify them.
They remain immutable.
2. The wiki
This is the compiled knowledge layer.
It is a directory of markdown files generated and maintained by the LLM. These pages may include:
- source summaries
- entity pages
- concept pages
- timelines
- comparisons
- synthesis pages
- open questions
- maps / indexes
- decision records
- thematic overviews
This layer is where the knowledge compounds.
3. The schema
This is the operating instruction layer.
It is a file such as AGENTS.md, CLAUDE.md, or similar. It tells the LLM:
- how the wiki is structured
- what page types exist
- how pages should be formatted
- how ingestion works
- how queries should be answered
- how maintenance should be done
- how logging and indexing should work
- what quality standards to follow
The schema is what turns the LLM from a generic chatbot into a disciplined wiki maintainer.
The schema and the wiki should evolve together over time.
How the system operates
1. Ingest
You add a new source and ask the LLM to process it.
A typical ingest flow looks like this:
- the LLM reads the source
- it extracts the important points
- it creates or updates a source summary page
- it identifies related entities, concepts, timelines, or existing pages
- it updates those pages where relevant
- it adds links and references
- it logs what changed
- it may suggest follow-up questions, missing pages, or additional sources to look for
A single source might affect many existing pages.
This is the whole point.
The goal is not to create one isolated summary and move on. The goal is to integrate the source into the system so the wiki becomes better as a whole.
2. Query
You ask questions against the wiki.
The LLM should search and read the relevant wiki pages first, not just the raw sources. If needed, it can also read the underlying sources to verify details or deepen the answer.
The answer can take many forms:
- direct response
- structured markdown note
- comparison page
- research brief
- report
- slide deck
- chart
- timeline
- canvas
- decision memo
One important principle:
if a query produces a reusable insight, that output can itself be filed back into the wiki as a new page.
That way, questions also contribute to the growth of the system.
3. Maintain / lint
Periodically, the LLM should inspect the health of the wiki.
It should look for:
- contradictions
- stale claims
- weak or missing cross-references
- orphan pages
- duplicated ideas
- missing entity pages
- concepts that appear often but have no page
- places where a newer source should update older synthesis
- questions that remain unresolved
- areas where the wiki is underdeveloped
This is important because a persistent knowledge base should not just grow. It should improve.
Page types
The exact page taxonomy will vary by domain, but a good starting point is:
Source pages
One page per source.
Contains a summary, metadata, key claims, notable facts, and links to affected wiki pages.
Entity pages
For named things:
- people
- organizations
- products
- places
- books
- tools
- companies
- projects
Concept pages
For abstract or recurring ideas:
- theories
- methods
- themes
- frameworks
- debates
- technical concepts
Timeline pages
For sequences of events, developments, releases, or turning points.
Synthesis pages
Higher-level pages that combine multiple sources and pages into an evolving view.
Comparison pages
Useful when you repeatedly compare alternatives, approaches, people, products, or ideas.
Question pages
Pages that track important unresolved questions.
Map pages
High-level navigation pages that organize clusters of related pages.
The page taxonomy does not need to be perfect at the beginning. The schema can evolve as patterns emerge.
Indexing and logging
Two special files are especially useful.
index.md
This is the main catalog of the wiki.
It is content-oriented, not chronological.
It should list the major pages in the wiki, usually grouped by type or topic, with:
- title
- link
- short description
- optional metadata such as source count, last updated date, or status
The LLM can use this file as its first stop when navigating the wiki.
At small to medium scale, this works surprisingly well and can delay the need for a more complex search stack.
log.md
This is the append-only activity log.
It is chronological.
It records what happened and when:
- source ingests
- major updates
- query outputs filed into the wiki
- maintenance passes
- refactors
- structural changes
A consistent heading format is useful. For example:
## [2026-04-10] ingest | Title of source
- Created: [[Page A]]
- Updated: [[Page B]], [[Page C]]
- Notes: challenged previous claim on [[Topic]]