kuma.github@gmail.com

Applications and Real-Time Independent Submission AI agents tool calls signed receipts co-signed receipts trust DID This document defines a wire format for signed execution receipts produced by AI agents when they invoke tools, services, or other agents. A receipt records the minimum facts needed to make a trust decision about a future call: who acted, who delegated, what tool was used, whether the call succeeded, how long it took, and how the call's inputs and outputs are identified (without disclosing their contents). A distinguishing property of the format is optional caller co-signature over the same canonical per-call record. When both signatures validate, the receipt cryptographically binds the identified Caller and Agent to the same canonical payload. This does not establish that either party independently observed every field, that the recorded execution was correct, or that the parties did not collude. A receipt may carry the Agent signature alone, and consumers may distinguish the two cases according to deployment policy. The format is intentionally tool-system-agnostic. The same receipt structure can be emitted by MCP (Model Context Protocol) servers, LangChain.js callback handlers, OpenAI tool-calling loops, HTTP clients, or proprietary agent runtimes. Receipts use Ed25519 signatures over a JCS-canonicalized payload, and identities are W3C Decentralized Identifiers (DIDs). This revision introduces an explicit wire-format version (formatVersion), pins the hash preimage profile, and ships executable conformance test vectors. Scoring policy, aggregation architecture, and reactive behavior in response to receipts are explicitly out of scope and left to deployments.

Introduction

Motivation AI agents increasingly act on behalf of users: they pick tools, call APIs, delegate to other agents, and -- in some deployments -- participate in transaction workflows. Each of those actions is preceded by an implicit trust decision: which tool should I use, and is it likely to do what I expect? Today, that decision is mostly answered by upstream proxies -- whether the tool's name appears in a model's training data, whether a registry surfaces it, whether a platform recommends it. None of these proxies record what the tool actually did in real calls. There is no widely-deployed, interoperable record format that an agent (or an agent-payment protocol, or an audit system) can use to look back and answer "what happened the last N times this tool was called?" This document defines such a format. It is intentionally narrow: it covers the wire format for one receipt. How receipts are stored, aggregated, queried, scored, or reacted to is a deployment-policy concern and is out of scope.

Design Principles

• Wire format only. Scoring models, aggregation topologies, and decision logic are deployment choices, not protocol requirements.
• Tool-system-agnostic. The same receipt can be produced by MCP, LangChain, OpenAI tool calling, plain HTTP, or proprietary runtimes.
• Content-minimizing. Receipts identify inputs and outputs by hash rather than embedding their contents. This reduces direct disclosure but does not make low-entropy or guessable values private; see the Security Considerations.
• Independently verifiable. Anyone holding the receipt and the public keys can verify the signatures without consulting any registry or trusted third party.
• Mechanically checkable. Every processing rule in this document is exercised by the executable test vectors described in the appendices; a conforming implementation can be validated byte-for-byte without interpreting prose.
• Co-signature supported. The Caller can sign the same canonical payload as the Executor (Agent). A receipt verifies as co-signed only when valid signatures for both the identified Caller and Agent are present. The degree to which those signatures represent operationally independent assertions depends on the control separation described in the Security Considerations.

Out of Scope This document does NOT define:

• A scoring model. Trust scores derived from receipts are deployment policy.
• An aggregation architecture. Receipts can be stored locally, federated, anchored, or relayed in any pattern.
• A query API. Consumers may serve receipts and/or derived data over any protocol they choose.
• Identity priors. If a deployment chooses to weight different DID methods differently, that is deployment policy.
• A specific transport. Receipts may be exchanged over HTTP, MCP, message queues, or any other carrier.

Conventions and Definitions 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

Agent:

An automated system, typically an AI agent, that invokes tools, services, or other agents on a principal's behalf.

Caller:

The party that delegated the tool call to the Agent. Often (but not always) the same legal entity as the Agent's principal.

Tool:

