The Vaara Receipt: A Recomputable Receipt Format for Decisions About Autonomous Actions

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 14 April 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶

Table of Contents

1. Introduction

A Vaara receipt is a signed, independently recomputable record that binds a decision about an autonomous action to the evidence it was made on, and optionally to one or more external timestamp anchors. Any system that emits or consumes Vaara receipts conforms to this document. Downstream specifications define profiles that pin to a version of this document and add only their own evidence schema; they do not redefine the envelope. An action here is any operation an autonomous or semi-autonomous system performs; an AI agent tool call is one case, and the format does not depend on the actor being an AI agent. The property this provides is accountable autonomy: an autonomous system may act, and an outside party can still recompute what it was permitted to do and what it did, without trusting the operator.¶

The receipt's trust is root-agnostic. The same record is verifiable with or without a hardware TEE and re-expressible as an IETF RATS ([RFC9334]) Entity Attestation Result (an AR4SI vector, [I-D.ietf-rats-ear]), whether rooted in a TPM 2.0 host, an AMD SEV-SNP confidential VM, or software alone. The signature and the optional external time anchor carry the evidence, not a single trust root.¶

This document packages a format that already ships and is independently recomputable from public conformance vectors. The executable conformance fixtures live under tests/vectors/ in the source repository ([VAARA-REPO]), each directory with a checker (_check_independent.py) that imports no issuer code: only the standard library and, as its profile needs, libraries for signatures, JCS, ASN.1, or ML-DSA.¶

The floor of the format is the engine decision profile (Section 6.8): one receipt per decision an engine records on its hash-chained audit trail, bound to that trail record, with no payment rail, settlement artifact, or external evidence record to join. It is the smallest conforming receipt, it is what a default install of the reference implementation emits for every decision, and it is the entry point a producer reaches for first.¶

2. Canonicalization, Digests, Numbers, and Times

Every digest of a JSON value in this document, and every signed payload, is computed over the JSON Canonicalization Scheme (JCS, [RFC8785]). The canonicalization label for the evidenceRef.canonicalization member (Section 4) is "jcs-rfc8785". The values "JCS" and "jcs-json-v1" are accepted aliases for the same algorithm; producers SHOULD emit "jcs-rfc8785", and consumers MUST accept all three.¶

A digest is written "sha256:" followed by the 64 lowercase hexadecimal characters of a SHA-256 ([FIPS180-4]) value. Unless the definition of a member says otherwise, the hashed bytes are the JCS encoding of the referenced JSON value. Where a member is a digest over bytes that are not a JSON value (a UTF-8 string, a configuration file, a joined preimage), its definition names those bytes.¶

No signed block and no evidence record defined in this document carries a non-integer number. Quantities that are not integers, such as risk scores and thresholds, are carried as decimal strings (for example "0.12"). A producer MUST NOT emit a non-integer JSON number in any of them, because two JCS implementations are only guaranteed to agree on integers within the range JCS defines.¶

Times are date-time strings as defined in [RFC3339], in UTC with the "Z" designator. Fractional seconds MAY be present. A consumer MUST NOT reorder or compare receipts by these strings without parsing them, because two producers can write the same instant with a different number of fractional digits.¶

3. The Receipt Envelope

A receipt is a JSON object. It is either a decision receipt, which records a decision about an action, or an execution receipt, which records what followed. Both kinds share the envelope below and differ in their derived block and their asserted block.¶

A decision receipt carries decisionDerived and issuerAsserted and neither outcomeDerived nor receiptAsserted; an execution receipt carries the reverse. The schema is closed. A consumer MUST reject a receipt that carries a member not listed for its kind in Table 1, and MUST reject any member not defined by this document inside backLink, decisionDerived, evidenceRef, issuerAsserted, receiptAsserted, outcomeDerived, completeness, cryptoPosture, pqSignature, or existenceProof. A consumer that rebuilds a signed block from the members it understands would otherwise leave out signed bytes, and could report a receipt as verified over content it never checked. Evidence records are defined by profiles (Section 6), and their own rules govern members they do not define.¶

Appendix A gives the envelope in CDDL ([RFC8610]). The CDDL and the prose are both normative. Rules the CDDL cannot express, such as runningCount equal to seq + 1, the issuer block alg equal to the envelope alg, and the absence of sigSuite from a decision receipt, are stated in the prose only.¶

<CODE BEGINS>
decision receipt:
  ("version", "alg", "backLink", "decisionDerived", "issuerAsserted")
execution receipt:
  ("version", "alg", "backLink", "outcomeDerived", "receiptAsserted")

<CODE ENDS>

<CODE BEGINS>
========== NOTE: '\' line wrapping per RFC 8792 ==========

