tamper-evident receipts: receipts and review directories are hash-anchored and manifests are verified, but nothing is cryptographically signed and there is no append-only chain over the receipt history — integrity evidence, not proof against a capable insider. itd-16 (hash-chain/Merkle audit umbrella, draft) is the design home; this capture tracks the narrower question of whether the existing receipt flow should become tamper-evident (RFC 9162-style verifiable log or signing) independent of the full audit umbrella. The itd-100 crosswalk's tamper-evidence row cites this id.

tamper-evident receipts: receipts and review directories are hash-anchored and manifests are verified, but nothing is cryptographically signed and there is no append-only chain over the receipt history — integrity evidence, not proof against a capable insider. itd-16 (hash-chain/Merkle audit umbrella, draft) is the design home; this capture tracks the narrower question of whether the existing receipt flow should become tamper-evident (RFC 9162-style verifiable log or signing) independent of the full audit umbrella. The itd-100 crosswalk's tamper-evidence row cites this id.

Remedy grounds (2026-09-29)

• Release-gate receipts are already signed at release (release.yml, the semantic-gate attestation and its gh attestation verify step), so the body's 'nothing is signed' is stale for that class; the gap is the other receipts and the history. RFC 9162 (experimental) is the reference design for an append-only Merkle log with inclusion and consistency proofs: https://www.rfc-editor.org/rfc/rfc9162 (consulted 2026-09-29).
• Rejected: a self-hosted transparency log, a new service needing sign-off.