Guides
Guides
Task-oriented documentation for schemas, ingest, the two query grammars, filters, vector search, the admin console, configuration, and local development.
The guides are task-oriented. Each one takes a single part of YoloSearch — schemas, ingest, a query grammar, configuration — and explains the mechanism behind it, not only the commands that drive it. Where a page states a default or a limit, that value comes from the binary's own generated reference; see the CLI reference and the configuration reference when you need the exhaustive tables.
If you have not run YoloSearch yet, start with the quick start. It gets a server, a schema, a corpus, and a served query in one sitting. Come back here when you want to know why a step behaved the way it did.
| Guide | What it covers |
|---|---|
| Schemas | Writing a document schema as a protobuf message, the option defaults, canonicalization, and the rules for evolving a schema without breaking existing segments |
| Ingest | push, delete, the acknowledgment states, and the spool-seal-publish pipeline that turns a batch into a served generation |
| The Lucene grammar | The default search-bar grammar: terms, phrases, boolean occurrence, ranges, and the operators that are refused by name |
| The CQP grammar | The positional grammar: token constraints, sequences, quantifiers, regex values, and how a quantifier lowers to a phrase or an alternation |
| Filters and projection | Filterable fields, typed filter values, range lowering, and asking for stored fields back with --fields |
| Vector and hybrid search | Declaring vector fields, the four embedding modes, and running vector, hybrid, and exhaustive queries |
| The admin console | The separate console process, its bridge, the Ingest upload endpoint, and the operations it can and cannot perform |
| Configuration | One catalog of settings, five precedence layers, file discovery, reload, and what may change at runtime |
| Local development | The one-binary yolosearch-local setup and the Docker Swarm fleet that gives you a real two-worker topology |
For application integration, start with:
- Schemas — everything else depends on the schema. Field options decide whether a field is searchable, filterable, projectable, or all three, and most of the refusals you will meet later are schema refusals arriving one layer down.
- Ingest — how documents reach a segment, and what "published" means. The distinction between an ephemeral acknowledgment and a published generation is the one that decides whether your next query sees your last write.
- The Lucene grammar — the grammar a search box sends.
- Filters and projection — how a query narrows and what comes back in a hit.
- The CQP grammar and vectors when the lexical surface is not enough.
For someone operating a deployment, read configuration first, then the admin console, then the deployment pages: containers, Kubernetes, the object store, and observability.
They assume the yolosearch binary is on your path and a server is reachable
at 127.0.0.1:9500, which is the default every client verb dials. Commands
are written without a --server flag when that default is correct and with
one when the page is talking about a topology that has more than one endpoint.
They also assume the mental model in concepts: documents become
immutable segments and objects, segments
are referenced by a catalog generation,
and a server follows the catalog rather than owning mutable state. If a guide
says "the next search sees it", that is the follower installing a new
generation, described in the query lifecycle.
Use the running binary to check its commands and settings:
yolosearch manual
yolosearch config list --prefix builder.manual renders the reference from the command tree and the configuration
catalog, so it cannot drift from the code it documents.
The CLI reference on this site is a manually maintained
summary of that output. config list
reports each setting's value, scope, and where the value came from, which is
the authority when a written table and a running process disagree.