1. Chunking
Each document is split into passages at structural boundaries. A passage starts at a heading whenever it can, never splits a fenced code block unless the block alone is too large, and never ends mid-line. Each one carries the heading trail it sits under and its section anchor, which is what a citation points at. Consecutive passages share a short overlap so a sentence that straddles a boundary is not lost. Credentials detected in your content are redacted before anything is stored or embedded. See Content best practices for how to write content that splits well.2. Hybrid search
Two searches run over the knowledge attached to the assistant, inside your organisation only:
Keyword terms are matched without stemming, so
ERR_SOCKET_TIMEOUT and config.yaml match exactly as written. The two rankings are combined by reciprocal rank fusion.
Fusion only orders candidates. Every passage, however it was found, is still judged by its own semantic similarity, so a keyword match on an unrelated passage cannot carry it past the evidence gate.
MITHUNAI does not rerank passages with a separate reranking model, and does not cache retrieval results.
3. The evidence gate
Before the model is called, the best passages are compared with score thresholds:
If any of these applies, the assistant abstains without calling the model. The thresholds are set by the platform, not per assistant, and neither an assistant’s settings nor its guidance can lower them.
Two more checks follow generation: the model may itself decline when the passages do not support an answer, and a draft that cites no passage it was shown is withheld. The full list of reasons is on Stream a message, and How answers work describes the whole path from question to cited answer.