GoodShyt Group Inc.

deonte@goodshyt.funhttps://orcid.org/0009-0005-8586-3650

GeneralInternet Engineering Task Force 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.

IntroductionComputational 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.

Conventions and TerminologyThe 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 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.

Evidence ModelAn 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.

JSON RepresentationThe 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.

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.

Example abstention

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.
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.

Decision ReasonsThe 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.

Interoperability and VersioningThe 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.

Security ConsiderationsUntrusted 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.

Privacy ConsiderationsRecord 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.

IANA ConsiderationsThis document has no IANA actions.

Experimental Status and LimitationsThe 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.

Normative References