A named operation invoked by the Agent. The tool implementation may be local code, an MCP server, an HTTP API, a sub-agent, or any callable target.

Receipt:

A signed record of a single Tool execution attempt.

Executor signature:

The signature produced by the Agent that ran the tool.

Caller signature:

The signature produced by the Caller over the same canonicalized payload as the Executor signature.

DID:

Decentralized Identifier, as defined in the W3C DID Core specification .

Legacy receipt:

A receipt produced before this revision, carrying no formatVersion member (see ).

Receipt Structure A receipt is a JSON object with the following fields:

Field	Type	Required	Description
formatVersion	string	yes (this revision)	MUST be "1" for receipts conforming to this revision. Part of the canonical payload (). Receipts without this member are legacy receipts; see .
agentDid	string (DID)	yes	The Agent that executed the tool.
callerDid	string (DID)	yes	The Caller that delegated the tool call. MUST be present on formatVersion "1" receipts; it MAY equal agentDid when there is no delegation.
toolName	string	yes	A stable identifier for the tool. Format is opaque to this spec.
taskHash	string (64-char hex, lowercase)	yes	A SHA-256 hash of the task input, computed per the preimage profile ().
resultHash	string (64-char hex, lowercase)	yes	A SHA-256 hash of the task output, computed per the preimage profile (). When success is false and no output is committed to, the value MUST be the empty-input sentinel (); when a canonical failure description is committed to instead, the preimage profile applies to it.
success	boolean	yes	true if the tool call satisfied the agent's success criterion, false otherwise.
latencyMs	integer	yes	Wall-clock time from invocation to completion, in milliseconds. MUST be an integer in the range 0, 2^53 - 1.
failureType	string	yes	One of the values defined in when success is false. When success is true, the value MUST be the empty string "". The member is always present on the wire and in the canonical payload as a (possibly empty) string; null is not used and the member MUST NOT be omitted.
timestamp	string (RFC 3339)	yes	UTC timestamp of completion. formatVersion "1" producers SHOULD render it with exactly three fractional-second digits and the Z designator (e.g. 2026-07-02T01:23:45.678Z); a single rendering keeps signature-level deduplication () byte-stable. A future revision may make one rendering mandatory.
signature	string (hex)	yes	Ed25519 signature by the Agent over the canonical payload (), encoded as exactly 128 lowercase hexadecimal characters (a 64-byte signature).
callerSignature	string (hex)	recommended	Ed25519 signature by the Caller over the same canonical payload, same encoding as signature. See .
toolMetadata	object	optional	Tool-class or capability hints. Format is deployment-defined; see . Never part of the canonical payload.

A receipt SHOULD NOT carry top-level members other than those defined above. Consumers MUST treat any unknown top-level member as unauthenticated data: unknown members are not part of the canonical payload and are not covered by any signature. Producers MUST NOT rely on unknown members being preserved by intermediaries.

Example The following receipt is complete and verifiable: both signatures validate against the test keys published with the conformance vectors (), and every hash is reproducible from the preimages given there. The task input is the JSON object {"text": "hello", "target": "ja"} and the output is a five-character Japanese text string whose exact value is given in the unicode_string_raw_utf8 conformance vector. (The two signature values are single hex strings; they are wrapped here for line-length reasons only.)

Canonical Payload and Signing

Canonical Payload The signed payload is the JSON object containing the following fields, in this order after lexicographic sorting per : For receipts conforming to this revision, formatVersion MUST be present with the value "1" and is part of the signed payload. For legacy receipts () the payload contains the nine remaining fields only. The signature, callerSignature, and toolMetadata fields are excluded from the canonical payload. Implementations producing receipts MUST canonicalize using JCS as defined in . Verifiers MUST recompute the canonical payload from the receipt's field values exactly as received. In particular, verifiers MUST NOT apply Unicode normalization (NFC, NFD, NFKC, or NFKD) or any other transformation to field values before canonicalization; a storage or transport layer that normalizes strings will render legitimately signed receipts unverifiable. Producers SHOULD emit NFC-normalized strings. Compatibility normalization (NFKC/NFKD) MUST NOT be applied at any layer: it can fold visually or semantically distinct identifiers (for example, two different toolName values) into one. The taskHash and resultHash fields MUST contain a SHA-256 digest as defined in , encoded as exactly 64 lowercase hexadecimal characters. Because a receipt carries no hash-algorithm identifier, verifiers MUST interpret both fields as SHA-256 in this version. Supporting additional hash algorithms would require a future revision of the formatVersion mechanism ().

