Evidence, not trust

Provenance and the hash chain

Every write gets a chained SHA-256 entry per tenant. Edits and truncation both fail verification.

Two separate things

Provenance answers “does this memory state where it came from?” A stated source is stored verbatim and labelled declared / source_attached. No source is labelled unattributed / unverified. Neither label is a trust score; a declared source can still be wrong.

The chain answers “was this record changed after it was written?” Each tenant has its own SHA-256 chain, starting from a genesis hash of 64 zeros.

Chain construction

entry_hash = SHA256(
    prev_hash || "|" || payload_sha256 || "|" || owner || "|"
    || memory_id || "|" || action || "|" || timestamp
)

What verification catches

• Edit. Changing any stored field or payload_sha256 breaks the entry_hash at that position; broken_at names the entry.
• Reorder. prev_hash no longer matches the preceding entry.
• Truncation. Deleting the newest entries leaves a *valid prefix*, so a walk alone still passes. verify_chain(owner, expected_head=...) compares against a head you recorded earlier and fails when it does not match. AETHER-33 records the head in GET /stats so a caller can pin it.
• Cross-tenant splicing. The owner is inside the hash input, so an entry cannot be moved between tenants and still verify.

What it does not prove

A chain proves the record was not changed *after the fact*. It does not prove the author was honest, that the source exists, or that a human reviewed it. It is tamper-evident, not truth-guaranteeing. A party that controls the database and every recorded head can rewrite history consistently; pinning heads outside this service is what closes that gap.