{
  "alg": "ES256",
  "backLink": {
    "attestationDigest": "sha256:e3b0c44298fc1c149afbf4c8996fb92427a\
  e41e4649b934ca495991b7852b855",
    "attestationNonce": "dc8b561b-01e2-4e8e-9af2-b8b0fcb9a2ff"
  },
  "decisionDerived": {
    "decidedAt": "2026-09-25T00:17:48.320Z",
    "decision": "allow",
    "evidenceRef": {
      "canonicalization": "jcs-rfc8785",
      "digest": "sha256:7663868c3f5830dba2be46d514c65451404b8cf93d75\
  69efff1493eb3c380a4e",
      "ref": "vaara:trail/dc8b561b-01e2-4e8e-9af2-b8b0fcb9a2ff",
      "schema": "vaara.trail-decision/v0"
    },
    "policyId": "policy:vaara-engine/1",
    "reason": "allow: risk=0.12 (threshold allow<0.55 deny>0.85)",
    "riskScore": "0.12"
  },
  "issuerAsserted": {
    "alg": "ES256",
    "iat": "2026-09-25T00:17:48Z",
    "iss": "vaara:engine",
    "nonce": "RBKpasu2API112jCGYcLZ0M7",
    "secretVersion": "es256:dfa441deb94a9c1c",
    "sub": "vector-agent"
  },
  "signature": "7ebfd51b88d876a46fea986beb497ef0e122e84f3356c5244dd0\
  a2a893a8aa7eaee95ec0c84d12a41929ea15403be85b0e9b1211ae4e6acb6dcb96\
  c4bafc42ad",
  "version": 1
}

<CODE ENDS>

<CODE BEGINS>
========== NOTE: '\' line wrapping per RFC 8792 ==========

{
  "actionId": "vector-action-0",
  "agentId": "vector-agent",
  "decidedAt": "2026-09-25T00:17:48.320Z",
  "decision": "allow",
  "eventType": "decision_made",
  "previousHash": "sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e464\
  9b934ca495991b7852b855",
  "reason": "allow: risk=0.12 (threshold allow<0.55 deny>0.85)",
  "recordHash": "sha256:b0b163a567a30a5396583055f4a943484958c3ad082d\
  2d656b2b30ebf6105af4",
  "recordId": "dc8b561b-01e2-4e8e-9af2-b8b0fcb9a2ff",
  "riskScore": "0.12",
  "schema": "vaara.trail-decision/v0",
  "tenantId": "",
  "toolName": "read_file"
}

<CODE ENDS>

<CODE BEGINS>
========== NOTE: '\' line wrapping per RFC 8792 ==========

{
  "alg": "ES256",
  "backLink": {
    "attestationDigest": "sha256:79acdd4bb3c22a688b1c3321b9a26cafb5c\
  b58c990a963874066d04b8497f70b",
    "attestationNonce": "fixed-attestation-nonce-000"
  },
  "outcomeDerived": {
    "completedAt": "2026-05-29T10:00:00Z",
    "resultCommitment": {
      "projection": "{\"deleted\":true,\"path\":\"/archive/2024-Q3.m\
  d\"}",
      "projectionDigest": "sha256:c9a4caed49b3efaa7908a29a550b8d33ff\
  bb088c52d519242477223a83214198"
    },
    "status": "executed"
  },
  "receiptAsserted": {
    "alg": "ES256",
    "iat": "2026-05-29T10:00:00Z",
    "iss": "issuer://test",
    "nonce": "fixed-receipt-nonce-0001",
    "secretVersion": "v1",
    "sub": "agent:archiver"
  },
  "signature": "867c0439a289d77b75d489b07c42292095c947869365f1c92d98\
  2440338bddf0bb0bf91212cf9b1e681b076315862b5458f5167e98f0fca3a03c42\
  3b2a825f44",
  "version": 1
}

<CODE ENDS>

4. Decision and Evidence Binding (decisionDerived)

"allow" means the action was permitted. "block" means it was refused. "escalate" means it was referred to a person or another authority and was not permitted at the time of the decision; a later decision, with its own receipt, settles it. These are the only values. Profiles below name verdicts that a verifier computes, such as "deny" or "revise"; those are outputs of a checker, not values of decision.¶

rationale has the members rule, reason, and declaredIntent (strings, REQUIRED) and intentSatisfied (a boolean, OPTIONAL). binding has four REQUIRED digests: policyDigest over the JCS encoding of the policy, intentDigest over the UTF-8 bytes of the declared intent, inputsDigest over the JCS encoding of the evaluation inputs, and bindingDigest over the UTF-8 bytes of policyDigest, intentDigest, inputsDigest, and decision joined in that order by the single byte 0x1F. decisionProof is a proof that the committed values reach the stated decision, opened against bindingDigest; its format is not defined by this document. A consumer that does not verify decisionProof MUST NOT read it as evidence of anything, and the signature covers it either way.¶