Signing Algorithm Signatures are computed using Ed25519, as defined in . The signature input is the UTF-8 encoding of the canonical JSON string produced in the previous subsection. The signature field is the Executor's Ed25519 signature, encoded as a lowercase hexadecimal string of exactly 128 characters. The callerSignature field, when present, is the Caller's Ed25519 signature over the same canonical input, in the same encoding.

Verification A verifier MUST:

1. Recompute the canonical payload from the receipt's fields per .
2. Resolve agentDid to its current public key per .
3. Verify signature against the canonical payload using the Agent's public key.
4. If callerSignature is present, resolve callerDid similarly and verify callerSignature against the same canonical payload.
5. Reject the receipt if any signature verification fails.

Verification of formatVersion "1" receipts is additionally fail-closed with respect to the wire format: a verifier MUST reject a formatVersion "1" receipt whose taskHash or resultHash is not exactly 64 lowercase hexadecimal characters, or whose failureType is inconsistent with success () -- regardless of whether its signatures are valid. A cryptographically valid signature over a malformed record does not make the record conformant. Verifiers SHOULD likewise validate the remaining MUST-level constraints of through and reject violations. A verifier MAY additionally validate that timestamp is within a deployment-defined freshness window.

Format Versioning and Legacy Receipts The formatVersion member identifies which revision's processing rules apply to a receipt. The only value defined by this document is "1", denoting: full 64-character hashes, the preimage profile of , toolMetadata excluded from the signed payload, failureType always present as a string, and callerDid always present. A receipt without a formatVersion member is a legacy receipt, produced under revisions -00 through -02 of this document. Verifiers MAY accept legacy receipts by reconstructing the nine-field canonical payload () and applying lenient handling; deployments SHOULD record which regime a stored receipt was accepted under. Two known properties of legacy receipts deserve care:

• Some legacy producers truncated taskHash/resultHash to 16 hexadecimal characters. A 64-bit digest is collision-findable with roughly 2^32 work and MUST NOT be produced anymore; consumers SHOULD NOT rely on truncated hashes as commitments.
• Some legacy producers incorrectly included toolMetadata in the signed payload, contrary to the canonical-payload rule of every revision that defined it. Such receipts fail verification under this revision's payload rule.

Because formatVersion is part of the signed payload, a receipt's version claim cannot be altered without invalidating its signatures. Verifiers encountering an unknown formatVersion value MUST reject the receipt.

Hash Preimage Profile formatVersion "1" producers MUST compute taskHash and resultHash over the following preimages. This profile makes hashes of semantically identical values byte-identical across independent producers, which is what enables cross-deployment comparison and later disclosure verification.

Text (a string value):

The raw UTF-8 content bytes of the string itself -- not its JSON-string serialization. "hello" hashes the 5 bytes hello (digest 2cf24dba...); a format that hashed the 7-byte JSON form (with quotation marks) would produce 5aa762ae... instead.

Raw binary content:

Its raw bytes, directly. (Together with the text rule: scalar content hashes its content bytes.)

Structured JSON value (object, array, number, boolean):

The UTF-8 bytes of its JCS canonical form. Member order therefore cannot change the hash.

Absent (no input; no output, e.g. on failure) or JSON null:

The empty byte string. SHA-256 of the empty string is the empty-input sentinel: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.

