Module consent 

Consent receipts — the durable, audit-grade record of a granted egress permission (docs/context-reuse.md §3).

A boolean consent flag answers “is this provider allowed?” in the moment it is asked, inside a process that will exit. It cannot answer the question an auditor actually asks months later: “what left the machine, to whom, who agreed, and when?” A ConsentReceipt is that answer — consent as an artifact rather than an event.

Like UsageReport, a receipt is a host-side artifact, not a wire message: it rides no envelope variant, and a provider implements nothing to make one possible. It lives here rather than in the host crate for the same reason the usage report does — it is a protocol- defined shape. Any host, in any language, that claims to implement the consent guarantee must produce this shape, and any auditor reading a ledger must be able to parse it without depending on one particular host implementation. The gate that consumes receipts (ConsentStore) is host machinery and stays in the host crate.

The receipt pins the provider’s identity at grant time, names an accountable Grantor, and carries an optional expiry. Hosts hold receipts in an append-only ledger: a new grant never edits or erases an old one, so the history of consent is itself the audit trail.

Structs

ConsentReceipt

An audit-grade record that consent was granted for one provider to send content under one egress scope (docs/context-reuse.md §3).

Enums

Grantor

Who granted a consent receipt (docs/context-reuse.md §3). Recorded so the audit trail names an accountable party, not just a moment.