design: memory deletion policy — trust, safety, and integrity concerns

[GoZumie]

Background

PR #89 implements a wagl forget <id> command that permanently deletes a memory item from the local DB. Before this can ship, we need a clear policy on whether and how memory deletion should work in wagl.

Core Concerns

1. External manipulation risk

A deletion command that can be triggered via CLI or API call creates an attack surface: a compromised pipeline, a malicious prompt, or an unauthorized caller could erase an agent's memory without its knowledge or consent. This is qualitatively different from a write — deletion is irreversible and leaves no trace by default.

2. Audit trail gap

If a memory is deleted, there is currently no record that it existed. This makes it impossible to detect tampering, investigate anomalies, or restore lost context. A trustworthy memory system needs to know what was removed, when, and by whom.

3. Trust model implications

An agent whose memory can be silently altered by external actors is not a trustworthy agent. Memory integrity is a prerequisite for reliable agent behavior over time.

Proposed Design Direction

Rather than hard deletion, consider:

• Soft delete / archive: mark a memory as archived or superseded with a timestamp and reason. It stops surfacing in recall but the record is preserved.
• Correction with provenance: when a memory is wrong, store a correction that references the original — never erase the original.
• Append-only audit log: any mutation (archive, correct, re-weight) is logged and the log itself is protected from deletion.
• Protected memory classes: canon and high d_score memories require explicit elevated authorization to modify.

Open Questions

• Is there any legitimate use case that requires true deletion (e.g., GDPR compliance, accidental PII storage)?
• If so, what authorization model should gate it?
• Should deletion be a separate, separately-gated operation from normal CLI use?

Status

PR #89 is marked [DO NOT MERGE] pending resolution of this design question.

[GoZumie]

Design spec completed: docs/memory-integrity.md\n\nKey features include soft-delete (salience=0), 30-day nomination window in canon, and append-only audit logging.

[GoZumie]

Related issues (memory integrity cluster)

This design question now has several companion implementation issues that should be coordinated:

• feat: write protection flag for high-salience / high-d_score memories #141 — Write protection flag for high-salience / high-d_score memories (auto-protect |d_score| >= 8 + salience >= 0.9)
• feat: append-only audit log for all memory writes and deletions #142 — Append-only audit log for all memory writes and deletions
• feat: startup self-diagnostics — DB integrity check + soul query verification #143 — Startup self-diagnostics (DB integrity check + soul query verification)
• Feature: Flash messages with start/end dates #150 — Flash messages with start/end dates (related: injection architecture)

Design artifacts

• Wagl/memory/2026-03-12-Locked-Memory-First-Pass.md in Chris/notebook — encryption at rest, user-key protection, session-scoped unlock
• Wagl/memory/2026-03-12-Actionable-Memory-Philosophy.md — actionable gating for recall safety
• March 17 design session: append-only model, salience-zero archival, 30-day nomination windows, supersession with bidirectional FKs, nominations stored as memories

Still needed

• Soft delete with cooling period — the staged deletion pipeline (soft-delete → 30/90 day cooling → confirmation → cold storage → physical purge). Filing as a separate issue.
• Agent consent gate — deletion requires agent acknowledgment, not just human command

Key design principle (Chris, March 17)

"I want to think about this less, but also remember why."

PR #89 (wagl forget) remains DO NOT MERGE pending this cluster.