Search Chips

Overview

A normal search box makes you choose. Either you write a precise filter and lose the ability to ask a vague question, or you ask the vague question and get results from the entire corpus.

Chips remove the choice. A chip is a hard filter — {{ motion and signed }} — placed inline with ordinary prose. The filter narrows the documents; the prose beside it says what you're looking for inside them.

{{ filingType=="motion" }} proportionality objections

That reads as one sentence and runs as two things: a structural filter, and a semantic question asked within it.

Why position matters

This is the part that surprises people: where you put a chip changes the query.

Each chip pairs with the free text that follows it, and each pair becomes its own sub-search. Two chips means two sub-searches, each with its own filter and its own question, merged at the end.

{{ filingType=="motion" }} proportionality objections {{ filingType=="order" }} what the court actually granted

This runs as:

Filter	Question
`filingType=="motion"`	proportionality objections
`filingType=="order"`	what the court actually granted

Not as one blended query against both. You asked two questions about two different kinds of document, and you get two answers, attributed separately.

Text placed before the first chip is treated differently — it becomes a framing segment, applied as a soft boost across the whole search rather than as a hard constraint. It nudges relevance; it doesn't exclude anything.

discovery dispute {{ filingType=="motion" }} proportionality objections
             ↑ framing (soft)      ↑ chip (hard)   ↑ intent (semantic)

A query with no chips at all behaves exactly as it always has — one question, whole scope. Chips are additive; nothing changes until you use one.

What goes inside a chip

Chip bodies are boolean filter expressions. They support:

Comparison

filingType=="motion"
filingDate>="2026-01-01"

Boolean operators and grouping

motion and signed
motion and not opposed
(filingType=="motion" or filingType=="response") and signed

References — the @ prefix points at a specific record:

motionRef==@m-0001

The composer parses as you type and shows a live syntax indicator. An incomplete expression is marked as incomplete rather than invalid while you're mid-keystroke, so it doesn't flash errors at you for typing a half-written parenthesis.

If an expression ultimately fails to parse, that chip is skipped rather than silently returning nothing — the rest of the query still runs, and the parse error is recorded.

Building chips

Chips can be composed two ways.

Type them. Write {{ and the composer opens a chip inline. Autocomplete suggests tags and fields present in your corpus.

Click them. The composer renders each chip as an editable pill. Click a term to change it, an operator to flip and / or / not, or drag to reorder. The underlying string is rewritten on every edit, so the typed form and clicked form are always the same query — there is no hidden state that drifts from the text.

That round-trip is deliberate: whatever you build by clicking, you can copy as text, paste into another search, or hand to a colleague.

Chips and scope together

Chips and scope solve different halves of the same problem and compose cleanly:

Scope answers which documents are eligible — drawn on the Haystack Block View by selecting a motion and everything connected to it.
Chips answer which of those, and what am I asking of each.

A scope of "this motion and everything arguing about it", with a chip of {{ filingType=="response" }}, asks a question of only the responses within that constellation. Neither mechanism can express that alone.

Worked example

Invented cause number and filing titles throughout:

{{ filingType=="motion" and filingDate>="2026-01-01" }} objections to the scope of requests
{{ filingType=="order" }} which objections were sustained

Sub-search one takes motions filed this year and asks, semantically, about objections to request scope. Sub-search two takes orders — no date bound — and asks which objections survived.

The result set shows both, labelled by the chip that produced them, so you can see that the motion argued nine points and the order addressed four.

Compare that to the flat query "objections to the scope of requests and which were sustained", which would rank every document mentioning objections against a single blended embedding and leave you to work out which document type each hit came from.

When not to use a chip

Chips add precision at the cost of a decision. Skip them when:

You don't yet know the shape of the answer. Start broad; add chips once you know what kind of document you're actually after.
The filter would match almost everything. A chip that excludes nothing costs you a sub-search boundary for no narrowing.
A scope selection already says it. If you've scoped to a single motion's constellation, {{ motionRef==@… }} is redundant.