A knowledge base the AI can read and a human can review
Published · updated
The person who knew how to reconcile the hours left in March. The internal portal exists; someone filled it in once, in 2019. The rest of the knowledge lives in mailboxes, in shared drives and in two people’s heads. This isn’t a missing tool. Most companies already own a wiki, an intranet or some document store. It’s a problem of form and rhythm, and a new tool has never fixed either one.
The definition of a knowledge vault
A folder of Markdown files, one file per subject, linked to each other and versioned in a repository. The files stay the canonical source: you don’t need a database or an application server to read the files. You need a text editor. Git is a structured store in its own right, and you can add a search index on top without letting the index turn into the source of authority.
Three properties follow from that form, and they’re the ones that matter:
| Property | What it changes |
|---|---|
| Readable with no tool | A text file opens anywhere, in ten years as now, with no licence and no migration |
| Comparable line by line | Diffs are transparent and independent of an office suite; Track Changes and document comparison still exist, but are less convenient to automate |
| Transferable to an authorised team | When the supplier changes, the canonical files are already an open deliverable, provided metadata, permissions and history are retained |
Authority comes from review, not from the tool
A document carries authority when you know where it came from, who changed it
and who approved it. Git keeps the commits. blame shows the last known change
to a line, but it doesn’t prove who originally wrote the line, and history can
be rewritten. To protect the value of that evidence you need signed identities,
retention on the repository and branch rules.
Approval is a decision your company makes, not something the software does for you. A change that matters arrives as a proposal. Somebody owns it, somebody reviews it, and the review leaves evidence before the merge. The mechanism comes from source code, and it transfers well to prose once you set those controls up.
Day to day, the difference comes down to two situations:
- Before an audit: you show the state of a procedure on a given date, and the trail of decisions that produced that state
- When two pages contradict each other: the contradiction is visible and dated, instead of sleeping in two folders nobody compares
The use the AI makes of it
An assistant that works from internal documents has to extract the material, cut it into chunks and pull out the useful passages when a question arrives. A badly parsed PDF, split every five hundred words, loses its structure. Modern parsers manage to keep headings, pages and tables together. So the weakness sits in the preparation, not in PDF as a format.
A vault brings the structure in advance. A file carries one subject. The title names the subject and the sections organise it. The system still has to chunk, index, rank and cite, and it still has to respect permissions. But it gets to start from editorial units that people chose.
Two differences decide everything else.
The answer cites a page, not a fragment
The reader gets to open the source and read the whole page, instead of getting five lines cut out of a context they’ll never see. They can judge for themselves. An assistant whose answers can’t be checked is only useful to people who already knew the answers.
Corrections happen at the source
When the assistant is wrong, you edit the canonical file. The fix is dated and attributed. But the fix only reaches later answers once ingestion and re-indexing have run, so you want a test to prove that the served index matches the approved commit.
The retrieval trade-offs themselves, similarity against lexical search against graph traversal, deserve their own page, so I cover them in a separate article.
The content that does not belong in it
In the architecture I propose here, a knowledge vault and agent memory don’t carry the same authority. The vault gets approved before publication. The memory may hold observations an agent proposed between sessions and nobody has yet agreed to keep. That’s not a universal definition, but it’s a useful security boundary. The four mechanisms that the word “memory” covers are separated here.
A base that keeps a resident’s file or a colleague’s situation is processing personal data, with everything that follows from that. For a municipality the applicable regime is cantonal, a point developed here.
The real cost
The tooling is free or close to it. What costs is the rhythm, and the rhythm is what most attempts fail to hold after six weeks.
One way in
Everything arrives in the same place and gets filed afterwards. Two ways in produce two bases that drift apart, and nobody knows which base governs.
A scheduled review
The read-through runs on a fixed date, not when somebody remembers to run it. Maintenance that waits for a daily decision doesn’t happen.
Organised forgetting
Every page carries a review date. When a fact changes, you write the new fact and mark the old fact as superseded rather than overwrite it. A false belief has to stay traceable to its source.
That last rule is the least intuitive one and the most useful one. A base with no forgetting looks healthy: the file count keeps rising. But it quietly piles up claims of different ages, and after a while nothing can tell the fresh claims from the dead ones.
A specimen you can browse
I keep a vault of this kind on my own technical subjects, published as it stands: Elysium. It shows search, a link graph, entry pages and the file structure in a personal project. It isn’t proof of an organisational outcome; permissions, approval and adoption add another layer of work on top.
Where to start
Not with the tool, and not with a complete filing plan. Take the knowledge that would cost you most to lose tomorrow morning, the kind that sits in one head. Write ten pages of it. Run the review for a month.
This work gets done with you rather than for you. Setting it up, the permissions, the review and wiring an assistant to the result are part of the data and AI services.
At the end of that month you’ll know two things no audit will tell you: whether the rhythm holds in your company, and which of those ten pages people have already used.
Minimum metadata for every page
Add a stable identifier, a source and a precise locator, an owner, an approval state, an effective date, a review date, a confidentiality class and the pages it supersedes. The index has to keep this metadata and it has to enforce the source permissions. An ingestion test has to prove that what you serve matches the commit you approved.
Technical sources, and the scope of this note
Markdown and Git improve portability and audit. But they don’t give you approval, permissions, quality or continuity by themselves. Elysium is a personal demonstration, not a client case study.
Git documentation reviewed on 14 August 2026.