Veriflow Evidence Envelope for Source-Grounded Computational Claims
draft-watts-veriflow-evidence-envelope-01

Internet Engineering Task Force                              D. O. Watts
Internet-Draft                                       GoodShyt Group Inc.
Intended status: Experimental                            30 October 2026
Expires: 3 May 2027

  Veriflow Evidence Envelope for Source-Grounded Computational Claims
               draft-watts-veriflow-evidence-envelope-01

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 3 May 2027.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Watts                      Expires 3 May 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
   Appendix A.  Changes since -00  . . . . . . . . . . . . . . . . .   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, as shown here.

Watts                      Expires 3 May 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 3 May 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 3 May 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 3 May 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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", RFC 8174, May 2017,
              <https://www.rfc-editor.org/info/rfc8174>.

Appendix A.  Changes since -00

   This section is to be removed before publishing as an RFC.

   Editorial and tooling-conformance changes only; no technical content
   was changed.

   *  Removed obsolete rfc2629-xhtml.ent DOCTYPE (no entities used;
      xml2rfc warning)

   *  Replaced Requirements Language paragraph with the exact BCP 14
      (RFC 8174) boilerplate (idnits)

   *  Normalized author metadata (full name with ASCII form, initials,
      organization GoodShyt Group Inc., San Francisco CA postal, email,
      ORCID URI)

   *  Updated document date and revision number.

Author's Address

Watts                      Expires 3 May 2027                   [Page 6]
Internet-Draft         Veriflow Evidence Envelope           October 2026

   Deonté O'dell Watts
   GoodShyt Group Inc.
   San Francisco, CA
   United States of America
   Email: deonte@goodshyt.fun
   URI:   https://orcid.org/0009-0005-8586-3650

Watts                      Expires 3 May 2027                   [Page 7]