How queries are read
Search reads a query before it looks anything up, so a phrase like "small enough for an iPhone" is understood as a constraint on the device rather than as a subject to search for, and "speech to text" does not come back as "text to speech". What the read finds shapes the ranking and never the result set: a preference moves a row up or down, so a query read wrong costs you ordering rather than an empty page.
A call is one query string in, one ranked list out: every kind of result competes on the same relevance ordering, rather than each kind getting a row of its own. Name a device in the query and the models that run on it move to the front of that list, with rows that do not run on it kept below. If the read finds no preference to act on, the same list comes back ranked on relevance alone.
The trade-off to know up front is that this reading can order results but never filter them. A preference moves rows and does not remove them, so no phrasing will keep a result out of the response; anything that must be excluded has to be filtered by the caller after the call. The fallback is silent, too: a query whose preference the read does not recognise is not an error but an ordinary relevance-ranked page, so code that needs to be sure a preference took effect has to judge it from the ordering it receives.
Tags @ranking @search
graph LR
cap["How queries are read"]
b0("A query that names a device<br/>returns models that run on it")
b1("A preference reorders results,<br/>it never removes them")
b2("A query with no recognisable<br/>preference is ranked on<br/>relevance alone")
b3("Results are ranked by<br/>relevance, not one row per<br/>kind")
cap --> b0
cap --> b1
cap --> b2
cap --> b3
classDef cap fill:#eef2ff,stroke:#1d4ed8,stroke-width:1px,color:#1d4ed8
classDef beh fill:#fffdf2,stroke:#eeb900,stroke-width:1px,color:#14161a
class cap cap
class b0,b1,b2,b3 behA query that names a device returns models that run on it
Reading a device name as a topic rather than a filter would surface models that merely mention it, not the ones that actually run on it.
Given a query naming a device
When the query is read
Then the device is treated as a constraint, not as the subject
And the search is widened to on-device formats
A preference reorders results, it never removes them
Preferences express desirability rather than eligibility, so treating a mismatch as a disqualification would discard results that remain useful.
Given a query that prefers a format
When a candidate is scored
Then a matching candidate ranks higher
And a candidate that does not match is still returned
A query with no recognisable preference is ranked on relevance alone
Queries without an expressed preference still deserve results, and inventing a filter to fill the gap would skew them, so absence must count as no instruction.
Given a query with no preference in it
When the read finds nothing to act on
Then results come back in plain relevance order
Results are ranked by relevance, not one row per kind
Ranking by relevance is what makes a combined result list useful; otherwise the best match can be buried under weaker entries chosen just to represent each kind.
Given results drawn from several corpora
When they are merged into one list
Then rows are ordered by how well they match the query
And the list is not a round-robin of one row per kind
What to know
Plan for the misread, not the miss. A query the search reads as a preference reorders results and never removes them, so a query it reads wrong does not come back empty — it comes back ordered as though you had asked for something slightly different. That makes an empty page useless as a signal: nothing in the response will tell you a phrase was misunderstood, so test the exact phrasings your users will send, and where your client needs a hard guarantee — that a result really runs on the device the user named, say — verify the rows you get back rather than trusting position alone. The edge cuts the other way too: when the read is right, position is the preference, so give the top rows prominence rather than burying them under kind-based grouping.
Two habits follow for what you send and how you render. Pass the user's words through intact — the read is sensitive to phrasing and word order, and a query you normalise into keywords or rearrange can arrive asking for the opposite of what was meant. Build for uneven responses as well: results come back ranked by relevance rather than one row per kind, so a page can be dominated by a single kind of result, and any client assuming balanced coverage — one of each, or a kind at a time — will break. A query with no recognisable preference at all gets plain relevance ranking, which is a fine default, but do not lean on the ordering as if it implied a constraint the user never stated.