The evidence loop in practice
A useful test of zvec-grep is a cross-file question whose wording names a behavior but not its location. Following that question from indexed discovery to structured evidence and, when necessary, exact verification shows what the system can make easier—and what a careful reader must still check before relying on the answer.
Consider a maintainer investigating a startup bug: “Where does the application restore a saved theme, and which component chooses the default when no saved value exists?” The maintainer may know the behavior and the product vocabulary, but not the function, file, or control-flow boundary that implements it. This is precisely the kind of question for which a literal search can begin with the wrong noun. The useful result is not just a matching line. It is a path through the workspace that identifies the relevant entities and their relationship.
A question becomes a route, not a guessed filename
The first move is to preserve the question’s relationship. “Restore a saved theme at startup” describes an action and a time boundary. “Choose the default when no saved value exists” describes a conditional branch. If the search is reduced immediately to a guessed class such as ThemeStore, the guess can narrow attention too early. That name may identify a storage object while the actual startup trigger belongs to a bootstrap module or an adapter in another file.
An indexed zvec-grep query can begin with the behavior and its relationship. Its hybrid path gives lexical retrieval useful anchors when the wording contains them and vector retrieval a way to connect related expressions. The returned items are ranked candidates, not a verdict. Their value at this stage is that they make unknown vocabulary visible: a result may reveal a symbol, a heading, a scope breadcrumb, or a source phrase that gives the next search step a more reliable anchor.
The searcher should read the result as a set of hypotheses with evidence attached. A candidate that mentions initialization may be relevant to the startup boundary. A candidate that mentions persistence may explain where the saved value comes from. A candidate supported by both recognizable terms and conceptual similarity may deserve early attention, but it still needs to be read in context. The original relationship remains the controlling question; discovered identifiers are clues that help express it more precisely.
Scope belongs in this first decision. If the question concerns application code, restricting the indexed query to the relevant source area can reduce noise. If it concerns documentation and configuration together, excluding one of those kinds can hide an important part of the answer. A result only supports a claim about the workspace material that was admitted and the filters that were applied. The disciplined phrasing is therefore “within the indexed source scope, these entities explain the behavior,” not “the workspace contains no other explanation.”
As candidates arrive, the investigation becomes a small sequence of source reads. The first result may identify a startup function and point to a range containing its initialization logic. The next may identify a preference object whose metadata supplies the enclosing scope and signature. A third may be a Markdown section or configuration fragment that explains a default. Zvec-grep does not need to know the final prose answer in advance. It needs to put source-linked pieces in an order that makes the answer economical to reconstruct.
This is where a mixed route is more useful than a forced choice. Indexed discovery finds the names and locations that a behavior-focused question did not provide.