How your node keeps answers accurate

Picture a careful researcher sitting an open-book exam. They do not answer from what they happen to remember. They find the passage in the book, read it, and answer from it. If the book does not cover the question, they say so rather than guess. That behavior has a name here: a grounded answer.

When you ask your node a question, it first searches your own knowledge base for the passages most relevant to the question, hands only those passages to the model, and instructs it to answer from them. If nothing relevant is found, the honest response is "I do not have that information," not an invented one. The answer is anchored to your material, which never leaves your deployment to produce it.

Getting the right passage in front of the model is a short pipeline, and each stage has its own concept page:

Find. Two searches run at once. A semantic search catches passages that mean the same thing as your question even when the words differ, and a keyword search catches exact terms like a clause number or a part code. Their results are fused into one shortlist by hybrid search.

Rank. On Pro and Enterprise nodes, a second, more precise model reads your question against each shortlisted passage and re-orders them so the best-supported answer sits first. This reranking step is part of hybrid search.

Ground and cite. The top passages are handed to the model that writes the answer, running in-pod on your node for paid tiers (see in-pod generation). On Pro and Enterprise, every claim carries a numbered marker back to the exact excerpt it came from, explained in Citations.

Ranking scores are relative, not absolute. The reranker is good at ordering passages from best to worst, but the raw number it assigns can be low even for the passage that clearly answers the question, especially when your wording is very different from the document's. A system that threw away every passage below a fixed score could end up discarding the correct, top-ranked passage and answering "I do not have that information" when the answer was sitting right there in your files.

Your node guards against that. When the usual relevance filter would leave the model with nothing to work from, it falls back to the passages that search already judged relevant, keeping them in ranked order, rather than returning an empty answer. The result: your node only says it lacks an answer when nothing relevant was actually found, not when a score merely looked low.

"Trust us, it is accurate" is not an answer a regulated buyer can accept, so we do not ask you to. We keep a fixed benchmark of realistic question-and-answer pairs across legal, finance, and healthcare documents, each labelled with the passage that should support the answer. Every change to the retrieval and answer pipeline is run against it and scored on two things:

Retrieval hit-rate asks whether the passage that holds the answer was actually found and ranked near the top. Citation accuracy asks whether the answer went on to cite that supporting passage. A minimum bar on both is enforced automatically, so a change that would quietly make answers worse fails the check before it ships. Because the benchmark is frozen, an improvement in the score is a real, like-for-like improvement rather than an easier test.

Measured accuracy is a floor across a representative benchmark, not a promise about every possible answer. A citation shows you which passage grounded a claim; it does not certify that the claim restates that passage perfectly, which is why the full set of retrieved passages is always returned for you to check (see the honest limits in Citations). And accuracy still depends on your documents: a question whose answer is not in your knowledge base should, and will, come back unanswered rather than guessed.