Revision and Forgetting

Canonical records and current projections

Observations, memory versions, contributions, and source links are canonical records. A projection is a computed view over them: it names the relevant versions and alternatives, their support and grade, their applicability, and the reasons behind those labels. Projections do not copy the claim text as a second authority; they point to exact versions.

This separation allows labels to change without rewriting history. If evidence is retracted or a source group changes, the same immutable versions can receive new projections. Projection indexes are derived data and can be verified or rebuilt from canonical records.

Revision is a correctness boundary

A write that can change a label marks the affected memory and its dependency closure for revision. A durable, monotonically increasing requested revision tracks what needs recomputing; a published revision tracks what has finished. Repeated changes coalesce work while preserving the newest requested generation. Bounded background drains relabel affected memories and continue after restart.

Current reads must be consistent with that boundary. They return content only when the published revision has caught up with the requested revision and no relevant deadline is due. Otherwise, the current answer is pending. This avoids serving an old projection as if it reflected a correction that has already been accepted. Historical reads can still inspect observations and prior versions while revision proceeds.

The design distinguishes several useful milestones: a report can be captured, formation can finish, indexes can be ready, and belief revision can publish. They are independent states, not synonyms for “the memory is ready.”

History and replay

Version history answers what a focused memory said at each revision. Event and contribution history records what was accepted, by whom, and against which inputs. A historical query can ask what was known at a past time or command position, rather than viewing today’s projection and assuming it was always the answer.

Accepted decisions retain the input references, versions, content digests, proposer identity, policy versions, and accepted or refused operations needed to explain the result. Replaying an identical logical decision does not apply it twice. If a proposer or model is later withdrawn, its contributions can be deactivated and the system can recompute surviving support from the remaining record. The original observations remain available according to their own retention policy.

Forgetting is not one operation

The design separates several effects that are often hidden behind a single “forget” or health score:

• Lowering retrieval priority may make an item less prominent while leaving its support and visibility unchanged. This is a ranking concern, not a verdict about truth.
• Cache eviction releases fast or resident resources while preserving all durable rows and answers.
• Support withdrawal changes labels only when evidence is retracted, deactivated, or expires under a rule that removes its support.
• Archival hides an observation or memory from ordinary reads. It removes no bytes and does not change its evidence, support, grade, or deadline.
• Raw expiry deletes observation bytes at their retention deadline while allowing separately retained focused memories and eligible exact excerpts to remain.
• Erasure removes content and derived lineage under an explicit erasure operation. It has to account for what depended on the erased data.

These actions must not imply one another. Archiving a memory is not evidence that it is false. Retracting support does not erase the text that was once reported. Expiring raw text does not automatically delete a focused memory that has a retained justification. A memory that is seldom recalled is not therefore incorrect.

Retention policy

The managed design uses separate retention for raw observations and transient processing artifacts. The current proposed defaults are 30 days for raw observations and 24 hours for transient artifacts; focused memories and necessary evidence have no age limit by default. Deployment settings establish the maximum retention, and a tenant may shorten raw observation retention. Deadlines are fixed so retries or later policy lengthening cannot silently extend data already scheduled to expire.

Age rules are explicit and name both their target and operation. There is no implicit idle-memory archive and no general health-decay process in a managed store. Rules are applied by bounded, resumable background work so a restart does not skip an item that is due.

Availability and limitations

These pages describe the maintained-memory architecture and development implementation, not a released v0.5.3 user feature. The current release keeps its existing memory lifecycle behaviour. The development work is evolving, and availability of individual internal commands or storage structures does not mean the complete capture-to-current-belief workflow is exposed to clients. Consult the release notes before planning a deployment around maintained memory.