Use case: on-prem enterprise AI search with Cohere models

1. THE DOCUMENTS. ONE COMMAND.

The corpus: NIST AI RMF 1.0, the NIST generative AI profile, CSF 2.0, SP 800-53 rev. 5, SP 800-61 rev. 3, SP 800-30, the NIST Privacy Framework, and six chapters of CMS manuals on claims processing, benefit policy and program integrity. All public domain. One command makes them searchable, one record per page or section.

$ xerj autoindex ./corpus --prefix policy
indexed: 3033 documents live; this run submitted 3033 source records from 14 files
xerj-done ok=true exit=0 reason=completed wall=7.9s files=14 records=3033

Searching it: a full-text match over the 3,033 records ran at 0.8 ms p50 and 2.3 ms p95 on the same node.

2. THE DATABASE. CONNECT ONCE.

The claims table lives in Postgres 16. One command registers it as a source inside the node: a consistent snapshot, then every insert, update and delete through Postgres logical replication. The node remembers it across restarts.

$ xerj connect postgres://[email protected]/claims --password-env PG_SRC_PW
claims: snapshotting 92% (185000 rows, 47105 rows/s, ETA 0 s)
claims: streaming
claims is live (streaming). Indices:
  public.claims -> src-claims-public-claims (200000 rows)

3. QUESTIONS IN PLAIN WORDS. ANSWERS WITH EVIDENCE.

For plain-language questions over structured records, we wrote 1,000 claims (an export of the same table) as facts and asked XERJ Query-1. It compiles each question into a small program, runs it over the facts and shows the record it used. When it cannot ground an answer it says UNKNOWN; it does not guess.

$ xerj autoindex claims.csv --facts claims --key claim_id
claims: 1000 rows · key claim_id · wrote 6000 facts (1000 new, 0 changed, 0 unchanged, 0 withdrawn)

Five answers, five correct, three honest declines, about 0.2 to 0.4 seconds each on CPU. For totals, the ordinary aggregation in step 2 is the right tool and is exact.

4. COHERE ON TOP. CITATIONS BACK TO THE PAGE.

Rerank as a stage of XERJ's own search, then Command answering from the best passages with citations that resolve to a file and a page. These calls went to a mock of Cohere's API (no key yet), so they prove the wiring and the shapes, not Cohere's quality.

POST /policy-docs/_search
{"query": {"match": {"body": "how long does a beneficiary have to file an appeal of a claim decision"}},
 "rerank": {"provider": "cohere", "model": "rerank-v5.0-fast", "window": 30}}

"_rerank": {"applied": true, "provider": "cohere", "model": "rerank-v5.0-fast",
            "window": 30, "judged": 30, "partial_failures": 0, "usage": {"search_units": 0}}

$ python3 command_rag.py ask "How long does a beneficiary have to file an appeal of a claim decision?" --assert-citations
Citations:
  -> cms-benefit-policy-ch15.pdf page 29 (_id 0ced0557c9bed8f895a9a8bb1fda8253)
  -> cms-benefit-policy-ch15.pdf page 42 (_id f503a0792638a0f359ebb1ff2702e546)

The cookbook embedded all 3,033 records and wrote them back with vectors in 7.6 seconds against the mock; with a real key, that time depends on Cohere's API. The mock's answer text is left out because it says nothing about Cohere's quality.

WHAT IT RAN ON, AND WHAT IT COSTS.

Everything ran on one laptop-class machine (x86_64). The search node, holding the 200,000-row table, the 3,033 document records and the vector index, used 787 MB of RAM. The node with the XERJ Query-1 model used 1.05 GB. For a larger example workload, 10 GB of text and a million questions a month, we priced one 32 GB CPU server at about $468 a month against $21,175 to $65,747 for managed vector-RAG and GraphRAG stacks on the same data, at list prices fetched on 2026-11-05. Most of that difference is the per-question language-model bill, not the infrastructure. Method and caveats.

TRY IT IN ONE PROMPT.

curl -fsSL https://xerj.org/get | sh -s -- --with-model

Cohere setup: the integration page and docs/COHERE.md. Sources of the documents: nvlpubs.nist.gov and cms.gov, U.S. government works in the public domain.