← Back to catalogue
Published

Memory Retention and Forgetting Policy

vr.wm-mem-010 · wm-mem-010-memory-retention-and-forgetting-policy

Define governed lifetime, relevance-decay, preservation and forgetting rules for agent-held memory, with scoped evidence requirements.

World Models Information and virtual systems INF.MEM.RET
Bundle → Layer → Finding → QuestionsClassifiersWhat it isWhy it existsDistinguishing featuresWhat robots and AI may and may not doMoral aspectsOwnersLinks to other meta-modelsIdentity and identifiersDirect propertiesRecognitionCapabilities and actionsHazards and failure modesStandards and interfacesContext of useSources

Bundle → Layer → Finding → Questions Filled

6 bundles · 12 layers · 12 findings · 48 questions

Policy identity and applicability Proposed policy responsibilities for policy identity and applicability.

Policy revision

Policy questions and evidence for policy revision.

Policy revision

A policy is a governed, versioned entity whose identity survives revisions. Evaluation records and memory items have separate identities.

  1. Which master identifier and immutable revision identify this policy? identity
  2. Which accountable role owns approval and review of this policy? ownership
  3. Which transition makes this revision effective, suspended or superseded? lifecycle
  4. What evidence explains the rule change and affected cohorts? provenance

Target scope and purpose

Policy questions and evidence for target scope and purpose.

Target scope and purpose

Explicit selectors bind policy to a tenant, store, item class and purpose. Scope matching cannot grant access or change another tenant policy.

  1. Which memory classes and sensitivity categories are selected? classification
  2. Which store, tenant and item references define the policy boundary? relationship
  3. Which purpose and applicable authority justify retention? requirement
  4. How are missing labels and overlapping scope selectors handled? exception
Lifetime and decay Proposed policy responsibilities for lifetime and decay.

Trigger and expiry calculation

Policy questions and evidence for trigger and expiry calculation.

Trigger and expiry calculation

Separate retention start, review time, minimum preservation and maximum storage constraints. No default duration is asserted; incompatible bounds require escalation.

  1. Which event starts the lifetime and what timestamp precision is required? temporal
  2. Which minimum, maximum and review intervals govern this memory class? retention
  3. Can a recall or update restart the clock, and under what limit? process
  4. How are late events, clock rollback and contradictory bounds resolved? validation

Relevance decay and recall eligibility

Policy questions and evidence for relevance decay and recall eligibility.

Relevance decay and recall eligibility

Proposed memory-specific extension: relevance decay, recall suppression and storage expiry are separate outputs. No standard decay formula or cognitive forgetting claim is admitted.

  1. Which decay function, parameters and input observations determine relevance? measurement
  2. When does a score change eligibility without changing storage status? state
  3. Which hard expiry and access rules bound relevance-based reuse? constraint
  4. What happens when decay inputs are missing, stale or manipulated? quality
Decision authority and exceptions Proposed policy responsibilities for decision authority and exceptions.

Rule precedence and conflict referral

Policy questions and evidence for rule precedence and conflict referral.

Rule precedence and conflict referral

Policy conflicts concern incompatible obligations, not factual disagreement between memories. Undetermined decisions stop automated destructive action and enter bounded review; ordinary recall remains separately restricted.

  1. Which rule version determines precedence for overlapping obligations? decision
  2. Who may resolve a conflict between retention and erasure obligations? authority
  3. What outcome applies when precedence is unknown or contradictory? constraint
  4. How does an imported policy expose unsupported conflict semantics? interoperability

Scoped preservation and release

Policy questions and evidence for scoped preservation and release.

Scoped preservation and release

Preservation exceptions are scoped, evidenced and periodically reviewed. A hold can suspend disposition without authorizing normal recall or automatically extending every memory lifetime.

  1. Which targets and disposition actions does a preservation hold cover? exception
  2. Which role can issue, renew or release the hold? authority
  3. When must a hold be reviewed and how are overdue reviews escalated? temporal
  4. After release, is the original expiry resumed or a new schedule authorized? lifecycle
Forgetting outcomes and propagation Proposed policy responsibilities for forgetting outcomes and propagation.

Suppression, retirement and erasure intent

Policy questions and evidence for suppression, retirement and erasure intent.

Suppression, retirement and erasure intent

