Internet Engineering Task Force D. Watts Internet-Draft Independent Researcher Intended status: Informational 1 September 2026 Expires: 5 March 2027 Scientific Admissibility Evidence Records for Verifiable Research Provenance draft-watts-scientific-admissibility-evidence-00 Abstract This document describes a portable JSON evidence-record format for representing bounded scientific claims, preregistered procedures, admissibility evaluations, provenance artifacts, lifecycle events, and cryptographic integrity metadata. The format is intended to make research evidence exchangeable and mechanically checkable without treating cryptographic integrity, schema conformance, scientific admissibility, valuation, governance, or truth as equivalent concepts. This document is an individual informational proposal. It does not define a network transport protocol, does not establish scientific truth, and does not assign decision authority to automated systems. 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 5 March 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Watts Expires 5 March 2027 [Page 1] Internet-Draft Scientific Admissibility Evidence Record September 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 3. Design Requirements . . . . . . . . . . . . . . . . . . . . . 3 4. Record Model . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Scientific Consistency Invariants . . . . . . . . . . . . . . 4 6. Canonicalization and Integrity . . . . . . . . . . . . . . . 5 7. Append-Only Event Semantics . . . . . . . . . . . . . . . . . 5 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 9. Interoperability Considerations . . . . . . . . . . . . . . . 6 10. Security Considerations . . . . . . . . . . . . . . . . . . . 6 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 13. Implementation Status . . . . . . . . . . . . . . . . . . . . 7 14. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 7 15. Normative References . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction Research governance systems increasingly exchange machine-readable claims, executable analyses, provenance records, and integrity metadata. Interoperability becomes difficult when a single boolean such as "valid" is used to collapse distinct questions: whether a document is structurally well formed, whether its bytes are intact, whether its declared scientific procedure satisfies registered admissibility gates, whether a result has practical value, whether a governance consequence is authorized, and whether a proposition is true. This document specifies a record model that keeps those layers separate. A conforming implementation can validate record structure and integrity and can evaluate explicitly declared cross-field invariants. It MUST NOT infer scientific truth merely from successful serialization, signature verification, or schema validation. Watts Expires 5 March 2027 [Page 2] Internet-Draft Scientific Admissibility Evidence Record September 2026 2. Conventions and 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 when, and only when, they appear in all capitals, as shown here [RFC2119] [RFC8174]. Evidence Record A JSON object containing a claim, procedure, evaluation, artifacts, actors, lifecycle state, and ordered events. Admissibility A decision produced by declared scientific gates. It is distinct from valuation, governance, and truth. Artifact A referenced file or byte sequence, such as analysis code, executable notebook, data product, or result object. Event Core The event fields covered by canonicalization and digest computation, excluding the integrity object itself. 3. Design Requirements A conforming profile SHOULD satisfy the following requirements: * Structural validation and scientific consistency checks are separate operations. * Cryptographic integrity proves consistency of recorded bytes and event history, not scientific correctness. * Failed or underpowered designs remain representable without being converted into exclusions. * Automated interpretation MAY assist review but MUST NOT silently become the authoritative research record. * Normative consequences MUST be derived from explicit state transitions and registered predicates. 4. Record Model An evidence record is encoded as a JSON object as defined by [RFC8259]. Profiles of this specification SHOULD define a machine- readable structural schema. The top-level record contains the following conceptual members: * schema_version: record-format version. Watts Expires 5 March 2027 [Page 3] Internet-Draft Scientific Admissibility Evidence Record September 2026 * record_id: stable identifier for this record. * claim: bounded observable claim and lineage. * registered_model: model family, hypotheses, parameters, assumptions, and prediction fingerprint. * parameter_regions: search, power, and refutation regions. * registered_procedure: preregistered decision procedure and calibration declarations. * admissibility_evaluation: binding gate results and evidence references. * valuation: optional non-authoritative valuation information. * governance: optional consequence predicates and verification requirements. * current_state: state derived from the event sequence. * actors, artifacts, and events: provenance and lifecycle information. 5. Scientific Consistency Invariants Structural validity alone is insufficient to claim profile conformance. A profile MAY define additional deterministic cross- field checks. Where the corresponding fields are present, an implementation conforming to the core profile defined here MUST enforce the following invariants: 1. An admissibility evaluation refers to the exact registered procedure being evaluated. 2. A record MUST NOT report admissibility as passing while a binding calibration or power gate is failing. 3. An underpowered null result MUST NOT activate a scientific exclusion. 4. Diagnostics that are declared non-authoritative MUST NOT become autonomous admissibility gates. 5. A predictive revision MUST create a new claim version; a declared prediction-equivalent reparameterization SHOULD preserve claim identity when the profile's equivalence test passes. Watts Expires 5 March 2027 [Page 4] Internet-Draft Scientific Admissibility Evidence Record September 2026 6. A terminal retirement state requiring independent verification MUST NOT be reached before the corresponding verification event. 6. Canonicalization and Integrity When an event digest is used, the event core MUST be serialized using the JSON Canonicalization Scheme (JCS) defined by [RFC8785] before hashing. The event core consists of the sequence number, event identifier, event type, occurrence time, actor identifier, previous-event digest, and event payload. The integrity object is excluded from its own digest to avoid circularity. Profiles using SHA-256 SHOULD represent digests using an algorithm identifier together with the lowercase hexadecimal digest. Profiles using Ed25519 signatures SHOULD follow [RFC8032]. Implementations MUST reject a record when a required digest or signature fails verification. 7. Append-Only Event Semantics Events are ordered by a monotonically increasing sequence number. Except for the initial event, each event MUST reference the digest of the immediately preceding event. A conforming validator MUST reject a discontinuity, reordered event, or digest mismatch when the selected profile requires an append-only chain. Cryptographic linkage does not establish that the recorded event was scientifically justified or factually honest. It establishes that the protected event sequence has not changed without detection under the assumed cryptographic model. 8. Example Watts Expires 5 March 2027 [Page 5] Internet-Draft Scientific Admissibility Evidence Record September 2026 { "schema_version": "0.3", "record_id": "record-example-001", "claim": { "claim_version_id": "claim-example-001", "bounded_observable_claim": "A registered procedure controls the declared error rate.", "observational_domain": "Declared experimental domain" }, "registered_procedure": { "procedure_id": "procedure-example-001", "alpha": 0.05, "beta": 0.10 }, "admissibility_evaluation": { "procedure_id": "procedure-example-001", "status": "pass" }, "current_state": { "lifecycle": "reported" }, "events": [] } The example is intentionally incomplete and is not itself a complete profile-conforming registry record. It illustrates the separation of claim identity, procedure identity, evaluation, and lifecycle state. 9. Interoperability Considerations Producers SHOULD expose the exact profile identifier and version used to validate a record. Consumers MUST NOT silently reinterpret an unknown profile as a known profile. Extension fields SHOULD be namespace-qualified to reduce collisions. External standards references SHOULD identify the exact specification and revision on which an implementation depends. A standards reference is evidence of the applicable interoperability contract; it is not evidence that a scientific claim is true. 10. Security Considerations Implementations need to protect private signing keys, validate signatures before relying on integrity metadata, reject malformed or ambiguous JSON inputs, and avoid treating untrusted paths or artifact identifiers as local filesystem authorization. Watts Expires 5 March 2027 [Page 6] Internet-Draft Scientific Admissibility Evidence Record September 2026 Signature verification does not establish correctness of the underlying experiment, honesty of the signer, validity of a statistical model, or authorization of a governance consequence. Consumers MUST maintain those trust decisions separately. Canonicalization and hashing are sensitive to exact byte and character semantics. Implementations using JCS MUST enforce its constraints, including rejection of input that cannot be represented by the JCS data model. 11. Privacy Considerations Evidence records can contain author identifiers, timestamps, artifact locations, experimental metadata, or other information that becomes sensitive when correlated. Profiles SHOULD support data minimization and SHOULD avoid embedding secrets, credentials, private keys, or unnecessary personal information. 12. IANA Considerations This document has no IANA actions. 13. Implementation Status An experimental implementation corresponding to version 0.3 of the record model includes a JSON Schema structural contract, deterministic semantic conformance checks, RFC 8785 canonicalization tests, SHA-256 artifact verification, Ed25519 event-signature verification, passing and intentionally failing scientific fixtures, and append-only lifecycle checks. These implementation artifacts are informative and are not incorporated by reference as normative IETF material. 14. Open Issues * Whether this work belongs in the IETF, an IRTF research group, or another standards/research venue. * Whether a future revision should define a media type after interoperability experience exists. * Whether cryptographic agility should be mandatory in a future profile. * How profile registries should represent scientific-domain extensions without implying universal scientific semantics. 15. Normative References Watts Expires 5 March 2027 [Page 7] Internet-Draft Scientific Admissibility Evidence Record September 2026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [RFC8259] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, December 2017, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, June 2020, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, January 2017, . Author's Address Deonte Watts Independent Researcher Email: deonte@goodshyt.fun Watts Expires 5 March 2027 [Page 8]