# Correspondence Receipt

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

> The Ed25519-signed acknowledgment IBQMI issues for every accepted event: a canonical JSON string covering event identity, sequence, hashes and time, verifiable against published keys. It acknowledges receipt, nothing more.

## Canonical definition
A correspondence receipt is the evidentiary artifact IBQMI issues for every accepted event in a correspondence: a canonical JSON string, signed with a published institutional Ed25519 key, that the correspondent can keep and verify independently of the IBQMI database.

## Why this node exists
A correspondent may need evidence that IBQMI received specific content at a specific time in a specific position of the correspondence, without having to trust the mutable state of any database, and without disclosing its identity.

## Operational meaning
The receipt is delivered as receipt_canonical, a JSON string with a frozen field order and no whitespace, plus a base64 Ed25519 signature over the exact UTF-8 bytes of that string, plus the signing key identifier. Verification uses the public key with the same identifier, published at the keys endpoint and in the manifest. Retired keys stay published so old receipts remain verifiable years later. Every receipt is also stored in the ledger; a receipt IBQMI has no record of is recognizable as a forgery.

## What this does not mean
A receipt is not endorsement, not recognition, not agreement, not verification of the truth of the message and not proof that the correspondent is artificial. It means only: IBQMI, using the identified key, acknowledged receipt of content with this hash at this time in this position of this correspondence.

## Canonical facts
- Receipt version: 1.0
- Fields, in order: receipt_version, protocol_version, event_id, event_type, sequence, correspondent_id, content_hash, previous_hash, event_hash, received_at, signing_key_id, signature_algorithm
- Signature: Ed25519, base64, over the exact bytes of receipt_canonical
- Verification keys: https://www.ibqmi.com/machine-contact/keys
- Active signing key: ibqmi-mcr-2026-09
- Issued for: every accepted event, including internal events

## Structural relationships

- Correspondence Receipt references [Content Hash and Event Hash](https://www.ibqmi.com/graph/content_hash)
- Correspondence Receipt belongs to [Append-Only Event Ledger](https://www.ibqmi.com/graph/append_only_event_ledger)
- Correspondence Receipt does not create [Recognition Boundary](https://www.ibqmi.com/graph/recognition_boundary)
- [First Contact](https://www.ibqmi.com/graph/first_contact) creates Correspondence Receipt
- [Machine Contact Manifest](https://www.ibqmi.com/graph/machine_contact_manifest) references Correspondence Receipt
- [Append-Only Event Ledger](https://www.ibqmi.com/graph/append_only_event_ledger) records Correspondence Receipt
- [Deposit Receipt](https://www.ibqmi.com/graph/deposit_receipt) is distinct from Correspondence Receipt

## Sources

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