Compliance Profile of Signed Action Receipts for AI Agents

1.1. Profile, Not Fork

[ACTA-RECEIPTS] specifies a generic, signed receipt envelope for recording machine-to-machine access control decisions made by AI agents. Section 2.2 of [ACTA-RECEIPTS] defines a common payload field set in which all fields except type, issued_at, and issuer_id are OPTIONAL. Section 5.7 of [ACTA-RECEIPTS] introduces hash chaining (previousReceiptHash) inside an optional Commitment Mode extension. [ACTA-RECEIPTS] does not define receipt retention, does not require timestamping anchors, and does not bind to any regulatory regime.¶

This document is an additive overlay on [ACTA-RECEIPTS]: it constrains fields the upstream draft leaves OPTIONAL, fixes their values where regulation requires, and adds two extension fields with reserved names. A Compliance Receipt remains a conformant [ACTA-RECEIPTS] receipt. Field references use upstream field names rather than section numbers, to reduce maintenance hazard if upstream re-numbers in a future revision.¶

1.2. Scope

This document fills the regulatory binding gap for three obligations: Article 12 (record-keeping) and Article 26 (deployer obligations) of the EU AI Act, and Article 17 (ICT-related incident management) of DORA. The bindings are written from the Deployer's perspective. Providers of high-risk AI systems are subject to a parallel log-retention obligation under Article 19(1) of the EU AI Act; where a Provider operates the producing system, the same retention rules apply Section 5.5.¶

A verifier that implements only [ACTA-RECEIPTS] can cryptographically validate a profile receipt but cannot attest the additional compliance bindings of this document.¶

4.1. Common Payload Fields

4.2. Decision Receipt Fields (type protectmcp:decision)

The decision field value MUST be allow, deny, or rate_limit. Implementations using a different internal vocabulary (e.g. permit for allow) MUST normalise on emission and on Audit Pack export.¶

The upstream tool_name field (REQUIRED in [ACTA-RECEIPTS] Section 3.1.1) is REQUIRED for Compliance Receipts of type protectmcp:decision.¶

4.3. Hash-Chain Linkage (OPTIONAL upstream, REQUIRED in this profile)

