Evidence retrieval

Watch real searches

Recorded runs on two sample corpora. Each hit is a chunk with its byte offsets in the source document. The receipt is signed; your browser re-checks the signature, the index hash and every chunk's Merkle proof, and a changed character fails.

Loading the recorded run…

How it works

1. Documents are cut into chunks at paragraph and sentence boundaries (up to 1,200 characters, no overlap). Each chunk keeps its byte offsets in the source document and its SHA-256.
2. The index hash commits to the corpus (a Merkle root over each chunk's document hash, id, offsets and hash), the chunker settings and the embedder's repo and revision. The same files give the same corpus root on any machine.
3. Search: Qwen3-Embedding-0.6B (dense) and BM25 each propose 40 chunks, fused by reciprocal rank; Qwen3-Reranker-4B scores those 40 and orders them.
4. Every embed and rerank call gets a decosa.model-call.v1 receipt: the model's weights root, hashes of the texts and of the vectors or scores, and the parameters.
5. Every search returns a signed decosa.retrieval.search.v1: the index hash, the query hash, the reranker revision, and the chunks returned with their offsets, integer scores and ranks.
6. Downstream, answers may only quote retrieved chunks: quotes are matched word for word back to a chunk and its bytes, and the grounding block judges each sentence against the retrieved chunks only.

A search receipt, shortened:

{
 "v": "decosa.retrieval.search.v1",
 "id": "rs-1f3ec45321c2af8ca415",
 "index": {
  "hash": "e10c3051bfd024bb…",
  "corpus_root": "e398087f5b3e3b91…",
  "n_chunks": 171,
  "embedder": {
   "repo": "Qwen/Qwen3-Embedding-0.6B",
   "revision": "97b0c61"
  }
 },
 "reranker": {
  "repo": "Qwen/Qwen3-Reranker-4B",
  "revision": "22e6836"
 },
 "query_sha256": "f25e731a9cbaea36…",
 "params": {
  "k": 5,
  "rerank": true,
  "mode": "hybrid",
  "candidates": 40
 },
 "results": [
  {
   "rank": 1,
   "chunk": "K1#20",
   "doc": "K1",
   "doc_sha256": "bc3db8c11b06d084…",
   "byte_start": 16453,
   "byte_end": 17515,
   "sha256": "a33d10501ca38e5a…",
   "scores_ppm": {
    "dense": 449034,
    "rerank": 294215
   },
   "ranks": {
    "dense_rank": 14,
    "bm25_rank": 1
   }
  },
  "…"
 ],
 "model_calls": [
  {
   "id": "mc-6b3baa596d807019067c",
   "kind": "embed"
  },
  {
   "id": "mc-d2e6078e2c42cb7889fe",
   "kind": "rerank"
  }
 ],
 "signer": "700c585540114e5c…",
 "sig": "8124f74db726b1d6…"
}

API

Hosted, the block takes synthetic or public documents only, up to 60 documents and 1,500 chunks per index, held in memory for an hour. Self-host it for real ones.

Which models, and why

Six open models compared on dev splits only: our security-questionnaire questions (26) and in-contract clause finding on CUAD (164 queries, 40 contracts). The test splits and two MLEB sets were scored once, after the choice. Memory is the measured peak on the card.

The pairs with the 4B reranker tie on the questionnaire; on CUAD the Nemotron embedder is 0.014 MRR ahead, within noise on 164 queries. We serve the all-Apache Qwen pair: one licence, one prompt family, and the use cases built on the block were measured on it. The larger Qwen3-Embedding-4B bought nothing on dev or held out and would put the service over its 18 GB share of the card. The lean pair is the choice for a box without the room.

Results

First upgrade: the security questionnaire

The security questionnaire answerer now takes its candidates from the block: 4 approved answers and 2 policy passages after reranking, instead of 6 and 3 by BM25. Prompts, the selector and the checks are unchanged. Same synthetic library and the same 100 held-out questions, run once.

Retrieval alone now closes 71% of the gap between the old keyword baseline and the model's selection, with no model call, though it catches only 1 of 4 stale answers: the policy check still needs the model. On this small synthetic library the right source was always among the candidates either way, so the gains are a better top candidate and shorter prompts. Each question's search has a signed receipt, and the review record names the index hash.

Where it goes

• Security questionnairebuilt

  Candidates for the answer selector; a search receipt per question; the index hash in the signed review record.

• M&A due-diligence red flagsbuilt

  Each red-flag category searched across the data room; every flag quotes a retrieved chunk, checked word for word, cited to its byte span.

• Tariff classification memobuilt

  Similar CBP rulings and HTS text retrieved for a product description; the memo cites rulings by number with quotes checked against the retrieved text.

• Medical chronologybuilt

  Scans into retrieval: each page's document-reader elements become chunks that keep their page and box (a layout hash commits to the boxes); every chronology line's quote is located to its chunk, byte span and box, and a search per procedure finds other pages that give a different date.

• Legal drafting, privilege log, deposition, patent claims, filing pre-flightnext

  Replace each module's own keyword search for the lines a sentence cites.

• Groundingnext

  Evidence selection for long sources: the retrieved chunks, not BM25 windows, go to the judge.

Self-host

Two processes: the retrieval service holds the embedder and the reranker; decosa-api chunks, indexes, searches and signs.

uv venv .venv-retrieval --python 3.12
uv pip install -p .venv-retrieval -r services/retrieval/requirements.txt --extra-index-url https://download.pytorch.org/whl/cu130
hf download Qwen/Qwen3-Embedding-0.6B --revision 97b0c614be4d77ee51c0cef4e5f07c00f9eb65b3
hf download Qwen/Qwen3-Reranker-4B --revision 22e683669bc0f0bd69640a1354a6d0aebcfeede5
RETRIEVAL_EMBED=qwen3-emb-0.6b RETRIEVAL_RERANK=qwen3-rr-4b .venv-retrieval/bin/python services/retrieval/server.py   # 127.0.0.1:8499
DECOSA_RETRIEVAL_URL=http://127.0.0.1:8499 DECOSA_RETRIEVAL_SYNTHETIC_ONLY=0 python -m decosa_api

Then rehearse on the bundled synthetic policies before any real document: python scripts/rehearse.py evidence-retrieval. About 12 GB of GPU memory for the pair we serve; the lean pair (RETRIEVAL_RERANK=qwen3-rr-0.6b) needs about 5 GB and runs on a CPU, slowly. On a Mac the service uses MPS by itself: measured on an M3 Ultra, same scores, reranking about 3 times slower than our GPU. The rehearsal indexes nine synthetic policies and checks the corpus root anyone gets from them.

Licences and receipts

The embedder and reranker run outside our gateway, so their receipts are signed by decosa-api's own key (an attestation by its operator) and, where the gateway is configured, reported to it and countersigned as a witness of the hashes, not the bytes. The search receipt is signed the same way. What they prove: which corpus snapshot and model revisions were used and which chunks came back with which scores. What they do not: that the ranking is right.

What it does not do

• English only: no other language was measured.
• Finding one clause type inside one long contract: the reranker does not help (see above); use dense mode or read the top 10.
• The hosted index lives in memory for an hour, for synthetic or public documents only; it is not a database. Self-host for a persistent corpus of real documents.
• Scanned PDFs are not read here: pass the text, or the document reader's elements.
• A high reranker score means relevant, not correct: whether a passage supports an answer is the grounding block's job.