Preference store versus chat memory

Settings show mushroom dislike as a household rule: approved, editable, auditable. Chat also contains "maybe skip mushrooms tonight" from a tired Tuesday. The product treats both as "memory" in retrieval. Generation oscillates. Users cannot tell what is standing policy versus negotiation. Compliance cannot reconstruct why a rule exists. The product conflated two stores with incompatible governance, and the consequence is a system that remembers vibes while forgetting commitments.

Helpful context: Knowledge is endorsed, not retrieved owns belief promotion. Memory discipline in conduct sets behavioural rules. Memory is part of UX covers surfacing and editability. This page specifies the architectural distinction between preference stores and conversational memory.

A preference store holds standing choices. Mushroom dislike, once the household confirms it, is an endorsed fact with an approval event and a visible edit path. It belongs alongside Leena's confirmed cashew allergy and the twenty-five-minute busy-evening cooking rule. These records are durable. They persist until someone explicitly supersedes them, and the supersession is itself an auditable event. Hard constraints like allergies should apply deterministically after endorsement, routed into the deterministic shell rather than rediscovered each run from chat similarity.

Chat memory, by contrast, holds interaction history. "Avoid pasta because we had it recently" is context for the current planning run. It is useful, but it carries no approval event, no edit path, and no claim to durability. Treating it as equivalent to an endorsed preference is the architectural mistake this page addresses.

The difference matters because governance differs. A preference store entry has a known origin, a scope (which household member, or the whole household), a status (endorsed, pending, superseded), and an audit trail. A chat utterance has a timestamp and a conversational position. When retrieval treats both as undifferentiated "memory," the system cannot distinguish a committed allergy from a passing remark, and neither can the user.

	Preference store	Chat / episodic
Holds	Standing choices	Interaction history
Example	Mushroom dislike (approved)	"Maybe skip mushrooms tonight"
Governance	Endorsed, auditable, editable	Transcript record
Application	Deterministic once endorsed	Contextual, advisory
Lifetime	Durable until superseded	Episode-bound

How endorsement connects the two stores

Preference store entries are a form of endorsed knowledge. They reach the store through an explicit authority path: household confirmation, admin approval, structured intake. The distinction between "endorsed" and "observed" is the same distinction that four kinds of source draws at the architectural level, applied here to the UX boundary.

Chat may propose a promotion. A user who says "actually, we never eat lamb" is signalling a candidate preference. But the promotion requires an explicit gate: "Save as household preference?" with scope and reversibility. Silent promotion, where the system quietly embeds a chat utterance into the durable store, is how conversational magic becomes ungovernable policy. The system should surface the promotion opportunity, not execute it unilaterally.

This connects to retrieval discipline more broadly. Similarity search across chat must not override preference store facts. Least trustworthy input applies: chat retrieval carries weaker governance than endorsed records. When both sources are available for the same decision, the endorsed record wins. Retrieval may surface chat for context, but it cannot substitute for the structured store on questions of standing policy.

What this looks like in the household planner

In the Weekly Meal Companion, the preference store holds mushroom dislike (household approved), Leena's confirmed cashew allergy, the twenty-five-minute busy-evening rule, and the constraint that grocery purchase requires approval. These are deterministic inputs to planning. The system does not re-reason about cashew allergy each week from chat history. It reads the endorsed record and applies it.

Run context holds "avoid pasta because we had it recently." This is useful for the current planning episode, but it does not belong in the preference store unless someone explicitly promotes it. Working state, the current plan acceptance status, remaining gaps, and loop budget, lives in yet a third place described in working state versus transcript.

The distinction becomes visible in product copy. "Remembers you dislike mushrooms" should mean there is a preference store entry with an edit path in settings. "Remembers you're avoiding pasta this week" should mean there is context labelling that expires after acceptance. If the product uses "remembers" for both without distinguishing the backing store, users will eventually discover that their "remembered" allergy was actually a chat inference, or that their offhand remark became permanent policy.

Supersession and contestability

Standing choices change. When "always use olive oil instead of butter" updates the record, supersession should replace the prior entry visibly, not create shadow duplicates in embeddings. Users contest knowledge through the store UI and audit trail, not by hoping the model forgets.

Contestability requires inspectable grounds. A preference store provides those grounds: the user can see what is stored, when it was endorsed, and by whom. Chat alone does not. When a user says "why did you exclude lamb?", the system should be able to point to an endorsed preference record, not to a buried chat utterance from three weeks ago.

Scope matters for supersession. Leena's cashew allergy attaches to Leena, not to the household as a whole. Composition rules at planning time must pass member-scoped knowledge into the right cognitive unit inputs without leaking unrelated records. Scope mistakes produce false confidence: the system enforces the wrong allergy set or applies one member's temporary dislike household-wide.

The enterprise parallel

The same pattern appears in enterprise domains with different labels. Vendor payment terms, materiality thresholds, and posting policies live in governed policy stores with exact application in deterministic checks. A clerk pasting context into chat during an exception is providing observed input until it is verified and promoted through the proper authority path. The architecture is the same: standing endorsed knowledge in a structured store, ephemeral context in conversation, and an explicit gate between the two.

Common mistakes

The most frequent failure is a "remember this" feature that writes to the preference store without scope or duration. The user clicks once, and the system treats a passing remark as permanent household policy. A close second is a settings screen that mirrors chat, presenting an undifferentiated list without endorsement status, edit history, or member scope. Users see entries but cannot tell which are standing commitments and which are session artifacts.

Embedding merge on paraphrase is subtler but equally damaging. Two preferences collapse silently because their vector representations are similar, and the system retains whichever was embedded more recently. Re-reasoning hard rules each run, where allergy enforcement is checked by narrative retrieval instead of deterministic code, turns an exact safety property into a probabilistic one. And promotion without audit means compliance cannot reconstruct why a rule exists when a regulator asks.

These are not edge cases. They are the predictable consequences of treating "memory" as a single undifferentiated store. Each one is avoidable once the architecture distinguishes standing knowledge from conversational context and enforces the boundary with approval events rather than retrieval heuristics.

Product analytics should also distinguish the two stores. Events like preference_endorsed, context_set_run_only, and promotion_declined are more useful than a generic "memory updated" funnel. When personalisation teams request "use all chat for preferences," the architectural response is to redirect through promotion flows and preference store UX. Personalisation without endorsement is surveillance with better targeting.

What to do next

Inventory the product copy that uses "remembers" and map each claim to a store type. Where the claim implies a standing commitment, confirm that a preference store entry with an edit path backs it. Where the claim implies session context, label it as ephemeral. Add an explicit "save as household preference?" gate for promotions, with scope and reversibility, rather than silent embedding writes. Apply hard preferences deterministically after endorsement, in the shell, not through weekly re-reasoning from chat.

See memory is part of UX, six forms of memory, and salience and write policy.

Read next: Evaluation as engineering.