A Research Evidence Bundle JSON Envelope for Provenance and Replication Metadata

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.

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.

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

Record Requirements

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.

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.

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.

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.

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.

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.

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.

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.