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 inputs a record names (). The name judgement means that no mechanical rule can re-derive the result. A rule name other than judgement SHOULD identify the version of the specification it names, so that a changed rule has a new name.

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; the record itself is at level 1, and each object or array inside it adds one level. 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. Bytes that break the rules of this section, or a record that breaks other than in evidence and check, are refused before any step runs: the state is refused and the report names the rule broken. 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 mechanical rule on the inputs the record names, 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 exactly the members rule (a string, the name of the rule), inputs (optional) and result (the result the rule gave).The member inputs is an object. Each of its members names one input of the rule, and its value says where the checker reads that input:

• a string: the name of a member of body. The input is that member's value.
• an object with the member evidence, an integer index into the evidence array, optionally the member pointer, and no other member. With no pointer, the input is the digest the checker computes from the item it holds for that entry. With pointer, a JSON Pointer , the input is the value at that pointer in the item's bytes, parsed as strict JSON by the rules of ; the item need not be in canonical form.

An issuer SHOULD bind an input to evidence rather than copy a value from an evidence item into body: a copy is the issuer's statement, while a bound input is read from the cited bytes.

body:

An object: the content of the record. Its members depend on kind. It holds the claim () and any values the rule reads from body.

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.One exception: under the default policy (), step 3 can rely on a value in body that check.inputs names. That value is the issuer's statement, and the report names each such input, so a reader can see which inputs came from the issuer.

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; otherwise step 1 FAILs. 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, and verifies only when its own state is released. 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: the record being checked is at depth 0, so following one citation needs a depth of 1 or more. 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 resolves each input that check.inputs names () and re-runs the rule on them. If an input is bound to an evidence item the checker does not hold, or that step 2 does not rely on, step 3 is NOT RUN. If an input cannot be resolved (no such member of body, no such evidence entry, a binding object with another member, a pointer that does not resolve, or an item that is not JSON by the rules of ), or is of the wrong JSON type, that is a FAIL of this step, not a result of the rule. If one input cannot be read for the first reason and another for the second, the step FAILs. If the checker's policy reads inputs from evidence only (), an input read from body makes step 3 NOT RUN. 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, where it did not run, the input it needed. Under the default policy the report also names each rule input read from body (). 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 (over its canonical form, ) 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, as an integer of 0 or more. It can also state that rule inputs are read from evidence only; by default they are read from body or from evidence, as each input says. A policy that lacks one of the first three, or states any of them in a form other than these, is invalid, and a checker whose policy is invalid gives no verdict.Reading inputs from evidence only means that step 3 reads bytes the record cites by digest, not values written into body. Those bytes are outside the issuer's reach only as far as their verification in step 2 shows that another party made them. A record may still carry values in body; under this policy an input bound to body makes step 3 NOT RUN (), and other values in body play no part in the check.

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. An input bound to an evidence item shows only that the rule read the cited bytes; it does not show that what those bytes state is 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. Nor does it show that no evidence item has been withdrawn (). 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.

Reassessment and Withdrawn EvidenceA result can change: evidence arrives late, a cited item is withdrawn or superseded, or the rule or policy changes. A verdict record does not change. A reassessment is a new record. An issuer that reassesses its own result writes a new version of the same key, whose supersedes is the digest of the earlier version; both versions remain checkable. A party that reassesses another issuer's record writes a record of its own and cites the earlier record as evidence. If it cites the earlier record with the format "verdict-record/1", the new record is released only while the earlier one is; to reassess a record that is no longer released, it cites the earlier record's bytes under another format.Where a record cites another verdict record, the cited record is checked each time the citing record is checked, and the citing record relies on it only if the cited record is released; otherwise step 2 is NOT RUN (). A change that alters the state of a cited record therefore reaches every record that cites it, to the depth the checker follows, the next time that record is checked. Because the check is deterministic (), such a change comes only from a change in the items the checker holds or in its own inputs, such as its trust anchors or policy. No notice is sent to the citing records. The aim is comparable to truth maintenance , but nothing keeps justification links: the dependency is recomputed when a record is checked. A later version of a cited record does not by itself change the state of the earlier version; how a checker that holds a later version should treat a citation of the earlier one is an open question ().Because no step relies on the absence of a statement (), a checker cannot conclude that an evidence item has not been withdrawn. A withdrawal, retraction or revocation changes a check only where the verification rules of the item's format take it as input, or where the checker's trust anchors or policy change; no step of reads it otherwise.

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.
• Decision receipts for approvals, declined actions and executed actions give each of those a signed record with exact bytes and map them onto the record types of the audit architecture. They can be evidence items. That document cites this one; its digests cover the envelope's payload, so a verdict record that relates the two cites the payload as an item of its own ().
• Execution-trace verification for agents chains delegation hop records by the digest of their canonical form and requires that scopes do not widen along the chain. Its hop records can be evidence items, and two of its Section 5 checks can be applied by the rule of a verdict record ().
• Post-quantum agentic delegation defines hybrid signatures over delegation chains and aggregated execution receipts. Its receipts can be evidence items.
• The Verifiable Agent Trust Envelope records verifier-side admission decisions and links them to receipts. Where a required receipt arrives after its deadline, it records a new assessment and keeps the earlier one. takes the same approach.
• 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. Artificial Intelligence, vol. 12, no. 3, pp. 231-272 b7n0de

