Build note: the two-layer split that made an AI system safe to use

The businesses with the most to gain from AI over their own knowledge are usually the ones least able to use it. A professional-services firm holds exactly the kind of material that makes an AI assistant valuable — years of real cases, real reasoning, real outcomes — and exactly the kind that cannot be pasted into a public tool.

The usual response is a policy: don't put client information into AI. That works in the sense that a locked door works. Staff either comply and get no value, or quietly use their phones and you now have an uncontrolled problem.

The alternative is to make the separation structural.

Two layers

The vault I built for this firm has exactly two kinds of content, and the distinction is enforced by where things live rather than by what anyone remembers.

The knowledge layer holds de-identified, reusable expertise: around forty atomic pages covering process types, legal concepts, evidence categories, forms and legislative authority. These reference real cases only by internal code. Nothing here identifies a client. This layer is firm IP — shareable internally, usable for training, safe to point a model at.

The matter layer holds one entry per client: the case summary, the correspondence timeline, the document register. Confidential, internal-use only. Crucially, each matter links into the knowledge layer rather than duplicating it.

The direction of those links is the whole design. Concepts stay small and generic; the weight accumulates in the edges pointing at them. After three thousand matters, a concept page isn't bigger — it just has three thousand real cases hanging off it, each one retrievable, each one attributable.

Why this beats a permissions layer bolted on later

Three things fall out of the split that you cannot get by adding access rules to a flat store afterwards.

The safe layer is safe by construction. You don't have to trust a filter to strip client details from the knowledge pages, because client details were never written into them. There's no redaction step to get wrong.

You can reason about exposure precisely. "What could this assistant see?" has a structural answer — a folder — rather than an answer that depends on a query, an embedding, and a filter chain behaving correctly.

Sharing becomes possible. The firm can show the knowledge layer to a new hire, a colleague, or a regulator without any review process. That was an unplanned benefit and became one of the most used properties of the system.

Access control comes before the build

The part I'd emphasise to anyone doing this: decide the access model before writing the ingestion pipeline, not after someone notices a problem.

A junior staff member's assistant should be able to search precedent without reaching sensitive material — even when both technically live in the same system. That is a straightforward requirement to satisfy if the boundary exists in the data model from day one. It is an expensive retrofit if you built one flat index and now need to carve it up.

This is the single most common sequencing mistake I see. Teams build the impressive demo over everything, show it to the partners, and only then discover that the impressive demo is the reason legal won't approve it.

The honest limitation

The split costs something. Every new matter has to link into the knowledge layer to be useful, which means ingestion has to classify as well as extract, and the knowledge layer needs maintaining as rules change. A flat pile of documents with a vector index is much faster to stand up.

It is also much harder to put into production in a regulated business, which makes the comparison academic. The fast version is fast right up until the compliance conversation, and then it is infinitely slow.

The pipeline that populated this vault is its own note, and the retrieval layer on top is here.

---

Written with the firm's identifying details removed.