The binding is recomputable: given the receipt and the evidence record, a third party confirms that the digest of the evidence record equals evidenceRef.digest with no access to the issuer.¶

The digest is the binding; ref is advisory. A profile MAY assign the same ref to more than one evidence record, and profiles in use do: where a single action settles to several parties, each party's record is a separate evidence record carried under one shared ref. Those records differ under digest because their contents differ.¶

A consumer therefore MUST NOT resolve an evidence record by ref alone, and MUST confirm that the digest of the evidence record equals evidenceRef.digest before treating the record as the one the receipt decided over. Resolving by ref alone admits a record that shares the locator but is not the record the issuer signed over, and no check in this document fails when that happens.¶

5. Timestamp Anchors (timestampAnchors)

A timestamp anchor is evidence from outside the issuer that a decision receipt existed no later than a stated time. Anchors are optional and are attached to decision receipts; an execution receipt carries its time evidence in existenceProof (Section 3.6). Every anchor binds anchoredDigest, the digest of the receipt's signed payload (Section 3.2), so an anchor commits to the exact signed receipt and does not depend on any other anchor.¶

<CODE BEGINS>
{
  "method": "rfc3161",
  "anchoredDigest": "sha256:...",
  "token": "<base64 DER RFC 3161 TimeStampToken>",
  "authority": "<optional human-readable authority name>"
}

<CODE ENDS>

method is REQUIRED and selects the members that follow. anchoredDigest is REQUIRED for every method. authority is OPTIONAL and informative.¶

For every method a consumer MUST first recompute anchoredDigest from the receipt and reject the anchor if it differs. For the rfc3161 methods token is the base64 DER TimeStampToken, and a consumer requires its message imprint to equal anchoredDigest, or the blinded imprint below. The method name is not proof of who signed the token: a consumer treats the attested time as independent of the issuer only when it checks the token signer against a certificate or trusted list it holds, and as qualified only when that list is a qualified trust list.¶

A blinded method keeps the authority's request log from being matched against published receipts. The producer draws a fresh 32-byte salt from a cryptographic random source, sends the authority the imprint SHA-256("vaara/anchor-blind/v1" || salt || D), where D is the 32 raw bytes of anchoredDigest and the label is ASCII, and carries the salt as anchorSalt (64 lowercase hexadecimal characters). A producer MUST NOT reuse a salt. A consumer MUST recompute the imprint, MUST reject a blinded anchor whose anchorSalt is absent or malformed, and MUST reject an unblinded method that carries anchorSalt, so that a blinded anchor is never read as a plain one. Blinding does not hide the anchor from anyone holding the receipt, since the salt travels with it, and it does not hide the timing or volume of requests from the authority.¶

For the scitt method logId is the base64 SHA-256 of the log's name, leafIndex and treeSize are integers, inclusionProof is an array of base64 sibling hashes, and rootHash is the base64 root at the time of append. A consumer recomputes the root from the leaf (the 32 raw bytes of anchoredDigest) and inclusionProof. rootHash is the log operator's own claim. The anchor witnesses the receipt only when the consumer checks rootHash against a tree head it holds independently of the receipt, directly at the same tree size or through a consistency proof ([RFC9162]) to a later head.¶

The method registry is maintained by this document. A consumer MUST NOT treat an anchor whose method it does not implement as verified, and MUST NOT reject the receipt because of it: the receipt's integrity rests on its signature, and an anchor is additional evidence.¶

Registration with a SCITT Transparency Service ([RFC9943]) complements an anchor and is not one. A receipt's bytes can be the attached payload of a SCITT Signed Statement. The service's receipt commits to that Signed Statement as registered, not to anchoredDigest, so it travels beside the receipt and is not carried in timestampAnchors. A consumer verifies it against the statement bytes and the service's published keys, with no call to the service.¶

A receipt MAY carry several anchors of different methods. The producer's own time evidence (rfc3161 from its own authority, or scitt) and the legal anchor (rfc3161-eidas-qualified) are independent and can be added separately.¶

6. Profiles

A profile is a downstream specification that uses this envelope unchanged and defines only its own evidence record (the schema and contents behind evidenceRef), plus any join keys it needs. A profile MUST state the vaara.receipt/vN version it pins to and SHOULD ship recomputable vectors.¶

