How to Index the Files in Your Local Vault
Point RDK at the folder you already write in and run rdk vault:index. Each file is read, split into chunks, encrypted with your vault key, and synced to the network as private chunks. Your files are not moved or rewritten, and nothing becomes public unless you explicitly publish it.
Point it at what you already write
Your vault is the folder you edit by hand: an Obsidian directory, a docs tree, a notes folder, a repository of design decisions. RDK is designed to read that directly rather than asking you to migrate content into a new system.
Run rdk vault:index against it and the pipeline is straightforward. Files are read, split into chunks along meaningful boundaries, encrypted with your vault key, and synced. What you get back is a private layer your agents can search.
The originals stay where they are. This matters more than it sounds, because it means indexing is not a commitment. If you decide the content was wrong to index, removing the chunks from the network leaves your files exactly as they were.
Start narrow
The instinct is to index everything on the first run. Resist it. A focused index of material you trust produces better retrieval than a broad index of everything you have ever written, because the first layer answers 40 to 65 percent of queries and you want those answers to be right.
What happens to each file
A file becomes several chunks. Chunking along headings and sections rather than fixed character counts keeps each chunk semantically whole, which is what makes retrieval return something useful rather than a fragment cut mid-thought.
Each chunk is encrypted individually before sync. The network stores ciphertext. Your node decrypts at query time. RetroDeck cannot read any of it, and this is a property of where the key lives rather than a promise about what anyone will do.
Subsequent runs only reprocess what changed. The first index of a large vault takes a while; the ones after it are quick.
Deciding what belongs in the index
Retrieval is only as good as what it retrieves. The useful question is not whether a document could be indexed but whether you want an agent to answer from it.
Good candidates are decisions and their reasons, conventions, runbooks, architecture notes, postmortems, anything a teammate would otherwise have to ask about. These are exactly the questions agents repeatedly ask, and they are why the private layer resolves such a large share of queries.
Poor candidates are drafts you have not settled, notes that contradict current practice, and scratch material. They will be retrieved with the same confidence as everything else. If a document is wrong, indexing it makes it wrong faster and in more places.
Keeping it current
Because indexing is incremental, keeping the index honest is mostly a matter of keeping your vault honest. Edit the file, re-run the index, and the chunk updates. The failure mode to watch for is content that was correct when written and quietly stopped being correct, which no tool can detect for you.
Frequently asked questions
- Does indexing upload my files?
- It uploads encrypted chunks derived from your files, not the files themselves. The originals stay in your vault, unmodified.
- Is anything public after indexing?
- No. Indexing produces private chunks by default. Publishing is a separate, explicit action.
- How long does the first index take?
- It depends on vault size, and it is the slowest run you will do. Later runs only reprocess files that changed.
- Can I remove something after indexing it?
- Yes. Removing a private chunk from the network deletes the private state and leaves the local file untouched.