Gravit Verifiable Epistemic Decision Standard
draft-gravit-verifiable-epistemic-decision-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Alex Konviser | ||
| Last updated | 2026-08-09 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
GitHub Organization
GitHub Repository |
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-gravit-verifiable-epistemic-decision-00
Network Working Group A. Konviser
Internet-Draft Gravit Open Network
Intended status: Standards Track 9 August 2026
Expires: 10 February 2027
Gravit Verifiable Epistemic Decision Standard
draft-gravit-verifiable-epistemic-decision-00
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.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Konviser Expires 10 February 2027 [Page 1]
Internet-Draft Gravit VEDS August 2026
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Epistemic Validity . . . . . . . . . . . . . . . . . . . 5
4.1.1. Epistemic Classification Taxonomy . . . . . . . . . . 5
4.1.2. Classification Determination and Reclassification . . 6
4.1.3. Requirements . . . . . . . . . . . . . . . . . . . . 6
4.2. Evidence Admissibility . . . . . . . . . . . . . . . . . 7
4.2.1. Required Elements of Admissible Evidence . . . . . . 7
4.2.2. Determination Procedure . . . . . . . . . . . . . . . 7
4.2.3. Requirements . . . . . . . . . . . . . . . . . . . . 8
4.3. Traceability . . . . . . . . . . . . . . . . . . . . . . 8
4.3.1. Contribution Attribution Format . . . . . . . . . . . 8
4.3.2. Audit Trail Reconstruction Procedure . . . . . . . . 9
4.3.3. Requirements . . . . . . . . . . . . . . . . . . . . 9
4.4. Failure Handling . . . . . . . . . . . . . . . . . . . . 10
4.4.1. Failure State Taxonomy . . . . . . . . . . . . . . . 10
4.4.2. Requirements . . . . . . . . . . . . . . . . . . . . 11
4.5. Auditability and Assurance . . . . . . . . . . . . . . . 12
4.5.1. Decision Record Content . . . . . . . . . . . . . . . 12
4.5.2. Timestamping and Record Integrity . . . . . . . . . . 12
4.5.3. Retention and Access . . . . . . . . . . . . . . . . 13
4.5.4. Requirements . . . . . . . . . . . . . . . . . . . . 13
4.6. Security and Adversarial Resistance . . . . . . . . . . . 13
4.6.1. Threat Model . . . . . . . . . . . . . . . . . . . . 14
4.6.2. Required Verification Mechanisms . . . . . . . . . . 14
4.6.3. Requirements . . . . . . . . . . . . . . . . . . . . 15
5. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1. Conformance Levels . . . . . . . . . . . . . . . . . . . 16
5.2. Conformance Statement . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6.1. Evidence Manipulation . . . . . . . . . . . . . . . . . . 17
6.2. Residual Risks . . . . . . . . . . . . . . . . . . . . . 17
6.3. Opaque Decision Logic . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8. Normative References . . . . . . . . . . . . . . . . . . . . 19
Konviser Expires 10 February 2027 [Page 2]
Internet-Draft Gravit VEDS August 2026
9. Informative References . . . . . . . . . . . . . . . . . . . 19
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 19
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19
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
Konviser Expires 10 February 2027 [Page 3]
Internet-Draft Gravit VEDS August 2026
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
Konviser Expires 10 February 2027 [Page 4]
Internet-Draft Gravit VEDS August 2026
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
Konviser Expires 10 February 2027 [Page 5]
Internet-Draft Gravit VEDS August 2026
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.
Konviser Expires 10 February 2027 [Page 6]
Internet-Draft Gravit VEDS August 2026
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:
a. *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.
b. *Integrity*: a means of detecting modification since origination
(e.g., a cryptographic digest or signature covering the item's
content).
c. *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.
d. *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.
Konviser Expires 10 February 2027 [Page 7]
Internet-Draft Gravit VEDS August 2026
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:
a. a reference to the specific evidence item, resolvable to the item
as determined admissible under Section 4.2.2;
b. the item's epistemic classification at the time of use, per
Section 4.1.1;
Konviser Expires 10 February 2027 [Page 8]
Internet-Draft Gravit VEDS August 2026
c. a description of the role the item played in the outcome (e.g.,
necessary condition, weighted factor, corroborating support,
disqualifying condition); and
d. 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.
Konviser Expires 10 February 2027 [Page 9]
Internet-Draft Gravit VEDS August 2026
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.
Konviser Expires 10 February 2027 [Page 10]
Internet-Draft Gravit VEDS August 2026
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.
Konviser Expires 10 February 2027 [Page 11]
Internet-Draft Gravit VEDS August 2026
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:
a. a unique, stable identifier for the decision or Failure State;
b. the outcome (definitive decision value, or Failure State per
Section 4.4.1);
c. references to every evidence item that influenced the outcome,
and its individual contribution where determinable, per
Section 4.3;
d. the epistemic classification (verified fact, probabilistic
assessment, speculative claim; see Section 4.1) of each
referenced evidence item;
e. a verifiable timestamp of both evidence collection and decision
production, per Section 4.5.2;
f. 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.
Konviser Expires 10 February 2027 [Page 12]
Internet-Draft Gravit VEDS August 2026
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
Konviser Expires 10 February 2027 [Page 13]
Internet-Draft Gravit VEDS August 2026
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
Konviser Expires 10 February 2027 [Page 14]
Internet-Draft Gravit VEDS August 2026
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.
Konviser Expires 10 February 2027 [Page 15]
Internet-Draft Gravit VEDS August 2026
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:
a. 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);
Konviser Expires 10 February 2027 [Page 16]
Internet-Draft Gravit VEDS August 2026
b. 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);
c. its Decision Record retention period (see Section 4.5.3);
d. its criteria for treating two sources as independent for the
purpose of the Independent Corroboration Threshold mechanism (see
Section 4.6.2); and
e. 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
Konviser Expires 10 February 2027 [Page 17]
Internet-Draft Gravit VEDS August 2026
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.
Konviser Expires 10 February 2027 [Page 18]
Internet-Draft Gravit VEDS August 2026
8. 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,
<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,
May 2017, <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, 2026,
<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)", 13 June 2024,
<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
Konviser Expires 10 February 2027 [Page 19]
Internet-Draft Gravit VEDS August 2026
Alex Konviser
Gravit Open Network
CH- Zurich
Switzerland
Email: ietf@gravit.space
URI: https://gravit.space/
Konviser Expires 10 February 2027 [Page 20]