Network Working Group D. Wright Internet-Draft Sencor AI S.L. Intended status: Experimental 28 October 2026 Expires: 1 May 2027 Verdict Records: Results on Claims that Cite Receipts as Evidence draft-wright-verdict-record-00 Abstract This document defines a verdict record: a statement, bound to its issuer, of a result reached on a claim, together with the evidence the result relies on and the rule by which the result can be re- derived. Evidence is cited by digest and can be a receipt or record in any format, such as a SCITT Receipt or an Agent Action Capsule. The document defines how a checker checks a verdict record and what such a check does and does not show. It defines no receipt format and changes none. 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 1 May 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Wright Expires 1 May 2027 [Page 1] Internet-Draft Verdict Records 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 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Verdict Record . . . . . . . . . . . . . . . . . . . . . 4 2.1. Encoding and Digests . . . . . . . . . . . . . . . . . . 4 2.2. Members . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. The Claim . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Carrying a Verdict Record . . . . . . . . . . . . . . . . . . 5 4. Checking a Verdict Record . . . . . . . . . . . . . . . . . . 6 4.1. Results of a Step . . . . . . . . . . . . . . . . . . . . 6 4.2. Inputs . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Steps . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.4. State and Report . . . . . . . . . . . . . . . . . . . . 7 4.5. Checker Policy . . . . . . . . . . . . . . . . . . . . . 8 5. What a Check Shows and Does Not Show . . . . . . . . . . . . 8 6. Relation to Receipt Formats . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 9 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction Several formats record that something happened or that something was said. A SCITT Signed Statement, registered on a Transparency Service, yields a Receipt [RFC9943]. An Agent Action Capsule records one agent action and its disposition [I-D.mih-scitt-agent-action-capsule]. A Signed Evaluation Receipt records one evaluation result [I-D.gruszka-signed-evaluation-receipts]. Each records an act or a statement; a Receipt is issued by the Transparency Service on which the statement is registered. Wright Expires 1 May 2027 [Page 2] Internet-Draft Verdict Records October 2026 This document defines a companion to those formats: a verdict record, which states a result reached on a claim and cites such receipts and records as its evidence. It does not define how evidence is captured, and it does not replace any receipt format. A verdict record names the rule that produced its result. Where the rule is mechanical, any checker that holds the evidence can re-run it and compare. Where no mechanical rule can re-derive the result, the record says so, and a check then shows only what the result was based on, and when. A check of a verdict record never shows that a claim is true. It shows that the issuer asserted the result, on the stated evidence, under the stated rule. 1.1. Requirements Language 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. 1.2. Terminology Claim: A statement whose support is in question. A claim can be carried by a record or receipt in any format, or stated as text. Evidence item: A sequence of bytes, such as a receipt, a signed statement or a record, that a verdict record cites by its digest. Issuer: The party whose key binds a verdict record. The record names it in its writer member. Checker: Whoever runs the checks of Section 4. A checker needs no access to the issuer's systems. Presenter: Whoever hands the checker a verdict record and its evidence items. That can be the issuer, a party that relies on the record, or anyone. Rule: A named, specified procedure that re-derives a result from the body of a record. The name judgement means that no mechanical rule can re-derive the result. Wright Expires 1 May 2027 [Page 3] Internet-Draft Verdict Records October 2026 2. The Verdict Record 2.1. Encoding and Digests A verdict record is a JSON object [RFC8259] in canonical form. In canonical form, object members are sorted by name, compared as sequences of Unicode code points; there is no whitespace outside strings; strings escape only the quotation mark, the reverse solidus and control characters, and write every other character as its UTF-8 bytes; numbers are integers; and arrays keep their order. Re- serializing the parsed record MUST give the same bytes. A verdict record MUST be strict JSON: valid UTF-8 that does not start with a byte-order mark, in which no object at any depth has the same member name twice and no escape forms a lone surrogate. A checker MUST refuse JSON nested deeper than 32 levels at any point. An integer is written as an optional minus sign and digits only, with no leading zero, no fraction and no exponent, and lies between -(2^53 - 1) and 2^53 - 1. A time is UTC, written YYYY-MM- DDTHH:MM:SS.ffffffZ with exactly six fraction digits. Hex is lowercase, two characters per byte, with no prefix. A member of the wrong JSON type is refused at the step that reads it. The digest of a verdict record, and of an evidence item, is the SHA-256 hash [FIPS180-4] of its exact bytes, written in hex. This document defines no salted or hiding form of digest. 2.2. Members A verdict record has exactly the members below. No other member is allowed. The members v, kind, key, version, writer and body MUST be present. A record without evidence or check can be parsed, but fails step 1 or step 2 of Section 4.3. v: A string. This document defines the value "verdict-record/1". kind: A string: the record kind. This document defines two kinds: "check-run", a run of a rule whose body holds the values the rule reads, and "model-decision", a decision made by an AI model. A kind starting with "x-" is private. key: A non-empty string: the record's key within its kind, chosen by the issuer. It MUST be opaque. version: An integer of 1 or more: the version of this record for this key. Wright Expires 1 May 2027 [Page 4] Internet-Draft Verdict Records October 2026 supersedes: Null for version 1; for a later version, the digest of the previous version. writer: A non-empty string: the issuer, the party whose key binds the record. actor: An object: who reached the result. Its members are type ("person" or "system") and id, and for a system also model and model_version. act_time: A time: when the result was reached, by the issuer's statement. evidence: An array of the evidence items this record relies on. Each entry is an object with exactly two members: sha256, the digest of the item (Section 2.1), and format, a string that names the format by whose rules the item is verified (Section 6). check: An object with the members rule (a string, the name of the rule), inputs (an object, optional, naming members of body that the rule reads) and result (the result the rule gave). body: An object: the content of the record. Its members depend on kind. It holds the claim (Section 2.3) and the values the rule reads. 2.3. The Claim The member body.claim names the claim the verdict is about. It is an object with exactly one of two members: text, a string that states the claim, or ref, an evidence entry (as in evidence) for the record or receipt that carries the claim. When ref is used, the same entry MUST also appear in evidence. 3. Carrying a Verdict Record This document does not define how a verdict record is signed, time- stamped or made available. From the container that carries the record, a checker needs three things: the exact bytes of the record; a key that bound those bytes, shown to belong to the party the record names in writer; and an upper time bound, a time no later than which the record existed, which the checker establishes itself. A SCITT Signed Statement whose payload is the verdict record, registered on a Transparency Service whose Receipt the checker verifies, is one such container [RFC9943]. Wright Expires 1 May 2027 [Page 5] Internet-Draft Verdict Records October 2026 If the container does not show the record, the state is held, with the reason (Section 4.4). 4. Checking a Verdict Record 4.1. Results of a Step PASS: the step ran and its condition holds. FAIL: the step ran and its condition does not hold. The result names the step. NOT RUN: an input the step needs is missing, or is not shown to come from outside the issuer's reach (Section 4.2). The result names the step and the input it needs. When a step cannot run, the check goes on with its other steps. If a later step FAILs, the check FAILs at that step. Otherwise it is NOT RUN at the first step that could not run. Two checkers that implement this document and hold the same inputs MUST give the same result and name the same step. No step reads the checker's clock. 4.2. Inputs Every input that a step relies on MUST come from outside the issuer's reach. In this document an input is outside the issuer's reach in two ways only: the checker computes it from bytes it holds (a digest, a signature, or the re-run of a rule), or it is the checker's own input (its policy (Section 4.5), its trust anchors, this document, and the rule specifications it holds). A checker MUST NOT take its own inputs from the record or from the issuer. A statement made by the issuer alone, such as the content of the record, can be reported. It MUST NOT make a step PASS that would otherwise not pass. A step MUST NOT rely on the absence of a statement that the issuer or the presenter could withhold. 4.3. Steps Step 1. The member check MUST be present. It MUST name a rule and give a result. The rule judgement is allowed only for kinds that the checker's policy lists. Wright Expires 1 May 2027 [Page 6] Internet-Draft Verdict Records October 2026 Step 2. The member evidence MUST be an array of entries as in Section 2.2. For each entry, the checker MUST hold an item whose digest equals the entry's sha256; if it does not, step 2 is NOT RUN, naming the entry. Each item is verified by the rules of the format its entry names. An item that does not verify, or whose format the checker's policy does not list, is not relied on: step 2 is then NOT RUN, naming it. An item that is itself a verdict record is checked by this section, as a record of its own. Where an item's verification gives it an upper time bound, that bound MUST NOT be later than the upper time bound of the record that cites it; if it is later, step 2 is NOT RUN. The checker's policy sets how deep such citations are followed; beyond that depth, step 2 is NOT RUN. Step 3. If the rule is not judgement, the checker MUST hold the rule's specification. It re-runs the rule on body, reading the members that check.inputs names. A rule input of the wrong JSON type is a FAIL of this step, not a result of the rule. The result MUST equal check.result; if it does not, step 3 FAILs. The check passes when steps 1 to 3 PASS. 4.4. State and Report A checker reports the record's state: released, when steps 1 to 3 PASS; held, when no step FAILs and at least one is NOT RUN; refused, when a step FAILs; or no verdict, when the checker's own policy is invalid. With the state it reports each step's result and, for each step that FAILed or did not run, the step and the input it needed. A checker MUST NOT report any word or member that speaks for the whole record and that a reader could take as "this is true", such as verified, valid, true, trusted, correct, proven, confirmed or OK. A summary line, where one is printed, names the state and every step's result. A state speaks as of the record's upper time bound. The report states that time, and the SHA-256 digest of the checker's policy and of each set of trust anchors it used, so that another checker can see what the state rests on. Wright Expires 1 May 2027 [Page 7] Internet-Draft Verdict Records October 2026 4.5. Checker Policy A checker's policy is its own input. It lists the kinds for which judgement is allowed, the evidence formats the checker can verify, and the depth of citation it follows. A checker whose policy is invalid gives no verdict. 5. What a Check Shows and Does Not Show A released verdict record shows that its issuer asserted the result, on the stated evidence, under the stated rule, no later than its upper time bound. It never shows that the claim is true. For the rule judgement, a check shows only what the result was based on, and when. It does not show that the judgement is correct. The values in body that a rule reads are the issuer's statement. A check does not show that they are true. A check does not show that the issuer kept its key secret, or that no other version of the record exists beyond those the checker holds. 6. Relation to Receipt Formats Receipts and records made by other formats, such as SCITT Signed Statements and Receipts [RFC9943], Agent Action Capsules [I-D.mih-scitt-agent-action-capsule] and Signed Evaluation Receipts [I-D.gruszka-signed-evaluation-receipts], enter a verdict record as evidence items. A verdict record adds no property to them and requires none of them. The format member of an evidence entry is a media type [RFC6838] where one is registered for the item, and otherwise a URI that names the specification of the item's format. For an item that is itself a verdict record, the format is the string "verdict-record/1". A checker verifies an item only by the specification so named. 7. Security Considerations A verdict record is its issuer's statement. Its result can be wrong, and a mechanical rule can be re-run correctly on values that are false. A released state is a statement about what was asserted and on what evidence, not about the claim. A presenter can withhold evidence items or later versions of a record. Because no step relies on the absence of a statement that could be withheld (Section 4.2), withholding can leave a step NOT RUN but cannot make a step PASS. Wright Expires 1 May 2027 [Page 8] Internet-Draft Verdict Records October 2026 The rule judgement admits any result. A checker's policy limits it to the kinds for which the checker accepts a result that no rule re- derives. The check is deterministic and reads no clock (Section 4.1), so two checkers holding the same inputs report the same state. Every evidence item is given to the checker in full. An issuer ought to consider, before citing an item, whether it is fit to pass to every party that may check the record. Key compromise, revocation and the trustworthiness of time sources are properties of the container (Section 3) and are outside the scope of this document. 8. IANA Considerations This document has no IANA actions. A later version may ask IANA for registries of record kinds, rule names and evidence format names, which this version lists in Section 2.2, Section 4.3 and Section 6. 9. References 9.1. Normative References [FIPS180-4] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-4, DOI 10.6028/NIST.FIPS.180-4, August 2015, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . 9.2. Informative References Wright Expires 1 May 2027 [Page 9] Internet-Draft Verdict Records October 2026 [I-D.gruszka-signed-evaluation-receipts] Gruszka, K., "Signed Evaluation Receipts", Work in Progress, Internet-Draft, draft-gruszka-signed-evaluation- receipts-04, 26 October 2026, . [I-D.mih-scitt-agent-action-capsule] Mih, S., "An Agent Action Capsule Profile for SCITT", Work in Progress, Internet-Draft, draft-mih-scitt-agent-action- capsule-05, 26 September 2026, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, "Handling Long Lines in Content of Internet-Drafts and RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, . [RFC9943] Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", RFC 9943, DOI 10.17487/RFC9943, June 2026, . Appendix A. Example The record below is a decision by a model on a claim carried by another record. Its rule is judgement, so a checker re-runs no rule; it holds both evidence items, verifies each by its own format, and reports the state. Long lines are folded for display as described in [RFC8792]; the record itself has no whitespace and no line breaks. The claim record cited by both body.claim.ref and the first evidence entry is these bytes: =============== NOTE: '\' line wrapping per RFC 8792 ================ {"made_by":"builder.example","statement":"Release 2.1 of example-ser\ vice passed its acceptance suite."} The verdict record, with whitespace added for display: Wright Expires 1 May 2027 [Page 10] Internet-Draft Verdict Records October 2026 =============== NOTE: '\' line wrapping per RFC 8792 ================ { "act_time": "2026-10-23T10:00:00.000000Z", "actor": { "id": "checker-7", "model": "example-model", "model_version": "1", "type": "system" }, "body": { "claim": { "ref": { "format": "application/json", "sha256": "f4747f1fa1ad63eaad90e41b587794f8f5c82f9215b9a8e23\ a6c204edabc7d48" } } }, "check": { "result": "supported", "rule": "judgement" }, "evidence": [ { "format": "application/json", "sha256": "f4747f1fa1ad63eaad90e41b587794f8f5c82f9215b9a8e23a6\ c204edabc7d48" }, { "format": "https://datatracker.ietf.org/doc/draft-gruszka-sign\ ed-evaluation-receipts/", "sha256": "0c964f45c450a0253fc09eb2316e6ad271944be201c46ebf2c5\ d40e529f35306" } ], "key": "verdict-0001", "kind": "model-decision", "supersedes": null, "v": "verdict-record/1", "version": 1, "writer": "verifier.example" } Its digest, over its canonical bytes, is: 2a85c94e39c56f50185b3b69b8f56026946364631799774a83b4f93399841c45 Wright Expires 1 May 2027 [Page 11] Internet-Draft Verdict Records October 2026 Author's Address Darren Wright Sencor AI S.L. Spain Email: darren@sencor.ai Wright Expires 1 May 2027 [Page 12]