In Qdrant, why can two must conditions on an array payload match the wrong points?

## Array semantics When a payload field holds an array, Qdrant's conditions mean "some element of this array satisfies it". That is usually the behaviour you want: `tags: ["ml", "db"]` matching `MatchValue(value="db")` needs no special syntax, and `must_not` over the same field means no element matches. The subtlety appears only for **arrays of objects**, where you write conditions against several fields of the same logical record. ## The false positive Consider a product point: ``` payload = {"items": [{"name": "widget", "price": 5}, {"name": "gadget", "price": 50}]} ``` and the filter `must=[FieldCondition(key="items[].name", match=MatchValue(value="widget")), FieldCondition(key="items[].price", range=Range(gt=10))]`. Each condition is resolved against the whole array separately. The name condition is satisfied by element 0. The price condition is satisfied by element 1. Both clauses pass, so the point matches — even though no single item is a widget costing more than 10. This is not a bug; it is the documented meaning of an unqualified condition on an array. It is simply almost never what the author intended, and it fails silently: the result set is too *wide*, so nobody notices until someone checks a specific result. ## NestedCondition `models.NestedCondition` binds conditions to the same element: ``` models.NestedCondition( nested=models.Nested(key="items", filter=models.Filter(must=[...])) ) ``` The `key` names the array. The inner `Filter` is evaluated **against one element at a time**, with keys written relative to that element (`name`, `price` — not `items[].name`). The point matches when at least one element satisfies the entire inner filter. `NestedCondition` is itself a condition, so it drops into `must`, `should` or `must_not` of an outer filter alongside ordinary conditions on top-level fields. A practical consequence of the "at least one element" semantics: putting a `NestedCondition` inside `must_not` means "no element satisfies the inner filter", which is a genuinely different statement from "some element fails it". Keep the inner filter to field conditions on the element's own keys and reason about the outer clause separately. ## Indexing nested paths Payload indexes follow paths literally. To index a field inside an array of objects you create the index on the full path with the array marker: `field_name="items[].price"`. Indexing `items` alone does nothing for conditions on its members, and a `NestedCondition` benefits from those inner-path indexes the same way a top-level condition benefits from a top-level index. This is a common omission — the nested filter is correct, the query is slow, and the payload schema shows no index for the nested path. ## Modelling alternative Sometimes the right answer is not a nested filter at all. If you routinely need to retrieve "the matching item", not "the parent that has one", the array element is really your unit of retrieval — store one point per item with the parent id in the payload. Nested filters answer "which parents qualify"; they never tell you *which* element matched, and there is no way to get that from the response. Choosing between the two shapes up front avoids a class of awkward post-processing. ## Quick check Before trusting a filter over an array of objects, run it through `count(count_filter=..., exact=True)` with and without the nesting. If the counts differ, the unnested version was matching across elements and you have just measured your false-positive rate.