Control how memories are written

Automatic memory writes can turn casual statements and model guesses into persistent context. Put a candidate stage between extraction and durable use.

After a task or conversation, an extractor can propose candidate records with source spans, types and confidence. Deterministic checks then reject malformed items, unsupported types, missing sources and values outside permitted scope. Higher-consequence records may require a person or an authoritative system event to confirm them.

Different memory types deserve different promotion rules. A user explicitly saying "please remember that I prefer email for this project" may be accepted under that user's identity. A statement about another person's health, access or performance should not be stored as a preference merely because it appeared in the same conversation. A production owner change should come from the approved operational source or review path.

Deduplication needs semantics, not only similarity. Two records can have similar wording but different scopes. Conversely, "Friday" and an ISO date may represent the same value once resolved against the source timestamp. Normalise values where the type allows it, then compare subject, property, scope and effective period.

When a candidate conflicts with a current record, do not overwrite in place. Create the proposed replacement, link the old record through supersedes, and apply authority rules. If neither source clearly wins, mark the property disputed and return that status during retrieval.

Batch extraction should keep boundaries between users, projects and source permissions. A background process operating across many transcripts must not create cross-tenant links or use a broad embedding index to bypass source access.

Store the extraction version and policy version. When the schema or model changes, the team can identify which memories were produced under older rules and reprocess selected sources without pretending the earlier records never existed.