`memory_feedback` with Stale/Wrong Signals vs. Deletion: How ai-memory Handles Quality Control

memory_feedback with stale or wrong signals preserves the page while lowering its ranking and flagging it for review, whereas memory_delete_page permanently removes all versions and related data.

The ai-memory wiki system provides two distinct mechanisms for handling problematic content: a quality-feedback loop (memory_feedback) and destructive removal (memory_delete_page). Understanding this distinction is critical for operators who need to balance auditability, content remediation, and database hygiene.

---

What memory_feedback Actually Does

memory_feedback is a write-only operation that attaches a quality signal to the current version of a wiki page. According to the source in docs/usage.md, this tool never deletes data—it only influences how the page is ranked and surfaced.

The Three Effects of Stale/Wrong Feedback

1. Reduced salience, not removal. The pages row stays in the database, but its derived salience value drops to a "floor" level. This makes the page less likely to appear in normal queries without hiding it entirely.

2. Lint finding generation. The feedback row joins against pages.is_latest = 1 during the lint pass, producing a feedback_flagged finding. This alert prompts human review and potential rewrite.

3. Version-tied expiration. Because feedback binds to a specific page version, a subsequent rewrite (creating a new version) automatically clears the stale/wrong flag. The original content remains available for audit or rollback.

In docs/ARCHITECTURE.md, the page_feedback schema design makes this possible: feedback records reference page_version_id, so new versions start with a clean quality slate.

---

What memory_delete_page Actually Does

The memory_delete_page tool triggers a cascade delete through the admission chain with op=delete. From docs/usage.md, this operation:

• Removes all versions of the specified page
• Deletes associated links, embeddings, and related rows
• Makes the path unresolvable—no future retrieval or flagging possible

This is destructive and irreversible in normal operation. The path ceases to exist in the system.

---

Code Comparison: Feedback vs. Deletion

// Soft quality signal: preserves data, lowers ranking, triggers lint
await client.memory_feedback(
    path = "docs/design-decisions.md",
    kind = "stale",               // or "wrong"
    reason = Some("Content out‑of‑date after v2.0 release")
);

// Hard deletion: erases all traces permanently
await client.memory_delete_page(
    path = "docs/old-prototype.md"
);

Both calls use the same MCP client interface, but their data effects are fundamentally different: write versus destructive erase.

---

Soft-Delete: The Middle Ground

The ai-memory system includes a third path: soft deletion via soft_delete_for_decay_if_latest in crates/ai-memory-store/src/ops.rs (lines 31-38). This automatic forget sweep:

• Marks pages as non-latest (is_latest = 0)
• Sets superseded_at timestamp
• Retains the row for audit purposes

This differs from both feedback and hard deletion: it removes content from active rotation without human quality judgment, while still preserving history.

Mechanism	Data Preserved	Human Review Triggered	Reversible by New Version
memory_feedback (stale/wrong)	✅ Yes	✅ Yes	✅ Yes
soft_delete_for_decay_if_latest	✅ Yes	❌ No	❌ No
memory_delete_page	❌ No	N/A	N/A

---

Implementation Details from Source

The record_page_feedback function in crates/ai-memory-store/src/ops.rs (lines 51-66) implements the salience update and audit logging. Meanwhile, delete_page (lines 73-80) handles the hard-delete operation invoked by memory_delete_page.

Key architectural insight from docs/ARCHITECTURE.md (lines 64-71): the feedback system's design intentionally decouples quality signaling from data lifecycle. This allows operators to express "this content is problematic" without foreclosing on "this content might be useful for comparison or legal audit."

---

Summary

• memory_feedback with stale/wrong preserves the page, lowers its salience, creates a feedback_flagged lint finding, and expires automatically on rewrite.
• memory_delete_page executes a cascade delete of all versions, embeddings, and links—permanent and irreversible.
• Soft deletion via the forget sweep offers automatic archival without quality judgment.

Choose feedback when content needs human review; choose deletion when content must be fully purged.

---

Frequently Asked Questions

Does stale feedback hide a page from all queries?

No. Stale feedback lowers the page's salience to a floor value, making it less likely to appear, but targeted lookups by exact path still resolve. Only deletion makes a path unresolvable.

Can feedback on a wrong page be appealed or cleared without rewriting?

Feedback automatically clears when a new version is created. To clear feedback without rewriting, you would need database-level intervention—there is no "retract feedback" tool in the MCP interface.

Why not just delete content flagged as wrong instead of using feedback?

Deletion destroys audit trails and prevents future comparison. The ai-memory design favors explainable retention: keeping problematic content visible to operators (via lint findings) while ensuring it does not mislead automated systems (via salience reduction).

What happens if I submit feedback on a non-latest page?

Feedback joins against pages.is_latest = 1 for lint generation. Feedback on non-latest pages would still record in page_feedback, but would not trigger the feedback_flagged finding during normal lint passes—making it less actionable.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}