Make correction, expiry, and deletion propagate

A useful memory service supports adding, reading, correcting, superseding, expiring, and deleting records. These operations define product behavior, not merely database maintenance. If a user corrects a preference, the old value should not reappear because it has a higher relevance score. If a record expires, the retrieval index and prompt cache must respect that expiry. A write-only memory system accumulates contradictions that the model is then forced to resolve informally.

Define retention by record type and purpose. An incident episode may remain useful as history, while a temporary task preference may expire when the task ends. Keep the policy explicit and inspectable. This lesson describes engineering semantics for a local application, not a legal retention schedule. Actual organizational requirements can be represented as inputs to the same lifecycle mechanisms.

Assign a logical key to a mutable fact or preference and append versions with stable IDs and recording times. Resolve the current version first, then apply relevance ranking. Otherwise an older high-scoring value can defeat a newer correction. For an educational deterministic policy, choose the greatest (created_at, id) pair within the same tenant and logical key. Production may need authority levels or explicit conflict states instead of arrival order.

Suppose preference P1 says long explanations, and later P2 corrects it to concise summaries. P2 should control the current preference even if the current query shares more words with P1. Keep P1 as superseded history if policy permits, but exclude it from current-value retrieval. A history view and a current-context view are different queries over the same ledger.

Consider P1 with no expiry and a newer P2 that expires at time ten. At time ten, filtering expired records before version resolution can remove P2 and mistakenly restore P1. Decide the intended semantics explicitly. In this module, expiry of the latest version leaves no active value; it does not resurrect earlier versions. Therefore resolve latest versions first, then apply expiry and deletion.

A tombstone is a record stating that a logical value is deleted. The same ordering rule applies: if tombstones are filtered out before version resolution, a deleted record can reappear. An expiry boundary also needs precision. The lab defines an active interval ending just before expires_at, so a record with expiry ten is inactive when now equals ten. Boundary fixtures catch mistakes that ordinary recent-record tests miss.

A memory summary may depend on several episodes, and an embedding index may represent that summary. Deleting or correcting a source should invalidate or recompute dependent artifacts according to the application's policy. Store source IDs on derived records so the system can find them. Merely removing the original row leaves summaries, caches, and retrieved prompt fragments capable of reproducing the stale content.

For example, summary S1 combines episode E1 with preference P1. A correction P2 supersedes P1. Mark S1 stale and regenerate it using the new active preference, or stop retrieving S1 until it can be rebuilt. A dependency index makes this a targeted operation. Scanning every text blob for the old phrase is unreliable because summaries may paraphrase it or omit the exact wording.

Memory tests should advance an explicit clock instead of waiting for real time. Include just-before expiry, exact expiry, a newer tombstone, a correction with lower relevance, two tenants sharing a key, and a large record that exceeds the context budget. Test deletion through derived summaries as well as direct lookup. These scenarios establish observable behavior the user can rely on.

The code shows why version resolution precedes activity filtering. The latest preference has expired, so no value is returned even though an older one had no expiry. The lab combines this rule with tenant isolation and budget selection. For a portfolio artifact, include a lifecycle trace that explains which record replaced or invalidated another. This turns memory from a vague personalization feature into a reviewable data system with predictable change semantics.

The newest version is selected before checking expiry. At the exact expiry boundary, the logical preference becomes inactive and the old value stays superseded. The example assumes one tenant and an already valid record schema.