Bad candidates and residue

A memory system is only useful if it refuses junk. UnifiedMemory separates actionable memory claims from residue before they reach recall or human review.

Actionable memory

Good candidates are atomic, grounded, and useful later:

• explicit owner preferences;
• project decisions;
• completed tool outcomes;
• durable setup facts;
• narrow recurring failure/fix patterns;
• approved observations backed by clean evidence.

Example:

{
  "content": "The owner prefers MiniMax-backed search first for factual/current queries.",
  "source": "codex",
  "memory_plane": "task",
  "tags": ["search", "preference"]
}

Forensic residue

Residue stays auditable but should not invite an Approve button and should not enter assistant recall:

Input	Default treatment
hey, thanks, thumbs up	Forensic residue or skipped writeback.
Full assistant answer dumps	Quarantine or forensic residue unless an atomic owner/project/tool outcome is extracted.
Generic web facts	Suppressed unless tied to an owner decision or project state.
Setup prose copied from an assistant	Quarantine until an actual completed setup outcome exists.
System lifecycle logs	Ops-only, not Review.
Smoke/e2e/benchmark/diag/eval rows	Forensic-only.
Secret-like strings	Quarantine or deny-secret, never trusted.
Raw transcripts	Evidence only; extract useful atomic claims separately.

Human review boundary

needs-review means a human has a real decision to make about an atomic claim. It does not mean "anything pending." Quarantine, ops noise, cognitive placeholders, and proof rows are separate buckets.

Why this matters

Without this boundary, agents slowly poison their own future prompts with status chatter, test data, stale setup instructions, and generic summaries. The right failure mode is zero trusted recall, not confident recall of junk.

Next steps

• Use Retain for atomic facts.
• Use Agent writeback for post-turn capture.
• Cross-examine memory with Courtroom.