Sencor AI S.L.

Spain darren@sencor.ai

verdict claim receipt evidence 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.

Introduction Several formats record that something happened or that something was said. A SCITT Signed Statement, registered on a Transparency Service, yields a Receipt . An Agent Action Capsule records one agent action and its disposition . A Signed Evaluation Receipt records one evaluation result . Each records an act or a statement; a Receipt is issued by the Transparency Service on which the statement is registered. 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. An architecture for auditing agent interactions describes an Auditor that determines whether recorded behaviour matched the user's intent and the authorization in force, and whether recorded evidence supports or contradicts a claim. A verdict record is one way to record such a determination, so that a party that trusts neither the agent nor its operator can check what it was based on. The records that architecture defines can be its evidence.

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 when, and only when, they appear in all capitals, as shown here.

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

The Verdict Record

Encoding and Digests A verdict record is a JSON object 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 of its exact bytes, written in hex. This document defines no salted or hiding form of digest.

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 .

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.

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 (), and format, a string that names the format by whose rules the item is verified ().

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 () and the values the rule reads.

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.

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 . If the container does not show the record, the state is held, with the reason ().

Checking a Verdict Record

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

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 (), 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.

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. Step 2. The member evidence MUST be an array of entries as in . 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.

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.

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.

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. A check does not show that the evidence a record cites is all the evidence there was, or that the issuer wrote a record for every result it reached. A verdict record provides no completeness property. Where completeness matters, it comes from outside the record: from the container, or from the formats of the evidence items, for example a sequence that makes an omitted record visible.

Relation to Receipt Formats Receipts and records made by other formats, such as SCITT Signed Statements and Receipts , Agent Action Capsules and 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 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. The digest in an evidence entry is the digest of the exact bytes that the item's format verifies. For a format whose items are signed envelopes, such as COSE_Sign1 or DSSE, those bytes include the envelope. Some formats identify an item by a different digest, for example a digest of the envelope's payload; that digest does not replace the one a verdict record uses. An issuer that wants to relate the two can cite the payload as an item of its own.

Related Work Several documents define records of what an AI agent did, was permitted to do, or was decided about. A verdict record differs from each in the same way: it records a result reached on a claim, cites such records as evidence, and names a rule that a checker re-runs where the rule is mechanical. This section describes the published revisions cited.

