Short answer: Preference memory stores what someone likes or wants. It is semantic memory with graded, changeable taste rather than fixed world facts.
Preferences are standing truths, but they drift, conflict, and come in soft degrees. Treating them like ordinary facts misses supersession and nuance. Preference memory needs clear updates when taste changes and careful retrieval so old likes do not override new ones.
Semantic memory, covered earlier in this Part, is the general category for standing facts that are simply true rather than events that occurred. Preferences are a specific, extremely common member of that category, but they behave in a few ways that plain factual memory doesn’t, which is enough to make them worth treating on their own terms rather than lumping them in with every other kind of semantic fact without a second thought.
What Makes a Preference Different From an Ordinary Fact?
An ordinary semantic fact, like someone’s job title or their home city, is usually binary and externally verifiable: it’s either true or it isn’t, and there’s rarely ambiguity about which. A preference is inherently a matter of degree and context, not a flat true-or-false statement. Someone might prefer spicy food in general but not want it in every single dish, or prefer concise answers for quick questions while wanting detailed explanations for anything genuinely complicated. A preference is a disposition, a leaning, not a fixed fact that holds identically in every situation it might apply to.
This means a preference is harder to state completely in one short sentence than a plain fact is. “Works as a nurse” is complete on its own. “Prefers spicy food” is only a rough approximation of something more nuanced that might depend heavily on context the short statement doesn’t capture.
Why Do Preferences Change More Often, and More Subtly, Than Other Facts?
Preferences drift in ways that plain facts usually don’t. A person’s job title changes rarely and changes cleanly, one value replacing another with a clear before and after. A preference can shift gradually, get refined with exceptions, or apply differently depending on mood and context, all without ever producing one clean moment where the old preference was fully replaced by a new one. Someone who has always preferred window seats might mention, offhand, that they’d rather have an aisle seat on longer flights specifically, which isn’t a contradiction of the original preference so much as a refinement layered on top of it.
This means preference memory needs the same reconciliation machinery already covered for ordinary semantic facts, detecting when new information updates, narrows, or contradicts something already stored, but applied with more care, since a preference update is far more likely to be a nuance or exception than a flat replacement.
How Should a System Tell a Genuine Contradiction Apart From a Contextual Refinement?
The test that matters is whether the new statement and the old statement can both be true in different circumstances, or whether they’re making an actually incompatible claim about the exact same circumstance. “Prefers window seats” and “prefers aisle seats on long flights” aren’t in conflict, since both are true within their own scope, one is the general default and the other narrows it for a specific case. “Prefers window seats” and a later statement that flatly says “always wants an aisle seat now” genuinely are in conflict, and the second one should reasonably supersede the first.
Getting this distinction wrong in either direction causes real problems. Treating every refinement as a contradiction means the system keeps discarding the general preference every time a more specific exception comes up, eventually losing track of what the person’s default even is. Treating every genuine contradiction as if it were just a refinement means two incompatible preferences sit side by side indefinitely, with no way for retrieval to know which one should actually govern a given situation.
Does a Preference Need to Track Confidence the Way Other Kinds of Memory Might?
It benefits from it more than most other content types do, precisely because preferences are stated with a wide range of firmness. Someone who says “I really can’t stand cilantro, ever” is expressing something categorical and stable. Someone who says “I think I might prefer the shorter version, but I’m not totally sure” is expressing something tentative, worth remembering but worth treating as more provisional than a flatly stated preference. Collapsing both statements down to the same confident, standing fact risks over-committing to something the person themselves wasn’t fully committed to, and later contradicting it without any real inconsistency on the person’s part, just an inconsistency in how firmly the system chose to remember something that was always somewhat uncertain.
How Does Weaviate Engram Handle Preferences as a Distinct Case of Semantic Memory?
Weaviate Engram’s transform step is well suited to this, since it retrieves existing related memories before deciding how a new statement should be integrated, giving it the context needed to tell a refinement apart from a genuine reversal, rather than treating every new preference statement as a flat overwrite. Consider a meal-kit subscription assistant tailoring weekly recipe selections to a household’s tastes, where preferences arrive gradually and get refined across many separate conversations:
from engram import EngramClient
client = EngramClient(api_key=os.environ["ENGRAM_API_KEY"])
client.memories.add(
"This household generally prefers milder flavors, but is happy to have spicier dishes specifically on weekends when there's more time to cook.",
user_id="household-6634",
)
Weeks later, a follow-up message narrows this further without contradicting it:
client.memories.add(
"Actually, keep weekend meals mild too now — we've had a change in who's cooking and they don't enjoy spice at all.",
user_id="household-6634",
)
preferences = client.memories.search(
query="How spicy should recipes be for this household?",
user_id="household-6634",
)
Because the second message is a genuine reversal of the weekend exception rather than an unrelated new preference, Engram’s transform step recognizes it as superseding the earlier carve-out and updates the stored preference to reflect that the household now wants mild flavors across the board, rather than keeping both statements sitting in storage as an unresolved contradiction. Searching afterward returns the current, consolidated preference, not a confusing mix of an outdated weekend exception alongside its own reversal. This is what treating preference memory deliberately looks like in practice: not just storing whatever was said most recently, but genuinely reconciling how a preference has actually evolved, so that what’s retrieved reflects where the household’s tastes stand today rather than an unresolved history of everything that was ever said about them.
Preference memory deals with facts that are inherently graded and prone to nuanced revision. A related but different question is how a system should organize memory once there’s simply a lot of it accumulated for one scope, whether it’s better retrieved as a single, distilled summary or as a large set of small, individually retrievable facts. Our next chapter, What is the difference between summary memory and atomic fact memory?, turns to exactly that question.