| Internet-Draft | Veriflow Evidence Envelope | October 2026 |
| Watts | Expires 17 April 2027 | [Page] |
This document specifies an experimental, JSON-based evidence envelope for exchanging source-grounded computational assertions, including provenance, reproducible operation identifiers, evidence sufficiency, and explicit abstention when an answer is not supported. The envelope separates syntactic validity, source integrity, mathematical correctness, and empirical truth. This document does not standardize a general scientific inference engine or claim experimental superiority.¶
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 17 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.¶
Computational agents can return plausible numerical claims even when the requested value cannot be derived from available observations. An interoperable evidence envelope allows recipients to distinguish a value computed from cited records from an unsupported estimate or a refusal. This specification defines a minimal, deterministic interchange format; its evidence claims are not self-authenticating.¶
The motivating pilot used historical open-high-low-close-volume (OHLCV) records and demonstrated no accuracy advantage over an independent safe calculator. That finding motivates careful separation of auditability from predictive performance.¶
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals.¶
Claim: an asserted result of a named operation. Evidence: identified input records or artifacts. Unknown: evidence is insufficient to establish either truth or falsity. Refusal: a deliberate decision not to assert an unsupported value. Source locator: a stable identifier for a record within a referenced artifact.¶
An envelope carries a version, request identifier, status, operation identifier, optional typed result, a list of evidence references, and a decision reason. Its decision status is one of ANSWER, ABSTAIN, or ERROR. These describe response behavior, not external truth.¶
Every evidence reference MUST contain an artifact identifier, a digest algorithm, a digest value, and one or more locators. For this version, the digest algorithm MUST be sha-256 and its value MUST consist of 64 lowercase hexadecimal characters. Implementations MUST verify digest matches against the exact input bytes before claiming integrity_verified.¶
An ANSWER response MUST include an operation identifier, result type, result value, unit, and at least one evidence reference. An ABSTAIN response MUST NOT include a result value, and MUST include a machine-readable reason. An ERROR response MUST NOT include a result value. A recipient MUST NOT treat an unknown evidence condition as verified.¶
Evidence completeness does not imply correctness: a signed or hashed artifact can contain inaccurate observations. This specification does not define independent experimental validation.¶
The media representation is a UTF-8 JSON object. Producers MUST reject duplicate object member names. Numeric answers SHOULD be encoded as decimal strings where exact decimal arithmetic is required. Unknown members MAY be ignored, but MUST NOT override defined status semantics.¶
{
"version": "0.1",
"request_id": "example-001",
"status": "ANSWER",
"operation_id": "intraday_range",
"result": {"type": "decimal", "value": "4.25", "unit": "CNY"},
"evidence": [{
"artifact_id": "dataset-example",
"digest_alg": "sha-256",
"digest": "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
"locators": ["row:12"],
"integrity_verified": false
}],
"reason": "derived_from_high_minus_low"
}
The example digest is illustrative, not a hash of a provided artifact. The value MUST NOT be interpreted as a financial observation.¶
{
"version": "0.1",
"request_id": "example-002",
"status": "ABSTAIN",
"operation_id": "vwap",
"evidence": [],
"reason": "INSUFFICIENT_INPUT_DATA"
}
Recipients SHOULD retain an immutable audit log that includes the received envelope, verification outcome, and implementation version. Implementations SHOULD avoid logging credentials or sensitive source content.¶
The following reason strings are defined for ABSTAIN or ERROR: INSUFFICIENT_INPUT_DATA, UNKNOWN_OPERATION, SOURCE_UNAVAILABLE, SOURCE_DIGEST_MISMATCH, INVALID_UNIT, INVALID_LOCATOR, and INTERNAL_ERROR. Future versions MAY define additional reason strings. A recipient MUST treat an unrecognized reason as non-successful unless the status is ANSWER and all required checks pass.¶
The version field MUST be "0.1" for this specification. Producers MUST NOT silently alter the meaning of existing fields. A receiver encountering an unsupported major version MUST reject the envelope or abstain. This document does not register a media type or protocol endpoint; applications can carry envelopes in existing authenticated transport protocols.¶
Untrusted JSON and artifact locators can cause parser abuse, path traversal, server-side request forgery, and resource exhaustion. Implementations MUST impose input-size and nesting limits, MUST validate locators, MUST NOT fetch arbitrary network locations from an untrusted envelope without an explicit allowlist, and MUST keep credentials outside serialized evidence. Hash integrity does not authenticate the submitter or prove factual truth. Transport authentication and authorization are deployment responsibilities. An attacker can selectively omit evidence or supply internally consistent fabricated inputs; independent provenance checks remain necessary. Implementations MUST NOT translate ABSTAIN, ERROR, or unknown validation into authorization to act.¶
Record locators, hashes, and request identifiers can expose dataset membership or enable cross-context correlation. Producers SHOULD minimize unnecessary identifiers, avoid personal data, and apply retention limits appropriate to the deployment. Publication of an envelope does not confer rights to redistribute referenced artifacts.¶
This document has no IANA actions.¶
The motivating Veriflow-inspired pilot reported 72 correct answers out of 72 answerable table tasks and zero unsupported claims on 72 negative controls; an independent safe calculator matched both figures. These are repeated, deterministic tasks over an unauthenticated, user-provided dataset, not independent populations or evidence of superiority. This draft specifies exchange semantics only. Scientific novelty, external preregistration, and deployed interoperability have not been established.¶