Consider bounds for property string length, integer range, and float precision #1801

What to decide

Whether the property value domain should define bounds that every vector store and every ingestion consumer can honor exactly, for:

• String length. PostgreSQL refuses a btree index entry over 2,704 bytes, which applies per indexed field (episode producer, semantic set ids); Milvus refuses a declared string over max_varchar_length bytes and a JSON field over 65,536 bytes, both server settings. Long property strings are refused by Milvus and by PostgreSQL indexes after other stores have written them #1798 records the failures.
• Integer range in filters. Stored ints are refused outside signed 64 bits (Refuse property values that some store refuses or alters where an episode enters #1792, and the filter type check on [declared schema 2/2] Close the filter union, and make negation the complement on every backend #1616). Qdrant's range conditions take float bounds in both qdrant-client and the server's API, so an ordering filter on an int beyond 2**53 compares inexactly there: measured on Qdrant 1.19.1, x > 2**53 + 1 admits a record holding 2**53 + 1. The other stores compare such ints exactly.
• Float precision. Whether stored or compared floats need a stated precision, given that each backend keeps floats as IEEE doubles but PostgreSQL JSONB reads some back as integers (PostgreSQL JSONB reads float property values of 1e16 or more back as integers, making their segments unreadable, and -0.0 as 0.0 #1797).

For each, the options are a bound in the domain (refused where values enter, the same for every store), a bound per store or per field (stated in that store's contract), or no bound, with the difference documented.

Context

The property value domain is defined once in memmachine_common.api.spec by #1792 and enforced where episodes enter; the vector stores bind filters and records to their declared schema in #1616. Neither sets these bounds yet.

🤖 Written by Claude Code (Claude Opus 5.5) on behalf of @edwinyyyu.