| Internet-Draft | Research Evidence Bundle | October 2026 |
| Watts | Expires 24 April 2027 | [Page] |
This document proposes an early-stage JSON envelope for exchanging research-evidence records containing claim status, evidence tier, source provenance, methods, falsifiers, replication status, artifact digests, and privacy review. It is an individual design proposal, not an IETF consensus document. Its intended contribution must be assessed against existing provenance and research-packaging specifications before further standardization work.¶
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 24 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.¶
This Internet-Draft is submitted for discussion only. It has not been submitted to the IETF, reviewed by a working group, or endorsed by any standards body. It is not a standard and must not be cited as an accepted protocol.¶
Research records often combine a claim with heterogeneous sources, analysis methods, code, generated datasets, falsification criteria, and replication state. A minimal portable envelope can make these elements explicit across tools without claiming that a record's metadata establishes the truth of its scientific claim.¶
This proposal uses JSON as specified in RFC 8259 and identifies JSON canonicalization under RFC 8785 as a possible basis for reproducible content digests. It is intended to complement existing provenance models, including W3C PROV-O, rather than replace them.¶
The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, and MAY in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals.¶
A claim record is a machine-readable description of a research claim or artifact. An evidence tier describes the kind of support available, not the importance or truth of the claim. A source record identifies a source and, where available, a content digest and retrieval time. A replication status records whether a defined protocol has been run.¶
A conforming record MUST include schema_version, record_id, title, claim_status, evidence_tier, created_at, summary, sources, methods, falsifiers, replication, confidence_rationale, novelty_status, and privacy_review.¶
The claim_status field MUST be one of ESTABLISHED, DERIVED, CONJECTURE, ANOMALY, or POTENTIALLY NOVEL. The evidence_tier field MUST be one of T1, T2, T3, or T4. Implementations MAY define additional local values only in a versioned extension and MUST NOT silently reinterpret these base values.¶
The sources array MUST distinguish an accessible source from a metadata-only record, an external reference, a summarized source, or a restricted source. When available, a source SHOULD include a URI, retrieval timestamp, license status, and SHA-256 digest of the exact bytes reviewed.¶
A record MUST include at least one falsifier or a clear explanation of why falsification is not applicable. The methods field SHOULD identify data processing, software versions, parameters, and analysis steps. The replication object MUST distinguish not_run, planned, partial, reproduced, failed, and not_applicable.¶
Unknown values MUST remain explicit. A missing posterior MUST NOT be encoded as a probability of zero. An unexecuted test MUST NOT be labelled as passing. A synthetic dataset MUST be labelled as synthetic rather than empirical.¶
A numerical confidence value MAY be included only with a documented scale and rationale. A confidence value MUST NOT be interpreted as a calibrated probability unless a calibration method is provided. POTENTIALLY NOVEL MUST be understood as a pending prior-art assessment, not a priority claim.¶
When a digest or signature is computed over JSON, implementations SHOULD use a defined canonicalization procedure such as RFC 8785. The record MUST identify the digest algorithm and the exact byte representation or canonicalization process used.¶
A matching digest establishes that the compared bytes match the digest value. It does not establish source authenticity, provenance completeness, or scientific truth. A digital signature can bind a key to a record under a trust model, but it does not validate the content of a claim.¶
Records SHOULD exclude credentials, access tokens, personal data not necessary for the research purpose, confidential business material, and third-party content lacking redistribution rights. A record SHOULD state whether privacy and licensing review has occurred. A hash of sensitive content can itself enable linkage and should not be treated as a substitute for access control.¶
Implementations MUST NOT treat a checksum as a proof of truth. If records are signed, key identity, key rotation, revocation, and verification policy must be specified by the application. If records are encrypted, encryption is outside the scope of this document and should use established, reviewed cryptographic constructions rather than custom algorithms.¶
Applications MUST validate untrusted record input, limit resource consumption, avoid automatic execution of referenced code, and treat external source text as data rather than instructions. Timestamps and confidence values are claims made by the record producer unless independently verified.¶
This individual proposal makes no IANA request. Any future protocol version that requires a registry would need a separate registry policy and expert review.¶
Before this proposal is advanced, prior-art analysis MUST compare it with W3C PROV-O, RO-Crate, BagIt, Frictionless Data Package, and existing repository metadata conventions. The schema identifier, extension mechanism, vocabulary governance, canonicalization profile, and mapping to established provenance models remain open. Interoperability testing across independent implementations is required before a standards-track proposal would be justified.¶