Skip to main content

Consolidation policy

Memory quality is not only a retrieval problem. If the store keeps accumulating transcripts, stale task notes, duplicated facts, and unresolved contradictions, retrieval eventually becomes a ranking contest between junk and truth.

UnifiedMemory treats consolidation as a governed control loop with four levers: importance, merge, decay, and eviction.

Lever 1: importance at write time

Retain/writeback classifies content before it becomes assistant-facing memory.

High-importance candidates are usually:

  • explicit owner preferences;
  • project decisions;
  • durable setup facts;
  • completed tool outcomes;
  • recurring fixes with clear evidence;
  • supported observations that changed future behavior.

Low-importance or evidence-only candidates include:

  • greetings and acknowledgements;
  • emoji-only or filler messages;
  • assistant answer dumps;
  • raw transcripts;
  • lifecycle/proof/eval/smoke rows;
  • generic web facts unrelated to the owner or project;
  • secret-like payloads.

Low-importance does not mean "delete." It means archive, quarantine, or forensic-only unless an extractor finds a clean atomic claim.

Lever 2: merge and supersession

New facts should not silently overwrite older facts. They should become one of:

OutcomeMeaning
supportingAdds evidence for an existing current fact.
supersedingReplaces an older fact for current recall.
contradictoryRequires review or Courtroom inspection.
duplicateLinks to the canonical fact and suppresses redundant prompt use.
evidence_onlyPreserved as source material but not injected.

Current recall prefers the latest valid canonical fact. Historical queries can retrieve older facts, but they should be labeled as historical.

Lever 3: decay

Decay is not "newer always wins." Recency is useful only after relevance, scope, lifecycle, and trust gates pass.

UnifiedMemory applies different decay pressure by lane:

  • durable canonical owner/project/tool facts stay eligible until superseded, deprecated, rejected, invalid, or made forensic;
  • task captures and working/session rows age out of normal assistant recall unless promoted or refreshed;
  • pending review rows can auto-decay to suppressed rather than lingering as fake human decisions;
  • graph relationships may lose weight as evidence becomes stale.

The right failure mode is quiet abstention, not stale confident context.

Lever 4: eviction as audit-preserving suppression

Eviction is a last resort and should be audit-preserving. UnifiedMemory favors:

  • suppressed;
  • forensic_only;
  • resolved_forensic_residue;
  • archived;
  • explicit tombstones for forget/delete flows.

Production memories are not silently hard-deleted as part of quality repair. Controlled proof rows can be cleaned up only when the proof explicitly marks them as disposable.

How this maps to recall

Consolidation feeds recall by keeping the hot candidate set clean:

Current/temporal state is validity metadata. It can select the right version of a relevant fact, but it cannot make an unrelated fact relevant.

Tunable policy surface

Some knobs are already runtime-backed and visible in diagnostics:

  • system minimum recall relevance;
  • strict vs balanced trust policy;
  • stale working/task suppression;
  • profile topic caps;
  • MMR diversification for search;
  • review auto-decay;
  • forensic namespace firewalls.

Future tenant-level policy should expose these as named presets rather than raw scorer constants:

PresetUse case
strictAgent prompt context, MCP, gateway, and default production recall.
balancedOperator search and review where caution facts are useful.
forensicAdmin debugging, proof artifacts, and audit views only.

Known gaps

  • Mesh degraded timeout responses are bounded and safe, but the reliability target is still healthy multi-agent context without fallback.
  • Some importance/decay weights are currently internal settings rather than a public policy object.
  • Google Memory Bank revisions are evidence and comparison state; they do not replace UM consolidation or trust gates.

Next steps