When you delete a memory from a conventional system, it's gone. The record disappears, the fact becomes inaccessible, and the system has no way to explain why it no longer knows something it once knew. This is fine for simple applications — but it's a liability for any AI system where accountability matters.
A bi-temporal audit log separates two different time dimensions: valid time (when a fact was true in the real world) and transaction time (when the system recorded it). The separation lets you query not just what the system knows now, but what it knew at any point in the past — and what was actually true at the time, separate from when it was recorded.
This distinction matters when you need to answer questions like: "Was this decision made with accurate information at the time?" Or: "When exactly did the system record this fact, regardless of when it became true?" Or the hardest one: "This user has asked us to erase their data — but their preferences shaped 40 other memories. What does compliant erasure actually look like without destroying audit integrity?"
In this final module, you'll defend a retention and erasure policy across three deletion scenarios that test the edges of bi-temporal design.
A professional AI assistant has been active for two years. Over that time it has accumulated 6,000+ memories: user preferences, project decisions, technical constraints, meeting summaries, workflow patterns, communication styles. The system uses importance scoring, decay, consolidation, and a layered three-tier memory architecture. By any measure, it's a well-built system.
Then three things happen in the same month.
A user says: "Delete your memory of my preferred meeting format. I've changed how I work and I don't want the old preference influencing your suggestions." Simple enough — except that preference influenced 14 other memories created over the past 18 months. Should those be deleted too? If not, what happens when the AI surfaces a decision that was shaped by a now-deleted preference?
A different situation: the system recorded, eight months ago, that a project was using a particular vendor. It never was. The user who provided that information was confused. The fact is wrong — it was never true in the real world. But the system recorded it as truth. Three memories reference it as background context. What does correcting the record look like in a system where you're not supposed to mutate data?
And then the hardest case: a team member leaves. Under GDPR, they request erasure of all personal data the system holds about them. But their preferences, style notes, and past decisions are woven into project memories that other team members still need to function. The audit trail of their contributions to past decisions is legally required to be preserved. You can't delete everything. You can't keep everything. The line between their data and the project's data is blurry.
These aren't edge cases. They're the inevitable consequence of a memory system that's been running long enough to matter. The question is whether your schema was designed to handle them.
Bi-temporal data models track two independent time dimensions. Understanding the difference between them is the foundation of every deletion and retention policy.
Valid time is when a fact was true in the real world. A project started using a vendor on March 1st — that is the valid time for that fact, regardless of when you recorded it. If you later learn the fact was always wrong, the valid time span for a true fact was empty: it was never valid.
Transaction time is when the system recorded the fact. You recorded the vendor fact on March 15th — that is the transaction time. Transaction time is immutable: you cannot change when you recorded something, only add new records that supersede it.
A bi-temporal record stores both. This lets you answer: "What did the system believe on April 1st?" (query by transaction time) and "What was actually true on April 1st?" (query by valid time). The two answers can differ — and often do.
In a bi-temporal append-only log, you never delete or mutate existing records. To correct a fact, you add a new record with a new transaction time that supersedes the old one — and specifies the correct valid-time range. To retract a fact that was never true, you add a record indicating that the valid-time range of the original was empty.
This means the original incorrect record is still in the log. It's still queryable by transaction time: "What did the system believe on the day it was recorded?" The log preserves the history of the system's beliefs, not just the current truth. This is not a bug — it's the point. An audit trail that erases mistakes is not an audit trail.
Three operations look similar but have very different implications. Erasure means the data is permanently removed — storage-level deletion. This satisfies "right to be forgotten" requirements but destroys the audit trail for those records. In a bi-temporal log, true erasure is the nuclear option.
Suppression marks a record as not-retrievable for normal queries but preserves it in the log for audit and legal purposes. The record still exists; it just doesn't surface in regular retrieval. This is often the right approach for GDPR erasure requests: the data is inaccessible for operational use but the audit record that something was there — and removed — is preserved.
Archival removes a record from active retrieval and moves it to cold storage, typically for records past their useful life but within a legal retention window. Archived records are recoverable; suppressed records may or may not be, depending on implementation.
NIST's GOVERN function requires that AI systems have defined policies for oversight, accountability, and data governance throughout their lifecycle. An audit log is not optional infrastructure — it is the mechanism by which accountability becomes possible. A system that cannot reconstruct what it knew, when it knew it, and what decisions were made based on that knowledge cannot be governed. The bi-temporal schema is a direct implementation of NIST GOVERN's requirement for traceable, accountable AI decision-making.
Retention policies define how long different memory types must be kept and under what conditions they can be deleted. NIST GOVERN requires these policies to be documented, applied consistently, and reviewed when regulatory requirements change. The distinction between erasure, suppression, and archival is a governance decision that must be made deliberately — not handled ad hoc when a deletion request arrives.
Every bi-temporal audit schema must navigate three tensions. There are no universally correct answers — only defensible tradeoffs. Knowing which tension applies to a given deletion scenario is the first step to designing a policy that holds up.
A complete audit trail contains everything — including data about people who may have a legal right to have it removed. Preserving the trail fully satisfies accountability requirements. Erasing data satisfies privacy requirements. These are not always compatible. The design question is: can you satisfy privacy requirements through suppression rather than erasure, and is that distinction legally sufficient for your jurisdiction and use case?
Append-only logs grow without bound if you never delete anything. Retention periods cap temporal depth: records older than N years are eligible for deletion. The shorter the retention window, the lower the storage cost — but the shorter the queryable history. Define retention periods by record type, not globally: session notes may have 30-day retention; decision records may require 7-year retention.
A fully bi-temporal query — "what did the system believe on date X about fact Y, as of transaction time Z" — is powerful but complex. Most queries don't need full temporal fidelity. Designing for it everywhere creates implementation overhead and query complexity that exceeds the benefit. Choose where full bi-temporal fidelity is required (audit, legal, accountability) and where a simpler current-state model is sufficient (operational retrieval, importance scoring).
In the lab, you'll debate three deletion scenarios. Each one tests a different tension. You'll defend a position and explain how your bi-temporal schema handles each case specifically.