Graph health

Recall is only as good as the graph behind it. A healthy graph has well-described nodes, few orphans, no duplicates and relationships that say why things are connected. Most of this happens automatically; this guide covers what you can do on top.

What HyperMemory does for you

	How
Enrichment	After every write, background workers expand thin descriptions, extract data, detect people and organizations and link them.
Memory workers	The Enrichment worker discovers relationships and types, merges duplicates, cleans up orphans and detects hyperedges. Run it now or on a schedule from Memory Workers in the dashboard.
The memory-writer	The plugins’ writer agent stores each fact as its own node, links it to its siblings and cleans up after ingests.

Find orphans

hm_list_orphans lists nodes that aren’t connected to the main graph:

hm orphans --limit 100

For each one, either connect it to its context with hm_add_relationships, or delete it with hm_forget if it’s junk. Orphans appear most often after hm_ingest.

Merge duplicates

When two nodes describe the same thing:

1. Read both with hm_get_nodes.
2. Rewrite the better one with hm_update so it holds everything that’s true.
3. Re-create the other’s relationships on it with hm_add_relationships.
4. Delete the other with hm_forget.

Fix vague relationships

A relationship that just says “related to” or “mentions” doesn’t help recall. Replace it with one that explains the connection — “Alice owns the Acme renewal”, “checkout uses Redis for sessions”. Edges’ wording can be changed with hm_update and the edge’s edge_id.

Audit memory quality

The memory-quality-audit system skill grades your graph on recall accuracy, description quality, relationships, categorization and coherence, and recommends fixes. Ask your agent:

Get the memory-quality-audit skill with hm_skill and run it on my graph.

Habits that keep a graph healthy

• Recall before you store. Update existing memories instead of creating near-duplicates.
• One node per fact, decision, preference or risk — not one big event that buries them.
• Lead descriptions with the point, and keep IDs and paths in data.
• Always store with at least one relationship.
• Correct, don’t append. When something changes, rewrite the description to say what’s true now.