Short answer: It is structured fields on each memory used to narrow search by exact criteria alongside semantic similarity.
Meaning alone cannot enforce customer, date range, or category. Filters should constrain the eligible set before or during similarity search, not only discard afterward. Make filterable the properties callers must enforce exactly; leave narrative detail as semantic content. Multiple filters can stack. Engram combines property filters with semantic search so results are eligible and relevant.
Deduplication, covered in the previous chapter, keeps memory clean once similar facts start arriving. A separate, everyday need shows up the moment memory actually gets searched: narrowing a broad semantic match down to exactly the right slice of what’s stored. Structured properties, the metadata attached to each memory alongside its searchable content, are what make that narrowing possible.
Why Isn’t Semantic Similarity Alone Enough to Answer Most Real Questions?
A pure semantic search finds content whose meaning resembles a query, but meaning alone often isn’t the only thing a real question actually cares about. A caller asking about a specific customer’s history, a specific date range, or a specific category doesn’t just want content that sounds relevant, they want content that genuinely belongs to that exact customer, that exact window of time, or that exact category, regardless of how semantically similar some other unrelated entry might happen to be. Structured properties give a search a way to enforce these exact boundaries directly, rather than hoping semantic similarity happens to respect them on its own.
How Does Filtering on a Property Actually Combine with a Semantic Search Rather Than Running as a Separate Step Afterward?
A well-built filtered search narrows the pool of eligible candidates before the semantic comparison even runs, building a list of everything that satisfies the filter first, and then performing the similarity search only against that narrowed pool rather than against the entire collection. This differs meaningfully from filtering after the fact, checking each of the semantic search’s top results against the filter and discarding whatever fails, which risks running out of genuinely eligible matches entirely if the filter happens to be restrictive and the initial similarity search didn’t happen to surface enough candidates that would have passed it anyway.
Why Does This Distinction Between Filtering Before and Filtering After Actually Matter in Practice?
Filtering after the similarity search runs the real risk of returning too few results, or none at all, whenever the filter’s eligible pool is small relative to the whole collection, since the initial unfiltered search might never have surfaced any of that small eligible pool among its own top candidates in the first place. Filtering before the similarity search avoids this risk entirely, since the search only ever considers candidates already known to satisfy the filter, guaranteeing that a genuinely eligible match will actually be found and returned whenever one exists, rather than depending on luck about which candidates the unfiltered search happened to rank highly.
What Kinds of Properties Are Actually Worth Making Filterable on a Given Memory?
A property is worth making filterable whenever a caller might reasonably need to narrow a search down to an exact match on that specific dimension, an identifier, a category, a date, anything a search genuinely needs to enforce rather than merely hope a semantic match happens to respect. Properties that exist purely for descriptive or narrative purposes, without any real need for exact filtering, don’t need this same treatment, since their value comes from contributing to the semantic content of a memory rather than from supporting precise, structured narrowing. Deciding which properties deserve this filterable treatment connects directly back to the schema design judgment covered earlier in this Part.
Can Combining Several Filters Together Actually Narrow a Search Even Further Than a Single Filter Could?
Multiple filters can be combined in a single search, each one narrowing the eligible pool further before the semantic comparison runs, letting a caller enforce several exact conditions simultaneously rather than being limited to just one dimension of narrowing at a time. A search scoped to a specific customer and a specific date range and a specific category all at once benefits from combining all three filters together, arriving at a precisely narrowed pool before semantic similarity ever gets applied to whatever remains. This combinability is exactly what makes structured metadata such a flexible complement to semantic search, rather than a rigid, single-purpose mechanism limited to one condition at a time.
How Does Weaviate Engram Let a Caller Combine Structured Property Filters with Semantic Search in Practice?
Weaviate Engram’s search API accepts structured property filters alongside a semantic query, narrowing the eligible pool of memories before running the similarity comparison against whatever remains. Consider a boutique auction house’s item-provenance assistant, tracking notes on consigned items across many different categories and consignors over the course of several auction seasons:
from engram import EngramClient
client = EngramClient(api_key=os.environ["ENGRAM_API_KEY"])
client.memories.add(
"This mid-century sideboard's provenance was confirmed through a 1962 bill of sale found in the consignor's family records, tying it directly to the original Copenhagen workshop.",
properties={"consignor_id": "consignor-4417", "category": "furniture", "auction_season": "spring-2026"},
)
A specialist preparing a catalog entry can narrow a search precisely to this consignor’s furniture items from a specific season, rather than searching across every category and season the auction house has ever handled:
results = client.memories.search(
query="What provenance documentation exists for this consignor's furniture pieces?",
properties={"consignor_id": "consignor-4417", "category": "furniture", "auction_season": "spring-2026"},
)
Without these structured properties narrowing the pool first, a semantic search across the auction house’s entire history could easily surface provenance notes from an entirely unrelated consignor’s furniture, or from this same consignor’s jewelry rather than furniture, simply because the wording happened to sound similar. By filtering on consignor, category, and season before the semantic comparison runs, Engram guarantees the specialist sees only genuinely eligible matches, precisely the guarantee filtering before search delivers over checking a filter only after the fact.
Property-based filtering gives structured metadata a direct, reliable role in narrowing a search down to exactly what a caller actually needs. A related question follows naturally from how memory gets extracted and combined across many sources: how much should a system trust a given memory, and where did it actually come from in the first place. Our next chapter, How do you model confidence and provenance in memories?, takes up exactly that question.