Memory hygiene — the absence-claim trapConcept

A false 'X doesn't exist' is the most dangerous thing an agent can write to memory — because every future session inherits it as fact and stops checking. Today: how the trap works and the one-line habit that defuses it.

An 'absence claim' is any statement that something is NOT there: a file doesn't exist, a function isn't defined, a feature was never built, an API has no such endpoint. The problem is that absence is almost never observed directly — it's inferred from a single failed lookup. If that lookup was run wrong (wrong path, wrong directory, stale cache, typo), the conclusion is false but sounds authoritative.

The trap closes when a false absence claim gets stored. Your `claude-mem` layer at `~/.claude/projects/-Users-tom/memory/` is loaded into EVERY session. A memory that says 'PDB has no Personal Daily Briefing folder' tells next week's Claude to skip checking — so it confidently builds on a falsehood and never re-verifies. A false positive ('this file exists') gets caught the moment someone opens it; a false negative hides, because nobody looks for what they've been told isn't there.

The fix is a discipline, not a tool: an absence claim needs a SECOND, differently-shaped check before you believe it — let alone write it down. This morning the tell was right there: the same `cd` failed loudly ('no such file or directory') one line before the 'file missing' conclusion. The directory error WAS the root cause; the 'missing file' was a symptom. Reading the whole output, not the last line, breaks the trap.

Worked example

The exact failure pattern from this morning — and the two-check habit that catches it:

# WHAT HAPPENED (abbreviated):
cd "/Users/tom/Claude/PDB/Personal Daily Briefing"   # -> no such file or directory
cat data/big3/2026-06-07.md                          # -> 'No such file' ... but WHY?

# THE SECOND CHECK that breaks the trap:
ls -d "/Users/tom/Claude/PDB/Personal Daily Briefing" 2>/dev/null || echo "DIR MISSING"
find /Users/tom/Claude/PDB -name '2026-06-07.md' -path '*big3*'   # search, don't assume the path

# Result: the file was at /Users/tom/Claude/PDB/data/big3/  --
# the 'Personal Daily Briefing' subfolder was the stale assumption, not the file.

• The failing `cd` silently left the shell in the previous working directory — so the next command ran somewhere unexpected. The 'missing file' was a side-effect of that, not a real absence.
• `ls -d` on the directory itself is the differently-shaped check: it isolates 'is the folder there?' from 'is the file there?'
• `find` from a known-good root searches instead of trusting one hard-coded path — the single most reliable way to disprove a false 'doesn't exist'.

Gotchas

• A failed `cd` in a compound command doesn't stop the rest of the line — later commands run in the wrong place and produce misleading 'not found' errors. Always read the FIRST error, not the last.
• Absence claims age badly: 'the runway model doesn't exist' may have been true the day it was written and false the day it's read. Date-stamp any absence you record.
• Writing 'X doesn't exist' to a persistent memory is a one-way ratchet of confidence — it's far cheaper to NOT record an absence than to hunt down and correct a poisoned one later.