Internet-Draft Gravit VEDS August 2026
Konviser Expires 10 February 2027 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-gravit-verifiable-epistemic-decision-00
Published:
Intended Status:
Standards Track
Expires:
Author:
A. Konviser
Gravit Open Network

Gravit Verifiable Epistemic Decision Standard

Abstract

This document defines the normative requirements for the Gravit decision-making system. Gravit's core principle is to base all definitive decisions exclusively on verifiable epistemic grounds. This specification establishes mandatory rules for evidence admissibility, epistemic classification, traceability, failure handling, auditability, and security in adversarial environments, including a taxonomy of admissible evidence and failure outcomes, a required Decision Record format, and an explicit threat model with corresponding verification mechanisms. The goal is to ensure that all decisions are reproducible, auditable, and resistant to manipulation, thereby fostering trust and accountability in distributed and high-stakes settings.

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 10 February 2027.

▲

Table of Contents

1. Introduction

Gravit is a decision-making system architected to produce outputs that are rigorously grounded in evidence. The foundational premise is that for a decision to be legitimate and trustworthy, it must be possible to independently verify the basis upon which it was made.

The purpose of this standard is to codify this principle into a set of concrete, enforceable requirements. It is intended to prevent decisions based on unverifiable assertions, unsupported hypotheses, or opaque inference paths. This standard is particularly relevant for technical implementations in distributed, adversarial, or regulated environments where the legitimacy of a decision depends on its external verifiability and auditability.

Section 4 organizes the normative requirements into six areas: epistemic classification (Section 4.1), evidence admissibility (Section 4.2), traceability (Section 4.3), failure handling (Section 4.4), auditability (Section 4.5), and security against adversarial evidence (Section 4.6). Each area is specified through, as applicable, a taxonomy or model of the relevant concern, a procedure or set of mechanisms for applying it, and a list of normative requirements. Several deployment-specific parameters that this document deliberately leaves undefined (for example, decision-impact thresholds, or a Decision Record retention period) are collected under a single Conformance Statement mechanism defined in Section 5.

This document specifies what a conformant Gravit implementation must guarantee about the decisions it produces; it does not specify a particular protocol for performing the underlying evidence verification steps referenced in Section 4.2 and Section 4.6. This document is informed by, and intended to be usable together with, prior work referred to as GEVP, which defines one mechanism for evidence verification (see [GEVP]). An implementation satisfying the properties required by this document is not required to use GEVP specifically, provided its verification mechanism satisfies the requirements of Section 4.2 and Section 4.6.

Requirements comparable to those in this document, particularly the marking and detectability of AI-generated or AI-manipulated content, are also addressed by external regulatory frameworks, such as Article 50 of Regulation (EU) 2024/1689 [EU-AI-ACT-ART50]. This document does not implement or claim conformance with any specific regulatory framework; it is cited here only to note that a Gravit implementation's evidence, provenance, and traceability guarantees may be relevant to satisfying such external obligations, subject to independent legal assessment.

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 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.

For the purposes of this document, the following terms are defined:

Verifiable Epistemic Ground:
A fact, proof, data point, attestation, or inference chain that can be independently and objectively checked for validity, integrity, and correctness by a third party, without requiring privileged access to internal system states.
Evidence:
Any artifact, including data, logs, cryptographic proofs, attestations, or trace records, that is used to support or justify a decision.
Traceability:
The ability to reconstruct the complete, auditable chain of reasoning from a final decision back to the specific set of initial epistemic grounds and inference steps that produced it.
Fallback Mode:
A documented, non-default operating mode in which Gravit may operate with reduced decision authority or rely on explicitly defined and authorized heuristic processes when normal verification procedures fail. Authorization of a Fallback Mode configuration, including the conditions under which it may be entered and the parties responsible for approving it, is an operational and deployment concern outside the scope of this document, but implementations claiming conformance MUST document their authorization procedure in their Conformance Statement (see Section 5.2).
Failure State:
One of a fixed set of machine-readable outcomes (REJECTED, DEGRADED, or PENDING; see Section 4.4) that Gravit reports when it does not produce an unqualified definitive decision. A Failure State is itself a decision outcome and is subject to the same traceability requirements as a definitive decision (see Section 4.3).
Decision Record:
The complete, structured artifact that binds a definitive decision or Failure State to its evidentiary basis, provenance metadata, and timestamps, as required by Section 4.5. The Decision Record is the unit of storage referenced by all retention and audit requirements in this document.

