Part 6 of Foundations: what temporal databases teach a memory about change, correction, and history.
Two questions that look the same and are not: "Where did I live in 2023?" and "What did you believe in 2023 about where I lived?" The first is a history question. The second is the one that appears in audits, incident reviews, and attempts to reconstruct an earlier decision. A memory that cannot tell them apart may answer one with evidence for the other.
The good news is that this distinction was mapped years ago, by the temporal-database community. The 1998 consensus glossary, edited by Christian Jensen and Curtis Dyreson with a long list of contributors including Richard Snodgrass, defines bitemporal data as combining valid time (when a claim applies in the modeled world) with transaction time (when a database held that version). A product may expose the second axis as recorded-at, ingest time, or system time, and those terms are not interchangeable in every architecture. The point worth carrying away is simpler than the vocabulary: keep change in the world separate from change in the record.
Once you have the two axes, a small catalog of correctness rules falls out.
First, an update can close an interval instead of erasing it. When reliable evidence says you moved away from Denver in March, the old address becomes bounded rather than retroactively false. A latest-value overwrite cannot answer historical questions unless some other log preserves the earlier state.
Second, a correction is not the same animal as an ordinary change. "Actually, I moved in March, not May" revises the claimed valid time, while the system-time history can retain when each version was recorded. Subject to source quality and conflict policy, that one distinction supports both "when did you move?" and "when did this system record the March date?"
Third, succession is not contradiction. Austin, then Denver, can describe a perfectly consistent history. Two claims about the same interval that disagree describe a conflict, and a conflict should remain visible rather than being resolved by an unexplained latest-wins rule.
That covers time as a database sees it. Reading time out of language is a separate problem, and it has its own history.
James Allen was working on a difficulty that anyone building an AI planner in the early 1980s ran into: people describe time in relative terms. The meeting was before lunch, the outage overlapped the deployment, she was there during the review. Hand a system statements like that and it has to reason about what follows from them without ever being told a clock time. Allen's 1983 interval algebra gave that a footing, and the satisfying part is the number. There are exactly thirteen ways two intervals can relate to each other. Not thirteen common ones: thirteen, total, enumerated. Once you have seen the list you cannot invent a fourteenth.
Twenty years later the problem had moved into text. The TERQAS workshop in 2002 asked how a question-answering system could handle temporally grounded questions about news, and the answer that came out of it was TimeML, specified by James Pustejovsky and colleagues. Its move was to separate the things being annotated: events, time expressions, and the links that anchor one to another are distinct structures rather than one tangled markup. It also handles expressions that only mean something relative to something else, which is why "three years ago" needs machinery that "March 2024" does not.
Treat both as foundations, not as a finished parser. Recurrence, timezones, locales, vague dates, and context still need explicit handling, and the thirteen relations tell you nothing about which of them actually holds in a sentence somebody wrote in a hurry.
What two axes do not decide for you#
Two axes do not choose which source to trust when claims conflict. They do not turn "around March" into a precise date, or decide whether a date without a timezone means local time or UTC. Those are policy and interpretation decisions, and uncertainty should survive them.
Nor does historical retention cancel privacy, security, or deletion duties. Append-only is a logical model for corrections; a deployed system still needs retention controls, access boundaries, and a lawful way to remove protected data.
The recordkeeping analogy is the one I trust here. Accounting ledgers and version-control systems both preserve changes instead of replacing history. Their details and threat models differ, but the shared lesson is that a correction should be auditable.
CleverMemory's temporal design follows that lesson. "What's supported now," "what was supported then," and "when was this version recorded?" are separate questions, and the controlled fixtures treat them that way. Time participates in the claim; it is not merely a sort key.
So the rule of the house is that history is additive. A correction is written alongside the thing it corrects, never over it. That is a slightly unusual default: the ordinary instinct is to treat an update as a replacement and the old value as clutter. The old value is not clutter. It is the answer to every question about what was believed when a decision was made, and those are exactly the questions that show up in an audit.
Next: what a citation even means when the answer is computed rather than stored, and the 2007 result that turned several rival notions of lineage into one mechanism with dials.