> ## Documentation Index > Fetch the complete documentation index at: https://vitruvio.sh/docs/llms.txt > Use this file to discover all available pages before exploring further. # Searching > Filters versus hints, and reading a bundle without over-claiming. ```bash theme={null} vitruvio search "decompose a periodic function into sines" vitruvio query search "TEXT" --memory-type semantic --subject fourier --limit 10 vitruvio query resolve vitruvio query prove --memory-type semantic ``` ## Filters bound, hints suggest `--memory-type`, `--subject`, `--tag`, `--since` and `--until` restrict what is *eligible*. They are the difference between a useful answer and a ranking where "what happened in May" competes with "define a Fourier series". `--mode` is a hint. It narrows the admissible plans; it never selects one. `--mode semantic` still admits a term scan, because no index in this protocol is authoritative and a hint must not become a way to make one so. One filter rule is inherited from the protocol and surprises people: **a block with no `occurred_at` fails a time window**. Not "passes by default" — fails. `--since` over a module of undated semantic blocks returns nothing, and that is correct. Both `query search` and `query explain` accept `YYYY-MM-DD` calendar bounds as well as protocol timestamps. `--since 2026-05-01` expands to `2026-05-01T00:00:00Z`, and `--until 2026-05-31` includes the whole day through `2026-05-31T23:59:59Z`. Bounds are inclusive in UTC; a reversed interval is rejected. ```bash theme={null} vitruvio query search "" --memory-type episodic --since 2026-05-01 --until 2026-05-31 vitruvio query explain "" --memory-type episodic --since 2026-05-01 --until 2026-05-31 --json ``` With no query text, a date window uses the BTree `DateScan` when the selected modules have that index. Results are ordered newest first across modules, with block identity breaking timestamp ties. Additional filters, accessibility, and verification still apply before the result limit. Without BTree coverage, the planner can scan the blocks. ## What comes back is an evidence bundle ``` 3 matches verified against canonical sha256:fd522c4afb semantic sha256:95fd781b61 [1] 1.00 semantic sha256:9fcecd9c57 Fourier series source: sha256:fe6f2cdb9c #lines:1-5 ``` The roots line is not decoration: quoting a block without the root it verified against is quoting something nobody can check later. Read these four fields before citing anything: * **`score`** is agreement between retrieval strategies. Not a probability, not a confidence. A string in the JSON, at the protocol's precision — the ordering was decided on the full float before rendering, so two matches showing `1.00` are not tied. * **`truncated`** is `true` whenever a candidate that passed every filter was discarded, *including* one cut by a generator's `k`. Check it before ever saying "the brain does not contain X". * **`superseded_by`** means something replaced it. Cite the successor, or say you are quoting a superseded claim. * **`resolvable: false`** means redacted or not installed — **not** corrupt. The block is still a verifiable member. Verification failures never appear as a flag. A block that fails membership, its inclusion proof, or its store hash is **discarded**, and the discard is recorded as a degradation — because returning corruption with `verified: false` makes it look like a low-quality result. ## The CLI will never write your answer There is no `answer` field, and there will not be one. The brain returns evidence; synthesising prose is the caller's job. A CLI that summarised for you would have quietly become the model, and the summary would carry none of the verification the bundle exists to provide. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.