Engine 08 of eleven

Retrieval and enterprise memory.

Evidence, cited — and permissions checked after the ranking, not before.

Retrieval finds the policy, the procedure, the document or the prior case that bears on the question in front of you. What it returns is evidence with a citation, and it is never the authority for a balance, a quantity or a permission.

Cited · Permission re-checked on every result · Never authoritative for a figure
How it works

Lexical first, and measured before anything fancier.

The discipline here is unusual and worth stating: vector search is not adopted until there is measured evidence that lexical retrieval is the limiting factor. The database already carries trigram indexing and a generated full-text column over document text, and those have to be measured before an embedding index is introduced at all.

  • Lexical retrieval over document text, measured first, because it is often enough and it is cheap.
  • Vector retrieval where similarity beats keywords — product-description similarity, semantic alias assistance, document discovery.
  • Graph-assisted retrieval — the knowledge graph scopes the corner of the corpus worth searching before the search runs.
  • Prior-case retrieval — the ticket that looked like this one, and what actually resolved it.
  • Reranking, and then a permission re-check on every surviving result.
The risks it is built against

Six ways retrieval leaks, and the control for each.

Row-level security isolates embedding rows exactly as it isolates any other row — embeddings do not inherently bypass it. What they introduce is a derived-data surface with its own failure modes, and each one has a named control.

  • Source-permission drift — document-level access metadata on the index, and a permission re-check on every retrieved result. Index-time permissions are a filter, never the authority.
  • Stale content — the source document id and revision travel on every chunk.
  • Index invalidation — the embedding model version and the chunking policy version are recorded, and a change to either triggers re-embedding.
  • Deletion — propagated through to chunks and embeddings, and audited as complete rather than assumed.
  • Relevance failure — precision and recall evaluated before the feature is exposed to anyone.
  • Memorisation — evaluated before exposure, because an index that can recite its source is a disclosure risk.
  • Cross-tenant leakage — no unfiltered vector search is permitted to exist anywhere in the system.
The boundary

Never authoritative for a number.

Retrieved material is evidence. It is never the authority for a ledger balance, an invoice payment state, an inventory quantity, a tax treatment, a document lifecycle state, a posting or an authorisation. Those come from the authoritative module, every time. What retrieval contributes is the policy that governs the situation and the case that resembles it — cited, so you can go and read it yourself.

Where it shows up

When the answer is written down somewhere.

  • “What does our returns policy say about this?” — the clause, cited, with the version it came from.
  • “Have we seen this before?” — the prior case and what resolved it.
  • “Which procedure applies here?” — scoped by the entity and the jurisdiction you are actually in.
  • “Where is the contract that covers this?” — document discovery across everything you are permitted to see.
  • “Is there an equivalent product?” — description similarity, as a suggestion rather than a substitution.
FAQ

Frequently asked questions.

Do embeddings put my data at risk?

Not inherently — row-level security isolates embedding rows like any other row. The real risks are permission drift, staleness, incomplete deletion and memorisation, and each has a specific control rather than a reassurance.

Why check permissions after reranking rather than before?

Both. Index-time permissions filter the candidate set, and every surviving result is re-checked against live permissions before you see it — because the permission may have changed since the index was built.

Why not use vector search for everything?

Because it is not free, and lexical retrieval is often enough. Vector search is adopted where there is measured evidence that lexical is the limiting factor, not because it is the fashionable answer.

Can retrieval tell me my balance?

No. Balances, quantities, payment states and tax treatments come from the authoritative module. Retrieval finds the policy about them, not the figure.

See this engine on your own records.

Join the waitlist and ask it something real. Every answer names the engines it used and the records they read.

Join waitlist
No lock-in — export your data anytime.