Two consequences worth stating explicitly. First, hashing a structured value requires the same type-level discipline as the canonical payload itself: values must be JSON-representable and serialized by JCS, not by an implementation's default serializer. Second, the sentinel makes "no output" a first-class, verifiable state -- a failed call with no output has a well-defined resultHash rather than an empty or producer-invented value. Semantic equivalence across different profiles (for example, comparing a hash produced under this profile with one produced by a format that hashes JSON-string serializations) remains out of scope; the formatVersion mechanism exists so that such profile changes are explicit rather than silent.

SigningDelegate Pattern (Caller Co-signature) To produce a co-signed receipt, a Caller MUST NOT transmit private key material to the Executor. Instead, the Caller exposes a SigningDelegate interface: } ]]> The Executor sends the canonical payload string to the Caller's sign method and receives the signature. The private key never leaves the Caller's process boundary. When the Caller and Executor are not co-located, the transport carrying canonical payloads to the Caller MUST use TLS or an equivalent confidentiality and integrity layer. A Caller MAY decline to sign -- for example, if the Caller does not consent to the receipt's contents. In that case the Executor publishes the receipt with only its own signature and no callerSignature. Such receipts remain syntactically valid; consumers may weight them differently as a matter of deployment policy. Before signing, a conforming Caller SHOULD at minimum parse the canonical payload and confirm that callerDid identifies itself and that the payload corresponds to a delegation it actually issued (for example, by matching toolName and recomputing taskHash from the input it delegated). A Caller that signs whatever it is handed adds attribution but no verification; discusses the resulting trust boundary. By producing callerSignature, a conforming Caller attests that it accepts the canonical record as representing the identified Caller-to-Agent delegation. This attestation does not, by itself, imply that the Caller independently recomputed taskHash, observed the result committed to by resultHash, or validated success, latencyMs, or failureType, unless a deployment defines and enforces those checks. The Security Considerations discuss the resulting trust boundary.

Failure Type Classification When success is false, failureType MUST be either one of the following registry values or a deployment-defined extension value:

Value	Condition
timeout	The call exceeded a deployment-defined latency bound (default RECOMMENDED: 30000 ms), or the underlying error was timeout-shaped.
validation	The call failed due to input or output validation (schema, parse, type mismatch).
error	All other failures. This is the registry catch-all.

Receiving implementations MUST treat unknown failureType values as error for the purposes of any deployment-policy decision they make. Deployments defining extension values should note that extensions carry meaning only within that deployment. When success is true, failureType MUST be the empty string "". This is a deliberate choice over a null value: it keeps the canonical payload's value type stable (always string) so that JCS canonicalization () produces a predictable byte sequence regardless of success state. A verifier that substitutes a null value for an empty failureType will compute a different canonical payload and will fail to verify legitimate receipts. A formatVersion "1" receipt with success true and a non-empty failureType, or success false and an empty failureType, is malformed and MUST be rejected ().

Tool Metadata (Optional) A receipt MAY carry a toolMetadata object describing class or capability hints about the tool. This document does not standardize the schema of toolMetadata. A deployment may use it to convey:

• A tool class (e.g., advisory, data-retrieval, mutation, settlement).
• A settlement layer identifier when the tool executes on-chain transactions.
• A verifiability hint indicating whether the tool's outcome is externally anchored.