There is one binding mechanism, not one per plane. Each named profile (Section 6.3, Section 6.4, Section 6.5, Section 6.6) names an external artifact by content address and binds it through this envelope unchanged; they differ only in which artifact is hashed and the evidenceRef.ref label. Section 6.7 states that mechanism in schema-agnostic form: a single binding that does not depend on what is connected to it. The named profiles are instances of it, kept because a given ecosystem pins to a label it recognizes as its own.¶

7. Conformance

An implementation conforms to vaara.receipt/v1 if, for every receipt it emits:¶

1. The receipt keeps the rules of Section 3 and Section 4: one kind, no undefined members, an alg defined in Section 3.1 and repeated unchanged in the issuer block, a decision or status value defined there, and a well-formed completeness block where one is present.¶
2. The Section 3.2 signature verifies against the stated alg and key.¶
3. evidenceRef.digest equals sha256(JCS(evidence_record)) for the referenced record, under one of the Section 2 canonicalization labels.¶
4. Any timestampAnchors[].anchoredDigest equals the digest of the signed payload of the same receipt, and any existenceProof.recordDigest equals the digest of the receipt with existenceProof removed.¶
5. For an execution receipt (Section 3.7), backLink.attestationDigest equals "sha256:" of the JCS-canonical predecessor and backLink.attestationNonce equals the predecessor's issuerAsserted.nonce; and when status is "executed", resultCommitment.projectionDigest equals "sha256:" of the projection bytes.¶
6. Any cage block in an evidence record (Section 6.8.1) keeps the rules of that section.¶

The committed vectors plus _check_independent.py are the reference conformance suite; running the x402 profile checker and having it exit 0 is a passing run for that profile.¶

The same vectors serve as recomputable test evidence for the reversibility classification and enforcement controls in OWASP AISVS 1.0 ([AISVS2026]), specifically C9.2.3 (trusted reversibility classification), C9.2.4 (runtime enforcement of reversibility), and C9.2.10 (highest-impact class enforcement across multi-step chains).¶

8. Implementation Status

This section records the status of known implementations at the time of writing, per [RFC7942]. It is informational and may be removed before publication. The format is not specific to any single agent runtime; it records decisions about autonomous actions in general, of which AI agent tool calls are one case.¶

A reference implementation ships the format at three layers, all in the source repository ([VAARA-REPO]):¶

• A library that emits and verifies receipts, including the floor profile (Section 6.8): a default install signs one receipt per decision it records.¶
• The public conformance vectors under tests/vectors/ with per-profile standalone checkers (_check_independent.py) that import no issuer code, so a second party recomputes every digest, signature, back link, and completeness verdict from the bytes alone. Independent reimplementations have reproduced these vectors.¶
• A desktop application for macOS that reads the engine's audit trails, shows each allow, escalate, or deny decision as it is recorded, routes the machine's agent clients through the governance proxy, and verifies decision receipts with its own JCS, SHA-256, and P-256 code written in Swift. That verifier runs against the same conformance vectors as the library in continuous integration, so the two cannot drift apart unnoticed.¶

A default install of the library signs a receipt for every decision. The signing dependencies are part of the base package, not an optional extra.¶

The implementation also takes a receipt to roots outside its own signature. It registers a receipt with an IETF SCITT Transparency Service ([RFC9943]) over the reference APIs ([I-D.ietf-scitt-scrapi]) and verifies the service's receipt with no network access (Section 5). A continuous-integration job registers a decision receipt with a SCITT ledger built from its public source, stops the ledger, and verifies the result offline. For an AMD SEV-SNP host, it checks an attestation report's signing key offline against AMD's root key: the root certifies the intermediate key, the intermediate certifies the VCEK or VLEK ([AMD-VCEK]), the VCEK's chip identifier and TCB match the report ([AMD-SNP-ABI]), and the report signature verifies under it. The check passes on a report from production hardware. It does not consult AMD's certificate revocation list. The in-guest report emitter follows the kernel interface and has not yet been run inside a guest by the implementation.¶

The library, vectors, and checkers are exercised on every release. The application is built from source on the installing machine by its package formula and is not distributed as a notarized build.¶

9. Versioning

The envelope version is the integer "version" member and the vaara.receipt/vN schema identifier. A change to the signed-payload member set, the canonicalization, or the signature construction bumps N.¶

A new OPTIONAL member of a block defined in Section 3 or Section 4 is added only by a revision of this document and does not bump N. Because those blocks are closed (Section 3), a consumer built to an earlier revision rejects a receipt that carries the new member. That is intended: it fails closed rather than verifying bytes it does not understand. A producer that needs receipts accepted by such consumers omits the new member. New anchor methods and new profiles do not change how the envelope is parsed.¶

10. Security Considerations

