Give BoltAI a Real Knowledge Base, Not Just Document Dumping

Why I'm Writing This

I use BoltAI for quick tasks, writing, and code help, and it's good at that. But I also run a personal knowledge base of over 1,100 Markdown documents — 491 YouTube video transcripts, a published book, legal case files, product research, and travel guides — and BoltAI can't touch it.

The reason is simple: BoltAI doesn't do retrieval at all. When you attach a document, the whole thing gets stuffed into the context window. That works for a single short file. It breaks down completely the moment someone has a real knowledge base rather than a handful of documents, because there's no way to attach 1,100 files to a single chat, and no mechanism to find the two or three that actually answer a question.

I've built a system from plain files and SQLite that finds the right document out of that 1,100 and answers correctly almost every time. Nothing in it is exotic. Most of it would translate directly into BoltAI. Here's how it works and what I'd suggest you build.

How My System Works (The Reference Architecture)

The core idea: retrieval and context are two different jobs. Search finds the right document. The full document — not a chunk of it — is what goes to the model.

The setup:

1. One folder, plain Markdown, as the source of truth. Every piece of knowledge is a structured .md file in a numbered folder hierarchy. No proprietary format, no lock-in.

2. YAML frontmatter on every file. Each document carries kb_id, title, domain, and tags. These are first-class retrieval signals, not decoration. A query about "Simpson Desert tyre pressure" matches on domain and tags before any embedding maths happens.

3. A database that stores complete documents. A local SQLite database holds every document in full — title, full text, metadata, one row per document. It rebuilds from the files every 2 hours via upsert, so it never drifts and never duplicates. A cloud copy (Supabase) adds vector embeddings for semantic search.

4. Universal ingest with a complete internal scrape. Anything can be dropped in: PDF, Word, plain text, email, web page, video. Videos are transcribed with Whisper into one MD file per video. PDFs and other documents are converted into a complete structured text representation — the full content, restructured with headings, not a sampled extract. The original goes to archive; the complete text version lives in the knowledge base forever.

5. Hybrid search over a section index, full documents in context. The index knows about 11,700+ sections across the documents and searches them with combined lexical (BM25) and semantic scoring. Sections are only signposts. When the model answers, it reads the entire matched document.

Used with Claude, this setup finds the right information across 1,100+ documents with an accuracy BoltAI has no way to approach today — not because BoltAI's model is worse, but because it never gets to see the right document in the first place.

Where BoltAI Falls Short Today

BoltAI's document handling is attach-and-dump: the full content of whatever you attach goes into the prompt. There's no index, no search step, no concept of "which of my documents is relevant to this question." That's fine for one document. It's not a knowledge base feature — it's a paste-a-file feature with extra steps.

Ask BoltAI "summarise what I've written about the Simpson Desert" or "what tyre pressure did I settle on for soft sand" against a real vault, and there's nothing for it to do — you'd have to already know which of 1,100 files to attach, at which point you didn't need the AI to find it for you. The gap isn't a tuning problem like it is in apps that have RAG but do it badly. It's a missing feature.

Feature Suggestions

1. A knowledge base / brain feature, built on full-document retrieval

Let users point BoltAI at a folder (or add files one at a time to a persistent store, not just a single chat). Index it. When a question comes in:

• Search finds the matching document(s) via chunk/embedding matching, but resolves to the parent document.

• Send the complete document text to the model — not the chunk that matched.

• If multiple documents match, rank them and send the top 1–3 in full rather than a pile of fragments. With today's 200k+ context windows, three complete documents is cheap and transforms answer quality.

This is sometimes called parent-document or small-to-big retrieval. It's well understood and it's the single feature that would take BoltAI from "attach a file" to "query a knowledge base."

2. Complete internal scrape on ingest

When a file is added, create a complete structured text representation of it — the whole document, not a truncated preview:

• PDF → full text extraction with heading structure preserved (OCR fallback for scanned pages)

• Word, Pages, EPUB, HTML → full text conversion

• Email (.eml) → headers, body, and text of attachments

• Video and audio → full Whisper transcription, not just the current single-document dump

• Markdown and text → taken as-is

Store this complete version as the document record. Let users view and export the scraped text, so they can verify what the AI actually "knows" about each file. When retrieval misbehaves, being able to look at the stored representation is the difference between debugging and guessing.

3. Metadata-aware indexing

Read YAML frontmatter from Markdown files and use title, tags, and custom fields as ranked retrieval signals. Obsidian users — a market BoltAI already courts with its integrations — have already done the curation work. Ignoring frontmatter throws away the highest-quality relevance signal in the corpus. File path and folder structure are signals too: a file in Legal/DCS/ is about the DCS case even if the text never says so explicitly.

4. Hybrid search, not embeddings alone

Combine lexical (BM25) and semantic scoring with a tunable weight. Pure vector search routinely misses exact product names, place names, and codes — "Yerranderie", "YN67", "MAXTRAX" — that keyword search nails instantly. My index fuses both and it's a large part of why retrieval feels precise rather than vaguely thematic.

5. A browsable document registry

One row per document: filename, title, ingest date, scrape status, word count, last sync. Right now BoltAI is a black box between "I attached a file" and "the answer used it or didn't." A registry turns that into something users can actually see and trust.

6. Keep the attach-a-document mode too

None of this should replace what BoltAI already does well — quick tasks, drafting, attach-one-file-and-ask. It should sit alongside it as a separate "brain" mode for people with more than a handful of documents.

The Test That Matters

Take a 1,000-document Markdown vault with frontmatter. Ask: "Summarise what I've written about [topic]" and "What exact figure did I give for [specific detail]?" My plain-files-plus-SQLite setup answers both correctly, every time. BoltAI today can't attempt either, because there's no retrieval step to find the right document in the first place.

The fix isn't better prompt-stuffing. It's adding a real retrieval layer — one that finds the right document and hands over the whole thing, not a fragment.