Examples

A Model Decision 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

A Rule Re-run on Cited Delegation Records This record checks two delegation hop records from , contributed by that document's author.Its rule, named urn:example:verdict-record:rule:hop-continuity-attenuation:v1 for this example, applies items 2 and 3 of Section 5 of that document and not the other checks of that section. It takes exactly four inputs: parent_hash and parent_digest, which are strings, and parent_scopes and child_scopes, which are arrays of strings. Its result is "attenuated_and_linked" when parent_hash equals parent_digest and every member of child_scopes is a member of parent_scopes, and "not_attenuated_or_not_linked" otherwise. Here parent_digest is the digest of the cited bytes, which equals that document's SHA256(JCS(hop)) only when the item is already in JCS form, as these are. Each input is bound to an evidence item, so body holds only the claim, and a checker that reads inputs from evidence only () can re-run the rule. The parent hop, evidence item 0: =============== NOTE: '\' line wrapping per RFC 8792 ================ {"expires_at":1793463600,"granted_scopes":["mcp:tool:erp.ledger.read\ ","mcp:max_rows:100"],"issued_at":1793460000} The child hop, evidence item 1: =============== NOTE: '\' line wrapping per RFC 8792 ================ {"expires_at":1793463600,"granted_scopes":["mcp:tool:erp.ledger.read\ "],"issued_at":1793460000,"parent_record_hash":"1336337e88adc67853b8\ 0b4998363210dc5c0797cc7b7c722128cecc56a38c14"} The verdict record, with whitespace added for display: =============== NOTE: '\' line wrapping per RFC 8792 ================ { "act_time": "2026-10-31T18:00:00.000000Z", "actor": { "id": "agenttrust-trace-checker", "model": "none", "model_version": "0", "type": "system" }, "body": { "claim": { "text": "hop[1] preserves SHA-256 parent_record_hash continuit\ y and monotonic scope attenuation from hop[0]" } }, "check": { "inputs": { "child_scopes": { "evidence": 1, "pointer": "/granted_scopes" }, "parent_digest": { "evidence": 0 }, "parent_hash": { "evidence": 1, "pointer": "/parent_record_hash" }, "parent_scopes": { "evidence": 0, "pointer": "/granted_scopes" } }, "result": "attenuated_and_linked", "rule": "urn:example:verdict-record:rule:hop-continuity-attenuat\ ion:v1" }, "evidence": [ { "format": "https://datatracker.ietf.org/doc/draft-durga-agentt\ rust-trace-verification/", "sha256": "1336337e88adc67853b80b4998363210dc5c0797cc7b7c72212\ 8cecc56a38c14" }, { "format": "https://datatracker.ietf.org/doc/draft-durga-agentt\ rust-trace-verification/", "sha256": "8886795d4403b5cd8820eb813ee0724f1d6d5d383124364b09c\ dc5020639e00c" } ], "key": "agenttrust/trace/hop-1", "kind": "check-run", "supersedes": null, "v": "verdict-record/1", "version": 1, "writer": "agenttrust-reference-verifier" } Its digest, over its canonical bytes, is: 62017940a8ddddd5ddd7ff46c8ff2a6ce79dfcccb775d767b8dff8db0ebe19ed The hops carry no signature, which the format of requires. A checker that applies that requirement reports held, at step 2. A checker that verified these hop records without a signature, which this document does not yet define (), and that held the rule's specification above, would report released. If the child hop widened the scopes, the re-run would give a different result and the record would be refused; if the checker did not hold the child hop, the record would be held. Test vectors for these cases are being added to the test vectors for this document ().

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 and do.
• 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. The two give the same bytes except in the ordering of member names that contain characters outside the Basic Multilingual Plane.
• Whether a record should state the cutoff it applied to the arrival of evidence, so that evidence arriving later is visibly outside the assessment rather than absent from it (, ).
• What it means for an item to verify when it carries no signature its format requires, as for the delegation hop records of , and for a plain media type such as application/json.
• Whether a checker that holds a later version of a cited verdict record should treat a citation of an earlier version as superseded, and if so how, given that no step may rely on the absence of a later version ().
• Where rule names and their results are registered, so that a rule such as the one in can have a stable name outside an example.
• Test vectors and a reference checker are published at https://github.com/diggertydog/verdict-record-test-vectors, with the open points they exposed. A checker written by a party other than the author is still wanted. Contributions of evidence items in other formats, with their digests, are welcome for .

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

• A rule input can be bound to an evidence item, by index and JSON Pointer, so that a re-run reads the cited bytes rather than copies in body; a checker's policy can read inputs from evidence only (, , ).
• Added : reassessment as a new record, and how a withdrawn item reaches a check.
• Rule names should identify a version.
• Stated that a cited verdict record verifies only when released, how citation depth and nesting depth are counted, that malformed bytes are refused before any step runs, when a policy is invalid, and over which bytes the policy digest is taken.
• Added a second example, with delegation hop records as evidence (). In -01 such a rule could read only values copied into body, and a record whose copies disagreed with its cited evidence was still released; under -02 that remains so unless the checker's policy reads inputs from evidence only.
• Added related work and open questions.

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.