The integrity of a receipt rests on the Section 3.2 signature over the JCS-canonical signed payload, not on any timestamp anchor or trust root. A consumer MUST verify that signature, under the algorithm "alg" names and with the key the issuer block names through iss and secretVersion, before relying on any field. Because the signed payload excludes "signature" and "timestampAnchors", anchors added after signing cannot alter the signed content; a consumer MUST recompute each anchoredDigest from the signed payload rather than trusting the anchor's stated value.¶

Verifying that signature establishes that the key the issuer block names produced the signed payload and that the payload has not changed since. It says nothing about the state of that key now. Offline verification is a computation over the parameters the consumer holds, while revocation is a property of the present, and this document defines no revocation mechanism and places no freshness requirement on key material. A consumer MUST NOT treat a signature that verifies as evidence that the signing key is still valid. Where a decision depends on revocation state, the key resolution path and the staleness a deployment accepts are operational parameters of that deployment and MUST be stated by it; the receipt does not carry them.¶

Recomputability depends entirely on canonicalization. A producer and a consumer that disagree on JCS output for the same JSON value will compute different digests; implementations MUST use a conformant JCS ([RFC8785]) implementation and MUST treat any of the three accepted labels as the same algorithm.¶

The argument commitment in the authorization profile (Section 6.4) lets a receipt be published while the raw arguments stay private, but a low-entropy argument set is open to a dictionary attack against the commitment. Producers SHOULD ensure the committed object carries sufficient entropy (for example a per-call nonce) where argument confidentiality matters.¶

An absent refusal is evidence only within a declared coverage boundary (Section 6.4). A reader MUST NOT read a missing receipt as "the action did not happen"; without a coverage block it means only "not observed", and with one it means "not refused within this boundary". The completeness block makes a dropped receipt inside the boundary detectable, but a pure tail truncation is not detectable by sequence contiguity alone and requires a timestamp anchor over the running count to close.¶

A decision receipt records what was decided. It does not record what followed. A decision receipt carrying the verdict "allow", with no execution receipt bound to it by backLink, establishes that the action was permitted and establishes nothing about whether it ran. A consumer MUST NOT read a decision receipt as evidence that the action took effect: the executed status lives in the execution receipt's outcomeDerived and is signed there (Section 3.7). Only the pair establishes that an action was permitted and then took effect, which is why backLink is a required member.¶

A recipient that consumes a sealed maxClass to gate its own next action (Section 6.4) MUST bind the class to the signature before acting on it. maxClass sits in the unsigned evidence block and is covered by the signature only through the seal's decisionDerived.evidenceRef.digest = "sha256:" + JCS(evidence). A recipient MUST verify each receipt's signature and that its evidence recomputes to that signed digest; a seal whose binding fails contributes no class and the gate fails closed. A recipient that reads maxClass raw, without recomputing the binding, can be made to permit an irreversible action whose class an agent relabeled into a permitted one while the record signature, which never covered the evidence, still verifies. The gate is also a membership test over class labels, not an ordering; this document defines no ordering over classes, and a recipient MUST NOT infer one.¶

The cage block (Section 6.8.1) is an assertion by the issuer, bound by the issuer's signature. confirmed true is not an attestation by the cage, the kernel, or the hardware: a compromised issuer can sign a block that claims confinement it did not have, and a process can be confined in ways the issuer cannot see. A consumer that needs confinement established independently of the issuer needs evidence from outside it, such as a hardware attestation of the platform. Bases differ in strength. "hypervisor_present" shows that a virtual machine is underneath and not which one or how it is configured, and a mandatory access control label shows that a profile is attached and not what the profile allows. configDigest names the declared configuration; it does not show that the declared configuration is the one in force.¶

11. Privacy Considerations

A receipt is built to be handed to parties outside the issuer, so whatever it carries in clear travels with it. The signed blocks carry identifiers (iss, sub, aud, taskId), times, a decision, and an optional free-text reason. Evidence records defined by profiles carry more: the engine decision profile (Section 6.8) carries the agent identifier, the tool name, the tenant, and the reason. A producer SHOULD treat sub, agent and tenant identifiers, and reason text as potentially personal data where the subject or the operator is a natural person, and SHOULD keep personal data out of reason.¶

The format keeps the action's inputs and results out of the receipt by design. Arguments and results enter only as commitments (Section 3.7, Section 6.4), and the evidence record is bound by digest, so a receipt can be shared while the evidence stays with the operator. A commitment over a small or predictable value can be reversed by guessing; the dictionary-attack paragraph in Section 10 applies to every commitment in this document, not only to arguments.¶

