Architecting State and Inference Across Time
Your Data Has Become Memory
Deletion removes a value from a location. Effective forgetting prevents the past and its derivatives from regaining an authority they no longer deserve.
The decision brief“The past matters not only because it is stored, but because it has a route back into action.”
The decision brief
A practical starting point
Map what the AI can write, then test when state and its derivatives lose the right to influence behavior.
- Distinguish storing information, making it available as context and using it later.
- Identify responsibilities around derived information and changing validity.
- Ask evaluation questions about appropriate use and influence, not memory size alone.
Central question
Who governs an inference that no record ever contained?
The opening scene
The address that returned after deletion
A customer updates a shipping address after a move. The account shows the new address and confirms that the old one has been deleted. Weeks later, an AI agent orders replacement equipment—and sends it to the previous address.
The delete operation worked. The old state still made the decision.
It may have survived in a derived summary, a retrieval index, or persistent memory that was never refreshed. The operational question is no longer “Where is the data?” It is: who governs an inference that no record ever contained?
An intelligent system can infer a preference from several sources, retain it, and return it to a later context where it selects a tool or changes external state. Governing the source is only the start; the derived state needs its own origin, lifetime, and route to invalidation.
From records to state across time
The working-set idea reminds us that value does not come from keeping everything present, but from choosing what should be active now. The relational model gives us precise language for records, relations, and updates. Modern memory adds chunking, embeddings, retrieval, context, and derived state, distributing one fact across layers with different lifetimes and powers.
The source documents may be governed carefully while the system produces an inference that no document states. Once written to long-term memory, that inference becomes deferred input to a decision that does not yet exist. A memory write is therefore not an innocent background optimization. It is a decision about what the past may say in the future.
The read path is not enough
Teams often focus on what a model can read: which documents enter retrieval and which fields appear in context. Reading shapes the current moment. Writing can shape many later moments. Every summary, preference, or judgment a system writes can become the reason for a future retrieval, recommendation, tool choice, or action.
Derived state needs provenance: its source, whether it is a fact or inference, when it was formed, how it is refreshed, when it expires, and how it can be invalidated. This does not require retaining every detail forever. It requires knowing what remains for legitimate history and what must lose the status of “current,” even if it is still retained for another purpose.
Effective Forgetting
The talk proposes Effective Forgetting as a system-level property. Deletion is an operation at a particular table, index, store, or log. Effective forgetting asks whether the information, its derivatives, and the routes that can reactivate it have stopped producing the prohibited effect in future behavior.
Stored does not necessarily mean active, and gone does not necessarily mean harmless. An old address may remain in a valid historical record while losing every right to serve as the current shipping address. Test effective forgetting by tracing the effect: can the past still enter context, trigger a recommendation, or change an action?
Memory at a moving frontier
The meaning of memory keeps changing: long context, agent memory, systems that decide what to add or update, and methods intended to remove data effects from models or indexes. Each frontier returns us to the same root: which part of the past may remain present, in what form, and with what power?
The final action is to map the write path, not only the read path. Choose one fact the system can derive. Trace where it is written, how it is refreshed, when it expires, and how it affects later behavior. If there is no owner, expiry, or invalidation route, the memory is already stronger than its governance.
Explore the idea
A state map across time
Follow one piece of information from origin to future effect.
Source
Is this a recorded fact or an inference, and which evidence created it?
All perspectives
Source
Is this a recorded fact or an inference, and which evidence created it?
Derivation
Where did sources become a new summary, preference, or judgment?
Refresh
Which event corrects the state or causes it to be recomputed?
Expiry
When do the information and its derivatives lose the right to influence action?
An illustrative scene to explore
Windows into the idea
Questions that open another door
Is deleting the source enough?
Not if a derivative remains active in a summary, index, preference, or persistent context. Test the actual behavior after deletion rather than relying on the success message from one store.
Does effective forgetting mean erasing history?
No. A historical record may remain for a legitimate purpose while losing its status as current state and its right to guide a new decision. The distinction between retention and activity is central.
How should an inference be governed?
Link it to its sources, label it as inference rather than fact, record when it was formed, and define refresh, expiry, and invalidation.
Why focus on writing?
A read influences the current moment. A write can influence decisions that do not yet exist. What a system records today may become the reason for an action in another context.
What is the first practical step?
Choose a decision that depends on memory and map where its state came from, how it was written, when it refreshes, and when it expires. Begin with the effect, not an inventory of stores.
The idea’s bookshelf
Works that illuminate the subject and offer paths for further reading.
- The Working Set Model for Program Behavior
An author-institute copy of the 1968 Communications of the ACM paper introducing the working-set model for information active within a window of program behavior.
- A Relational Model of Data for Large Shared Data Banks
The 1970 Communications of the ACM paper that defined the relational model of data.
Who it is designed for
- Data, AI and privacy leaders
- Governance, security and data-architecture teams
- Researchers and developers of systems with persistent memory
When it fits
For enterprise assistants and personalised services that use user history or organisational knowledge.
What it does not promise
Not legal advice on privacy or a promise to remove every trace of information from every system.
One central idea. Depth to match the room.
These formats are proposals. Readiness, duration and interaction are confirmed for each invitation. These are the languages of the website descriptions. Live delivery languages and interpretation arrangements are confirmed separately for each engagement.