3. Scope

This document applies to all decision-making functions performed by the Gravit system. This includes, but is not limited to, direct decisions, decisions aggregated from multiple sources, and decisions delegated to or influenced by external subsystems.

This document defines requirements for the verifiability and traceability of decisions, not the specific internal inference algorithms or machine learning models themselves. Such algorithms are in scope only insofar as their operation affects the system's ability to meet the verification, traceability, and conformance requirements outlined herein.

4. Requirements

4.1. Epistemic Validity

4.1.1. Epistemic Classification Taxonomy

Gravit MUST classify every epistemic ground into exactly one of the following classes before it may contribute to a decision:

Verified Fact:
An epistemic ground that has passed the admissibility procedure in Section 4.2.2 and whose content has additionally been independently confirmed accurate, and not merely attributable and intact, through reproduction, cross-corroboration, or equivalent means.
Probabilistic Assessment:
An epistemic ground that assigns a likelihood or confidence value to a proposition, derived from a documented and reproducible method (e.g., a statistical inference procedure or a forecasting model with disclosed inputs), without asserting the proposition as definitively true.
Speculative Claim:
An epistemic ground whose truth cannot currently be verified or falsified through reproducible means, including unconfirmed reports, unattributed assertions, or model outputs lacking a documented confidence method.

The Verifiable Basis requirement of Section 4.1.3 MUST be satisfied using Verified Facts, Probabilistic Assessments, or a combination thereof only; a Speculative Claim MUST NOT, alone or in combination with other Speculative Claims, be treated as satisfying that requirement. Where a Probabilistic Assessment serves as part of the basis for a definitive decision, its confidence value SHOULD meet or exceed a documented, decision-class-specific threshold consistent with the Impact-Based Evidence Strength requirement in Section 4.2.3.

4.1.2. Classification Determination and Reclassification

  1. Pre-Use Classification: Gravit MUST determine the epistemic classification of a ground as a discrete step, completed before that ground is used in decision-making, in the same manner as the admissibility determination in Section 4.2.2.

  2. No Aggregation Laundering: Gravit MUST NOT treat the aggregation of multiple Speculative Claims as producing an epistemic status equivalent to a Verified Fact or Probabilistic Assessment, unless that aggregation is performed by a documented, independently verifiable method that itself qualifies as a Probabilistic Assessment under Section 4.1.1.

  3. Reclassification on Contrary Evidence: Gravit MUST reclassify an epistemic ground upon receipt of credible evidence contradicting its prior classification, and MUST re-evaluate any definitive decision for which the reclassified ground was part of the necessary basis under Section 4.1.1.

  4. Reclassification Record: Gravit MUST record a reclassification event, including the prior and new classification and the triggering evidence, in the Decision Record of any decision affected by it, per Section 4.5.1.

4.1.3. Requirements

  1. Verifiable Basis: Gravit MUST base every definitive decision on verifiable epistemic grounds.

  2. Prohibition on Unverifiable Inputs: Gravit MUST NOT base any decision, in whole or in part, on an unverifiable assertion, unsupported hypothesis, or unvalidated inference.

  3. Epistemic Classification: Gravit MUST clearly distinguish between and internally label different types of epistemic grounds, per Section 4.1.1.

  4. Preference for Reproducibility: Gravit SHOULD prefer evidence that can be independently reproduced or verified by a third party.

  5. Use of Speculative Signals: Gravit MAY use speculative signals only as non-decisive inputs, provided they do not determine the final outcome of a definitive decision without subsequent verification.

4.2. Evidence Admissibility

4.2.1. Required Elements of Admissible Evidence

