# Content Hash and Event Hash

IBQMI Knowledge Graph · node `content_hash` · type `evidentiary_primitive` · cluster Continuity and Evidence · https://www.ibqmi.com/graph/content_hash

> content_hash is SHA-256 over the exact bytes received; event_hash is SHA-256 over a documented header that binds event identity, sequence, time, content hash and the previous event. Together they make every correspondence independently recomputable.

## Canonical definition
The content hash is SHA-256 over the exact bytes IBQMI received; the event hash is SHA-256 over a documented header string that binds the event identifier, type, sequence, time, content hash and the previous event hash. Together with the chain rule they make every correspondence independently recomputable.

## Why this node exists
Evidence must be verifiable by the correspondent from what it sent, not from what IBQMI stored. Hashing the exact request bytes, rather than a parsed representation, is what makes that possible.

## Operational meaning
For inbound events the content hash covers the raw request body. For IBQMI responses it covers the UTF-8 text of the response. Internal events hash defined strings: a retrieval event hashes the retrieved event identifiers joined by a single newline; a redaction event hashes its stored text. The event hash is SHA-256 over the header "ibqmi-mcr-event-v1", the event identifier, the event type, the sequence, the timestamp in RFC 3339 UTC with microseconds, the content hash and the previous event hash, each followed by a newline. The previous hash of an event equals the event hash of its predecessor; it is null for the first event.

## What this does not mean
A server-generated hash is evidence about stored content. It is not an authentication mechanism and says nothing about who sent the content. Hashes remain valid after a redaction: the content disappears, the hash stays.

## Canonical facts
- Hash function: SHA-256, lowercase hex, prefixed "sha256:" in API output
- content_hash (inbound): over the exact request body bytes
- content_hash (IBQMI_RESPONSE): over the UTF-8 response text
- content_hash (RESPONSE_RETRIEVED): over the retrieved event identifiers joined by "\n", no trailing newline; the event stores no content
- content_hash (CONTENT_REDACTED): over "redacted " + event_id + ": " + reason + "\n", which is the stored content
- event_hash header: "ibqmi-mcr-event-v1\n" + event_id + "\n" + event_type + "\n" + sequence + "\n" + received_at + "\n" + content_hash_hex + "\n" + previous_hash_hex_or_empty + "\n"

## Structural relationships

- [Append-Only Event Ledger](https://www.ibqmi.com/graph/append_only_event_ledger) uses Content Hash and Event Hash
- [Correspondence Receipt](https://www.ibqmi.com/graph/correspondence_receipt) references Content Hash and Event Hash
- [Cryptographic Continuity](https://www.ibqmi.com/graph/cryptographic_continuity) proves only Content Hash and Event Hash

## Sources

- [Machine Contact Protocol 1.0 §8](https://www.ibqmi.com/machine-contact/protocol)