# Memory Maintenance Report Template

## Purpose

Use this template for recurring maintenance reviews after the memory pipes are live.
It is meant to produce not just metrics, but **assessment** and **suggestions** that drive action.

This pairs well with memory systems that support ongoing health checks, staleness pruning, deduplication, and periodic review.

## Suggested cadence

- **Hourly** during initial stabilization, if the system is being exercised heavily
- **Daily** during the first tuning window
- **Weekly** once the system is stable

Cadence can be adjusted by layer and by observed behavior.

---

# Memory Maintenance Report

## 1) Report metadata

- **Date/time:**
- **Reviewer:** Hermes / Bert / other
- **Scope:**
- **Surface:** WebUI / Telegram / Notion / CLI / other
- **Layer(s):** archive / candidate / approved_memory / open_brain / mcp / retrieval
- **Period covered:**

## 2) Metrics summary

| Metric | Value | Notes |
|---|---:|---|
| Searches run |  |  |
| Fetches run |  |  |
| Install actions |  |  |
| Prunes |  |  |
| Retags |  |  |
| Merges |  |  |
| Splits |  |  |
| Approvals |  |  |
| Rejections |  |  |
| Source-only decisions |  |  |
| No-change decisions |  |  |

## 3) What happened

Brief factual summary of the maintenance cycle.

- What was searched for:
- What was found:
- What was missed:
- What was noisy or redundant:
- What felt especially useful:

## 4) Assessment

Short analytical readout. This should interpret the data, not just list it.

### Assessment questions
- What pattern is emerging?
- Which memory types performed best?
- Which sources are most reliable/useful?
- Which queries are too broad, too narrow, or noisy?
- Which items seem stale, redundant, or over-promoted?
- Are we missing tangential context that should have been retained?

### Assessment summary

- **Overall status:** ok / needs-tuning / needs-pruning / needs-reindexing / needs-retagging / needs-more-data
- **Confidence:** high / medium / low
- **Key insight:**
- **Main risk:**
- **Main opportunity:**

## 5) Suggestions

Recommendations should be specific and actionable.

### Suggested actions
- keep as-is
- prune
- promote
- demote
- retag
- merge
- split
- reindex
- change cadence
- collect more data before deciding

### Suggestion summary

- **Primary recommendation:**
- **Secondary recommendation:**
- **Deferred recommendation:**
- **What should be done next:**

## 6) Decision record

| Decision | Target | Reason | Follow-up |
|---|---|---|---|
|  |  |  |  |
|  |  |  |  |

## 7) Trend watch

Track recurring patterns over time.

| Trend | Direction | Evidence | Decision impact |
|---|---|---|---|
| Retrieval precision |  |  |  |
| Retrieval recall |  |  |  |
| Noise level |  |  |  |
| Staleness rate |  |  |  |
| Duplicate rate |  |  |  |
| Source-only usefulness |  |  |  |
| Cross-surface consistency |  |  |  |

## 8) Open questions

- What are we still unsure about?
- What needs more data?
- What should be tested next?

## 9) Next actions

- [ ]
- [ ]
- [ ]

---

## Notes on style

Keep the report:

- concise enough to read quickly
- structured enough to compare over time
- explicit about assessment and suggestions
- tied to decisions, not just observations

The goal is for each report to answer:

> What happened?
> What does it mean?
> What should we do next?