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

> Discover how ai-memory's memory_feedback handles stale or wrong signals differently from deletion. Learn about quality control and signal preservation.

- Repository: [Fabio Akita/ai-memory](https://github.com/akitaonrails/ai-memory)
- Tags: deep-dive
- Published: 2026-08-20

---

**`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`](https://github.com/akitaonrails/ai-memory/blob/main/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`](https://github.com/akitaonrails/ai-memory/blob/main/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`](https://github.com/akitaonrails/ai-memory/blob/main/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

```rust
// 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")
);

```

```rust
// 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`](https://github.com/akitaonrails/ai-memory/blob/main/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`](https://github.com/akitaonrails/ai-memory/blob/main/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`](https://github.com/akitaonrails/ai-memory/blob/main/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.