| Internet-Draft | GEVP | August 2026 |
| Konviser | Expires 13 February 2027 | [Page] |
GEVP defines a minimal protocol for epistemic convergence. Renamed from VCP to avoid collision with draft-kamimura-scitt-vcp. Invariant C_manip > C_val*2.0 as engineering heuristic. Theta 0.73 RECOMMENDED, pinned 7755f53. Architecture stable per https://github.com/GravitOpenNetwork/gravit-canon. This revision adds a formal mapping between GEVP's Epistemic State Machine and the evidence taxonomy defined in the Gravit Verifiable Epistemic Decision Standard (VEDS).¶
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 13 February 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.¶
Gravit open network for verifiable knowledge transformations. Stable. Future is implementations.¶
GEVP defines ESM RAW->VALIDATED->VERIFIED->COMMITTED, verification types, persistence MAY Ledger IPFS GSS DB Archive, bindings separate.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Invariant C_manip > C_val*2.0 measurement.¶
States RAW VALIDATED VERIFIED COMMITTED explicit logged.¶
Artifact id hash SHA3-256 claim provenance signatures optional.¶
Record artifact-id verifier-id theta 0.73 result timestamp.¶
Convergence h>0.7 f<0.3.¶
MAY not MUST. Ledger IPFS GSS DB Archive.¶
Replay hash nonce. Sybil cost model. No PII. Signatures OPTIONAL.¶
Content MAY encrypted, provenance MAY redacted.¶
No IANA actions.¶
MVR 0.1.0-mvr https://github.com/GravitOpenNetwork/gravit-canon SHA 7755f53 TPR 93.4 FPR 0.4 theta 0.73 RECOMMENDED.¶
This section defines a normative mapping between an Artifact's position in the Epistemic State Machine (Section 3) and the epistemic classification taxonomy defined in Section 4.1 of [I-D.gravit-verifiable-epistemic-decision] (VEDS). This mapping specifies one conformant way for a GEVP-based implementation to satisfy the VEDS admissibility and classification requirements referenced from VEDS Section 1; implementations are not required to use GEVP, but if they do, this section applies.¶
A RAW Artifact MUST NOT be treated as admissible evidence under VEDS Section 4.2; it has not yet been checked against any admissibility element.¶
A GEVP implementation MUST transition an Artifact from RAW to VALIDATED only after confirming all four elements required by VEDS Section 4.2.1:¶
Provenance: the Artifact's provenance field resolves to an identifiable, nameable origin.¶
Integrity: the Artifact's SHA3-256 hash verifies against its content.¶
Freshness Bound: the Artifact's timestamp falls within the deployment-defined validity interval.¶
Interpretability: the Artifact's claim conforms to a documented, unambiguous schema.¶
A VALIDATED Artifact is admissible under VEDS Section 4.2 but MUST NOT be assigned an epistemic classification under VEDS Section 4.1.1 higher than Speculative Claim; admissibility alone does not establish truth.¶
An Artifact transitions to VERIFIED when at least one Record (Section 4) is produced for it by a verifier, with a theta value and a result. A VERIFIED Artifact backed by exactly one Record corresponds to a VEDS Probabilistic Assessment (VEDS Section 4.1.1): the verifier's theta-scoring method is the documented, reproducible method, and the recorded theta is the confidence value. Where the Artifact is to serve as part of the basis for a definitive VEDS decision, its theta SHOULD meet or exceed 0.73, consistent with the RECOMMENDED threshold in Section 9 and with the Impact-Based Evidence Strength requirement in VEDS Section 4.2.3.¶
A GEVP implementation MUST NOT treat a single Record, regardless of its theta value, as satisfying the VEDS Verified Fact definition; a single verifier does not constitute independent cross-corroboration.¶
An Artifact transitions to COMMITTED when Records from multiple verifiers achieve Convergence, h>0.7 and f<0.3 (Section 4). A COMMITTED Artifact corresponds to a VEDS Verified Fact (VEDS Section 4.1.1): the Convergence condition is the mechanism by which the Artifact has been "independently confirmed accurate ... through reproduction, cross-corroboration, or equivalent means," as required by the VEDS Verified Fact definition.¶
This document does not define criteria for treating two verifiers as independent for the purpose of Convergence. Implementations MUST apply criteria at least as strict as the Independent Corroboration Threshold mechanism in VEDS Section 4.6.2, and MUST document their specific criteria in their VEDS Conformance Statement (VEDS Section 5.2).¶
A set of RAW or VALIDATED Artifacts, however large, MUST NOT be treated as equivalent to a COMMITTED Artifact. Only Convergence over independently produced Records, per Section 10.3, MUST be used to reach COMMITTED. This reflects the No Aggregation Laundering requirement of VEDS Section 4.1.2: aggregating multiple Speculative Claims does not, by itself, produce a Verified Fact.¶
Contributors Canon Final v1.1¶