Search

BNLGit indexes both your source code and its .llm summaries. This page is deliberately specific about which parts are on by default, because the honest answer is more useful to you than a confident one.

Lexical search over summaries

Exact and fuzzy text search across .llm summaries. Available on every BNLRepo, always.

Results are ranked by a trust ladder that reflects how much a summary should be believed:

Stale and unverified results are down-ranked and excluded by default. Pass include_stale or include_unverified to opt back in — the point being that you have to ask for the untrustworthy material on purpose.

Exact code search

Exact search over your real source files, backed by git grep. Use it when you already know the symbol you want. Exposed to agents as the search_bnlgit_code tool.

Vector retrieval — read this before relying on it

BNLGit's retrieval pipeline supports vector-ranked semantic search over .llm summary chunks, returning both the matched summary excerpt and the exact backing source lines. It is built, it is tested, and it is what the search_bnlgit_hybrid tool uses.

It requires an embedding model to be configured on the repository pair, and it is not configured by default.

When a repository has no embedding model set, has no indexed chunks for the ref being searched, or the embedding call fails, the query does not error and does not return nothing — it falls back wholesale to the lexical summary search described above, and reports that it has done so in its response mode. Your agent gets a real answer either way; it is simply a lexically-ranked one.

Two further specifics worth knowing:

• It is a fallback, not a fusion. Within a single repository, a query is either vector-ranked or lexically-ranked, not both blended. In a fleet query spanning several repositories, repositories that fell back to lexical are scored on a deflated scale so they still compete against vector-ranked ones without outranking them.
• Existing summaries need backfilling. Chunks are indexed as summaries are generated. If you turn on vector retrieval for a repository that already has summaries, run bnlgit summaries backfill-embeddings to index what is already there.

About the index itself

Chunk vectors are stored as raw float arrays and nearest-neighbour search is a brute-force scan over them, per repository. An indexed database-side vector path exists in the codebase but is deliberately not wired up: it supports only one fixed dimension, and per-repository brute force is fast enough at the scale BNLGit actually runs at — fleet search ranks each repository independently rather than pooling every chunk into one giant query.

We mention this because it is the sort of thing that gets claimed as a performance feature. It is not one, we make no performance claims about it, and if your fleet ever outgrows it, that is a real engineering conversation rather than a config flag.

Fleet search

Pro.

/-/bnlgit/search searches across every BNLRepo you can see in one query instead of one repository at a time — subject to exactly the same lexical and vector behaviour described above, per repository.

Reranking

Pro. Off by default.

An optional cross-encoder reranking pass re-scores a candidate pool for relevance before results are returned, and the final ordering combines relevance with the trust tier. It is enabled per instance from Site Admin → Config, without a restart, and requires both a Pro edition and that explicit operator switch.

The candidate pool is capped, so reranking refines an already-retrieved set rather than widening it.

Where privacy comes in

When vector retrieval is enabled, the query is embedded using the instance's own server-side key — never your BYOK key. Your key is spent at index time, on your own repository, and nowhere else. This is deliberate: without it, one busy reader could fan embedding spend across every tenant whose repositories they can see.