The VaultOS Setup Guide

The models are extraordinary. The context is missing. Every session starts from a blank page, so you re-explain, re-paste and re-decide — and the decision you made three months ago may as well not exist.

The fix is not a better model or a longer prompt. It is a governed place where your knowledge lives, structured so a machine can retrieve it and cite it. That place is what this guide teaches you to build.

Six steps. None of them require our help.

The instinct is to import everything. Resist it. A vault full of meeting noise retrieves worse than a small one full of decisions, because every irrelevant document is another thing competing to be the answer.

Write down the questions you actually want answered — "what did we decide about pricing in March, and why?", "what is our refund policy?", "how do we onboard a new client?" — and keep only what answers them:

• Decisions, with the reasoning. The why is the part that evaporates. The what is usually recoverable.
• Runbooks and processes. Anything a new hire would otherwise ask a person for.
• Client and project context. Who they are, what was agreed, what went wrong.
• Hard-won lessons. Especially the expensive ones.

Leave out anything transient, anything duplicated elsewhere, and anything you would not want an assistant to repeat back to a colleague.

Plain markdown files with YAML front-matter, in a git repository. That is the whole format. It is human-readable in any editor, diffable, versioned, and every large language model already reads it natively — no SDK, no proprietary account, no export step.

Google formalised exactly this shape in 2026 as the Open Knowledge Format (OKF), which is worth knowing because it means the structure you build now is a standard rather than a private convention.

A workable note looks like this:

---
title: Pricing decision — March 2026
type: decision
business: Acme
created: 2026-03-14
---

We moved to quote-based pricing for installs.

**Why:** published price points anchored the negotiation
before we could scope the job.

The front-matter matters more than it looks. Those fields become the filters your assistant uses later to answer within a scope rather than across everything you own.

Link related notes to each other. Wiki links ([[note-name]]) are the cheapest way, and a link to a note that does not exist yet is not an error — it is a marker for something worth writing.

The reason links matter for retrieval is that they encode the relationships prose leaves implicit. A note about a client that links to the pricing decision, the runbook and the post-mortem gives a retrieval layer three more paths to the right answer.

Then run the check almost nobody runs: find your orphans. Notes with no inbound or outbound links are usually either misfiled or duplicated. When we audited our own graph we found hundreds, and fixing them improved answers more than any prompt change did.

A folder of good notes is not yet a brain. Something has to index the content and ground the model on it, so answers come from your documents rather than the model's memory.

Whatever you use to do this, hold it to one standard: every answer must cite the note it came from. An uncited answer is a guess with good grammar, and you cannot tell the difference by reading it. A cited answer is auditable — you click through and check.

This is the layer we built on Google Cloud, using a search data store that Gemini Enterprise grounds on. The principle is portable: index the files, ground the model, cite the source. On our own vault that runs at roughly a cent per grounded answer, which is not the expensive part of anyone's stack.

A knowledge base decays the moment capture becomes a chore. Two habits carry it:

• Capture where you already are. If writing a note means opening another app, it will not happen. Sync the vault to your phone and laptop so a thought lands in the graph in seconds.
• Write answers back. When your assistant produces something worth keeping, save it into the vault as a new note. The graph compounds instead of flattening — this is the difference between a knowledge base and an archive.

Set a recurring slot to review what came in. Ten minutes a week beats a quarterly clean-up you will not do.

The moment a second person can ask questions, retrieval becomes a permissions problem — and this is where most internal AI projects quietly go wrong.

Two rules we hold ourselves to:

• Enforce scope on the server, never in the interface. If the client application decides what it is allowed to see, it can be persuaded otherwise. The filter has to be applied where the request is served.
• Fail closed. A question outside someone's scope should return no sources — not a partial answer, not a summary that leaks the shape of what it found.

Then test it adversarially before anyone else gets the link: write a battery of questions about material that must not be reachable, and require every one to come back empty. Keep the results. That test is the difference between an assistant you can hand to a colleague and one you can only use yourself.

Every one of these is something we got wrong first.

1. Tables are close to invisible to retrieval. A summariser reading a markdown table will often miss the row you meant and confidently report a neighbouring number instead. Put anything load-bearing in a sentence, and treat the table as a convenience for humans.
2. Stale duplicates outrank fixed originals. Export a document to a second format and the old copy will keep winning retrieval long after you have corrected the original. De-duplicate at the source; do not rely on recency to sort it out.
3. Everything imported, nothing curated. Volume is not the goal. The best retrieval improvement is usually deletion.
4. Front-matter added later. Retro-fitting fields across hundreds of notes is miserable. Decide the two or three fields you will filter on before you write the hundredth note.
5. Orphan notes nobody linked. They exist, they are correct, and they never surface. Audit for them.
6. Secrets in the vault. API keys and passwords do not belong in a corpus you are about to make searchable. Keep credentials in a secret manager and reference them by name.