Forgetting is an explicitly typed policy outcome: suppress recall, retire, redact, request scoped deletion, or request sanitization assurance. Intent, execution and verification states cannot be collapsed.

  1. Which forgetting outcome is requested and what does it exclude? definition
  2. What evidence authorizes the target and scope of an erasure request? privacy
  3. How are requested, in-progress, partial, failed and verified outcomes distinguished? state
  4. What evidence is required before an all-copy deletion claim is accepted? evidence

Derived memory and copy coverage

Policy questions and evidence for derived memory and copy coverage.

Derived memory and copy coverage

Proposed propagation policy follows declared lineage across summaries, embeddings, passages, caches and exports. A derivation edge identifies a review candidate, not automatic proof of equivalent content or authority to delete it.

  1. Which derived representations and copies fall within the forgetting scope? composition
  2. How are consolidation and embedding lineage used to discover affected targets? provenance
  3. What duties apply to independent recipients or shared derived memories? relationship
  4. How is unknown lineage or an unreachable recipient reported? exception
Recovery and continuity Proposed policy responsibilities for recovery and continuity.

Backup and restoration policy

Policy questions and evidence for backup and restoration policy.

Backup and restoration policy

Backups require a separate expiry and restore rule. Proposed recovery controls reconcile suppression and deletion records before restored content is made available; an inaccessible backup prevents a full completion claim.

  1. Which backup classes have separate retention windows and restrictions? retention
  2. How are pending forgetting decisions reapplied before restored memory is served? process
  3. How is a restored item tested against the current policy rather than its old snapshot? validation
  4. What happens when a backup cannot support selective deletion? exception

Execution handoff and race control

Policy questions and evidence for execution handoff and race control.

Execution handoff and race control

Policy evaluation produces a proposed disposition plan for a separately authorized executor. Freshness checks, stable request IDs and per-target results are proposed controls against stale decisions and partial completion.

  1. Which revision and target snapshot must the executor recheck before acting? process
  2. How are retries and duplicate completion messages correlated? event
  3. What invalidates a plan when a hold or policy changes during execution? constraint
  4. How are failed targets and lost acknowledgements distinguished from successful disposition? quality
Assurance and maintenance Proposed policy responsibilities for assurance and maintenance.

Outcome assurance and minimal evidence

Policy questions and evidence for outcome assurance and minimal evidence.

Outcome assurance and minimal evidence

An execution receipt is evidence to assess, not automatic proof of erasure. Minimal policy and disposition records have their own retention schedule and must not preserve deleted payload or reversible payload hashes without a justified basis.

  1. Which evidence supports verification and which role accepts the assurance conclusion? evidence
  2. What distinguishes logical deletion assurance from media sanitization assurance? validation
  3. What minimal audit information remains and when must it expire? privacy
  4. How are evidence access, integrity and sensitive correlations protected? security

Policy testing and interoperability limits

Policy questions and evidence for policy testing and interoperability limits.

Policy testing and interoperability limits

Proposed adoption gates require boundary fixtures and mapping loss reports. ODRL and DPV alignments do not implement a scheduler, decay engine, deletion executor or learned-model unlearning.

  1. Which pinned vocabulary versions and local extensions are required? interoperability
  2. Which expiry, conflict, restoration and cross-tenant fixtures must pass? validation
  3. How are policy changes reviewed for existing memories and pending requests? lifecycle
  4. Which guarantees remain unavailable before operational adoption? requirement

Classifiers Filled

Family
World Models
Category
Information and virtual systems
Entry kind
entity
Navigation path
NAV.INF.MEM.RET
Domain
INF.MEM.RET
Industry
Cross-industry
Tags
memoryretentionforgettingpolicyinf.mem.ret

What it is Filled

One versioned policy entity selecting agent-memory targets and expressing evaluation, exception and assurance requirements. The hierarchy is proposed design grounded in open specifications; it does not itself execute retention or deletion.

In scope

  • Policy identity, authority, scope and revision lifecycle
  • Triggers, duration bounds, relevance decay and recall eligibility
  • Scoped holds, forgetting outcomes, lineage, backups and restoration gates
  • Proposed evaluation interfaces and minimal outcome evidence

Out of scope

  • Memory content and store implementation
  • Actual erasure, media sanitization procedures and learned-model unlearning
  • Universal legal compliance or cognitive forgetting
  • Independent recipient control and retroactive removal of delivered answers

Why it exists Filled

Define governed lifetime, relevance-decay, preservation and forgetting rules for agent-held memory, with scoped evidence requirements.

