Retrieval Augmented Generation, and How OBEL™ Actually Builds It

Retrieval Augmented Generation is a simple idea with a lot of ways to get it wrong. The premise: instead of relying only on what a model learned during training, you retrieve relevant material from your own documents at the moment of the question, and give the model that material as context before it answers. Done well, it turns a general purpose model into one that can accurately discuss your contracts, your policies, and your internal documentation. Done badly, it leaks sensitive content into a prompt, returns irrelevant chunks with no way to tell why, or quietly stops working the moment a document is longer than a few pages. Most vendors quietly hope for the first outcome and ship anyway.

I was the founding Chief Architect of OBEL™, and Knowledge Bases were one of the systems I built. We built it the way we build everything else in the platform: governance first, retrieval second. Every document that goes in and every chunk that comes back out passes through the same classification and scrubbing pipeline as a live chat message. No exceptions carved out for convenience. Here is what actually happens.

The standard RAG pipeline, and the extra stages OBEL™ runs

Most explanations of RAG, including Palo Alto Networks' widely cited breakdown, describe the same five stage pipeline: the user's query is encoded into a vector, documents are indexed into a searchable database ahead of time, the closest matching chunks are retrieved by similarity, that retrieved material is attached to the original question as augmented context, and the model generates a response from the combined input. That framing is correct, and it is also the industry's ceiling. It describes what has to happen for RAG to function at all. It says nothing about what has to happen for RAG to be safe to run on data an organisation cannot afford to leak.

OBEL™ runs the same five stages, adds a governance check at every one of them rather than treating governance as a wrapper around the outside, and inserts one stage the standard pipeline does not have at all: reversible tokenization of the fully assembled prompt, immediately before anything leaves OBEL™ for the model provider.

1. 1Query encoding. The user's question is classified by ARGUS-i before it is embedded. A question that itself carries content above the sovereign threshold is blocked here, before a vector is even generated, not after retrieval has already run against it.
2. 2Data indexing. Before any document is embedded and stored, every chunk is scrubbed for PII and classified. Chunks that fail are dropped, not indexed. A standard pipeline indexes first and worries about sensitivity later, if at all. OBEL™ never lets ungoverned content become searchable in the first place.
3. 3Document retrieval. Similarity search runs scoped to organisation, Knowledge Base, and access tier, at the database query level, so a match cannot surface from outside the tenant or the access scope regardless of how close the vector distance is. Relevance and permission are checked in the same query, not in two separate systems that can drift out of sync.
4. 4Context augmentation. Retrieved chunks are re-classified and re-scrubbed a second time before they are attached to the prompt. Content that was compliant when it was indexed six months ago is checked again against today's rules before it is allowed to influence today's answer. Citations to the source document are preserved through this step, not lost when the chunks are merged into a context block.
5. 5Tokenization. Where an org has reversible tokenization enabled, the fully assembled prompt, the user's question plus every retrieved chunk now sitting in context, is passed through OBEL™'s stateful tokenizer immediately before the call leaves the building. Names, identifiers, and other sensitive values are swapped for reversible tokens, mapped against an encrypted vault entry scoped to that conversation. This is not the same operation as the scrub-and-classify pass at ingest. Scrubbing decides whether content is allowed to exist in the index at all. Tokenization decides what the external model provider is actually allowed to see, on every single call, even for content that already passed every earlier check.
6. 6Response generation. The model answers using only tokenized placeholders where sensitive values would have been, and OBEL™ rehydrates the response, swapping tokens back to real values, before it reaches the user. The external provider never receives the real values at all, and the response still records which documents actually informed the answer, so the citation trail is real, not a plausible-looking approximation reconstructed after the fact.

From document to searchable knowledge

When a document is uploaded to a Knowledge Base, OBEL™ extracts the raw text using format-specific handling: PDFs are parsed with a lightweight WASM based extractor rather than a heavyweight native library, DOCX files are converted with a dedicated parser loaded on demand, and plain text, Markdown, and CSV are read directly. The extracted text is then split into overlapping chunks of roughly 400 tokens each, with the split points chosen to prefer natural paragraph and sentence boundaries rather than cutting mid sentence, and a smaller overlap carried between consecutive chunks so meaning is not lost at the seams.

Every chunk is scrubbed for PII and classified by ARGUS-i before it is embedded. If a chunk classifies above the sovereign threshold, it never gets embedded. If every chunk in a document fails that check, the whole document is marked quarantined rather than partially ingested. This happens before the document becomes searchable, not as a filter applied afterward.