Gravit MUST NOT treat an item as admissible unless it carries, or can be resolved to, all of the following:

  1. Provenance: an identifiable source or origin (e.g., signer identity, system of record, sensor identifier) sufficient to attribute the item to a specific, nameable origin.

  2. Integrity: a means of detecting modification since origination (e.g., a cryptographic digest or signature covering the item's content).

  3. Freshness Bound: a timestamp or validity interval sufficient to determine whether the item is stale relative to the decision being made; Gravit MUST define, per deployment, the maximum age at which an otherwise-valid item ceases to be admissible for a given decision class.

  4. Interpretability: a documented schema, encoding, or semantics sufficient for the item's content to be unambiguously interpreted without reliance on undocumented local convention.

An item missing any element in this list MUST be treated as inadmissible under Section 4.2.3, regardless of the apparent plausibility of its content.

4.2.2. Determination Procedure

  1. Pre-Use Determination: Gravit MUST determine admissibility as a discrete step that completes, with a recorded outcome, before the item is used in any decision-making process; admissibility MUST NOT be determined implicitly as a side effect of the decision computation itself.

  2. Binary Outcome: The admissibility determination for a given item MUST produce exactly one of two outcomes (admissible or inadmissible) for a given decision context; Gravit MUST NOT propagate a "partially admissible" item into decision-making without first resolving it to one of these two outcomes.

  3. Inadmissibility Recording: Gravit MUST record the specific element from Section 4.2.1 that caused an item to be found inadmissible, for inclusion in the Decision Record if the item's absence contributed to a REJECTED or DEGRADED outcome (see Section 4.4.1).

  4. Non-Reuse of Rejected Items: Gravit MUST NOT reuse an item found inadmissible in a later determination for the same decision context unless the specific deficiency identified under requirement 3 of this section has been remedied.

4.2.3. Requirements

  1. Source and Proof Linkage: Gravit MUST reject any input that cannot be linked to a verifiable source, a cryptographic proof, or a traceable inference chain.

  2. Pre-Use Validation: Gravit MUST validate the admissibility of evidence before using it in any decision-making process, per Section 4.2.2.

  3. Admissibility Criteria: Gravit MUST NOT treat an item as admissible evidence if its provenance, integrity, or interpretation cannot be established, per Section 4.2.1.

  4. Evidence Preservation: Gravit SHOULD preserve evidence, including items found inadmissible, in a form suitable for later audit and independent review.

  5. Impact-Based Evidence Strength: Gravit MAY require stronger forms of evidence (e.g., cryptographic proofs instead of digital signatures) for decisions with higher potential impact, provided the elevated requirement is defined in terms of the elements in Section 4.2.1 and not as an undocumented, ad hoc criterion.

4.3. Traceability

4.3.1. Contribution Attribution Format

Where Gravit records the contribution of an evidence item to a decision, per the Contribution Attribution requirement in Section 4.3.3, that record MUST include:

  1. a reference to the specific evidence item, resolvable to the item as determined admissible under Section 4.2.2;

  2. the item's epistemic classification at the time of use, per Section 4.1.1;

  3. a description of the role the item played in the outcome (e.g., necessary condition, weighted factor, corroborating support, disqualifying condition); and

  4. where the decision process is quantitative, the item's individual weight or score contribution to the outcome, to the extent the process supports isolating that contribution.

An attribution record that identifies only that an item was "used," without the role or weight information in this list, MUST NOT be treated as satisfying the Contribution Attribution requirement.

4.3.2. Audit Trail Reconstruction Procedure

To satisfy the Audit Trail Completeness requirement in Section 4.3.3, Gravit SHOULD support, at minimum, the following reconstruction steps from a Decision Record (see Section 4.5.1) alone, without reliance on Gravit's internal runtime state:

  1. identification of every evidence item referenced in the Decision Record;

  2. independent verification of each item's admissibility, per Section 4.2.1;

  3. independent verification of each item's epistemic classification, per Section 4.1.1; and

  4. confirmation that the recorded decision logic maps the referenced evidence, with its recorded roles or weights per Section 4.3.1, to the recorded outcome.

An implementation that cannot support step 4 of this procedure for a given decision SHOULD record that limitation explicitly as part of the assurance boundaries required by Section 4.5.4.

4.3.3. Requirements

  1. Decision-Evidence Relationship: Gravit MUST maintain a traceable relationship between each definitive decision and the evidentiary basis used to produce it.

  2. Contribution Attribution: Gravit MUST record which specific evidence items influenced a decision and, where applicable, the nature and extent of their contribution to the final result, per Section 4.3.1.

  3. Segregation of Premises: Gravit MUST NOT merge verified and unverified premises in a way that prevents their clear and unambiguous separation during an audit.

  4. Audit Trail Completeness: Gravit SHOULD provide an audit trail sufficient to fully reconstruct the decision process, per Section 4.3.2.

  5. Trace Fidelity: A recorded trace or explanation MUST NOT represent a reasoning path that did not, in fact, produce the recorded outcome; Gravit MUST NOT substitute a plausible post-hoc rationalization for the actual decision logic in any record used to satisfy this section.

  6. Limited Disclosure: Gravit MAY expose only a limited trace when full disclosure would violate security, privacy, or policy constraints.

4.4. Failure Handling

4.4.1. Failure State Taxonomy

Gravit MUST classify every non-definitive outcome into exactly one of the following Failure States, and MUST NOT define additional outcome types that are not reducible to one of these three without updating this specification:

REJECTED:
No verifiable epistemic basis exists and none is expected to become available without a material change in inputs. Gravit MUST NOT automatically retry a REJECTED request with the same evidence set.
DEGRADED:
A decision was produced, but only by operating in an authorized Fallback Mode (see Section 2) with reduced decision authority. A DEGRADED outcome MUST be labeled as such and MUST NOT be represented to downstream consumers as equivalent to an unqualified definitive decision.
PENDING:
Verification could not be completed within the applicable time or resource bounds, but a verifiable basis may become available (e.g., outstanding corroboration, an unresolved proof). A PENDING outcome MUST carry either a retry policy or an explicit expiry, after which it MUST transition to REJECTED.

4.4.2. Requirements

  1. Refusal with No Basis: Gravit MUST refuse to produce a definitive decision when no verifiable epistemic basis is available, and MUST classify the refusal as REJECTED per Section 4.4.1.

  2. Fail-Closed Default: When Gravit cannot determine which Failure State applies, or cannot complete classification within the applicable time bound, it MUST default to REJECTED rather than producing an unqualified definitive decision or silently defaulting to a permissive outcome.

  3. Degraded Mode Entry: Gravit MUST enter DEGRADED or REJECTED when evidence verification fails for a required decision, and MUST NOT enter DEGRADED except through an authorized Fallback Mode configuration as defined in Section 2.

  4. Prohibition on Unverified Heuristics: Gravit MUST NOT substitute heuristics or unverified approximations for formal verification unless explicitly operating in a documented and authorized fallback mode, as defined in Section 2.

  5. No Silent Retry with Weakened Evidence: Gravit MUST NOT re-attempt a decision using a relaxed admissibility threshold (see Section 4.2) as an automatic response to a REJECTED or DEGRADED outcome; any change to the admissibility threshold MUST be an explicit, separately authorized action.

  6. PENDING Bounds: Gravit MUST bound the duration or resource cost of a PENDING outcome and MUST transition it to REJECTED upon expiry, as required by Section 4.4.1.

  7. Failure Record: Gravit MUST produce a Decision Record (see Section 2) for every REJECTED, DEGRADED, or PENDING outcome, subject to the same traceability requirements in Section 4.3 as a definitive decision.

  8. Explanation of Refusal: Gravit SHOULD return a clear and actionable explanation for its refusal to decide when such disclosure is safe and operationally useful, and SHOULD include the applicable Failure State in that explanation.

  9. Request for Additional Evidence: Gravit MAY request additional evidence from trusted sources before attempting to decide again, and MAY represent the interim state as PENDING while such evidence is outstanding.

  10. Repeated-Failure Signaling: Gravit MAY escalate or flag a source or evidence path that produces repeated REJECTED outcomes for subsequent handling under Section 4.6, but such signaling MUST NOT itself be used as grounds for a definitive decision.

4.5. Auditability and Assurance

4.5.1. Decision Record Content

Each Decision Record (see Section 2) MUST contain, at minimum:

  1. a unique, stable identifier for the decision or Failure State;

  2. the outcome (definitive decision value, or Failure State per Section 4.4.1);

  3. references to every evidence item that influenced the outcome, and its individual contribution where determinable, per Section 4.3;

  4. the epistemic classification (verified fact, probabilistic assessment, speculative claim; see Section 4.1) of each referenced evidence item;

  5. a verifiable timestamp of both evidence collection and decision production, per Section 4.5.2;

  6. an explicit statement of assurance boundaries, per requirement 3 of this section, when the decision is DEGRADED or relies on any non-reproducible evidence.

4.5.2. Timestamping and Record Integrity

  1. Verifiable Timestamps: Gravit MUST associate each Decision Record with a timestamp that is itself verifiable (e.g., derived from a trusted time source or a cryptographic timestamping scheme), and MUST NOT rely solely on an unauthenticated local clock value for records used in audit or dispute resolution.

  2. Tamper Evidence: Gravit SHOULD store Decision Records in a form that is tamper-evident (e.g., via cryptographic hashing or hash chaining across records), such that undetected post-hoc modification of a stored Decision Record is computationally infeasible.

  3. Immutability After Finalization: Gravit MUST NOT modify a finalized Decision Record in place; corrections MUST be represented as new, separately timestamped records that reference the record they supersede.

4.5.3. Retention and Access

  1. Retention Period: An implementation claiming conformance MUST define and document a minimum retention period for Decision Records, commensurate with the operational, regulatory, or contractual audit requirements of its deployment context; this document does not mandate a specific duration.

  2. Machine-Readable Structure: Gravit SHOULD store Decision Records in a structured, machine-readable format to support automated audit tooling and independent re-verification.

  3. Access Control on Audit Data: Gravit SHOULD restrict write access to stored Decision Records to the decision-production process itself, and SHOULD make read access available to designated auditors independent of that process.

4.5.4. Requirements

  1. Decision Auditability: Gravit MUST ensure that definitive decisions are auditable against the full, recorded evidence set.

  2. Provenance Metadata: Gravit MUST preserve sufficient metadata, per Section 4.5.1, to support post hoc verification of decision provenance.

  3. Explicit Assurance Boundaries: Gravit SHOULD make assurance boundaries explicit, clearly documenting what was verified, what was assumed, and what remains unknown.

  4. External Verification Support: Gravit MAY publish partial proofs or attestations to support external verification.

  5. Minimizing Opaque Paths: Gravit SHOULD minimize the use of opaque decision paths where a verifiable path is feasible.

  6. Independent Re-Verification: Gravit SHOULD structure Decision Records such that an independent auditor with access to the referenced evidence can reconstruct the outcome without access to Gravit's internal runtime state.

4.6. Security and Adversarial Resistance

4.6.1. Threat Model

Gravit MUST be designed and operated under the assumption that an adversary may possess some or all of the following capabilities with respect to evidence entering the system:

Forgery:
The ability to generate evidence-like artifacts purporting to originate from a legitimate source that did not, in fact, produce them.
Tampering:
The ability to modify the content of evidence in transit or at rest, between the time it was originated and the time it is used in a decision.
Replay:
The ability to capture previously valid evidence and resubmit it outside the context, decision, or freshness window (see Section 4.2.1) for which it was originally produced.
Source Spoofing:
The ability to cause evidence to be attributed to a source other than its actual origin, including impersonation of a trusted source's identity or credentials.
Collusion:
The ability to cause multiple, ostensibly independent sources to act in coordination, so as to satisfy a corroboration requirement without providing genuinely independent confirmation.
Verification-Path Flooding:
The ability to submit high volumes of low-quality, malformed, or spurious evidence with the intent of exhausting verification resources or inducing the system to relax its admissibility or verification standards under load.

This list defines the minimum threat coverage required for conformance; it does not preclude an implementation from defending against additional threats specific to its deployment context.

4.6.2. Required Verification Mechanisms

For each threat identified in Section 4.6.1, Gravit MUST apply the corresponding countermeasure:

  1. Cryptographic Integrity Binding: To defend against Tampering, Gravit MUST verify a cryptographic digest or signature covering the evidence content, per the Integrity element defined in Section 4.2.1, before the evidence is used.

  2. Authenticity Binding: To defend against Forgery and Source Spoofing, Gravit MUST verify a binding between the evidence and a specific, nameable origin, per the Provenance element defined in Section 4.2.1, using credentials or identity proofs that the claimed source could plausibly, and only the claimed source could plausibly, have produced.

  3. Replay Defense: To defend against Replay, Gravit MUST enforce the Freshness Bound element defined in Section 4.2.1 and SHOULD additionally bind evidence to a nonce, sequence number, or decision-specific context value where the evidence format supports it, such that a previously valid item cannot be revalidated for a different decision without detection.

  4. Independent Corroboration Threshold: To defend against Collusion, Gravit SHOULD require corroboration from more than one source for decisions above a defined impact threshold (see the Impact-Based Evidence Strength requirement in Section 4.2.3). Gravit MUST NOT treat two sources as independent for the purpose of satisfying a corroboration requirement when they are known to share a controlling party, a common infrastructure dependency, or another relationship that would allow a single actor to influence both.

  5. Resource Bounding Under Load: To defend against Verification-Path Flooding, Gravit MUST bound the verification resources committed per source or per request, and MUST respond to resource exhaustion by producing a REJECTED or PENDING Failure State (see Section 4.4.1) for the affected requests rather than by relaxing admissibility criteria or verification depth to relieve load.

4.6.3. Requirements

  1. Adversarial Assumption: Gravit MUST assume that all incoming evidence may be incomplete, stale, malformed, or adversarially manipulated, consistent with the threat model in Section 4.6.1.

  2. Integrity and Authenticity Verification: Gravit MUST verify the integrity and authenticity of evidence before relying on it, per Section 4.6.2.

  3. Rejection of Tampered Evidence: Gravit MUST NOT accept forged, replayed, or tampered evidence as a valid basis for decision-making.

  4. Uniform Failure Path for Verification Failure: Gravit MUST treat evidence that fails integrity, authenticity, or replay verification as inadmissible under Section 4.2 and process it through the ordinary admissibility and failure-handling paths defined in Section 4.4, rather than through a separate, undocumented error path.

  5. Source-Based Verification: Gravit SHOULD apply stronger verification checks to evidence originating from untrusted or partially trusted sources.

  6. Isolation of Trust Levels: Gravit SHOULD isolate the processing path for evidence from untrusted or partially trusted sources from privileged internal state, such that a flaw in the handling of a single untrusted evidence item cannot by itself grant broader access to, or control over, the decision-making process.

  7. Source Confidence vs. Verification: Gravit MAY assign confidence levels to sources as an auxiliary signal for prioritizing or scheduling verification work (for example, determining the order in which evidence items are checked, or the amount of independent corroboration sought). Such confidence levels MUST NOT be used as a substitute for the direct verification of the evidence itself, and MUST NOT independently increase or decrease the admissibility of evidence as determined under Section 4.2.

5. Conformance

5.1. Conformance Levels

An implementation of Gravit conforms to this specification only if it satisfies all requirements marked with the keywords MUST, MUST NOT, REQUIRED, SHALL, or SHALL NOT.

Requirements marked SHOULD, SHOULD NOT, or RECOMMENDED are considered best practices; any deviation from them MUST be explicitly justified by documented operational constraints and risks, and that justification MUST be recorded in the implementation's Conformance Statement (see Section 5.2).

Requirements marked MAY or OPTIONAL are optional capabilities and do not affect an implementation's conformance.

5.2. Conformance Statement

This document deliberately leaves a number of parameters to be defined at the deployment level rather than fixing them normatively. An implementation claiming conformance MUST publish and maintain a Conformance Statement that documents, at minimum:

  1. its Fallback Mode authorization procedure, including the conditions under which Fallback Mode may be entered and the parties responsible for approving it (see Section 2 and Section 4.4.1);

  2. its decision-impact classes and, for each, the corresponding evidence-strength requirements and, where applicable, the minimum Probabilistic Assessment confidence threshold (see Section 4.2.3 and Section 4.1.1);

  3. its Decision Record retention period (see Section 4.5.3);

  4. its criteria for treating two sources as independent for the purpose of the Independent Corroboration Threshold mechanism (see Section 4.6.2); and

  5. any SHOULD-level or RECOMMENDED-level deviations in effect and their justification, per Section 5.1.

An implementation MUST NOT claim conformance to this specification while any parameter listed in this section remains undocumented. The Conformance Statement is a deployment-level artifact and is distinct from the Decision Record defined in Section 4.5.1; this document does not mandate a specific format or distribution mechanism for it.

6. Security Considerations

This section discusses security considerations in terms of the threat model defined in Section 4.6.1, the residual risks that remain after applying the mitigations in Section 4.6.2, and considerations that fall outside the scope of the normative requirements in Section 4.

6.1. Evidence Manipulation

The primary security risk for systems like Gravit is the acceptance of maliciously crafted or corrupted evidence, which could lead to incorrect decisions. Implementations MUST treat all incoming evidence as untrusted until it has successfully passed the verification requirements defined in Section 4.2 and Section 4.6, covering, at minimum, the Forgery, Tampering, Replay, and Source Spoofing threat classes identified in Section 4.6.1.

6.2. Residual Risks

The mitigations required by this document reduce, but do not eliminate, the risks associated with the threat model in Section 4.6.1. Implementers and deployers should be aware of the following residual risks:

  • Fail-Closed as an Availability Target: The Fail-Closed Default and Resource Bounding Under Load requirements (see Section 4.4.2 and Section 4.6.2) mean that an adversary who cannot forge admissible evidence may instead attempt a denial-of-service attack by flooding Gravit with low-quality or malformed evidence, with the goal of consuming verification resources and forcing legitimate decisions into REJECTED or PENDING. This document deliberately accepts unavailability as the safe failure mode in preference to producing an unverified decision; deployers requiring resilience against this specific attack SHOULD apply deployment-level defenses (e.g., request prioritization, per-source rate limiting, or capacity overprovisioning) in addition to, and outside the scope of, the requirements in this document.

  • Collusion Resistance Is Not Absolute: The Independent Corroboration Threshold requirement (see Section 4.6.2) is stated at the SHOULD level and depends on an implementation's ability to correctly identify relationships between sources. An adversary capable of establishing sources that appear independent by every criterion the implementation checks, but are not in fact independently controlled, can defeat corroboration. Deployments supporting decisions with severe potential impact SHOULD elevate this requirement to a local MUST and invest in stronger, deployment-specific independence criteria.

  • Trust Anchor and Credential Management: The Authenticity Binding mechanism (see Section 4.6.2) presumes the existence of a mechanism for establishing and distributing the credentials, keys, or identity proofs against which source authenticity is checked. The provisioning, rotation, revocation, and compromise recovery of such trust anchors are deployment-specific security concerns that this document does not define; an otherwise-conformant implementation remains vulnerable to Forgery and Source Spoofing if its trust anchor management is weak.

6.3. Opaque Decision Logic

A second significant risk is the presence of hidden or opaque decision logic that prevents external auditing and obscures the reasoning process. To address this, Gravit implementations SHOULD retain comprehensive provenance and metadata, per Section 4.5.1, to support later forensic review, especially in systems where decisions affect safety, access control, governance, or financial outcomes. Relying on heuristics or fallback modes outside of documented and justified circumstances, contrary to the Prohibition on Unverified Heuristics requirement in Section 4.4.2, introduces brittleness and should be considered a security vulnerability in its own right.

7. IANA Considerations

This document has no actions for IANA.

8. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.

9. Informative References

[GEVP]
Konviser, A., "Gravit Evidence Verification Protocol (GEVP)", Work in Progress, Internet-Draft, draft-gravit-gevp-06, , <https://datatracker.ietf.org/doc/draft-gravit-gevp/>.
[EU-AI-ACT-ART50]
European Parliament and Council of the European Union, "Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act), Article 50 (Transparency obligations for providers and deployers of certain AI systems)", , <https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng>.

Appendix A. Acknowledgments

This specification was informed by the requirement language defined in BCP 14 [RFC2119] [RFC8174] and the general industry need for transparent, traceable, and auditable decision-making systems in adversarial environments.

Appendix B. Change Log

[This section to be removed by the RFC Editor before publication; retained here for -00 tracking purposes.]

-00: Initial version.

This document is a companion policy standard to draft-gravit-gevp (currently at -06, POSTED), which is maintained as a separate document line and is not renumbered or superseded by this document's version counter.

Author's Address

Alex Konviser
Gravit Open Network
CH- Zurich
Switzerland
URI: https://gravit.space/