A Research Evidence Bundle JSON Envelope for Provenance and Replication Metadata
draft-watts-research-evidence-bundle-01

Individual Submission                                        D. O. Watts
Internet-Draft                                       GoodShyt Group Inc.
Intended status: Informational                           30 October 2026
Expires: 3 May 2027

A Research Evidence Bundle JSON Envelope for Provenance and Replication
                                Metadata
                draft-watts-research-evidence-bundle-01

Abstract

   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.

Status of This Memo

   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 3 May 2027.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Watts                      Expires 3 May 2027                   [Page 1]
Internet-Draft          Research Evidence Bundle            October 2026

   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.

Table of Contents

   1.  Status of This Memo . . . . . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Record Requirements . . . . . . . . . . . . . . . . . . . . .   3
     4.1.  Required Fields . . . . . . . . . . . . . . . . . . . . .   3
     4.2.  Methods, Falsifiers, and Replication  . . . . . . . . . .   3
     4.3.  Confidence and Novelty  . . . . . . . . . . . . . . . . .   4
   5.  Integrity and Canonicalization  . . . . . . . . . . . . . . .   4
   6.  Privacy and Data Governance . . . . . . . . . . . . . . . . .   4
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   9.  Open Issues and Next Steps  . . . . . . . . . . . . . . . . .   5
   10. Normative References  . . . . . . . . . . . . . . . . . . . .   5
   11. Informative References  . . . . . . . . . . . . . . . . . . .   5
   Appendix A.  Changes since -00  . . . . . . . . . . . . . . . . .   5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Status of This Memo

   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.

2.  Introduction

   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.

Watts                      Expires 3 May 2027                   [Page 2]
Internet-Draft          Research Evidence Bundle            October 2026

3.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   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.

4.  Record Requirements

4.1.  Required Fields

   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.

4.2.  Methods, Falsifiers, and Replication

   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.

Watts                      Expires 3 May 2027                   [Page 3]
Internet-Draft          Research Evidence Bundle            October 2026

4.3.  Confidence and Novelty

   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.

5.  Integrity and Canonicalization

   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.

6.  Privacy and Data Governance

   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.

7.  Security Considerations

   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.

Watts                      Expires 3 May 2027                   [Page 4]
Internet-Draft          Research Evidence Bundle            October 2026

8.  IANA Considerations

   This individual proposal makes no IANA request.  Any future protocol
   version that requires a registry would need a separate registry
   policy and expert review.

9.  Open Issues and Next Steps

   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.

10.  Normative References

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

11.  Informative References

Appendix A.  Changes since -00

   This section is to be removed before publishing as an RFC.

   Editorial and tooling-conformance changes only; no technical content
   was changed.

   *  Added submissionType="IETF" to <rfc>

   *  Replaced Requirements Language paragraph with the exact BCP 14
      (RFC 8174) boilerplate (idnits)

   *  Added RFC 2119 reference entry

   *  Added RFC 8174 reference entry

   *  Removed unreferenced bibliography entries (xml2rfc/idnits "unused
      reference"): RFC8259, RFC8785, RFC3339, BCP14, PROVO, RFC5378,
      RFC7991, RFC8493, ROCRATE, FRICTIONLESS

Watts                      Expires 3 May 2027                   [Page 5]
Internet-Draft          Research Evidence Bundle            October 2026

   *  Normalized author metadata (full name with ASCII form, initials,
      organization GoodShyt Group Inc., San Francisco CA postal, email,
      ORCID URI)

   *  Updated document date and revision number.

Author's Address

   Deonté O'dell Watts
   GoodShyt Group Inc.
   San Francisco, CA
   United States of America
   Email: deonte@goodshyt.fun
   URI:   https://orcid.org/0009-0005-8586-3650

Watts                      Expires 3 May 2027                   [Page 6]