Chunks that pass are converted into vector embeddings and stored alongside the document, indexed for fast similarity search. The index and storage live inside the same Postgres instance that runs the rest of OBEL™, filtered by organisation and Knowledge Base at the database query level. Retrieval cannot cross a tenant boundary because the boundary is enforced in SQL, not in application logic that could be misconfigured.

What happens when you ask a question

At query time, OBEL™ classifies the incoming question first. A question that itself carries content above the sovereign threshold is blocked before it ever reaches the retrieval step. If it clears that check, the question is embedded using the same model used at ingest time, and OBEL™ runs a similarity search scoped to the specific Knowledge Base, or Knowledge Bases, relevant to the conversation.

The chunks that come back are not trusted blindly. Each one is re-classified and re-scrubbed before it is allowed into the prompt, a second pass on top of the check already done at ingest. This matters because classification rules change over time as an organisation tightens its policy, and a chunk that was acceptable when it was uploaded six months ago should still be checked against today's rules before it influences today's answer. The surviving chunks are formatted into a labelled context block, with citations back to the source document, and injected as a system message ahead of the user's question. The model answers with that material in view, and the response records which documents were actually used, so the citation trail is real, not decorative.

This is not a theoretical concern. During an early pilot, one customer's HR team had uploaded a set of role transition templates into a shared, org-wide Knowledge Base, back when that Knowledge Base still allowed broad access. Fine at the time. Then a policy update tightened what counted as identifying information in performance related documents, and one of those templates now contained a named example that should never have been retrievable outside HR. Nobody went back and manually re-audited the old uploads. Nobody needed to. The next time a chunk from that document was retrieved, the re-classification pass caught it against the updated rules and it was scrubbed before it ever reached a prompt. That is the entire point of checking twice, once at ingest and again at retrieval. Policy drifts. Old documents do not defend themselves.

Where OBEL™ takes this further

Most products stop at document upload and search. That was never going to be enough for us. OBEL™ uses the same ingest and retrieval pipeline to power two other features that are not usually described as RAG, but functionally are.

Spaces memory

Every Space in OBEL™ can carry its own memory, and that memory is not a static summary bolted onto the conversation. Periodically, as a Space's conversation grows, OBEL™ summarises the recent transcript into a short, dated, factual paragraph and runs it through the exact same ingestion pipeline as any uploaded document: scrubbed, classified, chunked, embedded, and stored. The next time anyone asks a question in that Space, retrieval runs against the Space's document library and its self-updating memory together, merged into a single context block.

The result is a Space that genuinely remembers what has been discussed weeks earlier, retrievable by relevance rather than replayed as a wall of chat history, without needing a separate memory subsystem. It is the same Knowledge Base engine, pointed at a Space's own conversation instead of an uploaded file.

Knowledge Bases as a governance boundary, not just a search index

Because Knowledge Bases already carry organisation, department, and personal access scopes, and every retrieval is checked against that scope before it runs, Knowledge Bases double as an access control mechanism, not just a relevance one. A department scoped Knowledge Base cannot surface content to someone outside that department, regardless of how well their question matches the content. Most RAG implementations treat access control as a separate layer applied after search. In OBEL™, the scope check happens as part of the same query that does the retrieval.

Live web context, on the same governance path

When OBEL™'s web search is triggered for a time sensitive question, the retrieved results go through the same scrubbing pass before they are summarised and injected into the conversation. It is a different retrieval source, live search rather than a vector index, but it lands on the same governance path as Knowledge Base retrieval: nothing reaches the model without being checked first, regardless of where it came from.

None of this is glamorous. Data sovereignty rarely is. It is the quiet decision to check a chunk's classification twice instead of once, to scope a query to a tenant at the database layer instead of trusting application code to remember, to tokenize a prompt on the way out even though it slows the request down by a few milliseconds. We have always believed that governance an organisation has to remember to apply is governance that will eventually get skipped, usually under deadline pressure, usually on the one request that mattered. Building it into the pipeline itself is the only version of that promise we trust.

“The point of Retrieval Augmented Generation was never just search. It was giving a model the right context, safely, at the moment it needs it. Everything else is implementation detail, and the implementation detail is where most products fail.”

- Denis Bouton

Denis Bouton was an Operating Partner of ninthLABS and the founding Chief Architect of OBEL™. He is currently the APJ Head of Customer Onboarding for a global leader in digital experience platforms, and continues to advise ninthLABS as a Strategic Advisor.