Receipts are durable and have no expiry. A receipt that has left the issuer cannot be withdrawn, and its signature keeps verifying. Producers subject to erasure obligations should keep erasable data in evidence records held by the operator, where deleting the record leaves the receipt verifiable and the evidence unrecoverable from it. Timestamp anchors disclose to the time-stamping authority that a receipt existed at a time; the blinded methods (Section 5) keep the authority's log from being matched to published receipts.¶

12. Regulatory Applicability

This section is informative. It states which element of the receipt carries what a named legal or standards text asks for, and which public conformance suite in [VAARA-REPO] exercises that element. It does not assert that a deployment holding receipts complies with any text. Compliance is a property of the deployment and of its legal reading; the receipt is evidence a reader can recompute. Every suite named below ships a checker that imports no issuer code (Section 7).¶

The mapping covers Union law first because that is where the format is deployed. Other regimes with an equivalent logging obligation map onto the same rows and are not enumerated.¶

[AIACT] Art. 12(1): Automatic recording of events over the lifetime of a high-risk system.

The decision record and the execution receipt that answers it (Section 3, Section 3.7), one pair per action. Suites: execution_receipt_v0, decision_pairing_v0.¶

[AIACT] Art. 12(1), read with Art. 19 and Art. 26(6): Records that stay verifiable across a retention period measured in years, held by the provider and by the deployer.

Signature over canonical bytes (Section 2) with the signing key identified in the envelope, so a record verifies after the issuer rotates keys; the regulator package export. Suites: key_rotation_v0, article12_fold_v0.¶

[AIACT] Art. 12(1): A record of events, which a reader can only rely on if it can tell a missing record from an event that did not occur.

Gap-evident contiguity over a declared coverage boundary, checkable from the held receipts and the issuer's public key alone. Suites: contiguity_v0.¶

[AIACT] Art. 14: Human oversight, including the ability to intervene and override.

The disposition of a decision: who produced the allow, deny or escalate, so that a record cannot overstate human involvement. Suites: decision_disposition_v0.¶

[AIACT] Art. 13: Operation transparent enough for deployers to interpret output.

The one-page audit summary rendered from a record set: verdict, counts, findings, with pinned bytes. Suites: audit_summary_v0, record_set_v0.¶

[eIDAS] Art. 41 and 42: A qualified electronic time stamp enjoys a presumption of accuracy of the date and time it indicates.

An RFC 3161 token from a qualified trust service over the record's canonical bytes: the rfc3161-eidas-qualified anchor on a decision receipt (Section 5) and existenceProof on an execution receipt (Section 3.6). Suites: qualified_time_v0, which exercises existenceProof.¶

[GDPR] Art. 5(1)(c): Data minimisation.

Evidence enters the receipt by content digest, never by value (Section 4); the record proves what was decided on without carrying it. Suites: evidence_ref_v0.¶

[GDPR] Chapter V: Transfers of personal data to third countries.

A signed data-locality record binding one action's transfer facts to the decision that ran, optionally with a region attestation from a party other than the issuer. Suites: data_locality_v0.¶

[DORA-RTS] Art. 12: Logging that is protected against unauthorised alteration and whose clocks are synchronised.

Hash chain and signature over canonical bytes; the external time anchor as the clock the issuer does not control. Suites: transparency_consistency_v0, qualified_time_v0.¶

[PLD] Art. 9: Disclosure of relevant evidence at the claimant's request, in an accessible and understandable form.

A receipt recomputable by the claimant's expert from the bytes, with no access to the producer's systems. Suites: record_conformance_v0, article12_fold_v0.¶

[ISO42001] Annex A, event logging control: Recording of AI system event logs.

The same decision and receipt pair; the summary page is the management-system artefact. Suites: execution_receipt_v0, audit_summary_v0.¶

Two limits apply to every row. First, a receipt records what its issuer observed at signing time; the revocation and key-status limits in Section 10 hold regardless of which obligation the record is read against, and a suite (revocation_freshness_v0) pins what a clean answer may claim. Second, the rows name obligations on the operator of a system, and the receipt is the operator's evidence; the format places no obligation on a verifier beyond recomputation.¶

13. Related Work

Several independent research efforts published in 2026 converge on the same core observation this document implements: that governing agent behavior requires binding decisions to individual actions rather than to sessions or agents, using content-addressed, independently verifiable records.¶

Salfeld [Salfeld2026] introduces a zero-trust execution framework grounded in signed execution receipts with DSSE and Ed25519, demonstrating the pattern on a proof-of-concept infrastructure (zta-hub). He and Yu [He2026SEB] propose a Sovereign Execution Broker that interposes on tool calls with per-action attestation in cloud environments. He and Yu [He2026SAB] extend this to a Sovereign Assurance Boundary covering multi-tenant and Kubernetes deployments. Uchibeke [Uchibeke2026] examines pre-execution attestation and the case for binding authorization evidence before a tool call is dispatched.¶

