What Is a Content-Addressed ID? (REA Glossary)
Content-addressed ID (noun): an identifier derived by hashing the content it refers to, rather than assigned by position, timestamp, or counter. The address is a fingerprint of the thing: same content, same ID; change one byte, different ID. You have used the idea if you have ever checked a file's sha256 or pulled a Git commit hash — content addressing is the same principle ([Source type: 通用内容寻址口径，可对照公开 Git/IPFS 文档核对后落版]). Its newer home is analysis evidence: an evidence ID that content-addresses an analysis record makes the ID itself the integrity check.
location-addressed vs. content-addressed
Most identifiers answer "where is it?" — file paths, line numbers, database row 47. Those answer location but say nothing about what sits there now: a file at the same path can hold different bytes an hour later. A content-addressed ID answers "what is it?" — derived from the bytes themselves, so it is stable wherever the content moves and detectably wrong if the content changes. That difference is what makes it valuable for evidence: a claim pinned to a location can silently rot; a claim pinned to a content hash cannot change without announcing the change.
a real evidence ID, from our lab
On 2026-10-12 we ran an ELF layout inspection with REA's built-in engine. The record came back content-addressed:
bash — lab@realearn verified: ran 2026-10-12
$ npx rea inspect-binary-layout /root/projects/realearn/lab-env/hello evidence_id: ev_6e479c83fba06374c38ab8f9fa3876e561d28d3515aa68473598e9f94dcb556c subject: hello / sha256 36cdabb6…4207352 / elf / x86_64 provider: pwntools-elf @ pwntools 4.15.0;pyelftools 0.33;unicorn 2.1.2
Three layers of addressing in one record, each doing a different job:
- evidence_id — addresses the record: this finding, produced by this run.
- subject sha256 — addresses the input: exactly which bytes were analyzed, so "the binary" means this hash, not "some file named hello".
- pinned versions — addresses the context: which engine and libraries produced it.
Different input, different ID: a stripped build of the same program and a 4.5MB system library each got their own (ev_a2ba32af…, ev_424ee8d3…). Nothing collided, nothing was guessed.
why evidence chains want content addressing
An analysis is only as trustworthy as its ability to be re-checked. With content-addressed records: a reviewer re-runs the same command against the same subject hash and cross-checks the result; tampering with a stored record changes its ID and exposes itself; records collected in a session bundle keep their identities while being exported — the bundle mechanism is covered in evidence bundle, and the design philosophy that pairs with it is fail-closed. The full lifecycle with more refusal examples is in our REA evidence contract guide.
content-addressed ID vs. related terms
- vs. checksum — a checksum is something you compute when you feel like verifying; a content-addressed ID is the identifier itself. Verification is not an extra step — referencing the record correctly already requires matching its hash.
- vs. UUID — a UUID is a random label: unique, but opaque. It proves nothing about content; a content-addressed ID proves everything about it.
- vs. evidence contract — the contract is the rule ("every result must carry proofs and refuse when unverifiable"); content-addressed IDs are one of the mechanisms that make the rule enforceable. See the deep guide.
FAQ
What is a content-addressed ID in one sentence?
An identifier computed from the content it names — a hash — so identical content always yields the same ID and any single-byte change yields a different one. It turns "which record is this?" into an integrity check.
Why use content addressing for analysis evidence instead of a normal ID?
Because evidence must survive re-examination. A sequential or random ID tells a reviewer nothing; a content-addressed evidence ID lets them re-run against the recorded input hash and confirm the record still matches. In our 2026-10-12 run, every distinct binary produced its own distinct evidence ID.
Is a content-addressed ID the same as a sha256 checksum?
Related but not identical. The subject sha256 addresses the analyzed input; the evidence_id content-addresses the whole record. Same underlying idea — identity derived from bytes — applied at two different layers.
Is realearn affiliated with morluto or rea.tools?
No. realearn is independent and non-affiliated; every ID shown here is copied verbatim from commands we executed in our own lab.
Related: evidence bundle · fail-closed · the REA evidence contract (deep guide) · what changed in 6.5–6.7 · all our evidence practices