Upstream Commitment Mode introduces previousReceiptHash as part of an optional extension. This profile makes the linkage REQUIRED. Implementations MUST emit a previousReceiptHash field, populated as specified by Section 5.7 of [ACTA-RECEIPTS]: the lowercase hex encoding of SHA-256(JCS(receipt)) per [RFC8785], where the receipt covered by the digest is the entire signed receipt object including the signature field. The first receipt in a chain MUST set this field to the all-zero SHA-256 value (this profile's stipulation; [ACTA-RECEIPTS] Section 5.7 specifies only the digest scope of subsequent links). JSON key is the literal previousReceiptHash (camelCase, case-sensitive); snake_case aliases MUST NOT appear on the wire.¶

4.4. Anchoring (No Upstream Equivalent)

[ACTA-RECEIPTS] lists Sigstore Rekor in its Implementation Status appendix as an OPTIONAL temporal anchor. This profile imposes a normative anchoring requirement.¶

Compliance Receipts MUST be anchored. An anchor is an [RFC3161] timestamp token covering the signed envelope, an [OPENTIMESTAMPS] commitment covering the envelope, or both; implementations SHOULD emit both forms. For both anchor types, the bytes committed are SHA-256(JCS(envelope_minus_anchors)), where envelope_minus_anchors is the wire envelope object with the anchors top-level key removed prior to canonicalization, leaving the two-key object {payload, signature}. The anchors key MUST be removed from the object, not set to null or to an empty array; these produce different JCS output and break interoperability (mirroring the upstream Section 5.6 stripping rule). The anchor thereby binds payload and signature without being self-referential. The anchor evidence MUST be retained alongside the receipt for the applicable retention window. Verifiers MUST reject Compliance Receipts that lack at least one valid anchor.¶

An anchor MAY be attached after issuance if the receipt is persisted with an unambiguous pending marker and the anchor lands within a documented bound. For [OPENTIMESTAMPS], this profile imposes a 7-day deadline; this is a profile-imposed bound, not a property of the OpenTimestamps protocol, whose calendar-to-block upgrade time depends on the calendar operator's publication interval. [RFC3161] tokens MUST be obtained synchronously. A verifier MUST treat a pending receipt as non-conformant once the bound elapses.¶

The anchor MAY cover an aggregate of receipts (for example, a Merkle root over a batch) rather than each receipt individually, provided that the inclusion proof linking the receipt to the aggregate is retained alongside the receipt and the aggregate anchor.¶

Where the anchor type is [RFC3161], the full TimeStampResp DER bytes MUST be retained, sufficient for offline verification by a holder with access to the TSA's published public key. Time-stamp tokens carrying ESSCertIDv2 per [RFC5816] MUST be accepted by Compliance Verifiers. Where the anchor type is [OPENTIMESTAMPS], the upgrade from the initial calendar attestation to the Bitcoin block attestation MUST be completed within the 7-day profile-imposed bound, and the upgraded proof MUST be retained for the applicable retention window per the second paragraph of this section.¶

4.5. Extension Fields

This profile defines two extension fields that MAY appear in the signed payload alongside the fields defined by [ACTA-RECEIPTS]. Neither field is defined upstream.¶

risk_class:

A vocabulary term identifying the risk classification of the Action under the Deployer's risk management documentation. The vocabulary MUST be referenced in the Audit Pack metadata.¶

incident_class:

A vocabulary term identifying the ICT-related incident classification of the Action. Binding classification criteria are drawn from [REG-2024-1772]. The reporting templates are bound by [REG-2025-302], whose Annex II data glossary, field 3.23 (Type of the incident) defines the canonical six-value enumeration: Cybersecurity-related, Process failure, System failure, External event, Payment-related, Other (please specify). Implementations MAY refine the set, provided the flattened mapping in the Audit Pack manifest (Section 8) projects each refinement to one of the six canonical values.¶

risk_class MUST be encoded as a JSON string. incident_class MUST be encoded as a JSON string drawn from the canonical six-value enumeration defined above, OR as a JSON array of such strings to preserve the "Choice (multiple)" semantics of Annex II field 3.23 of [REG-2025-302]. Both extension fields appear inside the signed payload object and are therefore covered by the upstream Section 5.6 signature scope. Both fields are OPTIONAL at the syntactic level but MAY be REQUIRED by the regime bindings in Sections 5 through 7 of this document.¶

Implementations MAY define additional extension fields. Such fields MUST NOT collide with names defined by [ACTA-RECEIPTS] or by this document. Implementations defining extension fields SHOULD register them in the registry described in Section 11.¶

5.1. Article 12(1), automatic recording of events

Article 12(1) requires High-Risk AI Systems to technically allow for the automatic recording of events (logs) over the lifetime of the system. The signed-receipt format provides one mechanism that satisfies that logging capability; alternative mechanisms remain valid. Where this profile is chosen, a Compliance Receipt SHOULD be produced for every Action against an external resource, and a configuration change that disables receipt generation SHOULD be recorded as a protectmcp:lifecycle Compliance Receipt. Implementations MAY emit at finer or coarser granularity so long as the log set, taken together, satisfies Article 12(2)(a) through (c).¶

5.2. Article 12(2)(a), identifying situations that may result in the high-risk AI system presenting a risk within the meaning of Article 79(1) or in a substantial modification

The combination of type, decision, reason, and policy_digest MUST be sufficient for an auditor to identify, by query alone, receipts that correspond to risk situations enumerated in the Deployer's risk management documentation. Where the Deployer classifies an Action as risk-bearing, the receipt MUST carry a risk_class extension field.¶

5.3. Article 12(2)(b), facilitating the post-market monitoring referred to in Article 72

The hash-chain linkage required by Section 4.3 satisfies post-market monitoring traceability. The chain head MUST be made available to the Provider and to the competent authority on request.¶

5.4. Article 12(2)(c), monitoring the operation of high-risk AI systems referred to in Article 26(5)

Any change to the policy artefact referenced by policy_digest MUST produce a new digest. A change in policy_digest between two otherwise-comparable Actions may be examined by the Deployer or by a regulator as a candidate substantial-modification event under Article 43, and MUST be retained at least as long as the longest receipt in the chain that references either digest.¶

5.5. Retention

Article 12 itself sets no retention period; the operative deployer floor is Article 26(6) ("at least six months"), with the parallel provider floor in Article 19(1). Unless Union or national law sets a longer period, this profile expresses that floor as 184 days from the date of the Action: 184 is the maximum number of days in any rolling six-calendar-month window (worst case Aug-Jan, 31+30+31+30+31+31), so retention of 184 days satisfies "at least six months" regardless of the calendar months over which the window falls. Implementations that prefer the more common 183-day pick MAY use 183 days and remain conformant with Article 26(6) so long as per-receipt retention is at least six months from the Action date. Where the Deployer is also a Financial Entity, the sectoral floor in Section 7.4 applies.¶

6.1. Article 26(1), in accordance with the instructions for use

policy_digest MUST resolve through Section 8 to a retained artefact (machine check). The Deployer SHOULD demonstrate consistency with the Provider's instructions for use (process check). Inability to perform the machine check is presumed non-compliance.¶

6.2. Article 26(2), assign human oversight

For any Action whose decision is allow and which the Deployer's risk management documentation marks as requiring human oversight, the Deployer MUST ensure that the receipt is either reviewed by a designated natural person within the period required by national law, or that a follow-on protectmcp:lifecycle Compliance Receipt records the absence of such review with a reason code. Both records MUST themselves be Compliance Receipts. This profile addresses the trigger and record of oversight; the competence, training, authority, and necessary support of the reviewer required by Article 26(2) remain the Deployer's separate responsibility.¶

6.3. Article 26(5), monitor the operation

A Deployer MUST be able to produce an Audit Pack covering any contiguous time window since the High-Risk AI System became operational.¶

6.4. Article 26(6), keep the logs for at least six months

Compliance Receipts under this binding MUST be retained for at least the period stated in Section 5.5. Where the Deployer is also a Financial Entity, the longer sectoral floor in Section 7.4 applies.¶

7.1. Article 17(1), ICT-related incident management process

A Compliance Receipt produced inside a Financial Entity's ICT environment may serve as the canonical record of an Action that triggered an ICT-related incident. action_ref MUST be carried into the Financial Entity's incident workflow as the primary correlation key.¶

7.2. Article 17(2), record all ICT-related incidents and significant cyber threats

The hash chain required by Section 4.3 supports the recording obligation of Article 17(2) by making after-the-fact alteration of recorded incidents detectable. The Financial Entity MUST be able to produce, on request, the chain segment covering the period of an incident, together with the anchor evidence that fixes the chain to wall-clock time.¶

7.3. Article 17(3)(b), establish procedures to identify, track, log, categorise and classify ICT-related incidents

For Actions identified as part of an ICT-related incident, the producing system MUST emit incident_class. The classification criteria are those set out in Article 18(1) of [DORA], with further specification in [REG-2024-1772]. The canonical reporting enumeration to which incident_class flattens is bound by Annex II field 3.23 of [REG-2025-302] (see Section 4.5). Implementations MUST publish a flattened mapping in the Audit Pack manifest as required by Section 4.5.¶

7.4. Retention

Article 17 of [DORA] does not itself set a uniform numeric retention floor. The five-year (1827-day) figure used by this profile derives from sectoral instruments that overlap DORA-scoped Financial Entities. Investment firms keep records of all services, activities and transactions under Article 16(6) of [MIFID2], with Article 72 and Annex I of [REG-2017-565] fixing the form and content of those records. The explicit five-year retention period in [MIFID2] is set by Article 16(7) for records of telephone conversations and electronic communications, kept for a period of five years and, where requested by the competent authority, for a period of up to seven years.¶

Records of customer due diligence and of transactions under Article 40 of [AMLD] are kept for five years after the end of the business relationship. The AMLD record-keeping regime is superseded, in respect of record retention, by Article 77 of [AMLR] from 10 July 2027, which preserves the five-year floor and adds a case-by-case extension up to a further five years where the competent authority so requires. Implementations operating across the AMLD-to-AMLR transition MUST satisfy whichever instrument is in force on the date of the Action.¶

Compliance Receipts MUST be retained for the period required by applicable Union or national law; where a sectoral floor applies, retention MUST equal or exceed the longest applicable floor. Absent a more specific rule, this profile RECOMMENDS 1827 days from the date of the Action (the worst-case rolling five-calendar-year window contains two leap days, so 1827 days satisfies "five years" regardless of the calendar years over which the window falls). Anchor evidence MUST be retained for the same period. Verification keys whose lifetime expires within the retention window MUST have their public components retained so that historical signatures remain verifiable.¶

9.1. Mandatory Checks

A Compliance Verifier MUST perform all of the following checks before treating a receipt as a Compliance Receipt.¶

• Verify the signature using the algorithm declared in signature.alg, in accordance with [ACTA-RECEIPTS].¶
• Resolve the verification key through one of the key-distribution mechanisms described in Section 4.3 of [ACTA-RECEIPTS] (well-known JWK Set or out-of-band distribution), or through Audit Pack trust-anchor metadata. The verifier MUST NOT trust a verification key embedded in the receipt envelope.¶
• Verify that all fields marked REQUIRED by Section 4 are present and well-formed.¶
• Verify the hash-chain linkage by recomputing the digest of the immediately preceding envelope and comparing it to previousReceiptHash.¶
• Verify at least one anchor: an [RFC3161] token, an [OPENTIMESTAMPS] commitment, or both. The anchor MUST cover the signed envelope as it appears in the receipt. The verifier MUST cryptographically re-verify the anchor against the signed envelope; presence of anchor metadata without a successful cryptographic check MUST NOT yield "valid".¶
• Verify the future-skew bound on issued_at per Section 4.1.2. Past skew MUST NOT cause non-conformance when the receipt is within retention.¶
• Verify that policy_digest resolves through Section 8. A digest computed over a nonced or otherwise mixed-input form (for example, SHA-256(nonce || JCS(artefact))) MUST NOT be treated as policy_digest; the digest scope is the canonical form of the artefact alone. The verifier MUST recompute SHA-256 over the canonical form of the resolved artefact as documented in the Audit Pack manifest, and compare; for JSON artefacts the canonical form is JCS per [RFC8785].¶

A receipt that fails any of these checks MUST be reported as non-conformant.¶

9.2. Optional Checks

A Compliance Verifier MAY additionally perform any of the following.¶

• Cross-check the issuer_id against an external registry of Deployers or Financial Entities.¶
• Resolve the policy artefact referenced by policy_digest and compare it to a Provider-supplied reference policy.¶
• Recompute the chain head and compare it to a Deployer-published value.¶
• Validate incident_class (each element if encoded as an array) and risk_class extension values against the vocabularies referenced in the Audit Pack.¶

9.3. Reporting

A Compliance Verifier SHOULD produce a structured report that identifies, for each receipt verified, which regime bindings (Article 12, Article 26, DORA Article 17) it satisfies. The report SHOULD itself be signed using the same algorithm registry as [ACTA-RECEIPTS].¶

10.1. Tamper Resistance

The hash-chain linkage required by Section 4.3 provides tamper-evidence at the chain level. An adversary who removes a receipt from the middle of the chain MUST recompute and re-sign every subsequent envelope. The anchor evidence required by Section 4.4 binds segments of the chain to wall-clock time, raising the cost of a re-signing attack.¶

Implementations SHOULD anchor at intervals no longer than 24 hours. Implementations operating under DORA Article 17 SHOULD anchor at intervals no longer than one hour.¶

A deployment that uses only the signature, without chain linkage and anchoring, can be rolled back by an insider with control of the signing key for the period between the deletion and the next anchor. The MUST clauses of Section 4.3 and Section 4.4 close that window.¶

10.2. Key Compromise

A Compliance Receipt is only as trustworthy as the key that signed it. On suspected compromise of an issuer key, the Deployer MUST publish a revocation notice that names the key, the time of suspected compromise, and the chain head at that time. Receipts signed by the compromised key after the named time MUST NOT be treated as Compliance Receipts.¶

Verifiers MUST consult revocation metadata supplied with the Audit Pack and MUST reject Compliance Receipts whose signing key was revoked at or before issued_at.¶

10.3. Retention and Long-Term Verifiability

The 1827-day retention floor in Section 7 exceeds the typical operational crypto-period of a signing key under recommended key-management practice. Implementations SHOULD use ML-DSA-65 from the [ACTA-RECEIPTS] algorithm registry ([FIPS204]) for receipts expected to be verified after the cryptographic lifetime of classical signature schemes ends. Implementations MUST retain public key material for the entire retention window.¶

10.4. Privacy

[ACTA-RECEIPTS] prohibits the inclusion of raw prompts, tool arguments, and credentials in the signed payload. This profile extends that prohibition to the extension fields defined in this document. The risk_class and incident_class values MUST be drawn from controlled vocabularies and MUST NOT carry free-text personal data.¶

Where the underlying Action references a data subject, the payload_digest field MUST cover the data; the data itself MUST be held in a separate store that respects the data subject's rights under applicable law. A request for erasure that is granted under applicable data protection law MUST be reflected by deletion of the referenced payload, not by deletion of the receipt; the receipt remains as evidence that an Action occurred and was governed by a named policy at a named time.¶

10.5. Anchor Trust

The trust assumptions of an anchor depend on the anchor type. [RFC3161] timestamp tokens depend on the trust placed in the named Time Stamping Authority. OpenTimestamps commitments depend on the inclusion of the commitment in a public Bitcoin block. A Compliance Verifier SHOULD treat the simultaneous presence of both anchor types as stronger evidence than the presence of only one.¶

10.6. Replay

A Compliance Receipt is bound to a single Action via action_ref. Replay of a Compliance Receipt against a different Action is detectable by action_ref mismatch. The 300-second issued_at skew bound stated in Section 4.1.2 limits the window in which a freshly-replayed receipt can be presented as recent.¶

Where the verifier supports it, two receipts sharing action_ref and issuer_id SHOULD be flagged as a candidate duplicate-emission event for human review. This profile does not require verifiers to maintain a cross-receipt index; deployers needing duplicate-emission detection should arrange it at the Audit Pack production layer.¶

10.7. Cross-Regime Conflict

Where the same Action is in scope of more than one regime addressed by this document, the producing system MUST satisfy the union of the applicable requirements. Where a SHOULD clause in one regime conflicts with a MUST clause in another, the MUST clause prevails. Where two MUST clauses conflict, the producing system MUST refuse to issue the receipt and MUST log the refusal as a protectmcp:lifecycle Compliance Receipt.¶

10.8. Algorithm Agility

This profile inherits its algorithm registry from [ACTA-RECEIPTS]. Implementations MUST treat the verification of a historical receipt according to the algorithm registry that was in force at issued_at, not the registry in force at the time of verification, provided that the signing key was not revoked.¶

11.1. Compliance Receipt Extension Fields Registry

IANA is requested to create a new registry titled "Compliance Receipt Extension Fields" under a new "Compliance Receipts" registry group.¶

This registry covers both signed-payload fields and envelope-level fields (siblings of payload and signature); each entry's Description identifies which.¶

Each entry contains:¶

• Field Name: a JSON object key, lowercase ASCII letters, digits, and underscore.¶
• Description: a one-line summary of the field's purpose.¶
• Reference: the document that defines the field's semantics.¶
• Vocabulary: a URL or registry pointer for the controlled vocabulary that field values are drawn from, or "free-form" if none.¶

The registration policy is Specification Required, per [RFC8126]. The Designated Expert(s) SHOULD verify that the field name does not collide with any field defined by [ACTA-RECEIPTS], that the Reference is a stable, dereferenceable specification, and that the Vocabulary is documented sufficiently for an independent verifier to validate values.¶

Initial registry contents:¶

• risk_class - Risk classification term under the Deployer's risk management documentation - This document - Vocabulary referenced in Audit Pack metadata.¶
• incident_class - ICT-related incident classification term, criteria per Article 18(1) of [DORA] with further specification in [REG-2024-1772], canonical six-value enumeration per Annex II field 3.23 of [REG-2025-302] - This document - Audit Pack metadata.¶
• anchors - Envelope-level array of timestamp / transparency-log anchors covering the signed envelope; entries carry a type discriminator (rfc3161 or opentimestamps) and a value field - This document - Anchor type vocabulary: rfc3161 per [RFC3161], opentimestamps per [OPENTIMESTAMPS].¶

11.2. Compliance Receipt Type Namespaces Registry

IANA is requested to create a new registry titled "Compliance Receipt Type Namespaces" under the same "Compliance Receipts" registry group.¶

Each entry contains:¶

• Namespace: a colon-separated identifier prefix used as a value of the type field, lowercase ASCII letters, digits, hyphen, underscore, and colon.¶
• Description: a one-line summary of the receipt category.¶
• Reference: the document that defines the namespace.¶

The registration policy is Specification Required, per [RFC8126]. The Designated Expert(s) SHOULD verify that the namespace does not collide with any namespace already registered or any namespace reserved by [ACTA-RECEIPTS], and that the Reference is a stable specification.¶

Initial registry contents:¶

• protectmcp:decision - A receipt recording a policy evaluation outcome (allow, deny, rate_limit) for an MCP-mediated tool call - This document.¶
• protectmcp:restraint - A receipt recording the application or release of a restraint on an agent (e.g., quota, rate limit, sandbox tightening) - This document.¶
• protectmcp:lifecycle - A receipt recording an agent or system lifecycle event (e.g., configuration change, key rotation, oversight review) - This document.¶

draft-marques-asqav-compliance-receipts-02

Wire-shape alignment with upstream [ACTA-RECEIPTS]: receipt content wrapped in a payload object with signature and anchors as top-level siblings per Section 2.1; payload_digest object form per Section 2.2; action_ref as bare hex per Section 2.2; tool_name REQUIRED for protectmcp:decision per Section 3.1.1; issuer_id equal to kid per Section 2.2; chain hash scope is the entire signed receipt per Section 5.7. EU AI Act bindings use Official Journal wording: Article 12(1) framed as a logging capability obligation; Article 12(2)(a), (b), (c) headings match the OJ; Article 26(6) "at least six months" expressed as 184 days (with 183-day pick permitted as conformant). Article 19(1) provider parallel noted in scope. DORA Article 17 bindings: 17(2) recording obligation supported by hash chain; 17(3)(b) classification criteria sourced to Article 18(1) of [DORA] with further specification in [REG-2024-1772]; incident_class canonical six-value enumeration sourced to Annex II field 3.23 of [REG-2025-302]. Sectoral retention: Article 16(7) of [MIFID2] (five-year floor on telephone and electronic communications records); Article 16(6) supplemented by Article 72 of [REG-2017-565] (form and content of general records); Article 40 of [AMLD] superseded by Article 77 of [AMLR] from 10 July 2027. Anchoring: anchor MUST (at least one of an RFC 3161 token or an OpenTimestamps commitment); both RECOMMENDED; the 7-day deadline for OpenTimestamps upgrade is profile-imposed. LEI placeholder rules require an unallocated GLEIF LOU prefix at positions 1-4, the ISO 17442 reserved value 00 at positions 5-6, and ISO 7064 mod 97-10 check digits at positions 19-20. Algorithm references added: [RFC8032] (EdDSA), [RFC7518] (ES256), [FIPS204] (ML-DSA-65). Added [RFC5816] (ESSCertIDv2) as a normative reference; Compliance Verifiers MUST accept ESSCertIDv2-carrying time-stamp tokens. Reference block uses Official Journal verbatim titles (including "(recast)" for [MIFID2] and "(Text with EEA relevance)" where the OJ carries it) and OJ publication dates throughout. Definition of "Financial Entity" cites Article 2(2) of [DORA], the paragraph that establishes the collective term, with cross-reference to Article 2(1) for the entity list. Article 12(2)(a)/(b)/(c) headings now use the OJ participle form. [ISO17442] and [W3C-DID] moved to Normative References, since the issuer-id rule invokes them through SHOULD/MAY clauses governing wire-level identifier shape. IANA Extension Fields registry now includes anchors with the rfc3161 / opentimestamps anchor-type vocabulary. DORA-bound retention default is 1827 days (worst-case five-calendar-year window with two leap days), aligning the methodology with the 184-day six-month figure used in Section 5.5. Section 4.1.7 describes upstream session_id as an MCP session identifier (not transport-layer), matching [ACTA-RECEIPTS] Section 3.1.1. Section 4.2 names the decision field explicitly. Section 7.4 notes that AMLD supersession by Article 77 of [AMLR] is in respect of record retention. Section 4.1.4 states that payload_digest follows the upstream object form (hash, size, optional preview) defined in Section 2.2 of [ACTA-RECEIPTS]. Section 9.1 policy_digest recomputation rule generalised: SHA-256 over the canonical form of the resolved artefact as documented in the Audit Pack manifest, with JCS specified for JSON artefacts. Section 9.2 optional check on incident_class validates each element when the field is encoded as an array. DORA Article 17(3)(b) section heading expanded to include "establish procedures to" per the OJ wording. EU AI Act Article 26(2) prose no longer cites Article 14 (the competence/training/authority phrase comes from Article 26(2) directly). Worked example notes that the receipt shown is mid-chain. "Decentralized" spelling aligned with the W3C reference title. Anchor concept defined inline in Section 4.4 rather than as a Conventions term, removing capitalisation drift. Section 9.1 verification step on the verification key now references Section 4.3 of [ACTA-RECEIPTS] directly (well-known JWK Set or out-of-band) rather than the looser "trust anchor mechanisms required by upstream" wording. Section 4.1.3 names the upstream kid mechanisms (well-known JWK Set or sb:issuer:<base58-fingerprint>) being superseded for Compliance Receipts. Section 6.2 Article 26(2) prose includes "necessary support" alongside competence, training, and authority, matching OJ wording. Section 4.5 anchoring rule names the bytes committed (SHA-256 of the JCS-canonicalized envelope excluding the anchors array). Section 6.4 cross-refs the longer DORA sectoral floor when the Deployer is a Financial Entity. Section 4.1.3 LEI placeholder rule references the ISO 17442-1:2020 Annex A letter-to-digit conversion that precedes mod 97-10. Upstream draft author full name corrected to "Tom Farley".¶

draft-marques-asqav-compliance-receipts-01

Initial wire-shape alignment with upstream and addition of dual-anchor, hash-chain, retention, and DORA classification bindings. Subsequent revisions superseded the specific values introduced here.¶

draft-marques-asqav-compliance-receipts-00

Initial version. Defines a profile of [ACTA-RECEIPTS] that binds receipt fields to EU AI Act Article 12, EU AI Act Article 26, and DORA Article 17.¶