Raw at the bottom, schema at the top
Why a flat folder is not enough
A folder of notes is fine for capture and reasonable for retrieval; it is not enough to support reasoning. An assistant asked a question over a flat folder either reads everything — expensive, slow, and noisy — or relies on a search algorithm to guess which files are relevant. The result is competent on simple questions and unreliable on hard ones. The next step up in architecture is not more files but more layers: a place for the raw material that never changes, a place for synthesis that an assistant can update, and a small set of rules that govern how the two relate.
Layer one — the raw directory
The bottom layer holds the immutable source material. Books in plain text, transcripts from meetings and podcasts, screenshots, white papers, original documents. Nothing in this directory is ever rewritten by the assistant; it is the ground truth the system can refer back to. The discipline is to keep the original artefact as it was captured, including any metadata about where it came from and when. The reason this matters is that any synthesis that gets built on top has to be auditable; the worker must be able to ask the assistant to show its working and have a real source to point at.
Layer two — the wiki
The middle layer is a set of curated pages that synthesise across the raw material. One page per concept, one per person, one per recurring theme. Each page links downward to the specific raw documents it draws on and sideways to the other pages it relates to. The assistant maintains this layer on ingest: when a new raw document arrives, the assistant reads it, updates the relevant pages, creates new ones if needed, and flags anything that contradicts what is already there. The worker reviews and edits. The pages are written for a human to read, not just a machine to query, which is what stops them from drifting into incomprehensibility.
Layer three — the schema
The top layer is a single short document that defines the rules of the system. It says what the folder structure is, how pages are named, what each page must contain, how new sources are ingested, when the assistant should rebuild a page from scratch and when it should append. The schema is what stops the wiki rotting. Every knowledge system the working world has tried — paper Zettelkasten, internal wikis, shared drives — has eventually decayed because no one was responsible for the maintenance. The schema makes the maintenance a definable job, and an assistant given a clear schema will do it more reliably than any human team has.
Why this pattern compounds where wikis usually rot
The reason this architecture compounds rather than rots is that each new piece of raw material makes the wiki strictly more useful, and the maintenance burden does not scale with corpus size. A traditional human-maintained wiki rots because the marginal cost of keeping it tidy rises faster than the marginal value of each new addition; eventually the worker stops, and the wiki goes stale. A schema-driven, assistant-maintained wiki inverts this: the assistant does not get tired, and the schema constrains drift. The result is that a knowledge base built this way is one of the few productivity artefacts that genuinely improves over time without sustained heroic effort.
Imagine an assistant asked to summarise everything you have read about a recurring topic at work. Where would it look first, and how would it know which sources to trust?