| Internet-Draft | QIK-VRT Epistemic Status | October 2026 |
| Lohmann | Expires 8 April 2027 | [Page] |
This document defines an Experimental application-layer profile for representing the epistemic status of claims emitted or processed by machine cognition systems. The profile requires a claim not to be represented with a stronger epistemic status than its validated, provenance-bound evidence supports.¶
The profile distinguishes object truth from epistemic truthfulness. It does not guarantee that external sources are true, that reasoning is infallible, or that the external world is completely observable. It specifies how an implementation reports what is proved, observed, source-bound, interpretative, normative, predicted, or open.¶
The profile is designed to compose with QIK-VRT EFFECT_ACK without modifying the five-state EFFECT_ACK version-1 wire contract. EFFECT_ACK controls downstream effect authorization; this profile controls the strength of epistemic claims.¶
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 8 April 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
A machine can produce a linguistically confident assertion even when its available evidence is weaker than the assertion. This profile defines a machine-checkable boundary between an assertion and the evidence status that an implementation is permitted to claim for it.¶
The central invariant is:¶
ASSERT_AS_FORMAL_PROVED(C) implies VALID_BOUND_FORMAL_PROOF(C) if VALID_BOUND_FORMAL_PROOF(C) is false, C MUST NOT be classified as FORMAL_PROVED.¶
VALID_BOUND_FORMAL_PROOF(C) means that a checked proof artifact establishes the exact formal proposition resolved by claim_id, in the identified formal model and under the bound assumptions and proof-checking environment. Formal acceptance does not establish unencoded premises or external-world correspondence.¶
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals.¶
A conforming deployment MUST represent each governed claim using one of the following statuses. A deployment-defined refinement MUST bind its parent status from this vocabulary and retain all evidence conditions of that parent. Additional conditions MAY narrow the refinement; they MUST NOT replace or relax the parent conditions:¶
These evidence classes do not form a universal ranking. Formal proof, empirical support, documentary attribution, interpretation, and normative authority answer different questions. Status selection MUST use the conditions of the selected class and the scope of the claim rather than a single strength score.¶
A deployment profile MUST bind at least claim_id, claim_scope, subject identity, subject state or version where applicable, observation time, evidence references, source identity, and epistemic status. The claim_id MUST resolve the exact proposition or an immutable reference to that proposition. The claim_scope MUST state the applicable domain, conditions, and limits. Evidence references MUST identify the evidence required by the selected status and its relation to this exact proposition and scope. For FORMAL_PROVED they MUST resolve the checked proof, formal model, assumptions, and proof-checking environment. A deployment-defined refinement MUST additionally bind its parent status and the unchanged evidence conditions of that parent. A deployment SHOULD also bind the evaluator and applicable policy version.¶
claim = ( claim_id, claim_scope, subject, subject_state, observed_at, evidence_refs, source_refs, evaluator, policy_version, epistemic_status )¶
When a reported result contains properties with different evidence requirements, a producer MUST bind and classify those properties separately. A result concerning source fixity, formal acceptance, tested behavior, platform execution, effect authorization, or persisted target state MUST NOT be used as evidence for another property solely because the properties share a task, artifact, evaluator, or repository.¶
A content digest or byte-exact comparison establishes only the content identity covered by that validation and its stated assumptions. A producer MUST NOT use it alone to classify a claim about a natural person's identity, authorship, an authenticated principal, causal independence, or permission as established. Such claims require evidence appropriate to the exact identity, attribution, independence, or authority proposition.¶
Request receipt, execution success, authorization for effect, and observation of an effect are distinct propositions. A producer MUST NOT represent a target effect as EMPIRICALLY_EVIDENCED solely from an acknowledgement, a process exit code, a successful harness, or an authorization record. Evidence for that effect MUST include a validated readback bound to the target subject and state, the declared effect boundary, observation time, and the applicable persistence or durability scope. A lost response does not establish absence of effect; an apparent success response does not establish its presence.¶
A claim about execution on a particular platform MUST bind the observed operating-system and architecture predicates relevant to that claim. A build target, runner label, or successful execution on another platform MUST NOT by itself establish execution on the claimed platform.¶
If a required property remains unestablished, a producer MUST retain its OPEN disposition and MUST NOT promote an aggregate completion claim. Separately established properties retain their own validated status and scope. Missing admission, absent execution evidence, failed validation, and an unobserved effect SHOULD be reported as distinct unresolved conditions.¶
This profile composes with the independently specified QIK-VRT EFFECT_ACK mechanism [I-D.lohmann-qikvrt-effect-ack-03] and does not change its five-state version-1 wire contract. EFFECT_ACK determines whether a downstream effect is authorized under a bound policy and evidence set. This profile determines which epistemic status may be asserted for a claim.¶
An EFFECT_ACK_DONE record does not, by itself, make an external proposition true. Likewise, a FORMAL_PROVED or EMPIRICALLY_EVIDENCED claim does not, by itself, authorize a downstream effect.¶
An authorization record also does not, by itself, establish that the authorized target effect occurred or persisted. A claim that the effect occurred remains subject to the property-specific evidence and readback requirements of Section 6. This requirement governs claim reporting; it adds no EFFECT_ACK state, wire member, or release predicate.¶
The cited draft is informative work in progress. Its research-profile labels are not additional EFFECT_ACK version-1 enum values and are not an implicit identical registration of this profile's status vocabulary. This composition description creates no new mandatory wire member or protocol dependency.¶
Implementations MUST fail closed with respect to epistemic strength when required evidence cannot be validated. Missing evidence, stale subject identity, unresolved source identity, or unsupported status semantics MUST NOT be converted into a stronger claim status.¶
Attackers may attempt evidence substitution, stale-evidence replay, source laundering, status escalation, or provenance truncation. Deployments MUST bind claim status to the exact evidence and subject state needed to detect these failures.¶
This document has no IANA actions.¶