Two failed builds, a conversation that changed the brief, and the knowledgebase that came out of it.

Two failed builds

The first attempt was a custom-built retrieval system, put together without documentation, without a code history worth trusting, and without anyone left who fully understood how it worked. It wasn't a foundation anyone could safely build on. The second attempt moved to a Custom GPT provider, which solved the "nobody understands this" problem but created a different one: the chunking and data handling never quite worked, and there was no way to diagnose or fix that from the outside.

Two attempts in, the client didn't need a third rebuild guessing at the same problem from a different angle. They needed someone to sit down, go through what had actually gone wrong with both systems, and figure out the real requirements before writing any more code. Smart Knowledgebase is what came out of that conversation.

The gap neither build addressed

What the conversation surfaced was a gap neither build had addressed. A generic retrieval pipeline treats every document the same way: chunk it, embed it, search the whole corpus, rank what comes back. That's fine until a knowledgebase spans multiple sensitivity levels, departments, and document types, at which point "relevant" and "correct" stop being the same thing, and a generic pipeline has no way to tell the difference until you build one in.

So the fix wasn't a bigger model or a better embedding. It was narrowing what got pulled into consideration in the first place, as early and as aggressively as possible, instead of searching everything and hoping the ranking sorted it out afterward.

Smart Knowledgebase

In practice that meant splitting the system into two layers. Underneath, a general-purpose processing layer handles chunking, embedding, and storage across both a relational store and a vector index, so structured lookups don't have to go through vector search. On top of it sits a domain-specific layer built on metadata and taxonomy from the start, not added later once retrieval quality had already become a problem. The interface followed the same logic: built around what someone actually does with the system, not a generic chat box bolted onto a document store.

In the build, that filtering shows up at every stage of the pipeline, starting at ingestion:

• Every query is classified and scoped before retrieval runs, so the search covers the slice that matters instead of the whole corpus
• Recursive structural chunking, splitting by headings, then paragraphs, then sentences, so chunks stay coherent instead of cutting documents at arbitrary token boundaries
• Sensitivity and department are captured as pre-filters at ingestion and enforced server-side everywhere the data is touched: the database query itself, search, document browsing, and single-document lookups. A caller's access is capped by their credentials before a document is ever fetched, and an unauthorized document returns a not-found rather than confirming it exists
• Hybrid tagging: before the LLM pass runs, the system checks its own corpus for the most content-similar already-tagged documents and surfaces their tag frequencies as a signal, not an instruction, so tagging gets smarter as more content gets tagged. Any tag the LLM then proposes against the controlled taxonomy goes into a review queue for a human to approve, reject, or merge, instead of auto-applying and letting the vocabulary sprawl
• A managed taxonomy: categories and tags as first-class, browsable structure, not a free-text field nobody audits
• Scopes grouped into named collections at the point someone searches, so picking a specific knowledgebase actually narrows retrieval instead of being cosmetic
• Bulk tagging processed through a batch pipeline to keep the cost of maintaining the taxonomy down as the corpus grows

Each of those maps back to something that had gone wrong before: retrieval nobody could diagnose, access rules that lived in the interface instead of the database, and a codebase nobody could safely extend. The tagging review queue is the one that pays off latest, since a taxonomy that stays clean is what keeps a knowledgebase usable once it grows past a demo-sized set of documents.

The screens below are from UI prototypes and test interfaces used to build and validate Smart Knowledgebase, not a finished client-facing product.

←→

×←

→

The final UI is built to order for each client, shaped around what they actually need to put in and get out. What sits underneath it is the same platform either way.