Hey @U05092LD5 the AEV index and associated internal query code that uses it are simply not aware of the exact collection type of the value original submitted - instead, the query engine operating over that index just sees a sequence of ('decomposed'/'flattened') entries in the index and so a vector is assumed by default (this access path is in contrast to entity/`pull` which really do just retrieve the set from the original document, and not AEV). I think in theory the AEV index and get-attr code here could be changed to be aware of the set-nature of the submitted value, but in practice that probably means a breaking change (or get-attr2) and requires extending the index in some way to record the distinction.

Aha...I see. Thank you.

I think I would use such a get-attr2

(not [?entity :field _])

Should do it

https://v1-docs.xtdb.com/language-reference/1.24.3/datalog-queries/#clause-not

Awesome!