Internet Engineering Task Force D. O. Watts Internet-Draft GoodShyt Group Inc. Intended status: Experimental 14 October 2026 Expires: 17 April 2027 Veriflow Evidence Envelope for Source-Grounded Computational Claims draft-watts-veriflow-evidence-envelope-00 Abstract 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. 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 17 April 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Watts Expires 17 April 2027 [Page 1] Internet-Draft Veriflow Evidence Envelope October 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 2 3. Evidence Model . . . . . . . . . . . . . . . . . . . . . . . 3 4. JSON Representation . . . . . . . . . . . . . . . . . . . . . 3 5. Processing and Verification . . . . . . . . . . . . . . . . . 4 6. Decision Reasons . . . . . . . . . . . . . . . . . . . . . . 5 7. Interoperability and Versioning . . . . . . . . . . . . . . . 5 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 11. Experimental Status and Limitations . . . . . . . . . . . . . 6 12. Normative References . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction 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. 2. Conventions and Terminology The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals. Watts Expires 17 April 2027 [Page 2] Internet-Draft Veriflow Evidence Envelope October 2026 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. 3. Evidence Model 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. 4. JSON Representation 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. Watts Expires 17 April 2027 [Page 3] Internet-Draft Veriflow Evidence Envelope October 2026 { "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" } Figure 1: Example answer envelope (illustrative, not a measurement) 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" } Figure 2: Example abstention 5. Processing and Verification 1. Parse UTF-8 JSON and validate required members and status. 2. Resolve input artifacts only through explicitly authorized sources. 3. Verify byte-level digests before setting integrity_verified to true. 4. Validate operation identifiers, record locators, units, and domain constraints. 5. Compute results using a documented deterministic procedure, or abstain if required inputs are missing. Watts Expires 17 April 2027 [Page 4] Internet-Draft Veriflow Evidence Envelope October 2026 6. Record independent mathematical and empirical checks separately; do not promote an unknown state to verified. 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. 6. Decision Reasons 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. 7. Interoperability and Versioning 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. 8. Security Considerations 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. 9. Privacy Considerations 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. Watts Expires 17 April 2027 [Page 5] Internet-Draft Veriflow Evidence Envelope October 2026 10. IANA Considerations This document has no IANA actions. 11. Experimental Status and Limitations 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. 12. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", RFC 8174, May 2017, . Author's Address Deonté O'dell Watts GoodShyt Group Inc. Email: deonte@goodshyt.fun URI: https://orcid.org/0009-0005-8586-3650 Watts Expires 17 April 2027 [Page 6]