Grounded in your records, not the internet.
Retrieval that runs against live documents with permissions applied, so an agent never sees what its role could not open, and every answer can name the records behind it.
Live retrieval·Permission-aware·Cited answers
What makes an answer trustworthy.
Four properties. Miss any one of them and you have a system that is confidently wrong in a way nobody can check, which is worse than having no system.
What it reads
The sources an answer can be built from.
Live documents
The current state of records, not an overnight index. A question about stock returns the position now.
Structured and unstructured together
Ledger rows, document fields, attachments, and correspondence, so a question about an invoice can read the PDF and the posting.
Your own knowledge base
Procedures, policies, and published articles, retrieved alongside transactional records and cited the same way.
History as well as state
The version trail on a document, so 'when did this change and who changed it' is answerable.
Attachments read properly
Text, tables, and scanned pages extracted rather than treated as opaque files.
Permissions
Applied before the model sees anything.
Row-level at retrieval
The permission check happens when the records are selected, not by filtering the answer afterwards — which leaks and is the common mistake.
Same rules as a person
No parallel permission model for retrieval. If the role cannot open it, retrieval cannot see it.
Field-level redaction
Sensitive fields — salary, bank details — excluded from retrieval for roles that cannot see them, even on records they can otherwise open.
Company and dimension scope
In a group, an agent scoped to one entity cannot reach another entity's ledger through a question.
Citations
How you check an answer rather than trust it.
Named documents
Every answer lists the records it used, linked, so verification is one click rather than a search.
Figures traceable
A number in an answer resolves to the posting or the field it came from.
Refusal when unsupported
Where the records do not contain the answer, that is the answer. It does not reach for general knowledge to fill the gap.
Confidence surfaced
A weakly supported answer is marked as such rather than presented in the same tone as a certain one.
Freshness and cost
The operational reality of retrieval.
Indexed on write
A posted document is retrievable immediately, so there is no window in which the system is confidently out of date.
Deletes propagate
A cancelled or deleted record leaves the index with it. A stale index that still answers from removed data is a compliance problem.
Scoped retrieval
A question narrowed by company, period, or document type retrieves less and answers faster.
No re-indexing project
Adding a custom record type makes it retrievable without a separate pipeline to build and maintain.
From a question to a citable answer.
The permission step is second rather than last. That ordering is the whole design, and reversing it is how retrieval systems leak.
- 01
Interpret
The question resolves to record types, filters, and a period, rather than to a similarity search over everything.
- 02
Authorise
The requester's row-level permissions are applied to the selection before any content is read.
- 03
Retrieve
Matching records and their attachments are read at their current state, not from a snapshot.
- 04
Answer
The reply is composed from what was retrieved and lists the documents behind it, or says the records do not support one.
The specification.
What a data-protection review will ask about retrieval specifically.
- Source
- Live records; no separate warehouse or overnight index
- Permission point
- Applied at selection, before content is read
- Redaction
- Field-level, by role, within permitted records
- Freshness
- Indexed on write; deletes propagate immediately
- Attachments
- Text, tables, and scanned pages extracted
- Citations
- Named and linked on every answer
- Unsupported
- Refusal rather than completion from general knowledge
- Custom types
- Retrievable on creation, no pipeline to build
What retrieval will not fix.
Retrieval is only ever as good as the records under it, and it is better to say that here than to demonstrate it later.
- It cannot answer what nobody recorded
- If the reason for a credit note was never written down, no amount of retrieval will recover it. This is the most common disappointment and it is a process problem.
- It will not reconcile contradictory masters
- Three spellings of one customer produce three partial answers. Retrieval makes master-data problems visible rather than solving them.
- It is not a search engine for the web
- Deliberately. Grounding means your records, and mixing in general knowledge is how a citable answer becomes an uncheckable one.
- It does not improve a bad question
- 'How are we doing' resolves to nothing in particular. The console will ask what you mean rather than guess impressively.
Next step