]> Gravit Open Network

Zurich Switzerland ietf@gravit.space

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).

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? 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.

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.

Artifact:

A claim to be evaluated, identified by an artifact_id.

Record:

A statement by one verifier about one Artifact ().

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 ().

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 ().

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 ().
• VERIFIED: at least one Record exists.
• COMMITTED: Records from independent sources converge () and every rule of is satisfied.

Protocol Data Types

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 ().

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 ().

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 signature over the signing message ().

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.
• 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 () 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 () 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.

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.

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.

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 ().

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.

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.

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. 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.

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.

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.

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 (). 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 () 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 ().

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.

IANA Considerations This document has no IANA actions.

Implementation Status Note to the RFC Editor: please remove this section before publication, as described in . 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. Decision receipts () 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 () 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.

VEDS Conformance Mapping This section defines a normative mapping between an Artifact's position in the Epistemic State Machine () and the epistemic classification taxonomy defined in Section 4.1 of (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.

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. 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.

VERIFIED An Artifact transitions to VERIFIED when at least one Record () 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 ). 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.

COMMITTED An Artifact transitions to COMMITTED when Records from independent sources achieve Convergence () and the signed result rule () 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. The grouping of 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).

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 , 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.

References Normative References Gravit Open Network Informative References

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.