Content addressing: identity is a hash

In most systems, objects have an identity assigned by a database — a row ID, a UUID, a counter. The identity is arbitrary: two identical objects can have different IDs, and the same ID can point at different content over time. For a system whose core promise is honesty — "you can always trace what you see back to what produced it" — that arbitrariness is the first thing that has to go.

ASSAY's object store (SPEC-01) computes identity from content. An object's content hash is the SHA-256 of its canonical JSON — keys sorted, whitespace normalised, no non-deterministic formatting. Two objects with the same content produce the same hash; a one-character edit produces a completely different one. There is no update and no delete (knowledge model §2).

Try it: edit the object, watch the hash change

Edit the JSON below. The hash recomputes live using the real algorithm — SHA-256 over canonical JSON (sorted keys, normalised whitespace). Same content always produces the same hash; change one character and the hash is completely different.

Illustrative widget, real rule. The hash uses the browser's native crypto.subtle.digest('SHA-256', …) — the same API the shipped store uses. Keys are sorted to produce canonical JSON. Try swapping key order: the hash stays the same. Frozen as shipped on 2026-07-11.

Why it is load-bearing

Content addressing is the foundation of every honesty invariant above it. Determinism (G1): two compiles over the same knowledge produce the same stamp because stamps hash content hashes, not row IDs. Traceability (G3): a trace edge names a content hash, not a mutable pointer, so the chain cannot silently retarget. Immutability: there is no in-place edit — a "change" is a new version with a new hash, and the old version stays. The store is small, but it is the root that makes everything above it honest.