<?xml version="1.0" encoding="UTF-8"?>
<rfc version="3" category="info" docName="draft-watts-research-evidence-envelope-00"
     ipr="trust200902" submissionType="independent" xml:lang="en">
  <front>
    <title>Research Evidence Envelope: A Provenance-Oriented Interchange Record</title>
    <author fullname="Deonté O’dell Watts" initials="D." surname="Watts">
      <organization>GoodShyt Group Inc. (author-supplied affiliation)</organization>
      <address><email>deonte@goodshyt.fun</email></address>
    </author>
    <date year="2026" month="October" day="21"/>
    <area>General</area>
    <workgroup>Independent Submission</workgroup>
    <keyword>provenance</keyword><keyword>research data</keyword><keyword>JSON</keyword>
    <abstract><t>This informational scaffold sketches a versioned record for tracking scientific claims, source provenance, evidence classes, uncertainty, falsifiers, replication procedures, and artifact hashes. It is not an IETF standard, has not undergone IETF review, and does not define a wire protocol.</t></abstract>
  </front>
  <middle>
    <section anchor="status" numbered="true">
      <name>Status and scope</name>
      <t>This document is a working proposal. The format is intended for local archives and possible future interoperability review. It must not be represented as an IETF-approved specification.</t>
    </section>
    <section anchor="motivation" numbered="true">
      <name>Problem statement</name>
      <t>Research archives frequently separate claims, citations, code, datasets, test results, and revision history. A compact record can link these items while preserving uncertainty and provenance. This proposal is a data model only; it does not prescribe transport, registry, trust authority, or a scientific evaluation method.</t>
    </section>
    <section anchor="record" numbered="true">
      <name>Record fields</name>
      <t>A record SHOULD include a stable identifier, title, project identifier, claim class, evidence tier, source references, timestamp, revision, uncertainty statement, falsifier, replication protocol, status, and artifact hashes where available. Unknown fields SHOULD remain unknown rather than be inferred.</t>
      <t>Suggested claim classes are ESTABLISHED, DERIVED, CONJECTURE, ANOMALY, and POTENTIALLY_NOVEL. These labels are descriptive metadata, not certification. Suggested evidence tiers are T1 empirical, T2 derived, T3 rigorous conjecture, and T4 speculative. Implementations may add values using a documented extension mechanism.</t>
      <sourcecode type="json"><![CDATA[
{
  "schema_version": "1.0",
  "record_id": "MCDS-FP-001",
  "title": "Third-generation flavor portal extension",
  "claim_class": "CONJECTURE",
  "evidence_tier": "T4",
  "sources": ["conversation:2026-10"],
  "claim": "A flavor portal could connect a hidden sector to semitauonic B decays.",
  "uncertainty": "No explicit Lagrangian or global fit supplied.",
  "falsifier": "A validated joint fit excludes all viable coupling regions.",
  "replication_protocol": "Define interactions; match EFT; run RG; fit correlated observables.",
  "status": "conceptual",
  "artifacts": []
}
]]></sourcecode>
    </section>
    <section anchor="security" numbered="true">
      <name>Security and privacy considerations</name>
      <t>Records may expose unpublished research, personal information, credentials, proprietary source code, or sensitive experimental data. Implementations MUST avoid publishing secrets and MUST apply access controls appropriate to the data. Hashes support integrity checks but do not establish source truth, authorship, or scientific validity. Signatures, if added, require key-management and revocation rules.</t>
    </section>
    <section anchor="integrity" numbered="true">
      <name>Integrity and scientific limitations</name>
      <t>A provenance record does not prove a claim. Evidence classes and confidence labels are self-reported unless supported by review procedures. Dataset versions, analysis code, dependencies, random seeds, and negative results should be retained when applicable. Novelty and priority claims require independent prior-art review.</t>
    </section>
    <section anchor="iana" numbered="true">
      <name>IANA considerations</name>
      <t>This scaffold requests no IANA actions.</t>
    </section>
    <section anchor="next" numbered="true">
      <name>Open issues</name>
      <t>Open issues include schema formalization, canonical JSON serialization, controlled vocabularies, extension handling, artifact-signature format, privacy classification, retention, interoperability tests, and whether a genuine community need exists.</t>
    </section>
  </middle>
  <back>
    <references title="Informative References">
      <reference anchor="RFCJSON"><front><title>JavaScript Object Notation (JSON) Data Interchange Format</title><author><organization>Internet Engineering Task Force</organization></author><date year="2017" month="December"/></front><seriesInfo name="RFC" value="8259"/><format type="HTML" target="https://www.rfc-editor.org/rfc/rfc8259"/></reference>
    </references>
  </back>
</rfc>
