Receipt Standards Position

Signed denial evidence should be stable, verifiable, and honest about what it proves.

CFA's DeniedCapabilityReceipt/v1 is a signed record that a local policy denied a proposed action. We publish the schema, ship an offline verifier, and track emerging IETF attestation-receipt work without mutating installed receipt evidence while the draft is still moving.

Current Position

DCR v1 stays stableCFA will not break the DeniedCapabilityReceipt/v1 wire format for current protected bundles while draft receipt formats are still work in progress.
Verifier remains narrowThe standalone verifier proves receipt integrity under the embedded key and key id. It does not prove legal compliance, model quality, or runtime safety beyond the signed denial record.
Projection, not mutationFuture standards-facing work should use fabricledger/attestation-receipt-projection/v1 so original DCR bytes remain byte-for-byte verifiable.

IETF Alignment

ADR-002 compares CFA DCR fields against draft-chueayen-attestation-receipts-01, published 25 July 2026, and records the align/submit/track/ignore decision per field. The comparison treats the draft as work in progress and keeps CFA's current buyer-facing claims limited to signed denial evidence and offline verification.

Area CFA posture
Field alignmentMap trace, receipt id, payload hash, outcome, timestamp, public key, and signature semantics through a future projection layer.
Submit / trackTrack optional policy hash binding, denial reason/detail, tool or destination denials before model selection, and issuer identity versus embedded-key integrity.
PreserveKeep CFA-specific denial fields such as denied_capability, attempted_resource, policy_hash, audit_chain, and host_enforcement_proof.

Evidence Links

Boundary

CFA does not claim that DCRs are an IETF standard, that the current verifier proves issuer identity beyond the trusted-key process, or that receipt verification alone proves legal compliance.