Distinguishing features Derived, awaiting review

  • Unlike WM-XCT-035 Retention / Disposition: Candidate parent alignment only: general retention triggers, holds and disposition remain reusable; this entity adds agent-memory decay, recall and derived-representation policy. No validated inheritance is asserted.
  • Unlike WM-MEM-001 Memory Store and WM-MEM-002 Memory Item: Store and item masters own tenancy, content and item lifecycle; this policy selects them through references and never contains their payload.
  • Unlike WM-MEM-007 Memory Recall Event and WM-MEM-013 Context Assembly: This policy constrains eligibility and retention. Recall observations and context contents remain external; suppression cannot retract an already delivered answer.
  • Unlike WM-MEM-008 Memory Consolidation and WM-MEM-014 Retrieval Index: Derived-target discovery depends on lineage and index masters; no unconditional cascade or fabricated completeness is permitted.
  • Unlike WM-MEM-009 Memory Conflict and Precedence Rule: Factual memory conflict is distinct from retention-obligation conflict. Reference domain precedence only when its authority and scope fit.
  • Unlike WM-MEM-011 Memory Scope and Sharing Grant and WM-MEM-020 Memory Quarantine and Redaction: Retention neither grants access nor clears quarantine. Authorized quarantine and redaction workflows execute separately.
  • Unlike Learned-model parameters and human memory: This policy handles agent-held records and representations. It cannot certify machine unlearning, modify learned weights, prove absence from all outputs or govern human cognition.

Note: Derived from boundary notes against neighbouring models.

What robots and AI may and may not do Derived, awaiting review

Must not

  • Policy owners are accountable roles, never product names
  • Deleting a policy must not orphan governed memories or erase active obligations; identify successor or bounded review state
  • Deny until tenant, purpose, role and current grant are resolved.
  • Policy eligibility never creates an access grant.

May

  • Resolve applicable policy: Proposed local evaluation selects policies and reports missing scope or competing obligations. Unimplemented research interface.
  • Evaluate lifetime and eligibility: Proposed evaluation returns separate recall, retention and review outcomes; no destructive action. Unimplemented research interface.
  • Prepare forgetting scope: Proposed planning resolves lineage and recipient limits without deleting anything. Unimplemented research interface.
  • Record hold review: Proposed local record operation captures authorized issuance or release evidence and requires re-evaluation. Unimplemented research interface.
  • Assess completion evidence: Proposed local assessment records partial, rejected or accepted evidence within a declared claim scope. Unimplemented research interface.
  • Evaluate restoration gate: Proposed local preflight checks restored references against current policy and outstanding forgetting decisions. Unimplemented research interface.

Note: Derived from functions, policies, CRUD and access rules; prohibitions were not authored for agents as such.

Moral aspects Derived, awaiting review

  • privacy and retention

Note: Sentences mentioning harm, privacy, consent or similar, collected from the specification.

Owners Filled

Steward

Name an accountable policy steward by role and record authority

Roles

Policy steward
Own scope, basis, review cadence and approved revisions
Authority reviewer
Resolve applicability, preservation conflicts and exceptional retention
Memory custodian
Maintain target inventory, lineage and restore controls under approved policy
Disposition executor
Perform separately authorized operations and return scoped outcomes
Assurance reviewer
Assess evidence, residual gaps and audit-record minimization

Links to other meta-models Filled

aligned

  • WM-XCT-035 - Candidate general retention alignment; schema compatibility and inheritance unverified.

references

  • WM-MEM-001 - Reference the store master and tenancy boundary.
  • WM-MEM-002 - Reference targets without copying memory payload.
  • WM-MEM-008 - Use consolidation lineage for scoped derived-memory review.
  • WM-MEM-011 - Resolve permissions independently of retention eligibility.
  • WM-MEM-014 - Request index target coverage from the index master.
  • WM-MEM-020 - Refer to authorized quarantine or redaction workflows without overriding them.

neighbor

  • WM-XCT-035 Retention / Disposition - Candidate parent alignment only: general retention triggers, holds and disposition remain reusable; this entity adds agent-memory decay, recall and derived-representation policy. No validated inheritance is asserted.
  • WM-MEM-001 Memory Store and WM-MEM-002 Memory Item - Store and item masters own tenancy, content and item lifecycle; this policy selects them through references and never contains their payload.
  • WM-MEM-007 Memory Recall Event and WM-MEM-013 Context Assembly - This policy constrains eligibility and retention. Recall observations and context contents remain external; suppression cannot retract an already delivered answer.
  • WM-MEM-008 Memory Consolidation and WM-MEM-014 Retrieval Index - Derived-target discovery depends on lineage and index masters; no unconditional cascade or fabricated completeness is permitted.
  • WM-MEM-009 Memory Conflict and Precedence Rule - Factual memory conflict is distinct from retention-obligation conflict. Reference domain precedence only when its authority and scope fit.
  • WM-MEM-011 Memory Scope and Sharing Grant and WM-MEM-020 Memory Quarantine and Redaction - Retention neither grants access nor clears quarantine. Authorized quarantine and redaction workflows execute separately.
  • Learned-model parameters and human memory - This policy handles agent-held records and representations. It cannot certify machine unlearning, modify learned weights, prove absence from all outputs or govern human cognition.

