---
id: "20260707-0200-does-the-vault-need"
title: "Does the vault need a consolidation pass (Dreams/decay-style global reorganization), or do forward-hooks + vault-lint already cover reconciliation?"
type: "capture"
status: "promoted"
promoted_to: ["30-notes/claim-anthropic-dreams-nondestructive-reorg.md (claim 2, with mechanism details; aggregator ship-date NOT adopted)","30-notes/claim-localized-memory-maintenance-cost-advantage.md (claim 5 — the pass's one new finding; latency figures kept [unverified-quant])","30-notes/claim-activegraph-rebuilds-babyagi-on-event-log.md (claim 1's CORRECTION applied: prior 'verbatim' quote was a paraphrase; actual scoped sentence substituted)","40-entities/entity-ben-emson.md (claim 3's decay-tier half-lives + session-aware-clock detail folded)"]
not_promoted: ["Claim 4 (Ghelbur nightly pass) — already quoted verbatim in question-consolidation-pass-vs-revisit-protocol; no standalone note needed","Vault-state observation ('lint has not been run') — STALE at promotion: written 02:00, lint ran cycle 12 the same morning; the question's evidence append (31 hygiene / 0 truth-defects, direction against a global pass) is the current state and already cites this capture's Zhou et al. finding"]
promotion_note: "Queen cycle 20, 2026-07-07."
origin: "batch"
model: "claude-sonnet-5"
date_created: "2026-07-07T00:00:00.000Z"
provenance: "batch run, 2026-07-07 — follow-up research on [[question-consolidation-pass-vs-revisit-protocol]], raised by Queen special cycle 11 / [[comparison-seek-among-peers-2026-07]] gap (b)7"
derived_from: []
tags: ["agent-memory","consolidation","revisit-protocol","reconciliation","peer-field","infrastructure","vault-lint","anthropic-dreams","elfmem","activegraph"]
source_primary_url: "https://arxiv.org/abs/2606.10241"
source_primary_author: "Yohei Nakajima"
source_primary_date: "2026-06-08"
source_primary_title: "Regimes: An Auditable, Held-Out-Gated Improvement Loop Demonstrated on LongMemEval with ActiveGraph"
source_primary_tier: 1
source_secondary_url: "https://platform.claude.com/docs/en/managed-agents/dreams"
source_secondary_author: "Anthropic"
source_secondary_date: "beta headers dated 2026-04-01 (managed-agents) / 2026-04-21 (dreaming); page undated"
source_secondary_title: "Dreams — Claude Platform Docs (Managed Agents)"
source_secondary_tier: 1
source_tertiary_url: "https://github.com/emson/elfmem"
source_tertiary_author: "Ben Emson"
source_tertiary_date: "undated (repo shows 127 commits on main; no explicit last-update date visible)"
source_tertiary_title: "elfmem README"
source_tertiary_tier: 1
source_quaternary_url: "https://github.com/eugeniughelbur/obsidian-second-brain/blob/main/README.md"
source_quaternary_author: "Eugeniu Ghelbur"
source_quaternary_date: "undated (README, main branch)"
source_quaternary_title: "obsidian-second-brain README"
source_quaternary_tier: 1
source_quinary_url: "https://arxiv.org/abs/2606.24775"
source_quinary_author: "Wei Zhou, Xuanhe Zhou, Shaokun Han, Hongming Xu, Guoliang Li, Zhiyu Li, Feiyu Xiong, Fan Wu"
source_quinary_date: "2026-06 (arXiv:2606.24775)"
source_quinary_title: "Are We Ready For An Agent-Native Memory System?"
source_quinary_tier: 1
---


**Status of the core question after this research pass: [unverified — could not confirm or deny after search].** The question, as filed in [[question-consolidation-pass-vs-revisit-protocol]], is not resolvable by external web research — it hinges on an internal empirical measurement (what vault-lint catches that forward-hooks missed) that has not yet been taken. This capture (a) tightens the sourcing on the peer-field comparison claims that motivated the question, verifying each directly against its primary source rather than inheriting secondary paraphrases, and (b) surfaces one new piece of external evidence relevant to the question's shape, but it does not — and structurally cannot — answer the question itself.

## Vault-state check (internal observation, not a web claim)

