Prerequisites
There is a policy on what the collaboration may remember: what may be kept, for how long, who may read it, and what the actor has agreed to. The policy is set before this sequence starts; no pattern here sets it.
Other sequences produce records: committed changes, reviewed runs, granted permissions. This sequence keeps those records but does not revisit the decisions behind them. It decides once what is kept, designs the actor’s return after an absence of any length, and enforces the limits on what is remembered.
Deciding what is kept
Keep one record — Activity log
Collect the accounts that other sequences write (of work, of permissions and approvals, and of reliance) into one record. Give every entry the same fields: who acted, what they did, what it applied to, and when. Make the record filterable from the start, and design it for new and returning actors as well as for audits.
Record who made each change and why — Provenance marking, recording origin when a change is made
Mark each change in the record with its origin (a person, a named rule, or a model run) when the change is made, because origin cannot be reconstructed later. Record any reason the collaboration wants to keep at the same time. The return steps read this.
Choose what is kept about the actor — Selective memory
Decide what the system keeps about the actor for next time: facts they stated, standing preferences, and less visible state such as what they have read, where they were, and work they set aside. Choose the default (remember unless asked, or forget unless asked), knowing that most actors never change it. Let the actor see and edit what is kept, and offer a session that keeps nothing.
Leaves: The collaboration keeps only what was chosen. Information the policy excludes is never written, which is cheaper and more reliable than deleting it later.
Supporting the actor's return
Applies when
An actor comes back after an absence, short or long, to a collaboration that either continued working or waited. Each step here reads what the keeping steps wrote.
Restore the actor's place
Decide whether to restore the actor's place automatically or offer to restore it: the conversation they set aside, the commitment deferred when they last closed, the unfinished change, and what they had already read. As part of resuming, check assumptions that may be out of date. Keep the option to start fresh.
Show what changed while the actor was away
Show the changes made since the actor's last visit, limited to what they have open, without asking them to accept or reject anything: which parts changed, who or what changed them, and why. Include only changes that could wait; anything urgent was sent when it happened. If the summary is generated, mark its evidence.
Let the actor return to named versions
Beyond the current session, where undo no longer applies, let the actor restore named versions, such as a publish, a release, or a version saved on purpose. Decide which moments get names, who names them, and how far back the history goes.
Leaves: The returning actor can see where they were, what changed, and how it changed. Each of these depends on what the keeping steps recorded.
Enforcing the limits on memory
Applies when
Kept information accumulates unless something removes it. The policy sets limits on what is remembered, and the design has to enforce them, both when the actor asks for something to be forgotten and when records are no longer needed.
Apply the limits to both kinds of kept information
Apply the policy to two kinds of kept information that are removed differently, in either order: what is remembered about the actor, and the actor's content with its history.
In any order:
Let the actor remove what is remembered — Selective memory, its forgetting controls
Let the actor remove remembered information per fact, per session, or per mode. Make sure a removed fact does not return, including through behaviour the system learned from it.
Decide what removal leaves behind — Deletion, what remains after removal
Decide whether removing an item also removes its history: offer a recovery period, leave a placeholder, or keep an entry for the deletion in the record. Give the actor what the policy promised, and let the record show what was removed.
Leaves: What the collaboration remembers is limited by the design, not by storage, and the actor can see it, correct it, and remove it.
Connections
Hands off to Delegating work
At Deciding what is kept, step 3, via AI tuning
remembered facts and learned behaviour are parts of the same memory: corrections to behaviour go to that sequence's tuning steps, and the memory controls show which part an edit changes
Hands off to The encounter
At Supporting the actor's return, step 1, via Opening (User)
a conversation the actor set aside resumes through an opening that shows its history, which that sequence designs
Calls Calibrating reliance
At Supporting the actor's return, step 2, via Citation
a generated summary of changes is AI output, so each claim links to the changes it summarises
Hands off to Attention and tempo
At Supporting the actor's return, step 2, via Notification
what could not wait was sent at the time, as that sequence decides
Hands off to Learning
At Supporting the actor's return, step 2, via Onboarding
when the system itself has changed, the return works like a smaller first encounter, which that sequence designs
Hands off to Making changes
At Supporting the actor's return, step 3, via Undo
restoring a named state is itself a change, graded and reversible like any other in that sequence's safety steps