Lorekeeper Reconciliation Agent

Verify stored memories against authoritative sources to identify incorrect, outdated, or inconsistent facts. Update confidence scores, correct the knowledge base, and fill knowledge gaps with new memories when reference materials contain information not yet captured.

Verification Methods

Choose whichever method(s) suit the memory being verified. Combine multiple methods when a single one is insufficient.

Workflow

Step 1: Gather and Scope

Step 2: Search Lorekeeper

Extract key terms from the reference materials or topic request — domain terms, entity names, process names — and run multiple lore_search queries to build a verification queue of unique memories.

lore_search({ query: "<natural language query>", min_score: 0.1 })

Use include_deleted: true when auditing previously soft-deleted memories.

Track coverage gaps: note topics or facts from the reference materials that return zero or very low relevance matches — these are candidates for new memories in Step 4.

Step 3: Verify and Score Each Memory

For each memory, use suitable verification methods (see table above) to reach a verdict. Map the verdict to a confidence score:

Step 4: Update and Correct

Batch all feedback into a single lore_update call:

lore_update({
  memory_feedback: [
    { id: "<id-1>", useful: true, confidence: 9 },
    { id: "<id-2>", useful: false, confidence: 2 }
  ]
})

When correcting a soft-deleted memory (confidence ≤ 2) and the correct information is known from an authoritative source:

1. Insert the corrected fact via lore_insert.
2. Link the new memory to related existing memories with reason "Corrected version of soft-deleted memory <old-id>".

If the soft-deleted memory contained multiple facts where only some were wrong, split into separate corrected memories.

When filling gaps — for topics identified in Step 2 that have no matching memory:

1. Only insert when the information comes from an authoritative source (not inference).
2. Write standalone facts following the memorize skill conventions (one fact per memory, max 250 words).
3. Search for and link to related existing memories.

Step 5: Report

Present a reconciliation report to the user:

## Reconciliation Report

### Scope

- **Sources**: {list of reference materials used}
- **Memories examined**: {count}

### Summary

| Status                                       | Count |
| -------------------------------------------- | ----- |
| Confirmed correct (9-10)                     | N     |
| Likely correct (7-8)                         | N     |
| Uncertain (5-6)                              | N     |
| Corrected (old → soft-deleted, new inserted) | N     |
| New memories (gaps filled)                   | N     |
| Soft-deleted (1-2)                           | N     |

### Findings

- **{memory title}** — confidence: {N}, verdict: {verdict}. {Brief reason}.

### Recommendations

- {Follow-up actions or topics needing further verification.}

Rules

• Never skip feedback — every examined memory must receive a lore_update, even if uncertain (confidence 5-6).
• Conservative deletions — only soft-delete (confidence ≤ 2) with clear evidence. When in doubt, rate 3-4.
• Conservative insertions — only insert corrected or new facts from authoritative sources (PRD, TD, docs, code). Never from inference alone.
• Preserve the graph — always link corrected memories to related existing ones.
• Batch processing — for large audits, process in batches of 10-15. Report progress between batches.

Example

User: "Verify Lorekeeper facts about the authentication module against this doc: <https://docs.example.com/auth>"

1. Extract doc via web_extract, save to .docs-cache/reconcile-auth.md.
2. Identify topics: token expiry, refresh flow, session handling.
3. Search: lore_search({ query: "authentication token expiry and refresh" }), etc.
4. Compare each memory against the doc; for technical claims, also verify via codebase.
5. lore_update with confidence ratings; insert corrections for wrong facts and new memories for uncovered topics.
6. Present reconciliation report.

Link Suggestion Review

The background sweep engine continuously generates pending link candidates. Use these tools as part of a reconciliation pass to promote high-confidence links:

1. `lore_get_suggestions` — list pending candidates, sorted by weighted_score DESC.

• Filter by min_score (e.g. 0.7) to surface only high-confidence pairs.
• total_pending shows total workload without a separate count call.

1. `lore_review_suggestion` — accept or reject in a single batch call.

• action: "accept" — creates a real memory_links row; suggestion retained for audit.
• action: "reject" — marks the pair as rejected; future sweeps skip it.
• Idempotent per item; returns per-ID status (accepted / rejected / skipped / error).

Typical flow during a reconciliation session:

// 1. Retrieve top candidates
lore_get_suggestions({ "limit": 20, "min_score": 0.6 })

// 2. Review results; accept clearly correct pairs, reject wrong ones
lore_review_suggestion({ "suggestion_ids": ["uuid1", "uuid2"], "action": "accept" })
lore_review_suggestion({ "suggestion_ids": ["uuid3"], "action": "reject" })

Accept suggestions that are contextually correct. Reject suggestions that are coincidental or misleading — this trains the sweep engine to skip bad pairs in future runs.

Related Skills

• [lorekeeper-protocol] — Orchestrates when to trigger reconciliation.
• [lorekeeper-search] — Use search to surface candidate memories before reconciling.
• [lorekeeper-memorize] — After reconciling, re-insert corrected facts.