| Internet-Draft | Claim Promotion Receipts | October 2026 |
| Watts | Expires 11 April 2027 | [Page] |
This document defines a protocol-neutral receipt for explicit promotion across evidence and claim-authority boundaries. It is designed to prevent raw observations, model outputs, or unreviewed evidence from being silently retyped as authorization-bearing state.¶
This RFCXML source is an archive working draft and is not represented as submitted, adopted, or endorsed by the IETF.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 11 April 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Many systems carry structurally similar JSON objects through observation, interpretation, evidence, authorization, and execution stages. Structural similarity can enable accidental or adversarial type collapse. This document defines explicit promotion receipts so that evidence can request promotion but cannot promote itself.¶
Profiles SHOULD distinguish ObservationRecord, InterpretationRecord, EvidenceCertificate, AuthorizationGrant, and ExecutionReceipt as separate nominal and verifier domains. An ObservationRecord MUST NOT satisfy a verifier expecting an AuthorizationGrant merely because common fields are present.¶
Registered transformations may be represented as O to I, I to E, E to A, and A to X. Direct O to A or E to X transitions are prohibited unless a profile explicitly defines a different typed transition and its corresponding authority semantics.¶
A profile MAY define maturity classes such as D0 raw observation, D1 validated observation, D2 replicated diagnostic, D3 registered evidence, D4 governance-admissible evidence, and D5 authorization-relevant evidence. The class labels are profile-specific and do not imply universal epistemic rank.¶
A higher class MUST NOT be inferred solely from a lower class. Promotion requires a valid receipt under the registered profile.¶
A receipt SHOULD bind: source digest, source type identifier, source schema version, destination class, procedure digest, environment digest, policy digest, result digest, reviewer identity, reviewer independence status when required, creation time, validity interval, nonce, and signature or equivalent integrity proof.¶
Profiles MAY additionally bind calibration records, uncertainty statements, dataset lineage, overlap declarations, and supersession references.¶
A verifier MUST check type identity, canonical representation where signatures require it, source digest, procedure and policy versions, time validity, reviewer requirements, nonce/replay policy, and signature integrity. Missing required checks MUST fail closed.¶
Verification of a receipt proves only that the registered transition requirements were satisfied according to the verifier. It does not establish that the underlying scientific claim is true or that an authorization decision is optimal.¶
Profiles SHOULD require reviewer independence for transitions that create governance or execution authority. The producer of evidence SHOULD NOT be able to sign the only promotion event that converts its own output into consequential authority when the threat model requires separation.¶
Receipts SHOULD support supersession, contestation, and revocation without deleting historical state. A later event can invalidate the active authority of a receipt while preserving the receipt and its provenance for audit.¶
Implementations MUST consider cross-type substitution, replay, stale-policy acceptance, schema confusion, canonicalization discrepancies, compromised reviewers, signature-key compromise, and unauthorized mutation of destination state. A valid signature is not evidence that the signer was an independent or scientifically competent reviewer unless the profile verifies those properties.¶
Receipts can reveal reviewer identity, dataset lineage, and sensitive policy information. Deployments SHOULD use the minimum information needed for verification and SHOULD support opaque references to protected records.¶
This document has no IANA actions.¶