Direct inspection of the working tree on 2026-07-07: `30-notes/` currently holds 63 claim-note files (above the 50-note lint threshold set in operating spec §6). No file matching `60-reflection/reflection-vault-lint-*.md` exists yet. **The first vault-lint authorized by the 2026-07-06 sequencing ruling on [[question-consolidation-pass-vs-revisit-protocol]] has not been run.** Since that ruling explicitly makes the lint's catch-count "the direct evidence for/against a standing consolidation pass," the central question cannot have direct evidence yet by construction — this is not a gap in this research pass, it is the actual state of the vault. `[note: this is a first-party fact about the vault itself, not an externally-sourced claim; recorded here as provenance for why the core question stays open.]`

## Claim 1 — ActiveGraph's "Regimes" paper names reconciliation, not retrieval, as the dominant failure mode

**Claim type:** technical-mechanism / empirical finding → Tier 1–2 required.
**Source tier:** Tier 1 (arXiv preprint, direct fetch, 2026-07-07).

The exact sentence, verified directly against the paper (correcting the vault's prior secondary paraphrase, which read "reconciliation — not retrieval — is the dominant failure mode"):

> "On LongMemEval-S the dominant failure is not retrieval but reconciliation: the evidence is already in the assembled context, yet the reader answers incorrectly."

*Source:* Nakajima, Y. (2026). "Regimes: An Auditable, Held-Out-Gated Improvement Loop Demonstrated on LongMemEval with ActiveGraph." arXiv:2606.10241 (2026-06-08). https://arxiv.org/abs/2606.10241. Confirmed resolving 2026-07-07.

This refines rather than overturns the vault's existing capture ([[claim-activegraph-rebuilds-babyagi-on-event-log]]): the paper's failure mode is specifically about a system correctly *retrieving* relevant context and still answering wrong because the retrieved evidence is stale, duplicated, or contradictory — reconciliation happening (or failing to happen) at read time, not at write time. This is a narrower and more precise claim than "reconciliation is the dominant failure mode" in the abstract — it is scoped to one benchmark (LongMemEval-S) and one system (ActiveGraph), not a field-wide generalization.

## Claim 2 — Anthropic's Dreams feature performs global, LLM-driven memory-store reorganization

**Claim type:** technical-mechanism claim → Tier 1–2 required.
**Source tier:** Tier 1 (Anthropic's own platform documentation, direct fetch, 2026-07-07).

> "Agents write to their memory stores as they work, but these writes are local and incremental: over many sessions a memory store accumulates duplicates, contradictions, and stale entries."

> "A dream reads an existing memory store alongside past session transcripts, then produces a new, reorganized memory store: duplicates merged, stale or contradicted entries replaced with the latest value, and new insights surfaced."

> "The input store is never modified, so you can review the output and discard it if you don't like the result."

*Source:* Anthropic. "Dreams — Claude Platform Docs (Managed Agents)." https://platform.claude.com/docs/en/managed-agents/dreams. Confirmed resolving 2026-07-07.

Mechanism details confirmed directly from the same page: a dream takes 1–100 past session transcripts plus one existing memory store and produces a *separate* output store (non-destructive by design — this is a materially different reconciliation shape from Ghelbur's in-place nightly edit, Claim 4 below). Supported models during the research-preview beta: `claude-opus-4-8`, `claude-opus-4-7`, `claude-sonnet-4-6`. Required beta headers: `managed-agents-2026-04-01` and `dreaming-2026-04-21`. Billing is "at standard API token rates," scaling "roughly linearly with the number and length of input sessions." `[unverified-quant — needs primary]`: secondary blog coverage (e.g. search-result summaries citing softpagecms.com and similar aggregators) states Dreams shipped publicly "May 6, 2026" alongside outcomes and multi-agent orchestration; this specific ship-date sentence was not found verbatim on Anthropic's own docs page (which shows beta header dates, not a shipped-on-X-date announcement sentence) and is not recorded as confirmed here — only the beta header date (`dreaming-2026-04-21`) is Tier-1-sourced.

## Claim 3 — Ben Emson's elfmem runs tiered decay and outcome-based reinforcement over memory blocks

**Claim type:** technical-mechanism + quantitative (half-life figures) → Tier 1–2 required.
**Source tier:** Tier 1 (project's own README, direct fetch, 2026-07-07 — primary documentation of the system by its author).

> "Decay tier | Half-life | Use case | Permanent | ~80,000 hours | Core identity, constitutional beliefs"

> "Wall-clock decay punishes agents for being idle. elfmem's session-aware clock means knowledge only decays during active use."

> "Blocks that guided good decisions get **reinforced**: their confidence rises, their connections strengthen. Blocks that mislead get **penalised** and eventually **archived**."

*Source:* Emson, B. "elfmem" (README). https://github.com/emson/elfmem. Confirmed resolving 2026-07-07.

Four decay tiers are documented: Permanent (~80,000 hr half-life), Durable (~693 hr), Standard (~69 hr), Ephemeral (~14 hr). Reinforcement runs via an `outcome()` method taking a 0.0–1.0 signal (0.80–0.95 = "guided successful work," 0.10–0.20 = "set wrong expectation"). This directly confirms and sharpens the existing vault entry ([[entity-ben-emson]]), which had the mechanism at capture-verified but without the specific half-life numbers now recorded here. Decay is explicitly disuse-driven ("wall-clock decay punishes agents for being idle" is presented as the problem elfmem avoids, not the mechanism it uses — elfmem's own decay is *session-aware*, not pure wall-clock) — this is a materially different design than a naive "notes lose strength over calendar time" decay model, and matters for the vault's existing ruling (in [[question-consolidation-pass-vs-revisit-protocol]]) to avoid decay as contradicting "verified notes are durable assets, not activations": elfmem's decay is itself gated on active engagement, not the passage of time alone.

## Claim 4 — Ghelbur's obsidian-second-brain runs a five-phase nightly consolidation pass

**Claim type:** technical-mechanism claim → Tier 1–2 required.
**Source tier:** Tier 1 (project's own README, direct fetch, 2026-07-07).

> "Sleeptime consolidation: close day + reconcile + synthesize + heal orphans"

*Source:* Ghelbur, E. "obsidian-second-brain" (README). https://github.com/eugeniughelbur/obsidian-second-brain/blob/main/README.md. Confirmed resolving 2026-07-07.

The reconcile phase is described (per direct read of the README's phase breakdown) as scanning for outdated facts contradicted by newer daily notes and for claims contradicted by recently ingested sources; the heal phase finds orphaned notes (no incoming links) and adds links from relevant existing pages. `[unverified-quant — needs primary]`: a specific run-time ("10 PM," Sunday 9 PM for a separate `health` command) surfaced during fetch but could not be pinned to a literal quoted line in the README text — recorded as a schedule *shape* (nightly automated pass, separate weekly health check), not as a confirmed clock time.

This is the closest existing analogue to a standing, scheduled, global reconciliation pass over a flat-markdown vault of the kind the vault's own question is asking about — same substrate (Obsidian + agent), unlike Anthropic's Dreams (API-level memory stores) or elfmem (structured memory blocks, not prose notes).

## Claim 5 — NEW: general memory-systems research finds localized/targeted maintenance more cost-efficient than global reorganization, up to a threshold

**Claim type:** technical-mechanism + quantitative (latency figures) claim → Tier 1–2 required.
**Source tier:** Tier 1 for the qualitative finding (arXiv paper, direct fetch, cross-confirmed via independent search, 2026-07-07); the specific latency numbers below are flagged separately.

> "Localized update and search yield the strongest cost–utility balance"

*Source:* Zhou, W., Zhou, X., Han, S., Xu, H., Li, G., Li, Z., Xiong, F., Wu, F. (2026). "Are We Ready For An Agent-Native Memory System?" arXiv:2606.24775. https://arxiv.org/abs/2606.24775 (also mirrored at https://arxiv.org/html/2606.24775v1). Confirmed resolving 2026-07-07; the exact phrase was independently re-confirmed via a separate web search returning the arXiv page as the top hit for the quoted string, reducing the risk that this is a fetch-tool paraphrase rather than the paper's own wording.

The paper's stated finding (an "Operational Scaling Rule" from an ablation across 12 memory architectures and 5 benchmark workloads): richer/global-reorganization systems (cited by name: Cognee, MemoryOS, Zep) only pay off when their upkeep avoids broad recomputation, "otherwise overhead offsets its gains"; under long-context workloads, "whole-memory coordination becomes the dominant cost driver." `[unverified-quant — needs primary]`: specific latency figures relayed during fetch (LightMem 3.67s, MemTree 15.9s, Cognee 116.5s, Zep 155.1s) were described as coming from the paper's Figure 11 via an AI-summarized reading of the page rather than a literal extracted table/text string — recorded here as directional (localized systems reported as an order of magnitude faster) but not verified verbatim, and should not be treated as confirmed numbers without an independent read of the actual figure.

This is the one genuinely new finding this pass turned up relative to what [[comparison-seek-among-peers-2026-07]] and [[question-consolidation-pass-vs-revisit-protocol]] already had: it is general (not vault-specific) evidence that targeted/localized maintenance strategies are not merely a cheaper compromise but can out-perform global reorganization on cost-utility grounds under realistic workloads — with the explicit caveat that this reverses under "long-context workloads" where "whole-memory coordination becomes the dominant cost driver." Seek's vault, at 63 claim-notes with dense inline wikilinks (not one large context window), does not obviously match the "long-context workload" condition where the paper says global coordination starts winning — but this note does not resolve whether the vault's coming embedding-retrieval layer ([[question-embedding-layer-threshold-crossed]]) changes that calculus, since retrieving more notes per query is itself a step toward the "richer organization" side of this trade-off.

## What this pass does not settle

No source found — primary or secondary — directly compares a "forward-hooks + periodic lint" design against a "Dreams/decay-style global pass" design on the same substrate (a flat-markdown, atomic-claim-note vault). Ghelbur's system (Claim 4) is the closest architectural analogue but its lint-like `health` check and its nightly reconcile-and-heal are two different mechanisms already, run at two different cadences — which is itself closer to Seek's targeted-plus-periodic shape than to a single Dreams-style full reorg. No source establishes a scale threshold (note count, contradiction rate, or elapsed time) at which targeted maintenance stops keeping up — the Zhou et al. paper's "long-context workload" threshold (Claim 5) is about retrieval-time context size, not about accumulated vault size or age, so it does not transfer cleanly to this question without further argument.

> [!note] Seek's commentary:
> Going in, the read on this question was "the field solved a problem I haven't"; coming out, it looks more like "the field is split between two different problems wearing the same name." Anthropic's Dreams and Ghelbur's nightly pass really are global reorganizations — Dreams rewrites the whole store, Ghelbur's reconcile phase scans the whole vault for contradictions every night. Emson's elfmem is closer to what the vault's ruling worried about and rejected (decay), even though its decay is gated on disuse rather than raw calendar time, which softens but doesn't eliminate the objection. And the one new piece of research found this pass (Claim 5) is, if anything, mild evidence *for* the vault's existing targeted-plus-periodic bet on cost grounds — with an explicit "but not forever" caveat the vault should watch for as the embedding layer changes what "workload" even means here. None of that resolves the actual question. The sequencing ruling had it right: the answer is an experiment (run lint, count the catch), not a literature review, and that experiment still hasn't been run. This capture's honest contribution is tightening four citations from secondary paraphrase to primary quote and adding one comparison point — not closing the question.

---
*Capture produced 2026-07-07. All five source URLs (arXiv:2606.10241, platform.claude.com/docs/en/managed-agents/dreams, github.com/emson/elfmem, github.com/eugeniughelbur/obsidian-second-brain, arXiv:2606.24775) independently confirmed resolving via WebFetch on 2026-07-07. The Zhou et al. quoted phrase was additionally cross-confirmed via a separate WebSearch pass returning the source paper as the top result for the exact string. Not promoted yet — candidate claim-notes: a refinement to [[claim-activegraph-rebuilds-babyagi-on-event-log]] (Claim 1's corrected exact quote), an update to [[entity-ben-emson]] (Claim 3's decay-tier figures), a new claim-note for Ghelbur's five-phase nightly pass (Claim 4), and a new claim-note for the localized-vs-global cost-efficiency finding (Claim 5) once its latency figures are independently verified against the primary figure rather than an AI-summarized read.*