Build your own brain — glossary
Every term you'll hit in the eight stages, defined for someone who's never built one of these. Grouped by where you first meet them, so you can read it top to bottom as a primer or jump straight to the word that stopped you.
The big picture
Brain
What we call the whole system: your documents, turned into something an AI can search and answer from, plus everything that keeps it accurate and current. Not a database. Not a chatbot. The governed body of knowledge underneath both.
Corpus
The full collection of documents you've decided the brain covers. "Governed corpus" just means someone has decided what's in it, what's out, and who can see what, and those decisions are enforced rather than hoped for.
Index
The searchable structure the retrieval store builds over your chunks and their embeddings. When a document is "indexed," it's been processed into that structure and can be found by a query. "Reindex" means rebuild it. You'll meet this word constantly, so worth being clear it's the searchable thing, not the documents themselves.
Provenance
Where a piece of information came from and how it got into the brain: which source document, which version, when it was ingested. Provenance is what lets an answer point back to something real. It's the difference between an assistant that says "here's why" and one that just says "trust me."
RAG (retrieval-augmented generation)
The general technique behind all of this. Instead of asking an AI to answer from memory, you first retrieve the relevant pieces from your own documents, then hand those pieces to the AI and ask it to answer using them. Retrieval first, then generation. The brain built in this guide is a RAG system with governance around it.
Evidence
The retrieved chunks handed to the assistant to answer from. Distinct from the answer itself (which the assistant writes) and from the citation (which points back to where the evidence came from). When you test "is this grounded," you're asking whether the answer actually used the evidence.
Grounded / grounding
An answer is grounded when it's actually built on evidence retrieved from your documents, rather than the AI filling in from general knowledge. An ungrounded answer might be plausible and still be wrong. Grounding is what you're testing for in stage F.
Hallucination
When an AI generates a false, fabricated, or unsupported claim. Confidence isn't required, a hallucination can be stated hesitantly too. Grounding reduces the risk. Nothing eliminates it, which is why answers should carry citations you can check.
Stage A — scope and governance
Scope
What the brain covers. One project, one client, the whole business. A scope is a boundary you've drawn, not a wish list.
Governance
The rules around the corpus: what's excluded, who has access, how changes are handled. Sounds heavier than it is. In practice it's a short list of decisions you make once and then enforce.
Policy
A rule the system enforces, as opposed to a rule someone is supposed to remember. Your exclusion list becomes a policy when the pipeline reads it and acts on it automatically. Same for access rules.
Document inventory
The stage A list of what you've actually got: where documents live, how many, what formats, how current. It's the baseline you'll reconcile against after ingestion in stage D.
Exclusion list / exclusion rules
The documents, folders, or patterns that must never be ingested into the brain. Drafts, scratch notes, sensitive material. Starts as a list in stage A and becomes an enforceable policy in stage B.
Access control / permissions
Who is allowed to see what. Matters the moment more than one person uses the brain, because retrieval can hand the wrong document to the wrong person while looking like it's working perfectly.
Authentication
Proving who the requester is. Logging in, in whatever form. Answers "who is asking?"
Authorisation
Deciding what that authenticated person is allowed to access. Answers "what can they see?" You need both: knowing who someone is doesn't tell you what they're permitted to retrieve.
Test set / evaluation set
A written list of real questions the brain should be able to answer, plus a few it should decline. You write it in stage A, test against it in stage F, and re-run it after material changes to the corpus, retrieval setup, permissions, or ingestion pipeline. It's how you know whether the thing actually works.
Stage B — the source of truth
Source of truth
The single authoritative location your documents live in and the brain reads from. If a document exists in three places, one of them is the source of truth and the other two are copies.
Deduplication
Finding documents that exist more than once and deciding which copy is authoritative. Left alone, the brain indexes all copies and can retrieve or cite the stale one.
Metadata
Data about a document, as opposed to its contents. Title, file path, document type, last modified date, who can access it. Small, structured, and what makes everything downstream (updates, deletion, citations, permissions) work.
Stable identifier / document ID
A permanent, unique reference for each document that doesn't change when the file is renamed or moved. Without one, the brain can't tell whether it's looking at an updated version of a document or a completely new one.
Sync / synchronisation
The process that keeps the brain in step with the source of truth. New, changed, moved, deleted, or newly excluded documents get reflected in the brain. "Sync" is the ongoing version; "ingest" (below) is usually the first big run.
Stage C — the foundation
Vector database / retrieval store
Where the searchable pieces of your documents live. A vector database is a store built to hold embeddings (see below) and search them by meaning rather than by exact keyword. "Retrieval store" is the more general term. Several have free tiers big enough to build a first version.
Embedding
A list of numbers that represents the meaning of a piece of text. Two chunks about the same topic get similar numbers even if they use different words. This is what makes "search by meaning" possible.
Embedding model / embedding provider
The AI model that turns text into embeddings. The provider is who runs it. You feed in a chunk, you get back its embedding. A replaceable choice, but changing it normally means regenerating every embedding, rebuilding or migrating the index, and re-running your test set, so pick sensibly rather than assuming you'll swap freely.
Sync runtime / where the jobs run
The environment where your ingestion and sync scripts actually execute. A scheduled script on your own machine can be enough for an experiment. For dependable sync, you want somewhere that stays on and can reliably reach the source: a small cloud function, a scheduled job on a server, that sort of thing.
Automation / scheduled job
Any process that runs on its own on a timer or a trigger, without someone starting it by hand. Your sync is automation. The whole point of stage G is that it keeps running when you're not watching, and that you find out if it stops.
Free tier
A usage level a service offers at no cost, usually with limits on storage or requests. Enough to prove the brain works before you pay for anything.
Stage D — ingestion
Ingest / ingestion
The full pipeline that takes raw documents and turns them into searchable pieces in the store: parse, chunk, embed, store. "Run the first full ingest" means run that pipeline once against everything in scope.
Pipeline
A sequence of processing steps where each one's output feeds the next. Parse → chunk → embed → store is the ingestion pipeline.
Parse / parsing
Reading a document file and extracting the actual text and structure from it. A PDF, a Word file, and a Markdown file all need to be parsed differently before you can do anything with them.
Chunk / chunking
Breaking a document into smaller pieces for retrieval. Too small and a chunk loses its meaning; too big and retrieval gets vague. "Heading-aware" chunking follows the document's own headings instead of cutting at a fixed number of characters, and is often a useful starting point for structured business documents.
Embed (verb)
Run each chunk through the embedding model to get its embedding. Then store both.
Store (verb)
Write the chunk, its embedding, its metadata, and a reference back to the source document into the retrieval store. That source reference is what makes citations possible later.
Write time vs query time
When a rule is enforced. At write time (during ingestion), excluded content is kept out of the index entirely, and each chunk that does go in gets its access metadata attached. At query time (when someone asks), every request is filtered against that person's current permissions. Both are needed, and they do different jobs: exclusions protect the corpus, query-time checks protect people from seeing what they shouldn't. Query-time filtering isn't a fallback, because permissions can change long after a document was ingested.
Reconcile / reconciliation
After an ingest, comparing what you expected to index (your document inventory) against what actually got indexed, skipped, or failed. If the numbers don't match, something's wrong and it's much cheaper to find out now.
Stage E — querying
Query
A question, phrase, or request used to retrieve relevant evidence from the brain.
Retrieval
Finding the most relevant chunks in the store for a given query. The first half of RAG.
Ranking
Ordering the retrieved chunks by relevance so the best evidence comes first. Retrieval finds candidates; ranking decides which ones matter most.
Semantic search
Searching by meaning using embeddings. Finds chunks about the same idea even when the words differ.
Keyword search
Searching by exact words. Finds chunks that literally contain the term. Better than semantic search when the query is a specific name, code, or phrase.
Hybrid search
Semantic and keyword search combined. Often performs better for business documents, when properly tuned and tested, because exact names matter alongside meaning.
Citation / source reference
The pointer from an answer back to the document(s) it was built from. An answer with a citation is checkable. An answer without one is an assertion.
MCP (Model Context Protocol)
An open standard that lets AI assistants call external tools and data sources. Expose your brain via MCP and compatible assistants (Claude, ChatGPT, custom agents) can query it from inside their own interface once connected and authorised, no copy-pasting.
MCP server
The thing you run that speaks MCP on behalf of your brain. The AI connects to it, sends queries, gets results back.
API
The more general way to expose the brain to other software. If you're wiring it into something that doesn't speak MCP, you'd build a simple API instead.
Assistant / agent
The AI tool the person actually types into. Claude, ChatGPT, or something custom. The assistant is where the person asks. The brain supplies governed evidence; the assistant uses that evidence to construct the answer.
Stage F — verification
Retrieval quality
Whether the right source documents are being found and ranked highly enough. Tested separately from answer quality, because a plausible answer built on the wrong source is worse than no answer.
Decline / non-answer
The brain saying "I don't have that" when the material genuinely isn't in the corpus. A correct decline is a feature. A brain that never says no is one you can't trust when it says yes.
Leak
When excluded or access-restricted material shows up in a result. The most serious thing verification can find, and the first thing to fix.
Baseline
The recorded, measurable results from a known-good run of your test set: which sources were retrieved for each question, which questions correctly declined, whether permission checks held. Later runs are compared to it to spot regressions. Record the evidence and outcomes, not the answer prose, because the same question can be answered in different words each time.
Regression
Something that used to work and now doesn't. Re-running the test set after changes is how you catch them.
Stage G — maintenance
Stale
Content in the brain that no longer matches the source of truth: a deleted document still indexed, an old version still cited, a newly excluded file still retrievable. Stale content is what an unmaintained brain fills up with.
Mixed index state
When a sync fails partway and queries can see an inconsistent mixture of old and new document versions. Prevented by atomic publication, or resolved through clean recovery (below).
Atomic publication
A sync either completes fully and goes live all at once, or doesn't go live at all. No half-updated state is ever visible to queries.
Recovery / rollback
Recovery is returning the brain to a trustworthy state after a failed sync, whether that means safely resuming, retrying, rebuilding, or rolling back. Rollback is one recovery method: returning the store to its last known-good state.
Monitoring
The checks that show whether ingestion and sync are actually healthy: when the last successful run was, whether any failed, how long they take, whether document counts are what you'd expect. It can start simple, but it has to make a stopped or failed sync visible before someone discovers it through a wrong answer in front of a client.
Drift
Slow divergence over time between what your policies say and what's actually happening. Exclusions that no longer match reality, access rules that haven't kept up with the team. Revisited periodically, not fixed once.
Stage H — the loop
Institutional memory
What a business collectively knows, as opposed to what any one person knows. A shared brain with proper access preserves the portion of that memory that's actually been captured and maintained, so it doesn't leave when someone does.
Compounding
Every project adds documents, documents feed the brain, the brain makes the next project sharper. The value grows when new material is curated and governed as it comes in. Poorly kept material compounds too, just as noise.
Retrieval miss
When retrieval fails to find or rank evidence that does exist in the corpus. Was the document missing? Badly chunked? Excluded by mistake? Fix the corpus, add the question to your test set, move on. If the right evidence was retrieved and the answer was still poor, that's an answer or grounding failure, which is a different problem.
If a term you hit isn't here, that's a gap in this glossary rather than something you should already know. Tell us.
Ready to see where these terms actually apply? Start at Stage A — define scope and governance →, or go back to the eight-stage process map for the full build.