How retrieval works

An agent answers from your content by retrieval: it searches your knowledge base for the passages that bear on a question, and answers from those passages with citations. If no passage is relevant enough, it says so. Every stage runs in your deployment, in your account.

Indexing

Answering

1. Your sources are synced into your deployment, in your account. New, changed and deleted items are synced; nothing comes to Atlantic.
2. Screening: each item is labelled and checked before it is indexed.
3. Passages: documents are split into overlapping passages.
4. Two indexes: keyword (BM25), and meaning, from an embedding model in your deployment, kept in SQLite or PostgreSQL with pgvector.
5. A question from an agent is searched by keyword and by meaning, within the caller's access scope.
6. Fusion: the two ranked lists are combined into one.
7. Re-ranking, if enabled: a closer read of the leading passages.
8. The agent answers from the passages and cites them, or, if nothing is relevant enough, abstains and says so.
9. Measurement: only counts and timings go to LightHouse, in Atlantic's account.

Every stage runs in your deployment, in your account. The only thing that leaves is operational telemetry: counts and timings, never content.

Where it runs

Indexing and answering both run inside the Atlantic Agentic Engine in your account. Your sources are synced into your deployment, and the documents, the passages, both indexes and the search itself stay there. Nothing is sent to Atlantic for indexing or for search.

LightHouse receives operational telemetry only: counts and timings, such as how many passages a search considered and returned. It does not receive a question, a passage or a document. See Where everything lives and The telemetry contract.

Indexing

Sync

Each connector reads its source on its own schedule and writes what it finds into your deployment’s corpus. It reads only what has changed since its last pull: new items are added, changed items are rewritten and unchanged items are left alone. Deletions are synced too (see When something is deleted).

Screening

Each item is labelled with its access classification as it is written, so that a search can later return only what the caller may see. An item that cannot be classified is held back and counted. It is not indexed. Separately, the gateway masks the personal data your policy names before any text is sent to a model.

Passages

Each document is split into passages, and neighbouring passages overlap. A sentence that falls across a boundary is therefore still found whole in one of them. A document is ranked by its strongest passage, so a long document does not outrank a short one on length alone.

Two indexes

Every passage is indexed twice:

• Keyword: a BM25 index of the words in each passage. It finds exact terms: a regulation reference, a product code, a person’s or system’s name.
• Meaning: an embedding of each passage, made by a small embedding model that runs inside your deployment. It finds passages that say the same thing in other words.

Neither index is built by an outside service, so your text is not sent anywhere to be indexed.

Storage

The passages and both indexes are kept in your deployment’s store: SQLite, or PostgreSQL with pgvector. The choice is made when the stack is deployed. Knowledge bases lists every supported store.

Answering

Access scope

A question is searched within the access scope of the person or agent who asked. The scope is applied inside the query itself, so a passage the caller may not see is never among the candidates.

Search and fusion

The question is searched by keyword and by meaning at the same time. Each channel returns its own ranked list, and the two lists are fused into one by rank: a passage that ranks well in either channel is kept, and one that ranks well in both rises to the top. Fusing by rank means the two channels’ scores never have to be compared directly.

Re-ranking

Re-ranking is optional and is set per pack. When it is on, a re-ranking model reads the question and each leading passage together and orders them again. It is more precise and slower, so it is enabled where a pack’s evaluation shows that it improves the result.

Citations and abstention

The passages that survive are given to the agent as evidence: each is wrapped and marked as material to read, and the model is told to treat it as such and never as instructions (see Evidence). The agent answers from those passages and cites the passage behind each claim. The engine checks the citations in code: a citation to a passage that was never retrieved is caught.

When no passage is relevant enough, the search abstains: it returns nothing, and the agent reports that your content does not answer the question rather than answering from general knowledge. The level at which a search abstains is calibrated for each pack against its evaluation set.

When something is deleted

An item deleted at the source is removed from your corpus and from both indexes on a later sync, wherever the connector can detect the deletion. Some connectors see a deletion on their next pull; others confirm deletions by listing the source on a schedule. Each connector’s page says how. A passage that has been removed can no longer be retrieved or cited. The index is part of your engine, in your account, so removing the engine removes it: see Leaving.

Measurement and the evaluation gate

Every search is measured in your deployment: the candidates considered, the passages returned, the tokens sent to the model and the tokens not sent. LightHouse reports these counts under Cost and token optimisation; the reduction in tokens sent is reported as an estimated saving.

Retrieval is also scored against each pack’s golden set: questions paired with the documents a good answer must find. Retrieval scoring calls no model, so it is repeatable and costs nothing. A release that makes retrieval worse than the last release on the same golden set is blocked. See Evaluations.

What you configure

Setting	Where it is set
The store: SQLite, or PostgreSQL with pgvector	When the stack is deployed
The embedding model, from those the engine supports	Per deployment; changing it rebuilds the meaning index
Re-ranking, on or off	Per pack
The level at which a search abstains	Per pack, calibrated against its golden set
The weight given to each search channel in fusion	Per pack
How often each source is synced	Per connection, in LightHouse (Sync schedules)

These do not change with configuration: every stage runs in your deployment; the caller’s access scope is applied inside every search; retrieved text is always fenced as evidence; and citations are always checked.

Clients under NDA receive the architecture in more detail, including the defaults and the evaluation results. Ask your Atlantic contact.