| Internet-Draft | Scientific Admissibility Evidence Record | September 2026 |
| Watts | Expires 5 March 2027 | [Page] |
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.¶
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 (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.¶
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.¶
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].¶
A conforming profile SHOULD satisfy the following requirements:¶
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.¶
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.¶
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:¶
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.¶
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.¶
{
"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.¶
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.¶
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.¶
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.¶
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.¶
This document has no IANA actions.¶
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.¶