Search families and their tradeoffs
Different retrieval evidence, composed without inventing another content index.
Exact search finds a literal string, not a regular expression. It is useful for a distinctive identifier or quotation. Its coordinates describe matching bytes in the rendition.
Lexical search uses word-based ranking. It helps when you know the terms likely to occur in the text. Semantic search compares meaning through embeddings, so it can connect different wording; model work makes it a different cost path from a tag selection or direct read.
Hybrid composes semantic and lexical results using reciprocal-rank fusion. Auto currently adds bounded exact evidence to that composition. These are policies over independent families, not new physical indexes or new copies of the source.
Everything's public search uses auto. Its owner search tool is also a bounded application interface, not an unrestricted wf-store client. Explicit service-level mode selection belongs to the underlying supported client contract.
Required coverage must be ready at the selected logical cutoff. A missing family must not become a silent partial success. Exact, lexical and semantic representations can be rebuilt or placed differently while logical asset and chunk identity remain separate from physical placement.
The guide sidebar takes a smaller path
The full public Search view uses auto, but search inside templates explicitly uses one bounded lexical query from a public page field. It requests no query embedding or automatic refill. Its related cards need not match full Search or MCP's collection/type-based get_related_pages. Those are different discovery behaviors, not additional copies of the corpus.