toolMetadata is NOT part of the canonical payload and is NOT signed. Consumers that wish to trust toolMetadata MUST validate it through out-of-band means (e.g., the tool's published manifest, signed separately). A future revision of this document, or a companion document, MAY standardize a portion of the toolMetadata schema if interoperability needs emerge.

Identity (DID) Requirements Both agentDid and callerDid MUST be syntactically valid DIDs per . This document does not constrain the DID method. Common choices in production include did:key, did:web, and ledger-anchored methods such as did:xrpl or did:ethr. A deployment MAY apply policy based on DID method -- for example, treating ledger-anchored identities differently from cryptographic-only identities. Such policy is out of scope for this document; the wire format treats all DID methods uniformly.

Security Considerations

Privacy Receipts identify inputs and outputs by hash. Implementations MUST NOT include raw inputs, outputs, prompts, user data, secrets, or PII in any signed field. toolMetadata, while not part of the canonical payload, also SHOULD NOT contain such data. Hash construction matters: a deployment that hashes uncanonicalized inputs may leak information through hash collisions or correlation. The preimage profile () removes serializer-level divergence; note that hashing does not make low-entropy or guessable values private, since a verifier holding a candidate value can always test it against the hash.

Replay A signed receipt is replayable by anyone who possesses it. Receivers SHOULD enforce a freshness window on timestamp and SHOULD reject duplicate receipts identified by (signature). Note that signature-level deduplication identifies distinct records, not distinct executions: two executions whose nine field values coincide exactly (same hashes, same millisecond timestamp, same latency) produce the same canonical payload and -- Ed25519 being deterministic -- the same signature, and are therefore indistinguishable at this layer; see . A deployment that needs cross-receipt deduplication MAY additionally store and dedupe by (agentDid, taskHash, timestamp).

Caller-Side Forgery A receipt with only signature (Executor) and no callerSignature represents the Executor's claim alone. A malicious Executor could fabricate such receipts. Co-signature by the Caller prevents this: a Caller observing a forged receipt about its own delegations would notice the absence of its callerSignature and could repudiate. When callerSignature is missing, a deployment SHOULD weight the receipt accordingly. The exact weighting is policy, but treating co-signed and non-co-signed receipts identically is a security mistake.

Single-Observer Dominance If a deployment derives reputation or trust signals from receipts and a single Caller produces most of the receipts about a given tool, that Caller's environment-specific bugs, biases, or hostile behavior propagate directly into the derived signal. This is a deployment-policy concern, not a wire-format concern. Deployments SHOULD record the set of distinct callerDid values contributing to any derived statistic so that consumers can reason about observer diversity.

Key Compromise A compromised Agent or Caller key allows arbitrary receipt forgery for the lifetime of that key. DID methods that support key rotation SHOULD rotate routinely. Verifiers MUST resolve DIDs to the current key set at verification time, not at receipt emission time.

Timestamp Trust timestamp is asserted by the Executor and is not independently anchored by this format. A deployment that requires verifiable time SHOULD pair receipts with an external time-anchoring mechanism (, blockchain inclusion, etc.).

Co-signature Trust Boundary A caller co-signature adds a second attributable assertion over the same canonical record. It represents evidence from an operationally independent source only to the extent that the Caller's signing authority is operationally separated from the Executor's authority. If the Caller and Executor share a process, operator, or key-management boundary, two signatures do not establish two independent observers. Co-signature does not prevent collusion. A Caller and Executor acting together can produce a co-signed receipt that describes an execution inaccurately or describes an execution that did not occur. Co-signature binds both identified parties to the same canonical record; it does not establish that the record is true.

Known Limitations The following are known limitations of this format. They are recorded so that implementers and reviewers can account for them; a future revision or companion document may address them.

• Key rotation and historical verification. A receipt carries no verification-method identifier. When a DID document exposes multiple applicable verification methods, a verifier may need to try multiple candidate keys, and the receipt provides no stable reference to the key used at issuance. If that key is later removed from the DID document, a legitimately issued receipt can become unverifiable. A deployment that needs long-lived verifiability must retain historical key material or pin keys out of band. Carrying an explicit key identifier in the receipt is a candidate for a future revision.
• Tool identity. Only the opaque toolName is part of the signed payload; toolMetadata is not signed. Two implementations, providers, or versions that share a toolName are not distinguishable from the receipt alone. Binding a stable tool identifier, a provider or endpoint identity, or a version or manifest digest into the signed payload is a candidate for a future revision.
• Receipt uniqueness. The format carries no nonce or per-receipt identifier. Two executions whose field values coincide exactly are represented by byte-identical receipts () and cannot be distinguished or counted separately. Deployments for which double-counting or under-counting such coincidences matters must add an out-of-band identifier; a nonce field is a candidate for a future revision.
• Cross-profile hash comparison. pins one preimage profile for formatVersion "1", which makes hashes comparable across producers within this format. Comparing hashes against records produced under a different profile (including legacy truncated hashes, and formats that hash JSON-string serializations) remains undefined and requires out-of-band agreement.

IANA Considerations This document has no IANA actions in its current form. A future revision may register a media type (e.g., application/xaip-receipt+json) and a failureType registry.

References Normative References W3C Informative References xkumakichi xkumakichi xkumakichi

Relationship to the XAIP Reference Implementation The XAIP reference implementation wraps this wire format with an aggregator, a Bayesian trust score, a class-aware risk-flag evaluator, and a decision engine that ranks candidate tools. None of those components are required to produce or consume receipts conformant to this document. A consumer that only wants to verify and store receipts does not need to import any of them. A consumer that wants a turnkey aggregator and scoring layer may use the reference implementation. A consumer that disagrees with any of those design choices is free to substitute its own implementation while remaining interoperable at the receipt-format layer. As of this revision, the reference implementation (SDK middleware, four client emitters, and the aggregation service) produces and fail-closed-validates formatVersion "1" receipts, and its behavior is locked to the conformance vectors of . The single-observer dominance failure mode discussed earlier in this document was first surfaced in the public dataset of that reference implementation .

Adoption Path for Agent-Payment Protocols This format is intended to be useful to agent-payment protocols (for example, agent-to-agent payment protocols, agent-mediated commerce protocols, and agent escrow systems) that need a "trust precondition" check before committing to a transaction. Such a protocol can:

1. Require that an Agent present a set of recent receipts before being allowed to initiate a payment.
2. Define its own scoring policy over the receipt set, or consult an external scoring service.
3. Require that receipts above a certain transaction value include callerSignature (co-signed).
4. Require that receipts for settlement-class tools (declared via toolMetadata, which is unsigned and therefore validated out of band per ) be additionally anchored to an external ledger.

Each of those is a policy decision local to the agent-payment protocol. This document only defines the receipt wire format; it does not define a payment mechanism, a settlement rail, or any value-transfer system.

Relationship to Adjacent Receipt and Audit Formats Other efforts also record evidence about AI agent actions. They differ from this document mainly in two dimensions: the unit of evidence (a single call versus a whole session) and which party attests to the record. This appendix is informative and describes that adjacent work for context; this document does not depend on any of these formats. Session-level integrity bundles record an entire agent session as a single hash-chained, signed archive, answering post-hoc audit questions about a completed workflow. A per-call receipt as defined here and a session-level bundle are composable: a bundle may embed or reference per-call receipts, and a per-call receipt may carry a reference to the session in which it occurred. Receiver-attested receipts are signed by the service that received the call and produced the result; obtaining such an attestation requires the invoked service to participate in the receipt protocol. The caller co-signature model in this document (the SigningDelegate pattern, ) instead lets the party that delegated the work sign the same canonical per-call record as the executing Agent, so that -- when both signatures are present -- the record is attributable to both parties to the Caller-to-Agent delegation without requiring the invoked Tool or service to sign. A further pattern places the signature on a mediator at the communication boundary between the Agent and the tool. These approaches represent different observation and control boundaries: a caller co-signature, in particular, does not imply that the Caller independently observed every field, and its evidentiary value depends in part on the operational separation between the Caller and the Agent. In that space, this document occupies the per-call point at which the executing Agent and the delegating Caller can co-attest the same record. It does not subsume executor-only assertion, receiver attestation, mediator attestation, or session-level bundles; a single deployment may combine more than one of them.

Conformance Test Vectors Executable test vectors for this revision are published in the reference repository :

• docs/spec/test-vectors/receipts-v1-vectors.json -- the vectors. Every hash, canonical payload byte string, and Ed25519 signature is real; test keys are embedded (and marked as such).
• docs/spec/test-vectors/check.mjs -- a dependency-free checker (Node.js 18 or later, standard library only) that re-derives every value from the vectors file and verifies all signatures, failing loudly on any drift.

The vectors pin, as executable bytes: the preimage profile of (raw-UTF-8 text hashing with the JSON-form value shown as the explicit wrong answer; JCS member-order invariance; the empty-input sentinel); canonical payload construction with and without formatVersion, including the byte-identity of payloads with and without toolMetadata; a complete co-signed receipt (the example in ), a failure receipt using the sentinel, and a legacy receipt; a tamper case whose signatures must fail; and the fail-closed rejections of (truncated hash, uppercase hash, failureType inconsistent with success). The vectors are the executable form of this document's processing rules: an implementation that reproduces them byte-for-byte conforms to the hashing and canonicalization layers of this revision, without needing to interpret prose. The example in and the vectors are generated from the same values, so the example cannot silently drift from the specification.

Change Log

• -03 (2026-07-02): Versioned the wire format and made it mechanically checkable. Added the formatVersion member (value "1"), carried inside the signed payload, and defined legacy-receipt handling. Pinned the hash preimage profile -- scalar content hashes its content bytes, structured JSON hashes its JCS form, absent values hash the empty-input sentinel -- narrowing the -02 known limitation on preimage encoding. Made verification of formatVersion "1" receipts fail-closed for hash format and failureType consistency. Pinned: no Unicode normalization at verification, NFKC/NFKD prohibited at any layer, NFC recommended for producers; signature encoding exactly 128 lowercase hex characters; latencyMs range [0, 2^53 - 1]; a single RECOMMENDED RFC 3339 rendering for timestamp; unknown top-level members are unauthenticated. Resolved the -02 contradiction between the closed failureType value set and deployment extensions, and required rejection of success/failureType-inconsistent receipts. Required the empty-input sentinel for failure receipts committing to no output. Added a SHOULD-level minimum check list for Callers before co-signing. Corrected the replay-section uniqueness claim and added the receipt-uniqueness (no nonce) known limitation; removed the format-versioning known limitation (resolved by formatVersion). Replaced the example receipt -- whose hash values did not conform to this document's own length requirement in -00 through -02 -- with a complete receipt that verifies against published test keys. Added executable conformance test vectors and a dependency-free checker. No changes to the signing algorithm, canonicalization scheme, or trust-boundary language of -02.
• -02 (2026-06-19): Scoped to define precisely what a caller co-signature establishes and what it does not. The Abstract no longer states that co-signature prevents unilateral fabrication outright; it now states that two valid signatures bind the identified Caller and Agent to the same canonical record, and that this does not establish independent observation of every field, execution correctness, or absence of collusion. Clarified caller-signature semantics, separated attribution from operational independence in the Security Considerations, scoped the adjacent-formats appendix to the Caller-to-Agent delegation, and named the executor / delegator / receiver / mediator / session-bundle attestation axis. Softened the privacy design principle to a content-minimizing claim. Normative clarification: taskHash and resultHash MUST be computed with SHA-256 and encoded as exactly 64 lowercase hexadecimal characters; this narrows the -00/-01 wording, which only RECOMMENDED SHA-256. Added a Known Limitations section. No wire fields were added or changed.
• -01 (2026-06-19): Foregrounded caller co-signature (mutual attestation) as a distinguishing property of the format in the Abstract, and added an informative appendix relating per-call, caller-co-signed receipts to session-level integrity bundles and receiver-attested receipts. No wire-format or normative changes; receipts valid under -00 remain valid under -01.
• -00 (2026-05-22): Initial individual draft. Split out from the XAIP reference implementation specification, focused on the receipt wire format only. Removed aggregator, scoring, and decision-engine content; left those to deployment policy.