parent

  • WM-XCT-035

What else AI and robots need to interact with it Incomplete

Identity and identifiers required Filled

  • Authoritative master-system identifier with tenant namespace
  • Policy revision plus opaque evidence identifier
  • Content digest for integrity only, never a replacement for authority or identity

Direct properties not applicable Not applicable

Not applicable

Institutional or informational subject: no invented physical properties.

Recognition optional Missing, in the backlog

Not described yet. This gap is in the card backlog.

Capabilities and actions required Filled

  • Resolve applicable policy: Proposed local evaluation selects policies and reports missing scope or competing obligations. Unimplemented research interface.
  • Evaluate lifetime and eligibility: Proposed evaluation returns separate recall, retention and review outcomes; no destructive action. Unimplemented research interface.
  • Prepare forgetting scope: Proposed planning resolves lineage and recipient limits without deleting anything. Unimplemented research interface.
  • Record hold review: Proposed local record operation captures authorized issuance or release evidence and requires re-evaluation. Unimplemented research interface.
  • Assess completion evidence: Proposed local assessment records partial, rejected or accepted evidence within a declared claim scope. Unimplemented research interface.
  • Evaluate restoration gate: Proposed local preflight checks restored references against current policy and outstanding forgetting decisions. Unimplemented research interface.

Hazards and failure modes optional Missing, in the backlog

Not described yet. This gap is in the card backlog.

Standards and interfaces required Derived, awaiting review

  • PROV-O: The PROV Ontology
  • HTTP Caching, RFC 9111
  • Date and Time on the Internet: Timestamps, RFC 3339
  • NIST SP 800-88 Revision 2: Guidelines for Media Sanitization
  • NIST SP 800-53 Revision 5: Security and Privacy Controls

Context of use required Filled

  • No jurisdictional retention period is supplied. NIST controls are a conceptual baseline whose applicability requires adoption review.
  • DPV is a community vocabulary; using it does not establish legal compliance.

Sources Filled

  1. ODRL Information Model 2.2 - W3C
  2. ODRL Vocabulary and Expression 2.2 - W3C
  3. PROV-O: The PROV Ontology - W3C
  4. HTTP Caching, RFC 9111 - IETF
  5. Date and Time on the Internet: Timestamps, RFC 3339 - IETF
  6. Data Privacy Vocabulary 2.0 - W3C Data Privacy Vocabularies and Controls Community Group
  7. NIST SP 800-88 Revision 2: Guidelines for Media Sanitization - NIST
  8. NIST SP 800-53 Revision 5: Security and Privacy Controls - NIST

Open questions

  • Compare pinned source versions with applicable current releases and errata, including DPV and NIST 800-53; verify direct retrieval and claim applicability independently.
  • Define and validate adoption profiles with authorized duration, clock, decay, conflict, preservation and recipient rules, without inventing universal defaults.
  • Implement nested schemas, neighbor mappings and acceptance fixtures for expiry races, hold release, unknown lineage, restored backups, partial completion and minimal audit retention.
  • Restore independent external review before any canonical or publishable-draft promotion.
  • No executable nested instance schema, scheduler, decay implementation, propagation executor or conformance test results.
  • No universal legal period or legal-hold priority; applicable jurisdiction and sector profiles require qualified review.
  • No machine-unlearning algorithm, learned-weight modification, anonymity guarantee or proof of absence from future outputs.
  • No complete runtime bindings to neighboring models; registry parent is a lead rather than verified inheritance.
  • Source HTTP status and body hashes are unmeasured locally; current release, errata and applicability checks remain open.
  • DPV 2.0 is an intentionally pinned older community report; later NIST 800-53 release differences have not been assessed.

Machine files

Card as JSON Specification AGENTS.md Source Card backlog vercy.card/1

Provenance

world-models research · reviewable-draft

Built from: models/wm-mem-010-memory-retention-and-forgetting-policy/spec.yaml