Network Working Group A. Konviser Internet-Draft Gravit Open Network Intended status: Informational 13 October 2026 Expires: 16 April 2027 Gravit Epistemic Verification Protocol (GEVP) draft-gravit-gevp-09 Abstract The Gravit Epistemic Verification Protocol (GEVP) defines how signed evidence Records about an Artifact are screened, grouped by independent source and evaluated, so that a claim is never promoted beyond what independent evidence supports. It specifies the Epistemic State Machine, the Record format and its signature, the meaning of the signed result of a Record, a verifier registry accepted under a threshold of root keys, a content-addressed Decision Record that anyone can reproduce, and optional signed receipts that let an auditor check a history of decisions offline. It maps these states to the evidence taxonomy of the Gravit Verifiable Epistemic Decision Standard (VEDS). 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 16 April 2027. Copyright Notice 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. Konviser Expires 16 April 2027 [Page 1] Internet-Draft GEVP October 2026 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. Epistemic State Machine . . . . . . . . . . . . . . . . . . . 3 4. Protocol Data Types . . . . . . . . . . . . . . . . . . . . . 4 4.1. Artifact . . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Record . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.3. The Signed Result . . . . . . . . . . . . . . . . . . . . 4 4.4. Record Signature . . . . . . . . . . . . . . . . . . . . 5 4.5. Independence and Convergence . . . . . . . . . . . . . . 5 5. Verifier Registry and Trust Root . . . . . . . . . . . . . . 6 6. Admissibility Screening . . . . . . . . . . . . . . . . . . . 6 7. Freshness . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8. Decision Record . . . . . . . . . . . . . . . . . . . . . . . 6 9. Decision Receipts . . . . . . . . . . . . . . . . . . . . . . 7 10. Persistence . . . . . . . . . . . . . . . . . . . . . . . . . 7 11. Security Considerations . . . . . . . . . . . . . . . . . . . 7 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 14. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 15. VEDS Conformance Mapping . . . . . . . . . . . . . . . . . . 9 15.1. RAW and VALIDATED . . . . . . . . . . . . . . . . . . . 9 15.2. VERIFIED . . . . . . . . . . . . . . . . . . . . . . . . 10 15.3. COMMITTED . . . . . . . . . . . . . . . . . . . . . . . 10 15.4. Aggregation Restriction . . . . . . . . . . . . . . . . 11 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 16.1. Normative References . . . . . . . . . . . . . . . . . . 11 16.2. Informative References . . . . . . . . . . . . . . . . . 11 Appendix A. Changes from draft-gravit-gevp-08 . . . . . . . . . 12 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction Automated agents increasingly act on claims they cannot check themselves: a payment is due, a price is confirmed, a step of a procedure was completed. GEVP answers one narrow question about such a claim: given the Records that verifiers produced about it, what may the claim be called, and on what basis? Konviser Expires 16 April 2027 [Page 2] Internet-Draft GEVP October 2026 GEVP does not decide whether a claim is true. It decides whether independent, signed and fresh evidence supports it, and it records that decision so that any third party can reproduce it without trusting the party that made it. Its central rule is that aggregating weak or non-independent evidence never by itself turns a claim into a Verified Fact. This document was previously published as the Verifiable Convergence Protocol (VCP) and was renamed to avoid a collision with draft- kamimura-scitt-vcp. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Artifact: A claim to be evaluated, identified by an artifact_id. Record: A statement by one verifier about one Artifact (Section 4.2). Operator: The organisation responsible for one or more verifier keys. All keys of one Operator count as one source. Verifier Registry: The list of verifier keys, their Operators and revocation status (Section 5). Trust Root: A set of root keys and a threshold; the Verifier Registry is accepted only when signed by at least that many of them. Decision Record: The outcome of evaluating one Artifact (Section 8). 3. Epistemic State Machine An Artifact moves through four states: RAW, VALIDATED, VERIFIED and COMMITTED. Every transition MUST be explicit and logged; no state is reached implicitly. * RAW: received, not yet checked. * VALIDATED: provenance, integrity, freshness and interpretability confirmed (Section 15.1). * VERIFIED: at least one Record exists. Konviser Expires 16 April 2027 [Page 3] Internet-Draft GEVP October 2026 * COMMITTED: Records from independent sources converge (Section 4.5) and every rule of Section 8 is satisfied. 4. Protocol Data Types 4.1. Artifact An Artifact has an artifact_id (a non-empty string), a claim, a provenance and an integrity hash (SHA3-256 of its content). A request to evaluate an Artifact names the claimed state, one of Verified Fact, Probabilistic Assessment or Speculative Claim, or none, and an evaluation context (Section 7). 4.2. Record A Record has the following fields. record_id: Identifier of the Record. verifier_id: Identifier of the verifier that produced it. theta: The verifier's confidence, a finite number with at most six decimals. result: The verifier's verdict on the claim: true, false or null (Section 4.3). timestamp: UTC time of the check, exactly in the form YYYY-MM- DDTHH:MM:SSZ. provenance: The root of the evidence the verifier used. integrity_hash: Hash of the exact content checked. key_id: The first 16 hexadecimal characters of the SHA-256 hash of the verifier's raw 32-byte Ed25519 public key. signature: Base64 Ed25519 [RFC8032] signature over the signing message (Section 4.4). 4.3. The Signed Result The result field is the producing verifier's verdict on the claim, and it is covered by the Record's signature: * true: the verifier's check supports the claim. * false: the verifier's check contradicts the claim. Konviser Expires 16 April 2027 [Page 4] Internet-Draft GEVP October 2026 * null: the check gave no verdict, for example because it could not be performed. An implementation MUST NOT classify an Artifact as a Verified Fact unless at least two independent sources (Section 4.5) are represented by counted Records whose result is true. Any counted Record whose result is false MUST prevent a Verified Fact, even if Records with result true outnumber it. A Record whose result is null supports nothing and contradicts nothing. Counted Records are the admissible Records (Section 6) when a Verifier Registry is in use, and all Records otherwise. The Decision Record MUST list the record_id of every counted Record with result false and of every counted Record with result null, so that a contradicted claim and a claim without a verdict produce different Decision Records. 4.4. Record Signature The signing message is the UTF-8 encoding of the following eight lines joined by a single line feed (U+000A), with no trailing line feed: the literal "gravit-evidence-v1"; the artifact_id; the record_id; theta formatted with exactly six decimals; the result as "true", "false" or "null"; the timestamp; the provenance; the integrity_hash. Text fields MUST NOT contain line breaks. A Record whose theta cannot be represented exactly with six decimals is malformed. Binding the artifact_id into the message prevents a valid signature from being replayed onto another Artifact. 4.5. Independence and Convergence Records that share a verifier identity or a provenance, directly or through a chain of other Records, form one source. When a Verifier Registry is in use, the verifier identity is the Operator of the signing key, so that all keys of one Operator form one source. Each source is represented by its Record with the lowest theta, so a source cannot outvote itself. Over the representatives, let h be the share with theta of at least 0.7 and f the share with theta below 0.5. Convergence holds when there are at least two representatives, h > 0.7 and f < 0.3. Konviser Expires 16 April 2027 [Page 5] Internet-Draft GEVP October 2026 5. Verifier Registry and Trust Root The Verifier Registry lists, for each key, its key_id, public key, Operator and whether it is revoked. It is distributed together with detached signatures by root keys; each root key signs the octets "gravit-registry-v1" followed by a line feed and the exact registry file. The Trust Root lists the root keys and a threshold, which MUST be greater than half of the root keys. An implementation MUST accept the registry only if at least threshold distinct root keys produced valid signatures. Without an accepted Verifier Registry, an implementation MUST NOT classify an Artifact higher than Probabilistic Assessment, and the Decision Record MUST state that the evaluation of independent signed evidence was not possible (Section 8). 6. Admissibility Screening With a Verifier Registry, each Record is admissible only if it passes the following checks, in this order; the first failing check gives the reason for exclusion: unsigned (no key_id or no signature), unknown_key, revoked_key, malformed (the signing message cannot be formed), bad_signature. Excluded Records MUST be listed in the Decision Record with their reason. Excluding a Record never rejects the Artifact by itself; it only removes the Record from the evidence that counts. 7. Freshness The evaluation context MAY declare a freshness policy with evaluation_time (a timestamp in the Record format) and freshness_max_age_seconds (a non-negative integer). If either is present, both MUST be valid and every Record MUST satisfy 0 <= evaluation_time - timestamp <= freshness_max_age_seconds; otherwise the classification is lowered. Without a policy, a non-empty timestamp is required. The implementation never reads its own clock; the caller decides what "now" is, which keeps decisions reproducible. 8. Decision Record Evaluating an Artifact produces a Decision Record with: the artifact_id; the identifiers of every rule applied; the final state; a status of SUCCESS (the claimed state is justified), DEGRADED (a lower state is justified) or REJECTED (no state is justified); the record_id of every Record; the convergence metrics of every rule; the reason; the excluded Records with their reasons; and the SHA-256 digests of the Verifier Registry and Trust Root used, if any. Konviser Expires 16 April 2027 [Page 6] Internet-Draft GEVP October 2026 The decision_id is the first 16 hexadecimal characters of the SHA3-256 hash of the canonical JSON of all other fields (keys sorted, no insignificant whitespace). Identical inputs therefore give an identical Decision Record on any machine and in any conformant implementation. An implementation SHOULD also state whether the claim was evaluated or could not be evaluated, for example because no Verifier Registry was available or the freshness policy was incomplete. A claim refused after evaluation and a claim that could not be evaluated are different facts and MUST NOT be presented as the same. It SHOULD state what independence rests on: for each Operator involved, either the evidence of its independence that the registry references, or that its independence is assumed, not evidenced. Two valid signatures are not proof of two independent organisations. 9. Decision Receipts A service that evaluates Artifacts on behalf of others MAY issue a receipt for each Decision Record. A receipt names the service, the service's key_id, an account, a sequence number, the issue time, the implementation version, the artifact_id, the decision_id, the final state and status, the SHA-256 hash of the canonical request, the SHA-256 hash of the exact result returned, and the SHA-256 hash of the previous receipt of the same account (all zeros for the first). The service signs the canonical JSON of the receipt with Ed25519. An auditor who holds the service's public key can then check, without trusting the service, that every receipt is signed, that each result matches its receipt, and that the chain of receipts is unbroken, so that a receipt removed or altered later is detected. 10. Persistence Decision Records and receipts MAY be stored in a database, an archive, a content-addressed store or a ledger. GEVP does not require any particular storage; the decision_id and the receipt chain make stored records verifiable wherever they are kept. 11. Security Considerations The Verifier Registry is trusted input. Signature checks and grouping by Operator cannot detect an Operator listed twice under different names, or collusion between registered Operators. Deployments SHOULD reference evidence of each Operator's independence and report where independence is only assumed (Section 8). Konviser Expires 16 April 2027 [Page 7] Internet-Draft GEVP October 2026 A signature proves who produced a Record, not that its content is true. A compromised verifier key or device produces valid signatures; independent corroboration by a second Operator is the defence. Keys MUST be revoked in the registry when compromise is suspected. theta and result are reported by the verifier. An implementation does not recompute them. The signed result (Section 4.3) ensures that a verifier's own negative or absent verdict cannot be counted as support. Earlier revisions stated a cost relation C_manip > 2 * C_val as an engineering invariant. In the trace published with those revisions (pinned 7755f53), the relation holds for 1457 of 3000 records (48.6 %). It is therefore retained only as a design target; it is not a guarantee, and deployments MUST NOT rely on it for security. Convergence over unsigned Records offers no protection against a single party fabricating several "independent" Records. Deployments that use COMMITTED as the basis for a VEDS Verified Fact MUST use a Verifier Registry (Section 5). 12. Privacy Considerations Records and Decision Records carry identifiers and hashes, not the content of the evidence. Content MAY be kept encrypted, and provenance MAY be expressed as an opaque identifier. Receipts link the decisions of one account; a service SHOULD use pseudonymous account identifiers in receipts. 13. IANA Considerations This document has no IANA actions. 14. Implementation Status Note to the RFC Editor: please remove this section before publication, as described in [RFC7942]. Reference verifier: https://github.com/gravit-open-network- foundation/verifier, release v0.6.0 (Python, with a Rust port), Apache-2.0. It implements every normative section of this document. 47 golden test vectors, including seven for the signed result, are reproduced by both implementations, decision_id included. The same code runs in a web browser at https://gravitverifier.space/sandbox/, where any visitor can reproduce all 47 vectors locally. Konviser Expires 16 April 2027 [Page 8] Internet-Draft GEVP October 2026 Decision receipts (Section 9) are implemented by an early-access hosted service, https://github.com/gravit-open-network-foundation/ gravit-verifier-service, with a client that verifies receipts and exports offline. A reference adapter for the SAFR v1.1 runtime governance framework, https://github.com/gravit-open-network-foundation/gravit-safr- adapter, uses GEVP to corroborate the steps of an agent's action trace. An external reviewer used it to show that release v0.5.0 counted Records with result false or null as support; the signed result rule (Section 4.3) was added in v0.6.0 in response. Reproducible evaluation: https://github.com/gravit-open-network- foundation/gravit-eval-pack reproduces every figure in this section with one command. Threshold calibration: a 3000-claim trace generated by the consensus engine at https://github.com/gravit-open-network-foundation/gravit- grover (10x Sybil amplification) gives, at theta = 0.73, a true positive rate of 91.7 % (1376/1500) and a false positive rate of 7.3 % (110/1500). The rates are identical for every theta in [0.11, 0.78]: once the network has converged, the threshold has little effect; what decides is whether honest evidence outweighs the Sybil evidence. Correction: revisions -00 to -07 reported TPR 93.4 % and FPR 0.4 % at theta 0.73 from a trace pinned at commit 7755f53 of the gravitnet repository. No generator for that trace exists and its figures could not be reproduced; it is superseded by the calibration above and kept unchanged for the record. 15. VEDS Conformance Mapping 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. 15.1. RAW and VALIDATED 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. Konviser Expires 16 April 2027 [Page 9] Internet-Draft GEVP October 2026 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. 15.2. VERIFIED An Artifact transitions to VERIFIED when at least one Record (Section 4.2) 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, the deployment MUST document the theta threshold it applies and how that threshold was calibrated, consistent with the Impact- Based Evidence Strength requirement in VEDS Section 4.2.3. This document does not recommend a specific value (see Section 14). 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. 15.3. COMMITTED An Artifact transitions to COMMITTED when Records from independent sources achieve Convergence (Section 4.5) and the signed result rule (Section 4.3) is satisfied. 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. Konviser Expires 16 April 2027 [Page 10] Internet-Draft GEVP October 2026 The grouping of Section 4.5 is the minimum criterion for independence. 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). 15.4. Aggregation Restriction 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 15.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. 16. References 16.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, . [I-D.gravit-verifiable-epistemic-decision] Konviser, A., "Gravit Verifiable Epistemic Decision Standard", Work in Progress, Internet-Draft, draft-gravit- verifiable-epistemic-decision-00, 9 August 2026, . 16.2. Informative References [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . Konviser Expires 16 April 2027 [Page 11] Internet-Draft GEVP October 2026 Appendix A. Changes from draft-gravit-gevp-08 * The document is rewritten as a complete specification: terminology, Record fields, signing message, independence and convergence, Verifier Registry and Trust Root, admissibility screening, freshness and the Decision Record are now specified precisely, matching the reference verifier. * New: the signed result of a Record (true, false, null) and its effect on a Verified Fact. * New: evaluated versus not evaluable, and the basis of independence in the Decision Record. * New: optional Decision Receipts for offline audit. * Security Considerations: a Verifier Registry is now required for COMMITTED as the basis of a Verified Fact. * Implementation Status updated to release v0.6.0 with 47 test vectors; the corrections of -08 are kept. Acknowledgments The author thanks the reviewer who showed, with a reproduction, that the result field was not applied, and the participants of IETF mailing list discussions whose questions shaped this revision. Contributors Canon Final v1.1. Author's Address Alex Konviser Gravit Open Network CH- Zurich Switzerland Email: ietf@gravit.space Konviser Expires 16 April 2027 [Page 12]