All four adopt per-action signed records with content-addressed evidence. This document adds a held-set completeness mechanism (Section 6.4) and publishes conformance vectors with checkers that import no issuer code.¶

A parallel line of work in the IETF community addresses signed receipts for agent actions taken over the Model Context Protocol (MCP). [ACTA-RECEIPTS] defines a base signed-receipt format for machine-to-machine access-control decisions, canonicalized with JCS ([RFC8785]) and verified against an issuer key resolved out of band; it records a decision after it is made. [ASQAV-COMPLIANCE] layers a regulatory compliance profile on that base format, mapping fields to obligations under the EU AI Act and DORA and tightening optional fields to required ones for audit use. [AGENTROA] places an enforcement proxy outside the agent process that authorizes an action before it runs, binds the MCP tool call by a hash of its canonical arguments, and can register the authorization with a SCITT transparency service ([RFC9943]). [VCP] profiles the same SCITT substrate for audit trails in algorithmic trading, a different domain.¶

[AGENT-ACTION-RECEIPTS] specifies a newline-delimited log of per-action receipts, and uses one construction this document does not. Its chain link is the SHA-256 of the previous record's transmitted octets, including that record's signature and any member the verifier does not recognize, where the linkage here and in the formats above digests a re-canonicalization. Digesting the transmitted octets makes chain verification independent of agreement about canonicalization and covers extension members a re-canonicalized digest excludes. Its signed byte sequence is a fixed member order rather than JCS, and its stated interoperability constraints exclude non-ASCII member names and non-integer numbers from the signed set.¶

This document shares the per-action, content-addressed, recomputable approach of these efforts. Three of its properties are worth naming next to them. First, the held-set completeness mechanism of Section 6.4: a monotonic sequence with a running count and an optional sealing record lets a third party prove a receipt is missing from a set, and a sealed worst-case class lets a chain recipient gate its own next action on the held set alone, with no issuer access. Second, one profile-neutral envelope carries authorization, settlement, checkout, and external-execution evidence through the same binding (Section 6). Third, the envelope's backLink binds a decision to its predecessor attestation, so a pre-execution authorization and its post-execution record form one recomputable pair rather than a single post-hoc entry; [AGENTROA] records the authorization decision and states that it carries no paired post-execution receipt.¶

A receipt is re-expressible as a RATS Entity Attestation Result ([I-D.ietf-rats-ear]), and its timestamp anchors admit an eIDAS-qualified timestamp (Section 5) as a swappable method for legal weight. This work references the formats above rather than profiling any of them, because the held-set completeness mechanism and the profile-neutral envelope are properties of the format that a field-level profile could not add.¶

[AUDIT-ARCH] describes an architecture for auditing AI agent delegation and interactions. It specifies roles, four classes of audit record and a set of candidate work items, and deliberately no wire format; its illustrative field names are stated to be placeholders. The envelope specified here is a candidate for its Action Record class: it is produced at the boundary where an action took effect, it carries a stable reference to the evidence a decision was derived from (Section 4), and it is re-expressible as a RATS Entity Attestation Result. This document defines no equivalent of that architecture's Authorization Transition record, which carries a change in permission state and is replayable to reconstruct the authorization in force at an instant. The envelope's backLink binds a decision to its predecessor attestation, while the architecture's correlation identifier ties a record to the interaction that motivated it. Those are different edges, so a deployment using both would carry both.¶

14. IANA Considerations

This document has no IANA actions. The timestamp anchor method registry (Section 5) and the profile registry (Section 6.1) are maintained by the specification, not by IANA, in this version.¶

Appendix A. Envelope Schema (CDDL)

This appendix is normative. It describes the JSON encoding of a receipt (Section 3) in CDDL. Maps are closed: a member not named here is not allowed, which is the rule of Section 3. A reference implementation validates every positive receipt in its published conformance vectors against this schema.¶

<CODE BEGINS>
; vaara.receipt/v1 envelope, JSON encoding.
; Maps are closed: a member not named here is not allowed.
; Rules CDDL cannot state are in the prose: runningCount is
; seq + 1, the issuer block alg equals the envelope alg, and
; the classical part of sigSuite equals alg.

receipt = decision-receipt / execution-receipt

decision-receipt = {
  version: 1,
  alg: alg,
  backLink: back-link,
  decisionDerived: decision-derived,
  issuerAsserted: decision-issuer-block,
  signature: hex,
  ? timestampAnchors: [* anchor],
}

