Independent Researcher

San FranciscoCAUSdeonte@goodshyt.funhttps://orcid.org/0009-0005-8586-3650

SecurityIndividual Submission 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.

IntroductionMany 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.

Non-Collapse Model 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.

Evidence Maturity Classes 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.

Promotion Receipt Fields 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.

Verification 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.

Independent Review 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.

Revocation and Supersession 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.

Security Considerations 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.

Privacy ConsiderationsReceipts 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.

IANA ConsiderationsThis document has no IANA actions.

References