• The audit architecture defines Interaction, Action, Delegation and Authorization Transition Records, and an Auditor that reaches a determination over them. A verdict record can carry that determination, with those records as its evidence.
• The AI Agent Execution Profile of SCITT records material agent actions in a hash-chained, independently held evidence chain, and places content evaluation out of its scope. Its records can be evidence items.
• The pre-execution authorization profile binds an allow, deny or challenge decision to the canonical bytes of the request later dispatched. It records a decision about an action before it runs; a verdict record records a result on a claim, and can cite such a decision as evidence.
• The AI-agent action receipt profile records an action with its recorded verdict at a governed boundary, and states that it does not claim the agent was correct.
• The proofbundle decision receipt records a signed verdict on a proposed action, with a policy digest, evidence digests, what was not checked, and the conditions that would change the decision. It identifies the policy by digest; it does not specify a re-run of the policy by a checker.
• Permission receipts and MUSUBI settlement each specify a verifier that recomputes from records whether recorded actions stayed within a signed permission or grant. Each fixes one rule. A verdict record names its rule per record and compares the issuer's result with the re-run.
• The Gravit Epistemic Verification Protocol moves claims through states backed by records from verifiers, with a committed state reached by convergence. A check of a verdict record never shows that a claim is true; each record is one issuer's statement.
• What an agent audit record can and cannot establish states limits that hold for any record format, including that a verifier never reports an unchecked property as passed. and follow the same discipline.
• PALA-1 separates internal consistency, completeness and existence in time, and reports completeness as not checked where it cannot be checked. A verdict record makes no completeness claim ().

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 (), withholding can leave a step NOT RUN but cannot make a step PASS. 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 (), 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 () and are outside the scope of this document.

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

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. National Institute of Standards and Technology Informative References This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice. This document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content. Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results. This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting. Traceability in supply chains is a growing security concern. While Verifiable Data Structures (VDSs) have addressed specific issues, such as equivocation over digital certificates, they lack a universal architecture for all supply chains. This document defines such an architecture for single-issuer signed statement transparency. It ensures extensibility and interoperability between different transparency services as well as compliance with various auditing procedures and regulatory requirements. Action State Group, Inc. This document defines a SCITT statement profile for recording what an AI agent did: the Agent Action Capsule. A Capsule is a digest- committed record of one agent action carrying its verdict-level disposition (executed, blocked, denied, errored, timed out), the deterministic constraints that were evaluated, the effect that was committed together with a confirmed-effect binding that distinguishes a dispatched attempt from an observed result, and an honest human-in- the-loop flag. Capsules are identified independently of signing and MAY be authenticated by one or more COSE_Sign1 Producer Envelopes. Its Capsule ID can separately be made transparent by registration in a SCITT Transparency Service [I-D.ietf-scitt-scrapi]. A Capsule is recorded on every verdict, including refusals: a blocked or denied Capsule is the auditor-grade evidence that a gate worked. b7n0de This document defines a Signed Evaluation Receipt: one JSON object that records one evaluation result, whether a stated threshold held for a stated metric of a stated test suite, and signs it with Ed25519 over a domain-separated encoding of its canonical bytes. A receipt shows who signed the recorded bytes. It does not show that the recorded result is true. A receipt does not prove registration with a Transparency Service. In SCITT, transparency additionally requires registering a Signed Statement carrying the receipt or its digest with a Transparency Service and verifying the resulting SCITT Receipt. Registration and verification of the resulting SCITT Receipt are outside this document. Ericsson Fraunhofer SIT This document describes an architecture for auditing of agent-driven interactions on the Internet. Autonomous and semi-autonomous software agents, including those based on artificial intelligence, increasingly act on behalf of users, organizations, and services. Existing auditing mechanisms often capture isolated system events but do not consistently represent delegation relationships, user intent, or evolving authorization. In agent-driven systems, auditability requires linking intent, delegation, authorization, and execution. The proposed architecture enables this through distributed audit record generation, propagation of audit context, optional attestation, and additional logging for transparency. Veridic Inc. Veridic Inc. This document defines a SCITT (Supply Chain Integrity, Transparency, and Trust) profile for creating independently verifiable, tamper- evident records of autonomous AI agent actions. The profile defines the AgentInteractionRecord (AIR) as the COSE_Sign1 signed statement payload for material agent actions; maps SCITT roles to the agent execution context, with the Agent Operator as Issuer and an independent Evidence Custodian as Transparency Service; specifies Registration Policy requirements including hash chain integrity, temporal ordering, and sequence completeness; defines a redaction receipt mechanism for privacy-preserving evidence custody; and provides compliance mappings to EU AI Act Articles 12 and 19, DORA, NIST AI RMF, MAS AI Risk Management Guidelines, PCI DSS, and MiFID II. Keel API, Inc. This document specifies a SCITT (Supply Chain Integrity, Transparency, and Trust) profile for pre-execution authorization records of AI agent actions. The profile defines a Signed Statement type, the "Pre-Execution Authorization Record" (also called a Permit), that records a policy-evaluated decision to allow, deny, or challenge an AI agent action before that action is dispatched to a model provider, tool, or service. The profile cryptographically binds the authorization decision to the canonical bytes of the request that is authorized. When the paired Closure Record carries a dispatch digest, a Verifier can compare the authorized-request digest against the recorded dispatched-request digest; on the managed dispatch path the reference implementation additionally enforces this equality before the request is sent. This revision also introduces authorization-lineage vocabulary. It defines how a Verifier can determine whether the authority conveyed by a child Permit is equal to or narrower than the authority conveyed by its parent (attenuation), given a signed or chain-committed Authority Representation and a declared Comparator Profile. The Permit remains an evidence artifact; this profile specifies the evidence a Verifier needs to make that determination, not a delegation or policy protocol. The profile composes with adjacent profiles for human-authority binding, post-execution material-action evidence, and content-refusal events, referenced rather than replicated. NordenSoft This document profiles the IETF SCITT (Supply Chain Integrity, Transparency, and Trust) architecture for AI-agent action receipts: tamper-evident, signed, offline-verifiable records of what an autonomous agent was recorded as doing at the governed boundary, under which recorded principal class, with what recorded verdict, and -- where the issuer records one -- under which policy identity. Each receipt is a signed record over a canonical JSON payload, hash- chained so that each record commits to its predecessor, and presented either bare -- the payload with its own native signature -- or enveloped in a COSE_Sign1. This revision specifies how such a receipt is carried as a SCITT Signed Statement, with the protected claims a Transparency Service requires, so that a receipt can be registered. Registration obtains a Transparency Service's signed proof that the statement was registered in its log -- a property a self-signed chain cannot provide alone. It does not, by itself, give an offline holder non-equivocation: that requires consistency proofs and monitoring of the log, which this profile does not specify. The profile makes a deliberately narrow, checkable claim: this is an issuer-authenticated, signature-verifiable, tamper-evident record of the action, the recorded principal class, the recorded verdict, and any policy identity the receipt carries. It explicitly does not claim that the agent was correct, safe, or wise, that the recorded inputs were true or complete, that a named approver authorized this exact action before it ran, that a downstream controller succeeded, or that any physical effect occurred. This revision separates those last three as distinct claims with independent failure behaviour, states the boundary of a shared action digest, and keeps a deterministic offline policy-replay capability out of scope. This document specifies records with which a third party can establish, later and without network access, what an automated agent, such as an artificial intelligence (AI) agent, was permitted to do and what it recorded doing. The person for whom the agent acts, the principal, signs a permission with a passkey; the permission carries limits that a verifier can check mechanically. The agent signs a receipt for each action with Ed25519 and the Module-Lattice-Based Digital Signature Algorithm (ML-DSA-87). Receipts are chained and entered in a log whose signed tree heads are time-stamped. A verifier reports, separately, whether the records are sound and whether each recorded action stayed within its permission. The content of each record is specified independently of its encoding; one encoding, JSON Web Signature (JWS) over canonical JavaScript Object Notation (JSON), is defined. The HORIZONs Co., Ltd. MUSUBI settlement is a deterministic function that takes a contract signed by two parties, a set of signed records of what an agent did under that contract, and a view of Bitcoin block headers, and computes whether the recorded acts stayed within the grant the contract gives. Anyone holding the same bytes can recompute the result without trusting the party that produced it. This document specifies one well defined part of that function, settle core v0, precisely enough that a second implementation can be written from the text and the published test vectors alone. Settlement is not runtime enforcement and is not a judgement of liability. Gravit Open Network The Gravit Epistemic Verification Protocol (GEVP) defines how signed evidence Records about an Artifact are screened, grouped by independent source and evaluated, so that a claim is never promoted beyond what independent evidence supports. It specifies the Epistemic State Machine, the Record format and its signature, the meaning of the signed result of a Record, a verifier registry accepted under a threshold of root keys, a content-addressed Decision Record that anyone can reproduce, and optional signed receipts that let an auditor check a history of decisions offline. It maps these states to the evidence taxonomy of the Gravit Verifiable Epistemic Decision Standard (VEDS). Tersign Agent audit records are signed, chained, counter-signed, timestamped, and registered with transparency services. Each mechanism establishes a narrower fact than it is often taken to establish. This document states, for any record format, protocol, or payment method, what a check of an agent audit record can and cannot establish about four properties: the independence of the entities that signed or observed it, the completeness of a set of records, the time at which a record or an action existed, and the result that a verifier reports. It defines independence by control rather than by key or process separation, separates the independence of a signer from the independence of an observation, states which commitments cannot support a report that a set of records is complete, and requires a verifier to report unauthenticated content as unauthenticated. It defines no record format, role, log, or service. Assault Consulting Assault Consulting This document describes PALA-1 -- version 1 of the Portable Append- only Log for Audit -- a compact binary record format for tamper- evident audit trails produced by AI inference runtimes and robotic control systems. It is designed for a class of deployment defined by three constraints that hold together: the hardware is computationally modest and its cycles are reserved for the workload and the power budget rather than for the audit trail; no external witness is reachable, whether because policy forbids outbound contact or because the platform operates beyond connectivity, so a witness is unavailable by rule or by physics rather than by circumstance; and the right to verify the trail is separated from the right to read what it records. Records form an append-only hash chain. Integrity verification requires no key material of any kind, inspects no record bodies, and costs one hash per record rather than one signature. The format distinguishes three separately answerable questions -- internal consistency, completeness against an external anchor, and existence at a point in time against an external witness -- and states which of the three a given trail actually supports rather than implying all three. The format is frozen at version 1.0 and is described here as it is. This document presents an existing wire format; it does not revise one. Where a deployment does permit an external witness, a chain head may be published to a transparency service such as that of the Supply Chain Integrity, Transparency, and Trust architecture (SCITT, RFC 9943); that path is described but is not part of the hashing contract. b7n0de

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 ; 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: =============== 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

Open Questions This section is to be removed before publication.

• Where the work belongs: SCITT, whose Signed Statements can carry a verdict record, or the proposed AUDIT work, whose Auditor reaches the determination a verdict record states.
• Whether a record should state what its issuer did not check, and why, as the decision receipt does.
• Whether a record should state what evidence would change its result.
• Whether the canonical form of should instead be a profile of the JSON Canonicalization Scheme , with the same restriction to integers.
• Test vectors, and a second checker written from this text alone. Contributions of evidence items in other formats, with their digests, are welcome for .

Changes Since -00 This section is to be removed before publication.

• Pointed to the audit architecture's Auditor in the introduction.
• Stated that a verdict record provides no completeness property.
• Stated which bytes an evidence digest covers for enveloped items.
• Added Related Work and Open Questions.