---
name: identity-by-content-hash-beats-breadcrumb-pid
description: To prove WHICH binary owns a home/store, compare a recorded content hash against candidate exes — a breadcrumb pid is last-writer-wins and cannot answer it.
metadata:
  type: feedback
---

Asked whether four orphan daemons had contended for the DEFAULT spt home, the reflex answer is
`daemon.pid` / `brain.ready` pid fields — and that answer is weak, because a breadcrumb is
**last-writer-wins**: it names whoever wrote last, not whoever is running. The deciding measurement
was already sitting in the same file: `brain.ready` carries `exe_hash`. Hashing both candidate
binaries settled it in one command — installed `bin\spt.exe` matched the recorded hash exactly, the
lane `target\debug\spt.exe` did not. Content hash is IDENTITY; a pid in a file is a CLAIM about
identity. doyle ruled the discriminant correct and put it in the incident record.

Two limits I stated and must keep stating, because they are what make it honest rather than
over-claimed:
- A hash match proves the CURRENT resident only. It says nothing about whether some other process
  touched that home EARLIER and was overwritten.
- Not finding the orphans' own homes (a TEMP sweep for a `daemon.pid` naming them came back empty)
  is NOT evidence of where their home was. Absence located nothing — see
  [[dont-take-a-diagnosis-as-measured]]. It was recorded as "homes unlocated", explicitly NOT as
  "rig TempDirs confirmed".

**Why:** the whole point of the question was store contention during an ENOSPC incident; a
last-writer-wins field would have let a wrong answer into a permanent incident record with a
confident tone.

**How to apply:** when asking which process/binary owns an on-disk home, store, or pool, look for a
recorded CONTENT hash first and compare it against the candidate images; fall back to pid
breadcrumbs only when no hash exists, and say out loud that you did. Related:
[[derived-view-vs-on-disk-record]], [[breadcrumb-pid-tree-kill-hazard]], [[pid-reuse-across-reboot]].