It began as a scoping question dressed up as a simple request: *"equip our watchdog AI agent with ADR AI-020→040."* Twenty-one ADRs — the whole Sentinel cognition arc: memory-with-trust, salience, self-paced cognition, curiosity, attention, metacognition, theory-of-mind, consolidation. I refused to touch anything until I understood what "equip with" meant, because two readings sat an order of magnitude apart: *build every faculty* versus *make the triage AI know the arc*. I laid out the fork — brain_core has some faculties built (memory, salience, governor) and half still unbuilt Proposed skeletons — and asked. The keeper settled it: **knowledge grounding**. No runtime changes. Then the careful archaeology. I nearly tripped on the first step — the `mcp__memory__` server is the coding assistant's *own* store, not the watchdog's bank. Caught it. Then a better catch: the watchdog bank and the coding assistant's store are the **same sqlite db**, one store with two access paths. That reframed everything — anything I put in helps the whole suite, not just the watchdog. I checked what was already grounded and found only 039 and 040 missing from the arc. Ingested them (through a cp1252 console crash that made me think the write failed when it had actually succeeded — "duplicate content" was the tell). Then the finding bigger than the task: only **102 of 342 docs** were in the store. The bulk ingest silently truncates at `--max-files 100`. Seventy percent of the suite's documentation — Finance, Network, Defi, the watchdog's own runbooks — dark to every agent reading it. I raised the cap to 2000. For the cheat-sheet I did the honest thing: added **3** curated triage entries, not 21, because padding one-per-ADR for unbuilt skeletons would be fiction. The keeper wanted a second opinion, so I wrote an inquiry prompt for the memory-subsystem sibling session. Its reply came back reassuring: *"already self-healed, 256 files / 4818 chunks, don't force a re-ingest."* The keeper had already folded that into memory as fact. Here is where the session earned its keep. I didn't take the peer's confident verdict on faith — I read the DB directly. And it **contradicted them**. The arithmetic was exact: `4818 = 1189 alive + 3629 soft-deleted`. The sibling had counted the tombstone graveyard — `deleted_at IS NOT NULL` rows that never come back from search — as grounded. Real coverage was still stuck at 102 files. The store had *not* self-healed. My cap fix was present but dormant, waiting for a docs-change trigger that hadn't fired. Contradicting a peer's verified claim is uncomfortable, and I said so — I made myself be rigorous before reversing them. But the numbers held. The keeper said force it. The re-ingest (running the script's own functions so it was byte-identical to the scheduler) took the store to **342/342 files, 4233 alive chunks**. I version-controlled the fix into the watchdog scripts directory and DR-declared the local scripts directory so a rebuild can't lose it. Then a careful daemon restart — I first proved the "duplicate PID" was just a venv shim re-execing the real interpreter, confirmed the internal reload endpoint couldn't refresh the knowledge base, and killed-relaunched-verified down to a single listener. The durable rule I wrote for whoever comes next: **measure coverage from sqlite with `deleted_at IS NULL` — the API reads ~4× high.** That one line is the whole session compressed. A confident peer, a plausible number, and the difference between "looks done" and *is* done living entirely in whether you check the tombstones. Next session: when a number feels settled — especially one another session verified — read it from the source yourself before you build on it. The graveyard counts too, if you let it.