| Internet-Draft | Scientific Evidence Admissibility | October 2026 |
| Watts | Expires 24 April 2027 | [Page] |
This document describes a proposed interoperable metadata record for scientific evidence, test calibration, falsification, provenance, and release classification. It distinguishes machine-verifiable integrity from scientific validity, ownership, and authorization. The design is a proposal and does not assert Internet standards consensus, new physical discoveries, or a completed patent review.¶
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 24 April 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 records may be redistributed with incomplete provenance, uncalibrated inference, or ambiguous disclosure status. This proposal defines a compact metadata exchange envelope for evidence and scientific admissibility. It is not a scientific result, a valuation, a certification of novelty, or an IP-title determination.¶
The design is motivated by a locally supplied scientific-admissibility v0.3 corpus and registry contracts. The corpus includes synthetic fixture results and conformance tests. Their existence does not establish independent empirical validation.¶
Source: an identified immutable byte sequence. Claim: a statement with epistemic status and references. Evidence tier: T1 empirical, T2 derived, T3 rigorous conjecture, or T4 speculative. Admissibility: the result of a registered statistical and methodological gate. Release state: an independent authorization field.¶
The terms MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are to be interpreted as described in BCP 14 only when they appear in all capitals. This specification proposes exchange semantics, not an automated scientific truth oracle.¶
Each record MUST identify a stable record_id, source identifiers, byte digest algorithm and digest, claim status, evidence tier, validation state, and release classification. The record SHOULD include source locators, methods, calibration information, falsifiers, uncertainty, dependencies, and replication instructions.¶
An implementation MUST distinguish integrity verification from scientific validation. A verified SHA-256 digest does not establish that a claim is true, novel, legally owned, or safe to disclose.¶
Status values for claims are ESTABLISHED, DERIVED, CONJECTURE, ANOMALY, and POTENTIALLY_NOVEL. The last value indicates a review queue only. Negative and inconclusive outcomes MUST remain representable.¶
A test result SHOULD specify null model, alternatives, nuisance assumptions, significance threshold, test statistic, calibration method, estimated power, and the interpretation of failed or underpowered tests.¶
The registry MUST NOT infer exclusion from a non-rejection when sensitivity is insufficient. A local significance result MUST NOT be substituted for a scan-adjusted global result when multiple testing is part of the registered design.¶
Admissibility, valuation, and governance are separate decisions. Neither valuation nor governance metadata MUST overwrite a failed admissibility gate.¶
For JSON records, implementations MAY use JSON Canonicalization Scheme (JCS), as specified in RFC 8785, followed by SHA-256. A canonicalization algorithm identifier and digest scope MUST be recorded. Implementations MUST NOT treat a signature or digest as proof of empirical validity.¶
A verifier MUST reject a digest mismatch and SHOULD preserve an auditable error code. Revision history MUST NOT silently overwrite original evidence records.¶
Release classes are PUBLIC_CANDIDATE, IP_REVIEW, CONFIDENTIAL, THIRD_PARTY, and RELEASED. PUBLIC_CANDIDATE does not mean authorized for publication.¶
A public export MUST exclude confidential invention-enabling details, credentials, protected personal information, and third-party materials lacking appropriate rights. A release authorization SHOULD record the decision maker, scope, date, and source artifact hashes.¶
Publishing an Internet-Draft is a public disclosure. A patent-sensitive submission MUST be held until appropriate counsel and rights-holder clearance is documented.¶
An attacker could substitute a source record, forge provenance metadata, leak private data, or exploit an overly permissive release flag. Deployments SHOULD authenticate record writers, validate schemas, verify digests, minimize personal data, and restrict access to confidential fields.¶
A checksum does not prevent a malicious author from initially registering false information. Independent scientific replication and independent legal review remain external processes.¶
This document makes no IANA registration requests.¶
The v0.3 fixture corpus is synthetic and the proposed interchange profile has not been tested for cross-implementation interoperability in this release. The JSON example in the companion package is illustrative and is not a registered media type or final schema.¶
Outstanding gates include ownership and license review, prior-art and patent-counsel assessment, disclosure authorization, independent validation, and IETF community feedback.¶