execution-receipt = {
  version: 1,
  alg: alg,
  backLink: back-link,
  outcomeDerived: outcome-derived,
  receiptAsserted: issuer-block,
  signature: hex,
  ? pqSignature: pq-signature,
  ? existenceProof: existence-proof,
}

alg = "ES256" / "RS256" / "HS256"
hex = tstr .regexp "[0-9a-f]+"
digest = tstr .regexp "sha256:[0-9a-f]{64}"
nonempty = tstr .regexp ".+"
date-time = tstr .regexp "[0-9-]{10}T[0-9:]{8}([.][0-9]+)?Z"
decimal = tstr .regexp "-?[0-9]+([.][0-9]+)?"

back-link = {
  attestationDigest: digest,
  attestationNonce: nonempty,
  ? fallbackProjection: nonempty,
}

issuer-block = {
  issuer-members,
  ? sigSuite: "ES256+ML-DSA-65" / "RS256+ML-DSA-65",
}

; A decision receipt has no pqSignature, so its issuer block
; names no sigSuite (SPEC.md 2.5).
decision-issuer-block = {
  issuer-members,
}

issuer-members = (
  iss: tstr,
  sub: tstr,
  iat: date-time,
  nonce: tstr,
  alg: alg,
  secretVersion: tstr,
  ? aud: nonempty,
  ? taskId: nonempty,
  ? completeness: completeness,
  ? cryptoPosture: crypto-posture,
)

completeness = {
  boundaryId: nonempty,
  seq: uint,
  runningCount: uint,
}

crypto-posture = {
  assetType: "algorithm",
  nistQuantumSecurityLevel: 0..5,
  algorithms: [+ crypto-algorithm],
}

crypto-algorithm = {
  algorithm: nonempty,
  primitive: nonempty,
  nistQuantumSecurityLevel: 0..5,
}

decision-derived = {
  decision: "allow" / "block" / "escalate",
  decidedAt: date-time,
  ? reason: tstr,
  ? policyId: tstr,
  ? riskScore: decimal,
  ? thresholdAllow: decimal,
  ? thresholdBlock: decimal,
  ? clientTurnId: tstr,
  ? evidenceRef: evidence-ref,
  ? rationale: rationale,
  ? binding: binding,
  ? decisionProof: { * tstr => any },
}

evidence-ref = {
  canonicalization: "jcs-rfc8785" / "JCS" / "jcs-json-v1",
  digest: digest,
  schema: nonempty,
  ? ref: nonempty,
}

rationale = {
  rule: tstr,
  reason: tstr,
  declaredIntent: tstr,
  ? intentSatisfied: bool,
}

binding = {
  policyDigest: digest,
  intentDigest: digest,
  inputsDigest: digest,
  bindingDigest: digest,
}

outcome-derived = {
  status: "executed" / "refused" / "errored",
  completedAt: date-time,
  ? resultCommitment: projection-commitment / reference-commitment,
  ? decisionDigest: digest,
}

projection-commitment = {
  projection: tstr,
  projectionDigest: digest,
}

reference-commitment = {
  ref: tstr,
  digest: digest,
  canonicalization: "jcs",
}

pq-signature = {
  alg: "ML-DSA-65",
  keyid: nonempty,
  sig: hex,
}

existence-proof = {
  backend: "rfc3161-eidas-qualified",
  hashAlgorithm: "sha256",
  recordDigest: digest,
  token: nonempty,
}

anchor = rfc3161-anchor / blinded-anchor / log-anchor / other-anchor

rfc3161-anchor = {
  method: "rfc3161" / "rfc3161-eidas-qualified",
  anchoredDigest: digest,
  token: nonempty,
  ? authority: tstr,
}

blinded-anchor = {
  method: "rfc3161-blinded" / "rfc3161-eidas-qualified-blinded",
  anchoredDigest: digest,
  token: nonempty,
  anchorSalt: tstr .regexp "[0-9a-f]{64}",
  ? authority: tstr,
}

log-anchor = {
  method: "scitt",
  anchoredDigest: digest,
  logId: nonempty,
  leafIndex: uint,
  treeSize: uint,
  inclusionProof: [* tstr],
  rootHash: nonempty,
  ? authority: tstr,
}

; A method this document does not define: carried, never
; treated as verified. CDDL cannot say "any method name but
; the three above", so this alternative also admits a
; registered name with members missing; the prose rule that
; a registered method keeps its own shape is checked by the
; verifier, not by this schema.
other-anchor = {
  method: tstr,
  anchoredDigest: digest,
  * tstr => any,
}

<CODE ENDS>

Appendix B. Cage Drivers and Bases in Use

This appendix is informative. It lists the driver and basis values a reference implementation emits at the time of writing. No value here is normative, and either list can grow without a revision of this document.¶

Author's Address