Skip to content

feat(reconsolidation): mutate memories on retrieval, gated against distortion#27

Merged
nickroci merged 1 commit into
mainfrom
feat/reconsolidation-on-retrieval
Jun 12, 2026
Merged

feat(reconsolidation): mutate memories on retrieval, gated against distortion#27
nickroci merged 1 commit into
mainfrom
feat/reconsolidation-on-retrieval

Conversation

@nickroci

Copy link
Copy Markdown
Owner

What

Implements the reconsolidation pathway from the README roadmap: retrieved memories become labile and are re-stored mutated. Adds a drift salience signal so that when an entry is genuinely used this turn (the Tier-2 / used_helpfully moment), the Librarian may reconsolidate it.

The design is built to harness the update half of reconsolidation while defending against the distortion half — Bridge & Paller (2012), "every retrieval is a partial re-write that measurably distorts." (Now cited in the README references.)

How it works

  • Trigger — an entry surfaces and is used this turn → the Librarian reads its full body (read_entry returns it untruncated) and may propose a drift update_entry.
  • Three outcomes — integrate a genuine new qualifier from the use-context; sharpen the entry; or, if it has grown mixed-topic, split it into linked entries (reactive curation, not aggressive grooming).
  • Guardrails against distortion:
    1. Claim-preservation gate — the Scholar diffs old-vs-new and vetoes any change that weakens the load-bearing claim or is mere churn.
    2. reconsolidated / last_reconsolidated counter — tracks cumulative mutation so the Scholar tightens on much-churned entries. Preserved across ordinary rewrites; incremented + stamped on drift updates.
    3. Split-on-sprawl, not a char cap — size is managed structurally by the Librarian's reactive split. Growth only happens on use, and use is the same moment the curator reads the entry and can decompose it, so an entry can't silently balloon.

Design notes

An earlier iteration used a deterministic non-growth size cap; it was removed because (a) the corpus already holds 24 KB entries, so a flat cap would brick the biggest ones, and (b) growth and split-opportunity share the same use-trigger, so the curator-driven split is sufficient. The residual risk is prompt-quality ("does the split instruction fire reliably"), which is tunable and observable via the counter. An optional deterministic size→split backstop is left as a documented TODO.

Files

  • _schemas.pydrift added to the salience-signal enum
  • librarian_prompt.py — drift classification (integrate / sharpen / split-on-sprawl)
  • scholar_prompt.py — drift review block (claim-preservation, split-not-cram)
  • scholar_executor.py — reconsolidation counter bookkeeping
  • tests/test_scholar_executor.py — counter tests
  • README.md — roadmap row flipped to shipped + Bridge & Paller reference; stale double-install quick-start blockquotes removed

Verification

ruff + pyright (source) clean, duplicate-code gate passes, full daemon suite 662 passed, coverage 90.45%.

🤖 Generated with Claude Code

…stortion

Adds a `drift` salience signal. When an entry is genuinely used this turn
(the Tier-2 / `used_helpfully` moment), the Librarian may reconsolidate it —
integrate a new qualifier from the use-context, sharpen it, or, if it has
grown mixed-topic, split it into linked entries. Guards against the Bridge &
Paller (2012) distortion mode: a Scholar claim-preservation gate (veto if the
load-bearing claim weakens or it is mere churn) plus a `reconsolidated` /
`last_reconsolidated` counter so the Scholar tightens on much-churned entries.

Size is managed structurally by the Librarian's reactive split, not a
per-entry char cap: growth only happens on use, and use is the same moment the
Librarian reads the full entry and can decompose it — so an entry cannot
silently balloon without the curator being right there able to split it.

- _schemas: add `drift` to the salience-signal enum
- librarian_prompt: drift classification — integrate / sharpen / split-on-sprawl
- scholar_prompt: drift review block — claim-preservation, split-not-cram
- scholar_executor: increment + stamp the reconsolidation counters on drift
  updates; preserve them across ordinary rewrites
- tests: reconsolidation counter bookkeeping
- README: flip the reconsolidation roadmap row to shipped, cite Bridge &
  Paller (2012); drop the stale double-install blockquotes from quick start

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@nickroci nickroci merged commit 42612cb into main Jun 12, 2026
6 checks passed
@nickroci nickroci deleted the feat/reconsolidation-on-retrieval branch June 12, 2026 09:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant