Asqav

Portugal info@asqav.com

General AI Agents Audit Trail Compliance EU AI Act DORA NIST AI RMF Colorado Automated Decision-Making Technology Act HIPAA NYDFS CIRCIA This document defines a profile for signed action receipts and independently checkable evidence about agent activity. It specifies versioned payload and signature semantics, hash-chain linkage, timestamp and witness policy, receipt verification and bounded regulatory-evidence mappings. It draws on ACTA-RECEIPTS but states its profile-specific overrides explicitly. A receipt supports checks about recorded bytes, identity, linkage and retained evidence; it does not by itself establish that an action occurred, that all actions were captured, or that an organization complies with a law. The profile supports retained historical receipts through explicit version and legacy rules rather than rewriting their committed bytes. Its intended core and implementation limitations are described in the body. Note to the Independent Submissions Editor This document requests no new IANA registry. The two tables in are administered outside IANA. Section 4 of generally precludes new IANA registries on the Independent Submission Stream, with a limited exception for a subcode registry tied to an allocation from an existing registry. This document does not invoke that exception. Section 5 excludes Specification Required and Expert Review policies for new subregistries created through that stream. The requested CWT claim allocation remains subject to the existing registry policy and expert review under Section 2. Any future proposal to move the external tables to IANA would require the applicable procedures and approvals; IETF Stream progression would not itself transfer them. Editor's Note: Target DesignThis local edition describes the completed target design selected for the core milestone. The specification uses present-tense requirements on that basis. It does not report current implementation completion, test results, customer deployment or publication approval. Those facts are maintained in a separate release evidence record. Remove this note only when the release evidence supports the publication being submitted.

Introduction

Profile and Explicit OverridesThis specification draws on the receipt model in . Its conformance requirements are defined here and in its normative references. ACTA records design history; its requirements are not incorporated by reference. Implementers use , and . Shared names do not establish wire compatibility.

Scope This document fills the regulatory binding gap on two surfaces. Section 6 binds the receipt to European Union obligations: Article 12 (record-keeping), Article 26 (deployer obligations) and Article 50 (transparency) of the EU AI Act, and Article 17 (ICT-related incident management) of DORA. Section 7 binds the receipt to United States obligations: the voluntary functions of the NIST AI Risk Management Framework, the deployer obligations of Colorado's Automated Decision-Making Technology law (SB 26-189) and the Texas Responsible AI Governance Act, the audit-trail and incident-reporting obligations of NYDFS Part 500, the audit controls and documentation retention of the HIPAA Security Rule, the broker-dealer recordkeeping requirements of SEC Rule 17a-4, and a provisional CIRCIA incident-evidence mapping. The bindings are written from the Deployer's perspective, where Deployer is used in the regime-specific sense (Article 3(4) of for EU bindings; Section 6-1-1701(7) of the Colorado Revised Statutes for Colorado bindings). Where another statute uses a different term (Provider, Financial Entity, Covered Entity or Business Associate for HIPAA, Covered Entity for NYDFS, Broker-Dealer for SEC, Covered Entity for CIRCIA), the binding section names the term as the source statute uses it. An upstream-only verifier can validate only the algorithms, framing and digest scopes it actually implements. Profile conformance and regulatory-evidence mapping require the checks of this document; cryptographic validity alone does not establish either. The required core consists of the receipt envelope, supported algorithms, chain and key semantics, selected witness policy, evidence export and verifier reporting. Type-specific extensions impose their rules when that type or extension is selected; they do not require every issuer to implement every listed product integration. Unsupported required extensions are reported as unverifiable. A release conformance statement lists the supported types and policies.

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. The following terms are used in this document.

Action:

An operation performed by an AI agent that is subject to a policy evaluation. Examples include a tool invocation, an external API call, a write to durable storage, and the issuance of an irreversible instruction to another system.

Action Receipt:

A signed record of an agent-related action or decision. The term does not imply conformance to an external receipt specification.

Compliance Receipt:

A receipt satisfying the envelope, common fields, selected type and verification requirements defined in this document.

Deployer (EU AI Act):

As defined in Article 3(4) of .

Deployer (Colorado ADMT Act):

As defined in Section 6-1-1701(7) of the Colorado Revised Statutes, as enacted by .

Developer (Colorado ADMT Act):

As defined in Section 6-1-1701(8) of .

Covered ADMT:

As defined in Section 6-1-1701(5) of ; "automated decision-making technology" is defined at Section 6-1-1701(2).

Consequential Decision (Colorado ADMT Act):

As defined in Section 6-1-1701(3) of .

Adverse Outcome (Colorado ADMT Act):

As defined in Section 6-1-1701(1) of .

Materially Influence (Colorado ADMT Act):

As defined in Section 6-1-1701(13) of .

Meaningful Human Review (Colorado ADMT Act):

As defined in Section 6-1-1701(15) of .

High-Risk AI System (EU AI Act):

As defined in Article 6 of .

Financial Entity:

The entities listed in Article 2(1), points (a) to (t), that Article 2(2) of collectively calls financial entities, subject to the applicable exclusions and scope provisions.

Covered Entity (HIPAA):

As defined in 45 CFR 160.103, namely a health plan, a health care clearinghouse, or a health care provider that transmits health information in electronic form in connection with a covered transaction.

Covered Entity (NYDFS):

As defined in 23 NYCRR 500.1(e), namely any person operating under or required to operate under a license, registration, charter, certificate, permit, accreditation or similar authorization under the Banking Law, the Insurance Law or the Financial Services Law, regardless of whether the covered entity is also regulated by other government agencies.

Broker-Dealer:

As defined in section 3(a)(4) and 3(a)(5) of the Securities Exchange Act of 1934, subject to recordkeeping under .

Covered Entity (CIRCIA):

A covered entity within the statutory framework of 6 U.S.C. 681 and the operative implementing rule. This draft's provisional mapping does not use proposed scope criteria to establish a present reporting duty; see .

Audit Pack:

A bundle of Compliance Receipts, the chain commitments that link them, the public verification keys, the trust anchor metadata, and the regime mapping required by the EU and US evidence mappings of this document, packaged for delivery to a regulator or auditor.

Counterparty:

The entity on the receiving side of an Action performed by another party's agent: the participant whose rights, systems, or funds the Action touches, and for whom the Compliance Receipt covering that Action is evidence. The Counterparty occupies the demand side of the receipt: it consumes verification verdicts; it does not emit receipts.

Acceptor:

The role a Counterparty occupies when it conditions acceptance of an incoming Action, or of the Action's output, on the verdict of a Compliance Verifier. An Acceptor gates the incoming Action on verification and treats an unverified receipt as non-acceptable input; the gating policy itself is outside the scope of this profile.

A normative reference supplies rules needed to implement the core or a selected extension or regulatory-evidence mapping. Sources used only by a selected mapping apply to that mapping; their classification does not make the mapping mandatory for every deployment or establish legal compliance. Provisional mappings remain provisional. Explanatory sources and design antecedents are informative. Reference categories describe technical dependency, not institutional prestige.

Relationship to ACTA-RECEIPTS This document derives from but does not claim byte-level compatibility with every upstream verifier. For Compliance Receipts, the versioned shape in , the signature scope in , and the anchor and counterparty scopes in and govern. Implementations MUST NOT infer a digest scope or signature encoding merely from the ACTA family name. The core envelope contains payload and signature; anchors MAY be omitted or an empty array under . Profile members belong inside the signed payload. Flat legacy transport representations are handled under an explicitly selected legacy format and MUST NOT silently change the bytes supplied to signature or chain verification. The supported signature algorithms and their key representations are defined in and . ML-DSA-65 uses . New profile issuance uses unpadded base64url for signature.sig; retained legacy signature strings MUST remain byte-for-byte unchanged. A verifier accepting a legacy encoding MUST report the applicable legacy policy. Re-encoding the same signature bytes can change an anchor or counterparty commitment and MUST NOT be used to repair retained history. Where this profile tightens an upstream optional field, its type-bound presence rule applies. Unknown signed members remain covered by the signature and are handled by . A failed mandatory profile check does not imply that the underlying signature is invalid, nor does verification under an older revision establish conformance to this revision. ACTA-RECEIPTS is an informative antecedent. No conformance requirement depends on its publication or on later changes to that draft. The local field, algorithm, signing-input, trust and type rules are authoritative. Shared field or namespace spellings do not import additional ACTA requirements. Supporting a bare ACTA receipt is a separate format choice and is not required for this profile.

Canonicalization Scope This section is normative. The canonicalization rule itself (JCS, ) is specified directly by ; this section bounds the inputs the rule is applied to, so that the cross-implementation byte equality on which the hash chain of , the anchor scope of , and the cross-agent binding of all depend is achievable in practice. This profile restricts digest-covered JSON numbers to exact integers in the closed interval [-(2^53-1), 2^53-1]. This is an Asqav input-domain restriction, not a requirement of , which also defines fractional-number serialization. Callers MUST represent other exact values as strings or explicitly defined integer-rational pairs. Verifiers MUST apply this profile restriction at the raw-input parse boundary, before a general-purpose parser can lose precision, and report an unsupported or malformed numeric input as unverifiable. An already parsed object cannot demonstrate that the original bytes passed this check. Historical formats with a different numeric domain MUST be evaluated under their documented legacy policy. A duplicated member name inside any digest-covered object is a terminal parse failure. An implementation MUST raise it before any hashing, canonicalization or signature check runs, at any nesting depth, and MUST report the receipt unverifiable rather than invalid, because nothing about the receipt was proven false: it could not be read. Last-wins ingest, in which a parser silently keeps the final occurrence, is never conformant here. The rule exists because the two occurrences give two different documents to two readers that both believe they parsed the same bytes, so a signature verified over one of them says nothing about what the other acted on; deferring the check until after canonicalization does not help, since canonicalization has by then already chosen one of the two. Object member names MUST be ordered by UTF-16 code unit, as Section 3.2.3 of requires. A verifier MUST NOT order member names by Unicode code point, and MUST NOT order them by UTF-8 byte sequence. The three orders agree across the whole Basic Multilingual Plane and can diverge when supplementary-plane and high-BMP characters are compared. An implementation that sorts by code point therefore emits a different canonical byte sequence, and so a different digest, for the same receipt. Rationale: this is a live interoperability hazard rather than a theoretical one, because the natural implementation in several languages is the incorrect one. Python sorted and json.dumps(sort_keys=True) order by code point, and Rust and Go string comparison orders by UTF-8 byte sequence, which for this purpose is the same order; ECMAScript string comparison orders by UTF-16 code unit and is already correct. A conformance corpus whose member names are all drawn from the Basic Multilingual Plane cannot distinguish the two, so implementations can agree on every published vector and still disagree on a receipt whose caller-supplied object carries an emoji or supplementary-plane key. Implementers SHOULD test against a vector that carries such a key; carries one in its canonicalization corpus (conformance/vectors.json) as asqav-24-jcs-astral-key-order, together with a negative case presenting the code-point ordering that a conformant implementation MUST NOT produce. Conformant JCS implementations serialize the same supported input consistently. Ordinary JSON serializers are not necessarily JCS implementations. The narrower domain above reduces implementation burden; it does not justify asserting that two conformant JCS implementations disagree. Tool-version-specific semantic equivalence is OUT OF SCOPE for the chain layer of this profile. The chain layer checks commitments to canonical bytes under its cryptographic assumptions. Examples of semantic equivalence that this profile does not assert and does not require a verifier to assert: SQL keyword case folding (SELECT vs select), filesystem path normalization (trailing slash, redundant separators, symlink resolution), Unicode normalization in any form (NFC, NFD, NFKC, NFKD); Section 3.1 of requires that all components depending on JCS preserve Unicode string data as-is, and Section 3.2.2.2 of serializes each code point without normalization, so callers MUST NOT rely on a verifier normalizing strings before comparison, locale-aware string collation (Turkish dotted-i, German sharp-s case folding, ICU collation tables), application-specific approximate numeric comparisons, or URL percent-encoding choices below the RFC 3986 unreserved set. Higher-level semantic equivalence is a per-tool concern and, where required by a regulator, MUST be expressed in the policy artifact resolved through policy_digest () rather than in the chain. The chain layer establishes relationships among recorded canonical payloads. It does not establish that the underlying action occurred at the issuer's declared time. Timestamp evidence supplies only the time properties supported by the authenticated construction and trust policy; those properties are reported separately from chain integrity. The core envelope has two required members, payload and signature, and the optional anchors member. Signed content lives inside payload. The signature input is the receipt's canonical payload; a chain link commits the predecessor's canonical payload. Anchor and counterparty commitments cover the core envelope with the anchors key removed, retaining the exact signature string. Legacy transports are separately identified and never silently normalized into this framing before verification.

Receipt Field Profile This section defines the fields and explicit upstream overrides used by this profile. The requirements below, including the version and legacy rules, govern profile verification.The core JSON envelope has REQUIRED payload and signature members. The signature object contains alg, kid and sig. New profile issuance encodes sig as unpadded base64url under . Historical encodings are accepted only under an explicit legacy policy and retain their exact committed strings. An OPTIONAL anchors array holds the proof objects defined in . A storage projection MUST preserve the signed and committed bytes; it MUST NOT repair historical receipts by renaming, re-encoding or reconstructing authenticated content.

Signature Object and Algorithm ContractThe core JSON signature is an object with three REQUIRED string members: alg, kid and sig. kid is a nonempty key-selection hint, subject to independent issuer authorization under . New issuance under this revision MUST use alg="ML-DSA-65"; a conforming verifier MUST implement that algorithm. The public key is an AKP JWK with kty="AKP", alg="ML-DSA-65" and unpadded-base64url pub under . The public key is 1952 octets and the signature is 3309 octets under .The algorithm choice above carries an interoperability cost that implementers need stated plainly. A verifier that implements only the mandatory-to-implement signature baseline of , which is Ed25519 under , will not validate ML-DSA-65 receipts issued under this revision. That upstream draft lists ML-DSA-65 as RECOMMENDED rather than mandatory; what this profile adds is the algorithm string and AKP JWK form, the binding, and the selection of ML-DSA-65 for the reference platform.The JSON signing input is the UTF-8 JCS serialization of the complete payload object. Use pure ML-DSA with an empty context string, not HashML-DSA and not an extra SHA-256 prehash. sig is the resulting signature encoded as unpadded base64url under . COSE and JWS use their own protected framing and signing-input rules under , and ; a JSON signature MUST NOT be reused as a framed signature without the required signing operation.A separately selected historical format MAY accept Ed25519 under or another explicitly documented historical algorithm. That policy MUST specify the identifier, key representation, original signing input and original signature encoding; acceptance is reported as historical verification, not new-revision conformance. Unknown or unsupported algorithms are unverifiable. A verifier MUST NOT select an algorithm from signature length, kid spelling or successful trial verification, and MUST NOT downgrade after a failed check. Unsigned algorithm metadata is interpreted only within the independently authorized key/algorithm policy.Unsupported ML-DSA-65 is reported as an unverifiable signature axis; antecedent-format support alone cannot satisfy this requirement.

Common Payload Fields

v (No Upstream Equivalent) REQUIRED. v is a wire-version integer identifying the receipt shape a verifier should read; its value under this document is 1. It is the first member a verifier reads, because it fixes the shape under which every other member is interpreted. An issuer conforming to this document MUST emit v on every Compliance Receipt. It is server-built in the sense of : a caller-supplied value MUST be dropped before signing. The version member is inside the signed payload in the core envelope, for both payload and hash modes. It MUST be authenticated before its claims are trusted. A flat legacy API response is a distinct transport representation; a verifier MAY support it through an explicit, documented adapter preserving its original signed bytes. The presence of a null payload is not authority to guess the signature scope. A verifier MUST report an unsupported version as unverifiable and MUST NOT guess its shape. The reference source inspected for this reconciliation emits v=1 with the payload_digest shape defined in . The corpus's version-2 signer canary does not by itself establish a released version-2 production contract. A new emitted version requires a complete shape definition and migration evidence before release. Absence is a distinct case from an unrecognised value, and it is the case an implementer meets first, because every receipt issued under a revision preceding this one carries no v. A receipt carrying no v member is not a Compliance Receipt of this document. It is either a receipt of another format, the absence being what distinguishes the two wire formats under the interoperability note of , or a receipt issued under an earlier revision of this profile. A verifier MAY process such a receipt under the rules of that earlier revision, and MUST NOT report it as verified under this document. A verifier MUST NOT infer version 1 from absence: inferring it would erase the only signal separating this profile's receipts from a bare upstream receipt.

mode (No Upstream Equivalent) REQUIRED. mode records how the Action was captured: payload or hash. It does not select the enclosing wire shape. In a Compliance Receipt it appears inside the signed payload object, which can carry either value. A verifier claiming conformance to this profile MUST determine the expected member set from the mode and the enclosing wire shape before applying the checks of . A successful signature check alone does not establish that conformance. payload means the issuing platform computes the Action-context digest. The signed payload carries action_type, timestamp, and payload_digest, in addition to the common profile members. The context member is OPTIONAL: the platform may receive a context without carrying it in the receipt. In the reference signing path, payload_digest.hash is SHA-256 over the canonical caller-supplied context, or over the empty object {} when no context was supplied. Omission of context from the receipt does not mean that the caller supplied an empty object. A verifier cannot recompute the digest from that receipt alone when context is absent or JSON null, and that absence is not a failure of the recomputation check. When a non-null context is carried, it MUST reproduce the committed digest under and MUST observe the content restrictions of . hash means the caller supplied a fingerprint instead of the Action context. A Compliance Receipt with this mode carries hash, hash_algo, and server_timestamp inside its signed payload, alongside the common profile members, including v, mode, action_id, agent_id, org_id, policy_digest, decision, and payload_digest. Its metadata member is optional. The reference platform emits neither context nor action_type on this path. The hash member carries the caller's self-describing fingerprint; payload_digest.hash carries its unprefixed digest value. Without a carried context the recomputation check does not apply. The mode does not exempt a Compliance Receipt carrying a non-null context from the consistency check in . For interoperability, the reference SDK also accepts flat hash signature receipts whose payload is JSON null. Their signed input is an eleven-member object: v, mode, hash, hash_algo, metadata, server_timestamp, action_id, agent_id, org_id, policy_digest, and policy_decision. The SDK's flat-path structure check rejects an absent or null value for every member except policy_digest; that member may be absent or null and is reconstructed as null in the signing input. This compatibility rule applies to the flat signing input. It does not require policy_decision on the nested Compliance Receipt, which uses decision, or make metadata mandatory there. Acceptance of a flat signature receipt does not establish this profile's chain and anchor requirements. Implementation note: the reference Python SDK's verify_receipt_offline() entry point uses the native oracle adapter, which enforces the member set on its flat hash path. For a nested payload, that adapter delegates to the common structure check without deriving a mode-specific set. The standalone verify_receipt.py artifact performs no mode-dependent member-set validation. Neither implementation's successful result establishes conformance to the full member-set requirement above; that requirement binds any verifier claiming conformance to this profile. action_type and tool_name are JSON strings naming the operation and tool respectively, with the presence conditions stated for the selected mode and receipt type. Payload-mode timestamp is an RFC 3339 string with an explicit timezone recording the issuer's signing-time assertion. It is distinct from the original Action descriptor timestamp in . In version-1 payload mode, absent hash_algo means sha256; hash mode requires the member. An explicitly supplied unsupported value is not absence and MUST NOT trigger that default.

type Compliance Receipts MUST set type to a value registered in the Compliance Receipt Type Namespaces Registry of , or to an extension namespace registered for use with this profile. That registry, not this paragraph, is the authoritative vocabulary: it carries protectmcp:decision, protectmcp:restraint and protectmcp:lifecycle together with protectmcp:acknowledgment, protectmcp:observation and their sub-namespaces, so a verifier that treats the first three as the whole set rejects receipts this profile defines. A selected type uses the common fields of , the mode-bound fields of , the decision/policy rules of and its explicitly named extension rules in . No additional field is required solely because the type spelling also appears in ACTA. In particular, that spelling does not implicitly add a manifest version or lifecycle event discriminator. A separately selected extension that requires such a field must define it explicitly. The protectmcp namespace and every sub-namespace under it are reserved to this document and are not available for third-party registration. A verifier that cannot resolve a receipt's type against the registry of MUST therefore distinguish two cases, because they are not the same finding and collapsing them hides both. A verifier resolves a type against the initial entries defined by the selected revision of this profile and the additions authorized by the selected registry edition. A protectmcp: value absent from that applicable vocabulary is a non-conformance of the receipt: report unverified with failure_class invalid under . Absence from an older or incomplete local registry copy alone does not establish that mismatch. If the verifier lacks the applicable vocabulary, report the type-resolution axis as unverifiable and derive the unverified summary and failure_class under , identifying the missing profile or registry revision. This distinction preserves the normative initial entries in and does not authorize third-party use of a reserved name. An unknown value outside the protectmcp namespace is the opposite case: it MUST be reported as an unregistered namespace and MUST NOT be treated as a failure, because a registry that has not yet caught up with a legitimate third-party extension must not turn that party's valid receipts into invalid ones. Such a receipt terminates in unverified with failure_class unverifiable. A registered value that this verifier has not implemented is also unverifiable, and a report SHOULD name it as a gap in the verifier rather than a defect of the receipt. In none of these cases may the verifier return verified or verified_keyed, and in none of them is the finding a signature or binding failure: the cryptography of such a receipt may be entirely sound. A verifier MUST report the selected profile revision and the registry edition it resolved against, or state that the required edition was unavailable. This identifies the vocabulary used for the result without implying that an older local copy establishes the contents of a newer edition.

issued_at REQUIRED in this profile. The value MUST be an RFC 3339 timestamp with an explicit UTC offset. The producing system MUST source the value from a clock synchronized to a recognized time authority and MUST NOT backdate it. Verifiers MUST reject receipts whose issued_at is more than 300 seconds ahead of the verifier's own clock under this profile's future-time rule. A receipt's age alone does not establish cryptographic invalidity. Historical verification applies the selected issuance revision, relevant key authorization and revocation evidence, and documented appraisal-time policy; it does not guarantee a passing result. A retention obligation is neither a maximum cryptographic age nor proof that retained evidence is sufficient. Action freshness and retention are evaluated separately.

issuer_id issuer_id is REQUIRED and identifies the issuing principal in the selected profile. It is an opaque, stable identifier. The trust policy binds that principal to its authorized signing keys, responsible organization and role. A principal identifier is not itself proof of a legal entity's identity. Implementations MUST NOT infer authority from the identifier's spelling, length or apparent namespace.signature.kid identifies candidate key material; it is distinct from the issuer's identity. This profile does not require the two strings to be equal for new issuance. Historical receipts that used equality remain interpretable under their issuance policy. The verifier MUST authenticate the key-to-issuer relationship independently, check the permitted algorithm and key purpose, and use a signed key_thumbprint when present to constrain key selection. The JSON signature object's metadata is outside the signed payload; a kid alone is not an authenticated authority claim.A trusted export or an independently authenticated directory can supply historical keys. Conflicting authoritative records or unresolved ambiguity make key authorization unverifiable; the verifier MUST NOT prefer a caller-supplied key merely because it appears in an Audit Pack. Multiple rotated keys under an issuer are permitted when key selection and historical authorization are unambiguous. Current directory contents alone are not proof of past authorization.An organization MAY publish an LEI under or a DID under in its identity metadata. This profile does not require a person or an organization to disclose a tax identifier in each receipt. The example's synthetic identifier is illustrative and must not be used as a production trust anchor. Existing identifiers and signed history MUST NOT be rewritten to match a later naming convention.A kid is an unauthenticated lookup hint and may match multiple keys. Implementations MUST NOT assume it is globally unique or equal to issuer_id; ambiguity is resolved only through the authorized key set, algorithm, signed thumbprint when present and issuance policy.

payload_digest (OPTIONAL upstream, REQUIRED in this profile) payload_digest is a REQUIRED JSON object containing REQUIRED hash and size members and an OPTIONAL preview. hash is exactly 64 lowercase hexadecimal characters, without a sha256: prefix. size is a nonnegative integer within the numeric domain of ; it counts the exact input octets covered by the digest. It is not the encoded digest length. A producer MUST NOT invent zero as a substitute for an unknown input length. A hash-mode caller must supply the original length if a conforming descriptor is to be issued.The input and algorithm follow and : in payload mode, hash the canonical context. In hash mode, use the input defined by the caller's identified fingerprinting contract, which may include a wrapper; size counts that input's bytes. Use the defined keyed construction when hash_algo selects it. When a non-null context is carried, the additional consistency check of applies. preview, when present, is a JSON string of at most 256 Unicode scalar values, subject to . It is optional display material, never an input from which the full digest may be inferred. Its presence cannot replace retained required evidence. Missing required input makes recomputation unverifiable; a demonstrated digest or length mismatch is invalid. Historical descriptors retain their actual version and committed bytes.

action_ref (OPTIONAL upstream, REQUIRED in this profile) action_ref is REQUIRED and is the JSON string sha256: followed by 64 lowercase hexadecimal characters. It commits an Action descriptor A containing exactly four members: agentId, actionType, scopeRequired and timestamp. The first two are strings identifying the actor and operation in the selected action vocabulary; timestamp is the original action timestamp as an RFC 3339 string. scopeRequired is an array of strings identifying the required scopes. Before canonicalization, sort that array by UTF-16 code-unit order; preserve repeated values and string contents without normalization. No other members belong in A.Compute action_ref = "sha256:" || lowercase_hex(SHA-256(UTF8(JCS(A)))), with JCS and the input restrictions of . Retain A in the authorized evidence-resolution material, with its vocabulary and construction revision. Parties correlating the same Action MUST use the same original descriptor; a verifier MUST NOT substitute a later receipt timestamp or infer scopeRequired from a policy name. Missing descriptor evidence makes this recomputation unverifiable. It does not authorize guessing an empty array. An opaque action ID, payload_digest.hash and action_ref have different constructions and MUST NOT be substituted for one another.This makes the inherited four-member construction explicit. The typing and ordering rules above resolve previously underspecified cases for new issuance. A historical action reference is evaluated under its documented original construction; its committed value MUST NOT be rewritten. The digest binds the descriptor, not a peer receipt envelope, execution outcome or delivery acknowledgment.

sandbox_state (OPTIONAL upstream, REQUIRED for High-Risk in this profile) REQUIRED for receipts produced by High-Risk AI Systems under . sandbox_state is a JSON string describing observed OS-level containment, with exactly three permitted values: enabled, disabled or unavailable. The declaration does not by itself prove containment. A Deployer that operates a High-Risk AI System and produces a stream of receipts in which sandbox_state is consistently disabled SHOULD treat that stream as a finding under the applicable risk-management documentation requirement (Article 9 of for the Provider's risk management system, with which a Deployer operating per Article 26(1) is required to be consistent) and document the rationale in the Audit Pack metadata.

iteration_id (OPTIONAL upstream, REQUIRED for multi-step in this profile) iteration_id is REQUIRED for multi-step agent workflows and is a stable JSON string identifying the logical task across its receipts. An OPTIONAL session_id is an opaque JSON string used for transport-session correlation. They have different scopes; neither is an authenticated identity credential. A Compliance Receipt MAY carry both.

key_thumbprint (No Upstream Equivalent) No upstream equivalent. OPTIONAL for receipts emitted in compatibility with prior revisions of this profile (earlier receipts are evaluated under their selected revision; absence alone is allowed only where that revision permits it); implementations conformant to this revision SHOULD emit the field on every new receipt, and the issuing platform MUST compute it when it does. The value is a JSON string of the form sha256:<64 lowercase hex chars> carrying the JWK Thumbprint of the receipt's signing key, computed per Section 3 of : SHA-256 over the canonical JSON serialization of the JWK containing only the required members of the key's kty, with members in lexicographic order and no whitespace. For an ML-DSA key the kty is AKP and its required members are kty, alg and pub, per , whose lexicographic order is alg, kty, pub; so the thumbprint input for an ML-DSA-65 key is exactly {"alg":"ML-DSA-65","kty":"AKP","pub":"..."}.The pub member is base64url WITHOUT padding. That encoding is relevant rather than cosmetic: the same key bytes rendered in the standard base64 alphabet produce a different digest, which no third-party verifier reproduces. The JWK input form is the one in which the issuing platform publishes the verification key under or the Audit Pack trust-anchor metadata, so a verifier recomputes the thumbprint from the resolved key with no additional distribution. The field is server-built: it is populated by the issuing platform at signing time from its own signing key, never carried in the producer's signing request, and a caller-supplied value MUST be dropped before signing. The field is covered by the signature scope of . The signed thumbprint binds the receipt to exact public-key material. A mismatch is an invalid key-binding check. A matching thumbprint does not independently authenticate the issuer: an attacker can create a different key and sign a different receipt containing its thumbprint. The verifier still establishes issuer authorization under . Absence is evaluated under the selected revision and legacy policy, and is reported as an unchecked key-binding axis where allowed.

Sequence Counter seq is an OPTIONAL positive integer within the profile's safe-integer range. It starts at 1 at genesis and increases by one for each receipt in the same chain. The chain scope follows : the core profile defines one linear chain per issuing principal, not two independent counters under that principal. The producer assigns the counter and predecessor in the same serialized emission operation and ignores a caller-supplied counter.A verifier compares counters only within the identified chain and format contract. A present non-integer, boolean or non-positive value is malformed. A repeated, decreasing or unexpectedly skipped value fails sequence continuity; it establishes an inconsistency, not whether its cause was withholding, a producer defect or missing input. Missing legacy counters leave continuity unchecked. Unsupported cross-format continuity is unverifiable unless an explicit migration contract supplies it.A sequence gap can expose missing entries within the observed series. A valid prefix cannot expose an omitted tail without a trusted later checkpoint, expected coverage interval or independently retained later receipt. No counter proves that actions without receipts were captured. The report states the observed interval and available checkpoint evidence.

Decision Receipt Fields (type protectmcp:decision) A protectmcp:decision receipt records a policy evaluation and uses decision allow, deny or rate_limit. It carries the policy digest and the tool identifier required by this type. The observation value is not valid for this type.When no policy was evaluated, the producer either declines to issue a receipt or uses a defined lifecycle or observation type with decision observation and the no-policy rule in . An internal policy_decision value of none maps to that observation state only at the documented emission boundary. Export of a retained receipt preserves its existing signed values. Each lifecycle subtype's own presence and decision rules apply.tool_name is REQUIRED for protectmcp:decision. A signed decision is evidence of the producer's recorded evaluation, not independent proof that the policy was appropriate or correctly executed.

reason (OPTIONAL upstream, REQUIRED for deny/rate_limit in this profile) REQUIRED for Compliance Receipts where decision is deny or rate_limit. The value MUST be a machine-readable reason code drawn from a vocabulary documented in the Deployer's Audit Pack metadata.

policy_digest policy_digest is REQUIRED. When a policy was evaluated, its value is sha256:<64 lowercase hex chars>, committing the retained policy artifact under its defined canonical-byte rule. The verifier recomputes that digest where required by the selected evidence policy. Unavailable required content is unverifiable; a demonstrated mismatch is invalid.The defined no-policy lifecycle and observation paths carry JSON null and decision observation. Null does not assert that a policy passed. Historical receipts with a documented no-policy sentinel digest retain that issuance-version interpretation and the referenced sentinel artifact; implementations MUST NOT rewrite those signed values. Null is not permitted for a decision that claims policy evaluation.

Hash-Chain Linkage (OPTIONAL upstream, REQUIRED in this profile) Each Compliance Receipt MUST contain previousReceiptHash in its signed payload. At genesis the value is 64 zero characters. Otherwise it is the 64-character lowercase hexadecimal encoding of SHA-256(JCS(R)), where R is the complete signed payload of the immediately preceding receipt emitted under the same issuer_id. The literal member name is case-sensitive; aliases are not accepted. The digest excludes the predecessor's signature object and anchors.The JSON receipt signature separately authenticates its own payload under . COSE and JWS carry that payload using their respective protected signing constructions. A chain verifier MUST recompute the predecessor-payload digest, verify each applicable receipt signature and report the two checks separately. A link cannot replace verification of the predecessor's signature.Informative comparison: the cited revision of specifies a chain over the complete signed receipt, including its signature. This profile instead links the predecessor's signed content. Where a peer's signature value must also be committed, defines the separate envelope commitment. This comparison imports no additional ACTA requirements.New streams under this revision use the local construction above. Previously signed or anchored history MUST NOT be rewritten to change its scope. A verifier that supports a different historical format selects its actual documented construction explicitly and reports that format; it MUST NOT silently substitute another digest scope.Each issuer MUST maintain a single linear per-agent chain. When one agent identity emits receipts from multiple concurrent execution paths (for example parallel tool calls dispatched within a single agent loop, or fan-out work performed by a thread pool inside one issuer), the issuer MUST serialize emission through a single predecessor pointer at a time: each newly emitted receipt's previousReceiptHash MUST resolve to SHA-256(JCS(R)) for the immediately prior receipt emitted by that same issuer_id (R as defined at the start of this section), taken in emission order, regardless of which concurrent execution path produced it. Parallel sub-chains within one agent identity (for example, a per-receipt chain_id discriminator that would partition one issuer's stream into multiple independently advancing chains) are NOT defined by this profile. An issuer that requires parallel sub-chains MUST express each parallel path as a distinct agent identity, with its own issuer_id value, its own signing key, and its own per-agent chain rooted at the all-zero SHA-256 genesis value. Rationale: deterministic verification of the chain segment covering an audit window, as required by the regime bindings of Sections 6 and 7 (in particular , , and ), depends on a single linear total order over the receipts emitted under each agent identity. A verifier reconstructing the chain from a regulator-supplied issuer_id needs that ordering to be well-defined without out-of-band metadata. Interoperability note: receipts of this profile chain over the payload member R, whereas receipts of the bare format chain over the whole-receipt object that includes the signature; the two wire formats are distinguished by the REQUIRED v member of : a receipt of this profile carries v, while the cited ACTA revision carries none. Version is interpreted within an explicitly selected format; its presence alone is not a universal format identifier. The anchors key MUST NOT be used for this purpose, because makes an absent anchors member conformant and an absent member distinguishes nothing; a present anchors key is a corroborating signal and never a decisive one. The type namespace MUST NOT be used either: it is shared with the upstream format, and the published acta-02-chain-link vector carries a payload.type of protectmcp:decision, so a prefix test on type declines precisely the upstream receipt it is meant to admit. The normative scope rule is the one defined in this section. The published conformance vectors asqav-03-chain-link (payload scope) and acta-02-chain-link (whole-receipt scope) corroborate it byte-for-byte and are published in the asqav-sdk repository (, maintained by this draft's author and commit-pinned in the reference below), so an implementer or independent verifier choosing between the two scopes need not maintain one fixture set per candidate scope. Ed25519 uses . JWK algorithm identifiers are interpreted with and the profile-specific algorithm rules. A verifier MUST NOT infer an algorithm from the key identifier alone or silently substitute another algorithm.

Anchoring (No Upstream Equivalent) The commitment formula in this section applies to the core JSON framing. This revision does not define a complete COSE or JWS anchor transport. A separately selected transport profile must specify its exact commitment bytes and proof carriage; a verifier MUST NOT apply the JSON formula to non-JSON bytes or infer full anchor conformance from a counterparty-binding digest.Issuers SHOULD obtain timestamp evidence over each receipt, individually or through a batch with a retained inclusion proof. Synchronous RFC 3161 acquisition SHOULD be available where the deployment can support it. Best-effort TSA availability is not a hard guarantee. A selected regulatory-evidence profile or relying-party policy MAY impose a stricter anchor floor; that floor MUST name its authority and applicability and MUST NOT be presented as the literal wording of a law without the supporting provision. For both and , the commitment input is SHA-256(JCS(envelope_minus_anchors)), with the anchors key removed completely and the original payload and signature retained. Setting the key to null or an empty array in the commitment input is incorrect. Stored signed and anchored bytes MUST NOT be rewritten during an encoding or schema migration. An anchor entry is a VALID ANCHOR when its value bytes cryptographically re-verify against that commitment input at verification time; an entry whose bytes do not re-verify, or whose proof has not yet been produced, is not a valid anchor, and a verifier MUST NOT derive validity from the presence of anchor metadata alone. An issuer-operated timestamp is not an independent witness. Independently operated evidence MAY arrive later; the verifier MUST report the observed evidence and its validation state separately from the issuer's signature. An OpenTimestamps commitment that has been submitted to a calendar but has not yet upgraded to a Bitcoin block attestation is pending. This profile sets the upgrade bound at seven days from issuance; it is a profile-imposed bound, not a property of the OpenTimestamps protocol, whose calendar-to-block time depends on the calendar operator's publication interval. When the selected policy requires such an upgrade, exceeding the bound fails that policy; it does not retroactively make the payload signature invalid. RFC 3161 responses, OTS proofs and aggregate inclusion paths MUST be retained for the applicable evidence-retention period. The anchors array MAY be absent or empty, both meaning that no anchor evidence was presented. A null value is malformed under this revision; an explicitly selected legacy format may define a different rule. Absent evidence MUST NOT be reported valid. Whether it prevents full verification depends on the required axes of the selected profile and relying-party policy. Verifiers MUST still report other independently evaluable axes. Each anchor entry has a required type of rfc3161 or opentimestamps and a required value holding base64-encoded TimeStampResp DER or OTS proof bytes respectively. An optional status of anchored, pending or failed is operational metadata. Optional anchor_block_hash, tsa_url and operator_id are likewise metadata. No metadata value establishes proof validity, a trust root or operator independence. Verifiers MUST validate the cryptographic evidence against independently configured trust material. They MUST NOT fetch a caller-supplied URL as a trust decision. A historical qualified-timestamp claim requires the applicable certificate, time, revocation and trusted-list policy, not only a root certificate. witness_policy is an OPTIONAL signed-payload object. It contains a REQUIRED positive integer required and a REQUIRED nonempty array witnesses of distinct operator identifiers. required MUST NOT exceed the array length. Operator identifiers name trust-policy records, not anchor-type labels. Each counted entry MUST re-verify over the committed bytes and resolve to an independently trusted operator in that policy. Multiple entries or different protocols controlled by one operator count once. An unresolved identity or independence relationship is unverifiable and MUST NOT be counted. When witness_policy is present, the verifier MUST recompute the count and compare it with the signed threshold. It MUST NOT trust a producer's witness_quorum_met flag. When the member is absent, the receipt-declared policy axis is undeclared, not satisfied. The relying party's external floor is evaluated separately: a weak or absent producer policy cannot waive it. The governance document may publish issuance defaults, but changing that document cannot change the policy committed by an existing receipt. This reverses the prior -09 working text's declaration-only policy. Both the threshold and the selected operator set must travel under the signature so a holder can evaluate the declaration without trusting a later mutable governance document. Legacy declarations absent from the signed bytes remain unavailable to that evaluation and MUST NOT be reconstructed as authenticated claims. The optional signed beacon_ref and its construction-specific limits remain defined in . A public round number or issuer-supplied observation time alone establishes no lower time bound. Beacon evidence is separate from timestamp anchoring and does not satisfy a witness quorum. The OPTIONAL signed-payload member beacon_ref commits to a cached public randomness beacon response. In the reference platform it carries the five members registered in . A verifier seeking a lower time bound must independently authenticate the carried signature for the declared chain and round, using trusted chain parameters and the applicable drand scheme (). A receipt's commitment to an unpredictable, authenticated beacon signature can support such a bound under the beacon's unpredictability and timing assumptions; the round number, chain identifier, or issuer's observed_at assertion alone cannot. The reference platform's structural check does not authenticate the BLS signature, and the reference SDK does not perform that authentication. A successful receipt-verification result therefore does not establish a beacon-derived time bound. The beacon is separate from the anchor evidence and does not satisfy an anchor or witness requirement. RFC 3161 certificate identification uses the applicable update in . Successful token parsing is separate from certificate-path, historical validity, message-imprint and trust-policy checks.

Signer-Outage Evidence (unsigned_gap) This section is normative. The hash chain of links the receipts that exist and is silent about Actions for which no receipt could be minted, so a chain verifies perfectly across a signer outage. An issuing platform that fails to mint a receipt for an Action because its signer was unavailable MUST tally that failure and MUST carry the tally in the unsigned_gap member of the signed payload of the next receipt it successfully mints for that issuer. The member is an object with three REQUIRED members. count is a JSON integer greater than or equal to 1. from and to are ISO 8601 timestamps with explicit timezone bounding the outage, where from is not later than to. The member is absent when no outage precedes the receipt, so receipts minted in normal operation are unchanged. The tally MUST be cleared only when a receipt carrying it has been signed. A signing attempt refused for an authorization reason (a revoked or suspended agent identity, or a failed policy gate) is NOT a signer outage and MUST NOT be tallied. Such refusals are decisions, evidenced under . The member is server-built in the sense of : a caller-supplied value MUST be dropped before signing. A verifier MUST NOT read it as evidence that the unsigned Actions were policy-evaluated.

Extension Fields This profile registers extension fields across seven groupings that MAY appear in the signed payload object alongside the common fields defined in : (a) regulatory classification fields (risk_class, incident_class) defined in this section; (b) the cross-agent envelope-binding field counterparty_binding defined in ; (c) per-action validity-window and integrity fields (result_digest, expires_at, nonce, tool_fingerprint, config_manifest_digest, cve_inventory_digest) and build-provenance fields (executable_hash, sbom_digest, slsa_provenance_pointer, supply_chain_pointer) defined in and ; (d) server-built enforcement-control record fields (authorized_under_mandate, controls_evaluated) defined in ; (e) producer-asserted risk-acceptance fields (approver_id, initiator_id, acceptance_reason, accepted_at, supersedes, sarif_digest, finding_ref, approval_ref, risk_snapshot) defined in ; (f) producer-asserted code-authorship fields (repo_ref, commit_sha, base_sha, change_digest, change_ref, change_approval_ref, change_class, authored_by) defined in ; and (g) self-declared threat-framework taxonomy fields (mitre_techniques, mitre_atlas, owasp_llm_top10, nist_ai_rmf, iso_42001, eu_ai_act_articles), the opaque caller-supplied rfc3161_timestamp token, and the platform-set guard framework_mappings_self_declared defined in . All extension fields appear inside the signed payload object and are therefore covered by the signature scope defined in .

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. Where the Deployer operates under , the documentation is the Provider's Article 9 risk management system as referenced via the instructions for use under Article 26(1); where the Deployer operates under , there is no statutory risk-management-programme document to reference: the reenacted Part 17 carries no such duty. The documentation is instead whatever the Deployer maintains to satisfy the pre-use notice of Section 6-1-1704(1) and, where the Deployer is also a developer, the technical documentation of Section 6-1-1702

incident_class:

A vocabulary term identifying the incident classification of the Action under the applicable regime: an ICT-related incident under , with classification criteria in and the canonical reporting enumeration of Annex II data glossary, field 3.23 (Type of the incident) of (verifiers MUST resolve the canonical values from the regulation directly); a Cybersecurity Event under 23 NYCRR 500.1(f) (or, where the Section 500.17(a) reporting threshold is met, a Cybersecurity Incident under 23 NYCRR 500.1(g)) for Covered Entities of ; a Covered Cyber Incident under once the final rule takes effect; or a security incident under 45 CFR 164.304 for covered entities and business associates within the scope of . Implementations MAY refine the set, provided the flattened mapping in the Audit Pack manifest () projects each refinement to the applicable canonical category for each in-scope regime.

risk_class MUST be encoded as a JSON string. incident_class MUST be encoded as a JSON string drawn from the canonical vocabulary referenced in the Audit Pack, OR as a JSON array of such strings to preserve cross-regime classification (for example, a single Action that is both a DORA ICT-related incident and a CIRCIA Covered Cyber Incident, or both a NYDFS Cybersecurity Incident and a CIRCIA Covered Cyber Incident). Both fields are OPTIONAL at the syntactic level but MAY be REQUIRED by the regime bindings in Sections 6 and 7 of this document. Implementations MAY define additional extension fields. Such fields MUST NOT collide with names defined by this document or its local registries. No moving external field list is incorporated. Implementations defining extension fields SHOULD register them in the registry described in . A verifier that encounters a signed-payload member it does not recognise MUST preserve it byte-for-byte, because it lies inside the signature scope of and dropping or rewriting it destroys the signature. The verifier MUST ignore the member for the purpose of determining conformance and MUST NOT report its presence as a failure or as a reason to withhold a verdict. This rule does not apply to v: an unrecognised wire version is not an unrecognised member, and governs it. An unrecognised member carries no protectmcp semantics, and a claim about such semantics is reported under rather than inferred from the member name.

Counterparty Binding This section is normative. counterparty_binding is an in-payload object an acknowledging agent ("B") emits to carry a cryptographic digest of the envelope-minus-anchors object of an originating agent ("A"). It provides cross-agent byte-equality evidence when a shared intermediary sits between two honest agents and the per-agent hash chains of validate independently regardless of whether B's observed bytes equal A's signed bytes. action_ref binds an Action descriptor under ; it does not bind the peer receipt envelope; counterparty_binding moves the evidence onto B's own COSE or JWS signature, which the verifier already trusts.

Wire Shape The field MUST appear inside the signed payload object. It MUST NOT appear in unprotected COSE or JWS header parameters, or in external_aad per Section 4.3 when the receipt is used for audit (external_aad is permissible only in transport-optimized modes out of scope for Compliance Receipts). For COSE-framed receipts the field sits inside the COSE_Sign1 or COSE_Sign payload per Section 4.1; for JWS-framed receipts it is a top-level claim per . The field is an object with the following members.

envelope_hash:

REQUIRED string. Base64url-encoded SHA-256 digest computed over A's signed envelope with the anchors array excluded, that is over the envelope-minus-anchors object of , which includes A's signature bytes. The digest input is framing-specific:

• For JSON framing, preserve A's parsed payload values and exact signature object, remove the anchors member, and apply JCS once to the resulting two-key envelope. Do not normalize strings, change payload values, or decode and re-encode the signature string. The digest input is the UTF-8 JCS encoding of {"payload": A.payload, "signature": A.signature}. This is the JSON anchor commitment input defined in .
• For a separately selected COSE framing, commit the exact retained COSE signed-object bytes. Do not re-encode an already signed object merely to change map ordering.
• For a separately selected JWS framing, commit the exact retained JWS Compact Serialization bytes. Do not reconstruct its header or payload encoding.

The digest algorithm is SHA-256 (mandatory-to-implement). The encoding MUST be base64url without padding per Section 5, the single alphabet of , for receipts issued on or after the publication date of this revision. A receipt issued before that date MAY carry the standard base64 alphabet of Section 4; a verifier MUST decode either alphabet, with or without padding, and compare the decoded 32 digest bytes rather than the encoded strings, so a pre-cutover receipt does not fail on encoding alone. Including A's signature in the digest scope binds the signed-over content of A's receipt at the envelope level and prevents an intermediary that re-signs A's claims with a different key from escaping detection. Excluding the anchors array is deliberate, and three reasons govern it. Anchors are OPTIONAL and change after issuance under this profile's own rules: permits late attachment within a documented bound, an proof upgrades from a calendar attestation to a Bitcoin block attestation, and an issuing platform MAY add a qualified external token later, so a digest that covered them would pin a passing state of A's receipt rather than A's signed bytes and would break as soon as A's anchoring completed. The non-JSON binding constructions are separate; this revision does not define their complete anchor transport. For the core JSON framing, one digest input serves both the anchor commitment of and the acknowledgment of this section, so an anchor and an acknowledgment commit to the same bytes and every verifier computes one value rather than two. The binding preserves the peer's selected framing and exact committed representation. JSON, COSE and JWS can produce different commitment bytes for related content. A verifier MUST NOT transcode before checking a binding. A digest mismatch establishes disagreement with the commitment; its cause must not be asserted without further evidence.This revision fixes the binding digest to SHA-256. Another digest construction requires an explicitly versioned binding specification; an out-of-band algorithm label MUST NOT change this field's interpretation.

scope:

REQUIRED string from this revision onward. The only value defined by this profile is envelope_minus_anchors, naming the digest scope stated above. A binding that carries no scope member was computed under the three-key text of revisions -04 through -08, whose scope this revision corrects; a verifier MUST report such a binding as unverifiable, legacy scope, and MUST NOT report it as verified or as failed on byte-equality grounds. Where the Audit Pack retains A's envelope exactly as B received it, including A's anchors array as B saw it, a verifier MAY verify a legacy binding against that retained snapshot and MUST label the outcome as verified under the legacy scope. A verifier MUST NOT try both scopes and report whichever matches: a digest that matches under a scope the receipt did not declare is not evidence, and trying both would let a mismatch be laundered into a pass.

receipt_ref:

REQUIRED opaque content-addressed locator the verifier resolves through the Audit Pack or a Deployer-published index to A's signed envelope as A emitted it, from which the verifier derives the envelope-minus-anchors digest input. The value is an opaque string from the verifier's perspective; producers MAY use any stable identifier scheme (URI, content-addressed digest, opaque database id) so long as the Audit Pack resolution layer returns the correct envelope bytes. Future profiles (for example, a SCITT-style inclusion-proof profile layered under the extension-field rules of ) MAY layer on this field.

expect_ack_from:

OPTIONAL string identifying the expected acknowledging principal. For new issuance, compare it with the acknowledging receipt's authenticated payload.issuer_id after validating key authorization. It is not an external signature.kid match. Historical key-identifier expectations require an explicitly selected legacy interpretation.

transport_label:

OPTIONAL string (mcp, bus, orchestrator, http). Operational only; verifiers MUST NOT derive trust from this label.

"counterparty_binding": { "envelope_hash": "bDqg...v5PE", "scope": "envelope_minus_anchors", "receipt_ref": "asqav-receipt://org/123/agent_A/seq/4811", "expect_ack_from": "00000000000000000098", "transport_label": "mcp" } The COSE form follows the same member set under deterministic CBOR map ordering per Section 4.2.

Emitter Behaviour B SHOULD emit counterparty_binding when a signed acknowledgment expectation or the selected policy requires it. B MUST compute the commitment using the framing-specific construction in . For JSON, that construction applies JCS to the envelope with anchors removed and the original signature string preserved. Changes to whitespace or member order that preserve the JCS representation do not change the commitment. Where one acknowledgment confirms several peers, each binding is evaluated separately; it does not prove that all peers received identical application data.

Verifier Behaviour A Compliance Verifier processing a receipt carrying counterparty_binding MUST, in addition to , resolve receipt_ref through the Audit Pack or a Deployer-published index to A's signed envelope, reduce it to the envelope-minus-anchors object by removing the anchors key, recompute the SHA-256 digest of that object under the scope rule of , encode the result, and compare to envelope_hash. A non-resolving receipt_ref or a digest mismatch MUST cause the acknowledging receipt to be reported non-conformant; liveness loss at A MUST NOT be silently treated as success. A verifier that has no resolution mechanism available at all, such as an offline verifier with neither an Audit Pack nor a published index, has not performed this check rather than failed it: it MUST report the binding as unverified and MUST NOT report the receipt as verified on the strength of a binding it never resolved. An unresolved counterparty binding supplies no verified corroboration. Where expect_ack_from is present, the verifier MUST compare it with the acknowledging receipt's authenticated payload.issuer_id after establishing the key's authorization for that principal. A demonstrated mismatch is invalid. Legacy key-identifier expectations are handled only under their documented issuance policy.The verifier MUST read the scope member before recomputing. A binding declaring envelope_minus_anchors is recomputed under the rule above. A binding with no scope member is a legacy binding under the superseded three-key scope of revisions -04 through -08: the verifier MUST report it as unverifiable, legacy scope, and MUST NOT report it as verified, unless the Audit Pack retains A's envelope exactly as B received it, in which case the verifier MAY recompute against that retained snapshot and MUST label the outcome as verified under the legacy scope. A verifier MUST NOT recompute under both scopes and report whichever matches. A binding declaring a scope value this profile does not define is reported unverifiable on the same axis, never verified. The holder retains peer envelopes and supporting evidence according to their lawful record-specific policy. Unavailable required peer evidence leaves the binding unverifiable. Chains of several parties use pairwise bindings; a co-signed envelope does not automatically establish the same sequence of acknowledgements.

Result-Bound and Validity-Window Extensions This section is normative. It defines six OPTIONAL extension fields that may appear inside the signed payload object to bind the receipt to the byte-equality of a downstream result, to bound the validity window of a decision, to declare the tool and configuration that produced the action, and to record the supply-chain Common Vulnerabilities and Exposures (CVE) inventory in effect at signing time. The fields are independently OPTIONAL; an implementation MAY emit any subset. All six are covered by the signature scope defined in .

result_digest:

OPTIONAL JSON string formatted sha256:<64 lowercase hex chars>. It is NOT an object and NOT the shape of payload_digest: the two fields are described together elsewhere and they differ on both axes, since payload_digest is an object whose hash member is unprefixed hexadecimal, while this field is a bare string in the self-describing prefixed form. There is no size or preview member on this field. The digest covers the canonicalized bytes of the downstream Action's result body (response payload, tool output, model completion). The field is emitted on a follow-up protectmcp:observation:result_bound receipt that references the originating protectmcp:decision via action_ref; a verifier processing a result-bound observation MUST treat a digest mismatch between result_digest and the verifier's local recomputation over retained result bytes as a non-conformance condition. Result bytes covered by result_digest follow their own lawful evidence policy under the legal-applicability and privacy rules.

expires_at:

OPTIONAL RFC 3339 timestamp with an explicit UTC offset, encoded as a JSON string. Declares the wall-clock time after which the producing system considers the decision result stale and not safe to replay. The field provides the upper bound of the decision's validity window, additive to the 300-second forward-skew bound on issued_at of ; expires_at bounds replay safety from above, the forward-skew rule bounds emission honesty from above. The window is declared, not enforced, by this field: enforcement against a replaying action is the verifier's and the Deployer's obligation under the next paragraph, and the receipt record itself never expires. A verifier MUST reject a downstream action that replays a decision whose expires_at lies in the past relative to the replay's wall clock; verifiers MUST NOT reject the originating receipt itself solely because expires_at has elapsed (the receipt remains valid as a record of the decision at issued_at).

nonce:

OPTIONAL JSON string carrying a producer-generated value that is unique across the producer's emission stream for the lifetime of the cryptographic key identified by kid. The field SHOULD be the lowercase hexadecimal encoding of 12 random bytes (24 hexadecimal characters). Verifiers SHOULD reject a second receipt that carries the same nonce under the same issuer_id as a replay candidate; the rejection is informational where the bound action is idempotent and relevant where the bound action is not. The field is OPTIONAL at the syntactic level but is a SHOULD-emit for any producer whose downstream actions are not idempotent. The nonce is NOT a challenge-response freshness proof: it is generated by the producer, not an unpredictable challenge generated and retained by the party appraising the evidence, so it supports emission correlation and replay-candidate flagging but does not prove uniqueness or execution.

tool_fingerprint:

OPTIONAL JSON string of 32 lowercase hexadecimal characters carrying the first 32 hexadecimal characters (128 bits) of the SHA-256 digest over the JCS canonicalization () of the JSON object {"tool_name": <tool name>, "schema": <declared input schema>}, where schema is the JSON object form of the tool's declared input schema (an empty object when the tool declares none). The field binds a receipt to a specific tool identity; a verifier or auditor reproducing the Action can detect tool drift (the same tool name with a different declared schema) by comparing fingerprints across receipts in the same chain, and a fingerprint change under an unchanged tool name surfaces naming collisions and registry shadowing. The field is OPTIONAL and complementary to action_ref: action_ref identifies the call, tool_fingerprint identifies the callee.

config_manifest_digest:

OPTIONAL JSON string formatted sha256:<64 lowercase hex chars> over the canonical bytes of the producer's configuration manifest in effect at the time the Action was signed. The manifest content is operator-defined and SHOULD include the producer's policy bundle reference, model identifiers and versions, prompt template digests, retrieval index identifiers, and inputs relevant to any separately applicable modification test, including Article 43 of and the intentional and substantial modification definition in Section 6-1-1701(12) of . A configuration change alone does not establish that either legal test is met. Because the manifest content is operator-defined, an operator's manifest MAY include an attestation or appraisal digest among its inputs; this profile registers no dedicated field for one. The field is OPTIONAL but, when emitted, SHOULD resolve through the Audit Pack to retained manifest bytes for its lawful record-specific retention period.

cve_inventory_digest:

OPTIONAL JSON string formatted sha256:<64 lowercase hex chars> over the canonical bytes of the producer's CVE inventory at the time the Action was signed. The inventory content SHOULD list the CVE identifiers known to apply to the producer's executing image and its declared runtime dependencies, plus the producer's accepted-residual rationale per Article 15 robustness obligations or the equivalent obligations under the EU and US evidence mappings. The field binds a snapshot of the producer's known-vulnerability surface to the receipt; a regulator examining the receipt can resolve the digest through the Audit Pack to the canonical inventory bytes that were in effect when the Action was signed, rather than relying on a later-time inventory that may have been updated after the Action was performed.

Implementations emitting result_digest SHOULD use the dedicated protectmcp:observation:result_bound type registered in for the follow-up receipt that carries the bound digest. Implementations MAY emit expires_at, nonce, tool_fingerprint, config_manifest_digest, and cve_inventory_digest on any receipt type defined by this profile; the fields are type-agnostic. Two type-bound presence rules attach to the fields of this section. The reference cloud implementation rejects at signing time, as the configuration_change_missing_config_manifest_digest guard, a receipt of type protectmcp:lifecycle:configuration_change (registered in ) that lacks a well-formed config_manifest_digest; and it rejects at signing time, as the result_bound_missing_result_digest guard, a receipt of type protectmcp:observation:result_bound that lacks a well-formed result_digest. Layering note on the validity window: this profile places the validity-window bounds in the receipt itself. nonce and expires_at ride inside the signed payload, and the conformant verifier enforces them: the expires_at replay rejection is a mandatory check of , and a verifier that maintains a seen-nonce index flags duplicate emissions on the duplicate_emission_candidate axis of . Enforcement of the nonce uniqueness bound requires that seen-nonce state and is therefore conditional; enforcement against replay of an expired decision is an application decision point the verifier's rejection feeds. Section 14.1 of reports that in that composition the freshness check was enforced outside the conformant Verifier, in the application's own appraisal step; a producer composing that pattern with this profile SHOULD emit nonce and expires_at so the receipt layer carries the bounds.

Build-Provenance Extensions This section is normative. It defines four OPTIONAL fields for evidence about the software associated with an Action: executable_hash identifies an artifact, sbom_digest commits to an SBOM document, slsa_provenance_pointer locates a build attestation, and supply_chain_pointer locates transparency-log evidence. An implementation MAY emit any subset. All four fields are covered by the signature scope in . Signing a digest or locator binds the producer's assertion; it does not by itself authenticate the referenced artifact, prove execution or establish complete dependency coverage.

executable_hash:

OPTIONAL JSON string formatted sha256:<64 lowercase hex chars>. For a container, its value is the SHA-256 content digest of the exact platform-specific OCI image manifest identified by the runtime for the executing image, computed over that manifest's bytes under the OCI Image Specification v1.1.1 content-descriptor rules. It is not a hash of the digest string, a mutable tag lookup, an image-index digest or an assertion about every file in a running container. For a non-container executable, it is SHA-256 over the binary file bytes observed at the resolved execution path. The Audit Pack records the artifact kind and observation method. A file or manifest digest alone does not prove which bytes actually executed. A verifier MAY compare this identity with an authenticated build attestation's subject. A mismatch for the same artifact and digest scope is reported as inconsistent evidence; different scopes require an evidenced mapping and otherwise remain incomparable. A required comparison that is inconsistent or unverifiable prevents full verification under .

sbom_digest:

OPTIONAL JSON string formatted sha256:<64 lowercase hex chars>, computed over an SBOM document in CycloneDX JSON or SPDX JSON form. This profile uses the complete document canonicalized under as the digest input; it does not assume that every edition of either SBOM format defines a common canonicalization algorithm. The Audit Pack manifest MUST identify the format, exact specification version, digest input rule and retained document. The document MUST satisfy JCS input constraints; otherwise this encoding cannot be used. The receipt payload's additional safe-integer restriction does not apply to numbers inside the separately retained SBOM document. Existing receipts using a different declared digest rule retain that rule under an explicit legacy adapter; missing or ambiguous rules are unverifiable and MUST NOT be guessed. The digest commits to the document, not to the accuracy or completeness of its dependency claims.

slsa_provenance_pointer:

OPTIONAL JSON string carrying an HTTPS URL for a SLSA build provenance attestation about the artifact identified by executable_hash. The target SHOULD use the SLSA Provenance v1 predicate in an in-toto Statement v1. Other supported versions require explicit version selection. A verifier checks the attestation signature, the independently authorized signer-builder pair and the subject digest under its selected policy before reporting verified provenance. A URL, a recognized format or the presence of a signature does not establish those checks. Missing required evidence remains unverifiable. The build platform's statements remain bounded by its trust policy and do not prove that the artifact later executed.

supply_chain_pointer:

OPTIONAL JSON string carrying an HTTPS URL for transparency-log evidence concerning the identified build artifact. An in-toto statement is an attestation format; Sigstore is a signing and verification ecosystem; Rekor is a transparency-log service used by Sigstore. They are not three interchangeable log formats, and this profile gives them no preference order. The Audit Pack identifies the supported log and entry format and retains the evidence needed for verification. A verifier claiming verified log inclusion MUST validate the artifact or attestation binding, inclusion proof and authenticated log checkpoint under its independently configured log trust policy. A locator alone is not inclusion evidence. Unsupported or missing required evidence is unverifiable. Log inclusion does not establish the truth of an attestation, complete capture or independent corroboration of a SLSA statement recorded in that same log.

Executable hashes, SBOMs and build attestations can help investigate which software produced a recorded action. Their use here is a profile recommendation. The cited logging and incident-management provisions do not themselves prescribe this particular set of artifacts. Retain each artifact under its lawful evidence policy and report any unavailable input as a verification limit.

Enforcement-Control Record Extensions This section is normative. It defines two OPTIONAL extension fields that record, inside the signed payload object, which authorization and enforcement controls the issuing platform actually evaluated when it signed the receipt. Both fields are server-built: they are populated by the issuing platform at signing time, never carried in the producer's signing request, and a caller-supplied value for either field MUST be dropped by the issuing platform before signing. Both fields are covered by the signature scope defined in . The design rule for both fields is omission-over-false attestation: a control that did not run is represented by the absence of its key, never by a present key asserting a result the control did not produce. The same omission discipline extends to freshness (informatively): a deployment that cannot perform an external freshness check inside the party that appraises evidence records that limitation by the absence of any freshness assertion, never by treating an affirming result as fresh. The two fields each carry a false-attestation guard that rejects a present-but-malformed attestation, in the same spirit as the framework_mappings_self_declared guard of and the witness_policy quorum guard of . The key set of this section is closed: both fields are server-built, unknown keys MUST be rejected, and this section does not convey remote attestation results.

authorized_under_mandate:

OPTIONAL object recording that the Action was signed under a self-declared authorizing mandate. The object carries four members: mandate_id (REQUIRED string, the issuer-scoped identifier of the mandate the Action was authorized under), issuer_id (REQUIRED string, the identifier of the party that issued the mandate, in the bare-identifier form required by ), scope_digest (REQUIRED string formatted sha256:<64 lowercase hex chars> over the canonical bytes of the mandate's authorized-action-types scope), and verified (REQUIRED boolean). The trust semantics are deliberately narrow: verified=true asserts self-declared issuer authority, the same trust level as framework_mappings_self_declared of , and is NEVER an issuing-platform attestation of verified third-party authorization. The mandate binding is self-declared by the issuer, is evaluated against the issuing platform's own clock at signing time, and scopes the Action to a set of authorized action types; this profile does NOT define a value cap, a counterparty restriction, or any other constraint on the mandate, and a verifier MUST NOT infer one from the presence of this field. A verifier resolves scope_digest by retrieving the mandate identified by mandate_id through the Audit Pack or a Deployer-published mandate index and recomputing the digest over the canonical scope bytes; a mismatch MUST be reported as a non-conformance condition. The false-attestation guard for this field, published as false_mandate_attestation_guard in the issuing platform's wire vocabulary, rejects an authorized_under_mandate object that is present but does not carry all of mandate_id, issuer_id, verified=true, and a well-formed scope_digest: a present-but-malformed attestation is rejected at signing time rather than signed and surfaced as truth.

controls_evaluated:

OPTIONAL object enumerating the enforcement controls that genuinely fired when the issuing platform signed the Action, plus the allow result. The member keys are drawn from a closed set: emergency_halt, delegation_scope, quorum, mandate, policy, content_scan, and result; an unknown key MUST be rejected. Each control key is present ONLY when its control actually ran on this sign; an absent key means the control never ran on this sign, and a verifier MUST NOT infer from an absent key that the control ran and passed silently. The quorum member, when present, MUST carry fired=true together with a 64-lowercase-hex attestation_hash proving the quorum evaluation; the policy member, when present and asserting a policy was evaluated, MUST carry matched_count greater than or equal to 1. The false-attestation guard for this field, published as false_control_attestation_guard in the issuing platform's wire vocabulary, rejects a present-but-malformed controls_evaluated object: an unknown control key, a quorum member lacking fired=true plus a 64-hex attestation_hash, or a policy member asserting evaluation without matched_count greater than or equal to 1, is rejected at signing time. Because the field is server-built and a caller-supplied controls_evaluated is dropped before signing, a verifier MAY treat the enumerated keys as the issuing platform's own record of which controls it ran.

Both fields are type-agnostic and MAY appear on any receipt type defined by this profile, though they are most commonly emitted on protectmcp:decision receipts where an authorization or enforcement evaluation produced the recorded decision. Neither field replaces the policy-evaluation honesty rule that an issuing platform MUST NOT assert a control ran when it did not (the design note carried under ): controls_evaluated records which controls ran, not that any control blocked, and an absent control key is the conformant representation of a control that did not run.

Risk-Acceptance Extensions This section is normative. It defines OPTIONAL extension fields that appear inside the signed payload object of a receipt of type protectmcp:lifecycle:risk_acceptance (registered in ), which records a producer's decision to accept a known risk, security finding, or policy exception. A risk-acceptance receipt is a lifecycle record, not a policy-evaluation outcome: it is emitted through the no-policy lifecycle path of , carries decision observation, and asserts that no policy was evaluated for the acceptance. The signature binds the producer's recorded assertions, including its asserted issued_at. Chain links and optional anchor evidence provide their separately defined integrity and time properties (, ); they do not establish that the acceptance was authored or chained at that exact time. The receipt does NOT make any accepted risk safe, any snapshot value true, reproducible, or verified, or any declared expiry enforced. The scope-honesty labels in the field definitions below are normative and mirror the labels published in the issuing platform's /.well-known/governance.json wire-vocabulary surface.

approver_id:

REQUIRED JSON string carrying the producer-asserted identity that authored the risk acceptance, in the bare-identifier form of (a bare kid or issuer_id). The field is bound into the signed bytes only: the issuing platform performs NO authority check, NO authentication of the named identity, and NO identity resolution; the only comparison it makes is the string-equality refusal against initiator_id applied to Compliance Receipts (the risk_acceptance_self_approval_guard of the initiator_id entry below). A risk-acceptance receipt that omits approver_id MUST be rejected at signing time by the false-attestation guard named in .

initiator_id:

OPTIONAL JSON string carrying the producer-asserted identity that requested the acceptance, in the same bare-identifier form. The field is bound into the signed bytes only. The reference cloud implementation refuses at signing time, as the risk_acceptance_self_approval_guard, a risk-acceptance Compliance Receipt whose initiator_id string-equals approver_id, because a receipt asserting an approval flow approved by its own initiator is incoherent on its face. The guard is a string-incoherence check (case-sensitive exact match), NOT identity resolution: it fires only when both fields are present, an absent field never fires it, and any real segregation-of-duties decision belongs to the Deployer's enforcement layer, not to this record format.

acceptance_reason:

REQUIRED JSON string carrying the free-text producer rationale for accepting the risk. The signed field binds the issuer to the recorded rationale and its asserted issued_at; it is never parsed, scored, or validated by the issuing platform. A risk-acceptance receipt that omits acceptance_reason MUST be rejected at signing time by the same false-attestation guard as approver_id.

accepted_at:

OPTIONAL RFC 3339 timestamp with an explicit UTC offset, encoded as a JSON string, carrying the producer-asserted wall-clock time at which the acceptance was authored. This value is self-declared by the producer; the only times the issuing platform attests are issued_at () and the anchors evidence (). The field is distinct from issued_at so that an acceptance back-dated relative to emission is auditable.

supersedes:

OPTIONAL JSON string carrying a producer-asserted pointer to the prior risk-acceptance receipt this one replaces, encoded either as an opaque receipt locator or as a sha256:<64 lowercase hex chars> digest. The field binds the supersession claim together with the asserted issued_at; resolution is the verifier's job, and the issuing platform NEVER invalidates the prior receipt: the recorded signed bytes remain unchanged and supersedes in the later receipt points to the earlier receipt.

sarif_digest:

OPTIONAL JSON string formatted sha256:<64 lowercase hex chars> over the producer-declared canonical bytes of the static-analysis (SARIF) scan artifact the acceptance rested on. The digest is a producer-supplied commitment. Checking its syntax does not establish that the SARIF artifact exists or existed at the asserted time. The issuing platform NEVER parses, fetches, re-runs, or validates the scan; a verifier recomputes SHA-256 over the SARIF bytes retained in the Audit Pack and treats a mismatch as a tamper signal, in the same manner as config_manifest_digest of .

finding_ref:

OPTIONAL JSON string carrying a producer-asserted opaque pointer to the specific finding or rule identifier inside the SARIF artifact (for example a ruleId plus a location). The field is free-text; it binds the asserted reference and issued_at and is never resolved or validated by the issuing platform.

approval_ref:

OPTIONAL JSON string carrying a producer-asserted opaque correlation pointer to a human-in-the-loop approval identifier or an external ticket. The field is free-text; it binds the asserted correlation pointer and issued_at and is never resolved or validated by the issuing platform.

risk_snapshot:

OPTIONAL object carrying a point-in-time snapshot of THIRD-PARTY risk signals as the producer read them, with members: snapshot_at (REQUIRED RFC 3339 timestamp with an explicit UTC offset, the producer-asserted read-time the snapshot is pinned to), snapshot_source (free-text string naming where the signals came from, for example a named EPSS feed, the CISA KEV catalog, or an NVD CVSS record; OPTIONAL when only snapshot_at and cve_ids are populated, REQUIRED whenever any of epss, cvss, cvss_vector, or kev_listed is populated), epss (OPTIONAL string), cvss (OPTIONAL string), cvss_vector (OPTIONAL string), kev_listed (OPTIONAL boolean), and cve_ids (OPTIONAL JSON array of CVE-identifier strings). The object is a producer-asserted snapshot, NOT a value the issuing platform computed, fetched, verified, queried, or vouched for; it binds the producer-supplied signals and asserted snapshot_at, and is explicitly NOT reproducible from any input the issuing platform holds. A verifier MUST NOT read any member as an issuing-platform-derived or verified score. All numeric risk signals (epss, cvss) MUST be encoded as JSON strings, not as JSON numbers, consistent with the IEEE-754 float prohibition of ; this string encoding is relevant for the snapshot-not-score semantics. Whenever any of epss, cvss, cvss_vector, or kev_listed is populated, snapshot_source MUST be present; a populated numeric or KEV signal without snapshot_source MUST be rejected at signing time by the false-attestation guard named in , so that a value can never be read as an issuing-platform-derived score.

A risk-acceptance receipt MAY additionally carry the type-agnostic expires_at field of to declare the wall-clock time after which the Deployer considers the acceptance stale, and the server-built authorized_under_mandate field of . Consistent with , expires_at on a risk-acceptance receipt is declared, not enforced: the issuing platform records the declared expiry but NEVER auto-revokes an expired acceptance, and a verifier MUST NOT reject the originating risk-acceptance receipt itself solely because expires_at has elapsed. The named identities (approver_id, initiator_id) are bound fields; beyond the string-incoherence refusal of the risk_acceptance_self_approval_guard, NO separation-of-duties check is performed by this profile.

Oversight Ruling Receipts This section is normative. It defines the sub-namespace protectmcp:lifecycle:oversight_ruling (registered in ) and the extension fields that appear inside the signed payload of a receipt of that type. An oversight ruling receipt records a human ruling made about one or more Actions after those Actions were recorded, and references the receipts it judges. The profile names oversight review in several bindings but, before this revision, defined no record for the ruling itself, so the reviewed and unreviewed cases were indistinguishable on the wire. An oversight ruling receipt is a lifecycle record, not a policy-evaluation outcome. It is emitted through the no-policy lifecycle path of , carries decision observation and the policy_digest of the sentinel artefact, exactly as does, so the false-attestation honesty rule is preserved: no policy result is asserted by the act of ruling. The type-bound presence rule applies, so a receipt of this type that omits judged_action_refs or ruling is refused at signing time rather than emitted incomplete. The ruling receipt is an ordinary member of the chain, emitted at the time of the ruling. It never rewrites, re-signs or re-anchors the receipts it judges: the judged receipts stand exactly as they were signed, and the ruling is a later, separately signed statement about them.

judged_action_refs

REQUIRED on this receipt type. A non-empty JSON array of action_ref values identifying the receipts the ruling is about. A verifier MUST resolve every entry against the Audit Pack of or the chain segment presented alongside the ruling. A reference that does not resolve is a non-conformance OF THE RULING RECEIPT, and MUST NOT be reported as a defect of any judged receipt: an unresolvable reference means the ruling names evidence it did not supply, which says nothing about the receipts that do resolve.

ruling

REQUIRED on this receipt type. One of: confirm, the reviewer upholds the recorded outcome; override, the reviewer replaces the recorded outcome with a different one; escalate, the reviewer refers the matter onward without deciding it; flag, the reviewer marks the matter for attention while leaving the outcome standing.

ruling_reason

OPTIONAL machine-readable reason code, under the same discipline as the reason code of .

reviewer

REQUIRED on this receipt type. An object with principal, an opaque identifier of the natural person who ruled, which MUST NOT carry a name, an email address or any other direct identifier in clear; role, free text naming the reviewer's function; and OPTIONAL attestation, an object with method (one of sso, hardware_key, signed_statement, manual_assertion) and, where method is not manual_assertion, evidence carrying the platform-verified artefact digest.

When attestation is absent or its method is manual_assertion, the human-review claim remains unverified. Signature, chain and anchor results are reported separately; the overall summary follows all required axes in . If the selected policy requires authenticated human-review evidence, its absence prevents full verification. A signed ruling binds the issuer's assertion and stated time but does not alone establish that a qualified human conducted a review. A verifier MUST NOT report the review as verified solely because the receipt signature passes. Bindings. Under an oversight ruling receipt can contribute to evidence of the human-oversight assignment Article 26(2) requires. Under it can contribute to evidence of an opportunity for meaningful human review and reconsideration, and the statutory definition there is deliberately demanding: it requires a reviewer with authority to approve, modify or override, who considers relevant available primary evidence, is trained to conduct the review, DOES NOT DEFAULT TO THE SYSTEM OUTPUT, and has access to enough information to understand the output's intended use, material limitations and categories of inputs, and the principal factors that generated it. The ruling receipt alone cannot establish reviewer training, authority or non-deference; those matters require separate evidence. An oversight ruling receipt therefore evidences that a ruling was recorded and, where an attestation was independently validated, the scoped reviewer-authentication result; the remaining elements of the statutory standard stay the Deployer's own responsibility, and a verifier MUST NOT report them as satisfied solely from the ruling receipt; any separate evaluation identifies its supporting evidence and limitations. Under the NIST AI Risk Management Framework the receipt is evidence toward the MANAGE function.

Code-Authorship Extensions This section defines extension fields in the signed payload of a protectmcp:lifecycle:code_authorship receipt (). It records a producer's assertion about a repository change. The receipt uses the no-policy lifecycle path in , carries decision=observation and asserts no policy-evaluation outcome. The issuer MUST enforce the type-bound required-field and no-policy rules at signing time and reject use of these fields on an incompatible type.The signature binds the recorded assertions; chain links and optional timestamp evidence provide their separately defined integrity and time properties (, ). They do not prove that the change exists, was authored by the named model, was executed at issued_at, or is correct, safe, reviewed or buildable. The receipt layer does not fetch the repository or validate the code. The separately selected rederivation feature in reports the specific source bytes it actually fetched and recomputed. Required but unavailable rederivation prevents full verification under .

repo_ref:

REQUIRED JSON string carrying a producer-asserted opaque pointer to the repository the change was authored against (for example a clone URL or an internal repository identifier). The field is free-text; it binds the asserted reference and issued_at and is never resolved, cloned, or validated by the issuing platform. A code-authorship receipt that omits repo_ref MUST be rejected at signing time by the code_authorship_missing_required_field guard named in .

commit_sha:

REQUIRED JSON string carrying the producer-asserted commit identifier of the authored change (for example a Git object name). The field is bound into the signed bytes only: the issuing platform NEVER fetches the named commit, never verifies that it exists, and never verifies its contents. It binds the producer-supplied commit identifier and asserted issued_at. A code-authorship receipt that omits commit_sha MUST be rejected at signing time by the same guard as repo_ref.

base_sha:

OPTIONAL JSON string carrying the producer-asserted base commit identifier the change was authored on top of. Like commit_sha, the field is bound into the signed bytes only and is NEVER fetched or verified by the issuing platform; it binds the producer-supplied base identifier and asserted issued_at.

change_digest:

OPTIONAL JSON string formatted sha256:<64 lowercase hex chars> over the producer-declared canonical bytes of the change (for example a unified diff). The digest is a producer-supplied commitment. Checking its syntax does not establish that the change exists or existed at the asserted time. The issuing platform NEVER fetches, re-diffs, or re-computes the change; a verifier recomputes SHA-256 over the change bytes retained in the Audit Pack and treats a mismatch as a tamper signal, in the same manner as sarif_digest of and config_manifest_digest of . A change_digest value outside the sha256:<64 lowercase hex chars> wire form MUST be rejected at signing time by the change_digest_not_sha256_wire_form guard.

change_ref:

OPTIONAL JSON string carrying a producer-asserted opaque pointer to the change as a unit (for example a pull-request or merge-request identifier). The field is free-text; it binds the asserted reference and issued_at and is never resolved or validated by the issuing platform.

change_approval_ref:

OPTIONAL JSON string carrying a producer-asserted opaque correlation pointer to a human-in-the-loop approval identifier or an external review ticket for the change. The field is free-text; it binds the asserted correlation pointer and issued_at and is never resolved or validated by the issuing platform, in the same manner as approval_ref of .

change_class:

OPTIONAL JSON string drawn from the closed vocabulary read, write, delete, execute, or deploy, declaring the producer-asserted class of the change. The value is self-declared; the issuing platform records it but does NOT verify that the change matches the declared class. A value outside the closed vocabulary MUST be rejected at signing time, the field being constrained to the closed vocabulary.

authored_by:

OPTIONAL object carrying a producer-asserted description of the authoring agent, with members: agent_id (OPTIONAL string identifying the authoring agent), model_id (OPTIONAL string naming the model), model_version (OPTIONAL string naming the model version), tool (OPTIONAL string naming the authoring tool), and attestation_source (OPTIONAL string naming where the authorship description came from). The object is producer-asserted, NOT a value the issuing platform computed, verified, queried, or vouched for; it binds the producer-supplied values and asserted issued_at. The issuing platform NEVER verifies the named model. Whenever any of model_id or model_version is populated, attestation_source MUST be present; a populated model field without attestation_source MUST be rejected at signing time by the false-attestation guard named in , so that a model claim can never be read as an issuing-platform-verified attestation.

A code-authorship receipt MAY additionally carry the server-built authorized_under_mandate field of to record the self-declared authorizing mandate the change was signed under; this profile reuses that field for code-authorship authorization and does not define a separate authorization field. Consistent with , authorized_under_mandate asserts self-declared issuer authority only and is NEVER an issuing-platform attestation of verified third-party authorization. Statements in these field definitions and their registry entries that the issuing platform does not fetch, resolve or verify describe ordinary receipt issuance. Separately requested authoritative rederivation follows and reports its actual scope and result.

Threat-Framework Taxonomy Extensions This section is normative. It defines seven OPTIONAL caller-supplied taxonomy fields, one OPTIONAL caller-supplied opaque timestamp token, and one platform-set false-attestation guard boolean, all of which MAY appear inside the signed payload object. The seven taxonomy fields record producer-asserted mappings of the Action into established threat-and-control catalogues; they are self-declared and are NOT verified by the issuing platform. The guard boolean exists so that a verifier can tell a self-declared classification apart from a platform-verified one. All nine fields are covered by the signature scope defined in , and an implementation MAY emit any subset.

mitre_techniques:

OPTIONAL JSON array of MITRE ATT&CK technique identifiers (for example T1059, T1078) self-declared by the producer. The values are referenced by identifier from the MITRE ATT&CK enterprise matrix. The field is not verifier-checked by the issuing platform; when the array is populated the issuing platform MUST set framework_mappings_self_declared to true.

mitre_atlas:

OPTIONAL JSON array of MITRE ATLAS identifiers (for example AML.T0051) covering AI-system-specific adversary techniques, self-declared by the producer and referenced by identifier from the MITRE ATLAS catalogue. ATT&CK and ATLAS are VERSIONED catalogues whose identifiers are re-scoped between releases, so a receipt carrying either field SHOULD also carry the catalogue version it drew the identifiers from, either as a version member alongside the array or as a suffix on each value under a convention documented in the Audit Pack metadata. Without it an identifier is only as stable as the reader's assumption about which release was meant. When populated the issuing platform MUST set framework_mappings_self_declared to true.

owasp_llm_top10:

OPTIONAL JSON array of OWASP Top 10 for LLM Applications identifiers, self-declared by the producer. Values MUST be edition-qualified, in the form LLM01:2025, and a bare LLM01 MUST be rejected. The qualifier is relevant rather than decorative: the numbering changed between the 2023 and 2025 lists, so a bare identifier names a different risk depending on which edition the reader assumes. When populated the issuing platform MUST set framework_mappings_self_declared to true.

owasp_agentic_top10:

OPTIONAL JSON array of identifiers from the OWASP Top 10 for Agentic Applications 2026, self-declared by the producer. This profile uses ASI01 through ASI10 for that edition, without a year suffix in the identifier. The issuing platform MUST set framework_mappings_self_declared to true when this field is populated. These identifiers name the agentic catalogue, not the OWASP Top 10 for LLM Applications. Any separately selected catalogue edition MUST be identified explicitly and MUST NOT silently change the meaning of a retained identifier. The official OWASP GenAI catalogue crosswalk lists the ten identifiers for the 2026 edition; their use here makes no claim that a receipt demonstrates a mitigation or that an external framework mapping has been independently validated.

nist_ai_rmf:

OPTIONAL JSON array of NIST AI Risk Management Framework function identifiers and subcategories (for example GOVERN-1.1, MEASURE-2.7), self-declared by the producer and referenced from . When populated the issuing platform MUST set framework_mappings_self_declared to true.

iso_42001:

OPTIONAL JSON array of ISO/IEC 42001:2023 control identifiers (for example A.6.2.6), self-declared by the producer and referenced from ISO/IEC 42001:2023. When populated the issuing platform MUST set framework_mappings_self_declared to true.

eu_ai_act_articles:

OPTIONAL JSON array of EU AI Act article identifiers (for example Article-12, Article-15, Article-50), self-declared by the producer and referenced from . When populated the issuing platform MUST set framework_mappings_self_declared to true.

rfc3161_timestamp:

OPTIONAL JSON string carrying a base64-encoded TimeStampResp (DER) supplied by the producer at signing time and preserved verbatim on the receipt for offline TSA chain verification independent of any platform-issued anchors. The payload entry is an opaque caller-supplied token, NOT the per-receipt anchor produced by the platform under ; the base64 encoding is per . It never counts toward the anchoring requirement of or toward a witness_policy quorum, and a verifier MUST NOT read it as the receipt's timestamping evidence. This field does not flip framework_mappings_self_declared.

framework_mappings_self_declared:

OPTIONAL JSON boolean false-attestation guard set by the issuing platform. The platform MUST set it to true whenever any of mitre_techniques, mitre_atlas, owasp_llm_top10, owasp_agentic_top10, nist_ai_rmf, iso_42001, or eu_ai_act_articles is populated. A producer-supplied value of false alongside a populated taxonomy field MUST be overridden by the issuing platform, in the same spirit as the false-attestation guards of and the witness_policy quorum guard of . The guard does not assert that the self-declared mappings are correct; it asserts only that they are self-declared rather than platform-verified, and a verifier MUST NOT treat a populated taxonomy field as platform-verified.

The nine fields are type-agnostic and MAY appear on any receipt type defined by this profile.

Environment Attestation Extensions (Normative-Optional) This optional extension carries signed environment-state claims asserted before an Action, drawing on the environment-record concept in . Absence is permitted by the base profile. A selected relying-party policy may require the extension; its required checks then participate in the summary under .

environment_attestation:

OPTIONAL object carrying boolean environment-state claims attested before the Action (for example sandbox liveness, egress state, secret-store lock state), signed by an environment key distinct from the receipt's signing key (separation of duty: the runtime asserts facts about itself under its own key, under a documented attester trust policy). Members: claims (REQUIRED object whose values are booleans), attester_kid (REQUIRED string identifying the environment key), attested_at (REQUIRED RFC 3339 timestamp with an explicit UTC offset), and sig (REQUIRED standard padded base64 signature over the JCS canonicalization per of the attestation object with the sig member removed, under the algorithm declared for the environment key). The object is covered by the receipt's own signature scope of in addition to carrying its detached environment-key signature. A verifier that checks the field verifies sig against the resolved environment key and bounds the staleness of attested_at relative to the receipt's issued_at under the verifier's documented bound; a stale, unverifiable or malformed attestation is reported on its own axis and prevents full verification when that check is required by the selected policy under .

An environment attestation supplies evidence to an authorization policy; it does not replace that policy or authorize an Action by itself. A valid receipt can faithfully record a denial. Receipt verification and permission to perform the Action remain distinct decisions. Absence of this extension has no adverse effect on the base-profile summary unless the selected external policy requires it. A verified environment signature establishes an assertion by the authorized attester, subject to key custody, measurement provenance, freshness and appraisal policy. Hardware custody of a signing key alone does not establish that its claims are authentic measurements or that a remote-attestation procedure succeeded. This extension does not define such a procedure. A report states which claims and trust assumptions it actually appraised and does not present producer assertions as independently observed facts.

Receipt Lineage Extensions This section is normative. It defines one OPTIONAL extension field, derived_from, that appears inside the signed payload object and names the parent receipts a derived Action was computed from, together with the lineage reference object that the array carries. The field is registered in . Lineage is a directed acyclic graph over receipts: node and edge identity reuse the SHA-256 and JCS canonicalization already defined in , so this section introduces no new cryptography.

derived_from:

OPTIONAL JSON array of lineage reference objects, each naming one parent receipt by full identity. A producer MUST byte-sort the array by each element's merkle_root member before signing, so that independent producers of the same child compute identical signed bytes. The member sits inside the signature scope of : re-pointing a parent changes the child's signed bytes and so breaks the child's signature. A producer with no parent to name omits the member entirely rather than emitting an empty array.

A lineage reference object carries exactly the four members defined below, and a producer MUST NOT emit any other member inside one. The closed member set is what makes the sort deterministic: an unrecognised member could carry ordering significance that a sorting producer and a verifying consumer would resolve differently.

merkle_root:

REQUIRED JSON string carrying sha256: followed by 64 lowercase hexadecimal characters, holding SHA-256 over the JCS canonicalization of the parent's signed envelope, that is the object carrying the parent's payload and signature members. The parent's anchors member is EXCLUDED from this digest, because anchors are attached after signing and including them would change a parent's identity every time an anchor accrued. This member is the array's sort key.

data_hash:

REQUIRED JSON string in the same sha256: form, holding SHA-256 over the JCS canonicalization of the parent's payload member alone. It binds the parent's signed content independently of the parent's signature bytes, so a consumer holding only the parent's payload can still check the edge.

schema:

REQUIRED JSON string carrying the schema identifier of the parent receipt. The JSON key is the literal schema, case-sensitive.

relationship:

REQUIRED JSON string carrying the provenance verb that relates the child to the named parent, with a value drawn from exactly this set: derivedFrom, parentOf, componentOf, inputTo. The vocabulary is reused verbatim from established content-provenance and provenance interchange work, so the graph carries no verb coined by this document.

A lineage reference binds the producer's parent claim and asserted child time. A resolved parent whose recomputed commitments differ from the referenced values fails that binding check. The reference alone establishes neither parent availability, parent signature validity nor actual derivation. Each is a separate applicable check under . An unresolved parent does not by itself invalidate the child's signature, but prevents full verification when parent resolution or derivation evidence is required by the selected policy ().

Heartbeat and Denial EvidenceA heartbeat is a lifecycle observation with type=protectmcp:lifecycle, action_type=asqav:heartbeat, decision=observation and the no-policy JSON null value of . Its signed heartbeat_interval_seconds is a positive safe integer expressing the declared interval. On a sequenced chain it consumes a sequence number like any other receipt. The first counter value remains one.Silence beyond the declared interval is a coverage/liveness uncertainty and must be compared with the observation window and retained checkpoints. It is not proof of a missing action. A verifier without a trusted later checkpoint cannot infer that a retained prefix has no omitted tail. A locally self-signed denial that never enters the platform chain may lack seq; it MUST be labeled outside platform-sequence coverage and must not satisfy a platform-chain completeness claim.

Capture Coverage and Enforcement AuthorityCapture topology, capture layer and enforcement authority are separate axes. The coverage vocabulary is harness_enforced, framework_callback, in_path_proxy, model_invoked and passive. The name describes placement, not a universal guarantee. An implementation claiming enforcement MUST document the exact harness version, hook family, settings authority, covered actions, deadline and failure policy, and retain evidence for the installed path. A configuration attestation does not itself prove ongoing enforcement or coverage outside that boundary.The Claude Code hook reference distinguishes a timed-out command/HTTP/MCP-tool hook on PreToolUse, which renders no blocking decision, from an Agent SDK callback timeout, which blocks the tool call. The reference defines five handler types, command, http, mcp_tool, prompt and an experimental agent type, and it distinguishes that agent handler from the separately documented Agent SDK callback hook. Its timeout rule names the first three; it does not state the same outcome for a prompt or agent handler. An enforcement claim over a handler whose timeout outcome the reference does not state MUST NOT assume that handler blocks, and MUST identify the handler type it relies on rather than the transport alone. A hook that fails to start falls in the same non-blocking class as a timed-out one: the reference records a non-blocking status for a handler that is missing or not executable, and for most events the action proceeds. An enforcement claim MUST therefore state its startup-failure policy alongside its deadline, because an unstarted hook and a satisfied one leave the same trace in the action's outcome. The reference also documents exit-code and JSON output behavior, and carries version qualifiers on individual fields rather than on a single versioned contract. Implementers MUST use the supported version's actual event semantics and MUST NOT treat every callback as non-enforcing or every in-process hook as unbypassable. Managed settings constrain configuration authority but do not independently establish complete coverage of other execution paths. See .The reference product does not build a model-invoked tool as its enforcement boundary. Observation-only integrations remain useful if labeled accordingly. A remote MCP authorization profile is distinct from a local stdio integration; audience-bound OAuth semantics are specified by for the applicable HTTP transport.

Legal Applicability and Evidence Policy The technical profile can be used in different jurisdictions. The mappings below explain possible uses of its evidence; they do not establish worldwide compliance, legal admissibility, a presumption of truth, or approval by a regulator. A receipt cannot make a prohibited activity lawful. An issuer signature authenticates a recorded statement under a trusted key; it does not establish the truth of every statement. Before applying a legal mapping, the responsible organization identifies the jurisdiction, regulated role, system and activity, affected people, record class, applicable provision, effective date, exemptions and competent authority. It records the source version and the person responsible for that determination. A product label, an issuer-selected regime code or the location of a timestamp server is insufficient to establish applicability. Uppercase requirement words specify this document's technical conformance rules. They do not rank laws or convert an optional profile policy into a statutory duty. Requirements within a legal mapping apply only when that mapping is selected and its applicability has been established. A stricter contractual or organizational policy is identified separately, with its authority and scope. An unresolved applicability question is reported as unknown; it MUST NOT be reported as legal compliance. Retention policy specifies the record class, legal basis, triggering event, calendar period, access restrictions, deletion conditions and any lawful hold. A period measured from a decision, record creation, last use, report submission or end of a relationship is not interchangeable with the receipt's issued_at. Calendar months and years are not replaced by a universal number of days. The applicable law determines the calculation and exceptions. Data minimization, access, correction, erasure and transfer restrictions apply to receipts and supporting evidence where those records contain personal or otherwise protected information. A jurisdiction-specific extension SHOULD publish this applicability information and identify each evidence claim, required input, verification rule, unknown state and limitation. Its conformance examples SHOULD include exemptions, missing evidence, a changed law and conflicting retention or deletion duties. Such extensions do not require a new core receipt format or additional personal data on a public chain. Machine-readable legal mappings remain versioned policy artifacts, not legal conclusions signed into existence.

European Union Bindings Article 113, third paragraph, point (c), of the EU AI Act , as amended by Article 1(40)(b) of , sets the application dates for Chapter III, Sections 1 to 3, except Article 6(5): 2 December 2027 for AI systems classified as high-risk under Article 6(2) and Annex III, and 2 August 2028 for those classified as high-risk under Article 6(1) and Annex I. The Article 12 and Article 26 mappings below concern duties within those sections, subject to the applicable scope and Article 111 transitional provisions. Before the relevant duties apply to a deployment, use of these two mappings is voluntary early adoption. This does not make duties that already apply voluntary.Article 50 generally applies from 2 August 2026 under Article 113, second paragraph. Article 111(4) gives providers of the specified synthetic-content systems placed on the market before that date until 2 December 2026 to comply with Article 50(2); that transition does not defer all of Article 50. DORA has applied since 17 January 2025 under Article 64 of . A selected mapping MUST record its provision, role, scope, application date and relevant exceptions under .

EU AI Act Article 12 Binding Each subsection cites the operative phrase of Article 12 and binds it to the receipt field that provides evidence for it.

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 supporting 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, covers Article 12(2)(a) through (c).

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.

Article 12(2)(b), facilitating the post-market monitoring referred to in Article 72 The hash-chain linkage required by provides evidence for post-market monitoring traceability. The chain head MUST be made available to the Provider and to the competent authority on request.

Article 12(2)(c), monitoring the operation of high-risk AI systems referred to in Article 26(5) When the policy changes, the producer MUST bind subsequent receipts to the policy version used for those records. It retains the relevant policy artifact for the lawful evidence period of the receipts that reference it. A later receipt does not automatically extend retention of every earlier payload or policy artifact indefinitely.A change in policy_digest between two otherwise-comparable Actions may also be examined as a candidate substantial-modification event under Article 43. That reading belongs to Article 12(2)(a), whose binding is in , and is noted here only so the cross-reference is not lost; it is not a 12(2)(c) obligation.

RetentionArticle 12 does not itself set a retention period. Article 26(6) addresses logs under a deployer's control: retention is appropriate to the intended purpose, with a six-month minimum unless applicable Union or national law provides otherwise. Article 19(1) contains a provider-side rule. The responsible organization identifies the role and applicable exception rather than assigning every receipt the same expiry date.For a selected deployer mapping, retention policy MUST identify the log scope, purpose, calendar calculation and applicable legal exceptions. It MUST NOT replace six calendar months with a fixed 183-day or 184-day rule. Supporting proofs and public verification material are retained for the lawful period in which the related evidence must remain verifiable. Sector-specific rules are assessed under and .

EU AI Act Article 26 Binding

Article 26(1), in accordance with the instructions for use policy_digest MUST resolve through to a retained artifact (machine check). The Deployer SHOULD demonstrate consistency with the Provider's instructions for use (process check). Inability to perform the machine check leaves the Article 26(1) obligation unevidenced by this profile; this document creates no evidentiary presumption under Union or national law.

Article 26(2), assign human oversightArticle 26(2) concerns assignment of human oversight to people with the required competence, training, authority and support. A receipt can record an assignment or an observed review. Where an applicable instruction or control requires review before an action, a later review record does not satisfy that prerequisite. Recording that oversight was absent documents a failure; it is not an alternative means of meeting the oversight duty. The organization remains responsible for the required human arrangements.

Article 26(5), monitor the operationFor a selected monitoring mapping, the producer MUST support an Audit Pack for the requested interval within its lawfully retained evidence. The pack states its coverage, known gaps, unavailable records and the basis of its time claims. This capability supports monitoring; it does not replace the deployer's operational, incident-response or notification duties under Article 26(5).

Article 26(6), of at least six monthsRetention under this mapping follows . Any sector-specific rule is assessed for the relevant entity and record class; the profile does not automatically apply a financial-sector duration to every receipt.

EU AI Act Article 50 Binding This binding differs from the Article 12 and 26 bindings above in the one respect that matters on the day this document publishes: those Articles sit inside the high-risk regime that Regulation (EU) 2026/1744 deferred, while Article 50 has applied since 2 August 2026. A reader adopting this profile for AI Act reasons alone is otherwise pointed at obligations nobody has to meet yet, which is why this section exists and why it says so plainly. The duties include informing people, marking output and disclosing certain synthetic content. Receipts can bind evidence about those activities; the statutory duties are not reducible to receipt shape or a timestamp. A producer assertion must be distinguished from observed delivery and independently checked output. A receipt that evidences one of these duties SHOULD declare Article-50 in eu_ai_act_articles (), so that an issuing platform can attest the declaration by the receipt's shape: a protectmcp:lifecycle disclosure receipt for Article 50(1) and 50(3), a receipt carrying result_digest over the emitted or published bytes for Article 50(2) and 50(4). The attestation is to the shape only; it does not assert that a disclosure was understood or that an exception under Article 50(4) applies.

Article 50(1), informing a natural person that they are interacting with an AI system A receipt can record the producer's claimed disclosure time and a reference to the relevant interaction. Evidence that information was presented to the person by the required interaction time is assessed separately. The issuer's issued_at alone does not establish delivery. A relationship to another action is expressed through a defined reference or Audit Pack relationship, not by silently changing the meaning of action_ref.

Article 50(2), marking synthetic output in a machine-readable format The marking duty concerns the output. A result_digest can bind presented output bytes to a recorded claim; it does not prove which system produced them, when the production occurred, or that a compliant marking was applied. Assessment requires the retained output and evidence relevant to the marking requirement. Article 50(2)'s limited transition for systems placed on the market before 2 August 2026 must be distinguished from the general application date, as explained by the Commission guidance.

Article 50(3), informing persons exposed to emotion recognition or biometric categorisation For emotion recognition or biometric categorisation, evidence SHOULD connect the system, disclosure and relevant interaction without repurposing action_ref, which identifies the Action under . The Audit Pack MAY retain an explicit relationship and the disclosure material. A declared issued_at alone does not establish that a person received the information before processing.

Article 50(4), disclosing artificially generated or manipulated content For content constituting a deep fake, and for text published to inform the public on matters of public interest, the Deployer SHOULD emit a Compliance Receipt recording the disclosure, carrying result_digest over the published bytes so the disclosure is bound to the specific content rather than to the publication as a whole. Where an exception in Article 50(4) is relied on, the receipt SHOULD carry a reason code naming it; the issuing platform performs no check that the exception applies, and a verifier MUST report the code as producer-asserted.

Timing, Accessibility and RetentionArticle 50 specifies no general receipt-retention duration. The responsible organization must determine applicable retention and deletion rules rather than infer a universal limitation-period floor from this binding. Paragraph 5 also requires clear, distinguishable and accessible information by the first interaction or exposure. Exceptions and the duties of each provider or deployer must be evaluated under the applicable text; a signed reason code is not proof that an exception applies.

DORA Article 17 Binding

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.

Article 17(2), record all ICT-related incidents and significant cyber threats The hash chain required by 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 with the time bounds supported by the verified construction.

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 , with further specification in . The canonical reporting enumeration to which incident_class flattens is bound by Annex II field 3.23 of (see ). Implementations MUST publish a flattened mapping in the Audit Pack manifest as required by .

RetentionDORA Article 17 requires an incident-management process and records, but does not set a uniform numeric retention period for every receipt. The financial entity identifies the applicable record class and Union, national and supervisory requirements. This profile does not invent a five-year default by analogy to other financial rules.For a selected mapping, the evidence policy MUST state its retention basis and triggering event under . Retained verification material supports the lawful evidence window. A timestamp protocol or a signed chain alone does not establish compliance with DORA's incident-management, classification or reporting requirements.

United States Bindings

NIST AI RMF Binding is a voluntary framework. Adoption of this profile, on its own, does not establish conformity with the AI RMF; it provides a tamper-evident receipt substrate that an AI RMF program can use as evidence under the MEASURE function and as a structured input to the GOVERN, MAP, and MANAGE functions. applies the AI RMF functions to generative AI; the profile bindings below apply to generative and non-generative AI agent deployments alike unless explicitly noted.

GOVERN function The GOVERN function requires that organizations document AI policies and procedures. The combination of policy_digest and the Audit Pack manifest provides a machine-readable binding between every Action and the policy artefact in force at the time of the Action. A change to the policy artefact MUST produce a new policy_digest value (per ); the Audit Pack therefore records every policy change in a tamper-evident manner.

MAP function The MAP function requires that the context, capabilities, and risks of an AI system be characterised. The combination of type, tool_name, action_ref, and iteration_id SHOULD be sufficient for an auditor to reconstruct the operational context of any Action without dereferencing the underlying payload.

MEASURE function Receipt continuity can support risk tracking under the MEASURE function of . Assessing and tracking risks requires additional evidence and organizational processes.

MANAGE function The MANAGE function requires that AI risks be prioritised and acted upon based on projected impact. The risk_class extension field carries the Deployer's risk classification of the Action; together with decision, reason, and policy_digest, it supports prioritisation and incident response without requiring the verifier to re-derive risk from the underlying payload.

Colorado Automated Decision-Making Technology Act (SB 26-189) Binding SB 26-189, , repeals and reenacts Part 17 of Article 1 of Title 6. The reenacted text includes developer documentation duties in Section 6-1-1702 and deployer record-keeping duties in Section 6-1-1703. The main operative date is 1 January 2027, with the upon-passage exceptions in Section 5(2) of the act; Section 5(3) addresses consequential decisions made on or after that date. This mapping concerns the reenacted ADMT duties and does not determine the applicability of the earlier law to earlier activity. SCOPE OF THIS BINDING. It applies only where the Deployer determines that the Agent's Action uses a covered ADMT to materially influence a consequential decision, as those terms are defined in Section 6-1-1701. A receipt recording any other Action carries no obligation under this binding, and a verifier MUST NOT report a Colorado obligation as unmet for a receipt outside that scope. The conditional HIPAA exclusion in Section 6-1-1708(3)(a) applies to the specified sections, subject to its business-associate service limitation, Colorado scope and employment exception. The location and disclosure provisions in subsections (3)(b) through (e) must also be assessed; the exclusion does not remove every duty in Part 17.

Section 6-1-1704(1), pre-use notice The statute requires that "PRIOR TO A DEPLOYER USING A COVERED ADMT TO MATERIALLY INFLUENCE A CONSEQUENTIAL DECISION, THE DEPLOYER SHALL PROVIDE A CLEAR AND CONSPICUOUS NOTICE TO A CONSUMER" that a covered ADMT was or will be used, together with instructions for obtaining the further information the section describes. The Deployer SHOULD record the notice artifact in force as a protectmcp:lifecycle Compliance Receipt carrying the digest of that artefact, emitted before the first covered consequential decision. The digest MUST resolve through . The receipt evidences that a notice artifact of a given content existed and was chained at a given time; it does not evidence that the notice reached any particular consumer, and a verifier MUST NOT report delivery as shown.

Section 6-1-1704(3), post-adverse-outcome disclosure Where a covered ADMT materially influences a consequential decision "THAT RESULTS IN AN ADVERSE OUTCOME FOR A CONSUMER", the statute requires the Deployer to provide, "WITHIN THIRTY DAYS AFTER MAKING THE DECISION", a plain language description of the decision and the role the covered ADMT played in it, instructions and a simple-to-follow process for requesting further information, and an explanation of the consumer rights in Section 6-1-1705. The Deployer SHOULD record the disclosure as a protectmcp:lifecycle Compliance Receipt that references the decision receipt by action_ref and carries the digest of the disclosure artefact. The verifier MAY report the interval between the disclosure and decision receipt issuance times. It MUST report the legal disclosure deadline as unevaluated unless reliable evidence establishes the decision date and actual provision of disclosure. A timely receipt alone does not establish that the disclosure was provided or that its content satisfies the statute.

Section 6-1-1705(1)(a)(II), meaningful human review Following an adverse outcome, the statute entitles the consumer to request, and requires the Deployer to provide, "AN OPPORTUNITY FOR MEANINGFUL HUMAN REVIEW AND RECONSIDERATION OF THE CONSEQUENTIAL DECISION, TO THE EXTENT COMMERCIALLY REASONABLE." Where such a review occurs, the Deployer SHOULD record it as an oversight ruling receipt per , naming the judged decision receipt in judged_action_refs. Section 6-1-1701(15) defines meaningful human review as review by an individual designated by the Deployer who has authority to approve, modify or override the consequential decision, and who considers relevant available primary evidence, is trained to conduct the review, does not default to the system output, and has access to sufficient information to understand the output's intended use, material limitations and categories of inputs, and the principal factors used to generate the output. A ruling receipt alone does not establish reviewer training or independent consideration. Other evidence may support those facts; a verifier MUST NOT infer them solely from the presence of a ruling receipt. The oversight ruling receipt therefore evidences that a ruling was recorded, by whom in opaque form, and the scoped reviewer-authentication result where an attestation was independently validated. The remaining elements remain the Deployer's own responsibility and a verifier MUST NOT report them as satisfied solely from the ruling receipt; any separate evaluation identifies its supporting evidence and limitations.

Section 6-1-1703, deployer record keepingThe cited Colorado enactment distinguishes deployer records measured from a consequential decision from developer records measured from record creation. Its three-year provisions apply to their respective record classes and roles, with longer periods where applicable law requires them. The selected mapping MUST identify the role, statutory trigger, applicability date, exemptions and relevant implementing rules. It MUST NOT substitute a universal 1096-day period from the receipt's issuance time.

Section 6-1-1706, enforcement Section 6-1-1706 provides for Attorney General enforcement through the Colorado Consumer Protection Act. Subsection (3) conditions notice on the Attorney General deeming cure possible and provides a sixty-day cure period after notice, with an exception for knowing or repeated violations. Subsection (3) repeals on 1 January 2030. Part 17 creates no new private right of action and preserves existing rights and remedies. This profile imposes no technical binding on enforcement.

Texas Responsible AI Governance Act (HB 149) Binding Section 1 of enrolled HB 149 names the Act the Texas Responsible Artificial Intelligence Governance Act. The Act takes effect on 1 January 2026. Section 4 adds Texas Business and Commerce Code Subtitle D, including the AI requirements and enforcement provisions discussed here. The selected mapping follows the enacted text of and its applicability conditions.Section 552.104 provides a notice and opportunity-to-cure procedure. An Audit Pack can support evidence about a claimed response, but neither a timestamp nor a policy digest establishes that the violation was cured. Section 552.105 contains conditional defenses. The internal-review route in subsection (e)(2)(D) is qualified by substantial compliance with the most recent NIST Generative AI Profile or another recognized AI risk-management framework. It is not blanket immunity for using this receipt format.

Defence-to-liability evidentiary support The internal-review discovery route in Section 552.105(e)(2)(D) is conditional on the defendant substantially complying with the named NIST Generative AI Profile or another qualifying framework. The discovery route and the defendant's framework compliance are separate factual questions. An Audit Pack MAY support evidence about them; it does not establish entitlement to a defense or a general safe harbor.

Prohibited-use detectionA receipt can record a producer's prohibited-use classification and a deny decision. That classification is an assertion, not a legal determination. The record is retained under the applicable evidence policy and any lawful preservation duty. This profile sets no independent six-year retention floor for Texas deny records.

HIPAA Security Rule Binding (45 CFR Part 164, Subpart C) Under 45 CFR 164.302, covered entities and business associates must meet the applicable Security Rule requirements for a covered entity's electronic protected health information. See . This mapping concerns relevant activity in information systems that contain or use electronic protected health information, including applicable administrative and security activity. An individual action or receipt need not itself contain or directly reference that information.For a deployment in which Asqav performs business-associate functions, this mapping is applied from the business associate's perspective. A deployment selecting this mapping MUST identify whether the responsible organization is a covered entity, a business associate, or both for the relevant activity. That status depends on its functions and legal relationship; signing receipts alone does not determine HIPAA status. Any Colorado exemption is assessed separately under the conditions of Section 6-1-1708(3).

45 CFR 164.312(b), audit controls 45 CFR 164.312(b) requires implementation of "hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information". The combination of type, action_ref, tool_name, and the hash-chain linkage required by provides evidence toward the recording requirement; the verification rules of provide evidence toward the examination requirement. The responsible covered entity or business associate remains responsible for satisfying the audit-control standard across the information systems within its applicable HIPAA scope. 164.312(b) is a standard that carries no implementation specifications, required or addressable; standards are themselves mandatory under 45 CFR 164.306(c).

Security Rule Documentation and RetentionThe six-year requirement in 45 CFR 164.316(b)(2)(i) concerns the documentation required by that rule, measured from creation or the date it was last in effect, whichever is later. It is not a general six-year retention requirement for every individual audit-log record. See the required-documentation categories in 45 CFR 164.316(b)(1) and the retention rule in 45 CFR 164.316(b)(2)(i), .The selected mapping MUST classify each record and apply its actual retention rule. A receipt that references electronic protected health information does not acquire a six-year statutory period merely because of that reference. Other federal, state, contractual or organizational requirements may apply and are recorded separately. This profile sets no additional six-year analogy floor.

NYDFS Cybersecurity Regulation Binding (23 NYCRR Part 500) applies to Covered Entities (NYDFS) operating under New York Banking, Insurance, or Financial Services Law. The bindings below apply only to receipts produced by such Covered Entities.

23 NYCRR 500.6, audit trail Section 500.6 addresses applicable systems for reconstructing material financial transactions and audit trails for detecting and responding to the specified cybersecurity events. Hash chains can support integrity of retained evidence. They do not by themselves satisfy the reconstruction, detection or response requirements. Applicability and exemptions are assessed under the current text.

23 NYCRR 500.17, notices to superintendent 23 NYCRR 500.17(a)(1) requires that "Each covered entity shall notify the superintendent electronically in the form set forth on the department's website as promptly as possible but in no event later than 72 hours after determining that a cybersecurity incident has occurred at the covered entity, its affiliates, or a third-party service provider." The reporting trigger is a Cybersecurity Incident under 23 NYCRR 500.1(g), not any Cybersecurity Event under 500.1(f). For Actions identified as part of such an Incident, the producing system MUST emit incident_class with a value indicating Cybersecurity Incident under 23 NYCRR 500.1(g), and the Covered Entity MUST be able to produce, on request, the chain segment covering the period of the Incident together with the anchor evidence with the time bounds supported by the verified construction.

23 NYCRR 500.6 retentionSubject to the applicable scope and exemptions, 23 NYCRR 500.6(b) distinguishes five years for paragraph (a)(1) financial-transaction records from three years for paragraph (a)(2) cybersecurity audit trails. The selected mapping MUST identify the record class and applicable calculation. It MUST NOT treat every AI-action receipt as both classes or convert the rule into a universal number of days. Section 500.19 exemptions must be assessed for the entity and provision.

SEC Broker-Dealer Recordkeeping Binding (17 CFR 240.17a-4) Rule 17a-4 applies to the broker-dealer records within its scope. Rule 18a-6 governs stand-alone Security-Based Swap Dealers and Major Security-Based Swap Participants; its paragraph (e)(2) technical system requirements apply to entities without a prudential regulator. The 2022 release amended both rules. A selected evidence mapping identifies the entity, record class and operative paragraph rather than applying the same rule to all three classes. See .

17 CFR 240.17a-4(f), electronic recordkeeping system The November 3, 2022 amendments to 17 CFR 240.17a-4 (compliance date May 3, 2023) added an audit-trail alternative at 17 CFR 240.17a-4(f)(2)(i)(A), which stands as an alternative to the write-once-read-many (WORM) limb at (f)(2)(i)(B) rather than as an addition to it. The alternative requires a complete time-stamped audit trail carrying four elements, not one: (1) all modifications to and deletions of the record or any part of it; (2) the date and time of actions that create, modify, or delete the record; (3) where applicable, the identity of the individual creating, modifying, or deleting the record; and (4) any other information needed to maintain an audit trail in the required manner, which "will permit re-creation of the original record if it is modified or deleted". Re-creation is the tail of the fourth element and not the whole requirement. The hash-chain linkage required by together with the retention rule in and the anchor evidence required by provides evidence toward the technical recreation capability the audit-trail alternative requires; the accompanying undertaking obligations (designated-executive-officer and third-party-access arrangements among them) are outside this profile's scope and remain the broker's or dealer's own responsibility.

17 CFR 240.17a-4(a) and (b) retentionRule 17a-4 assigns different periods and accessibility conditions to specified records. Paragraphs (a) and (b) include six-year and three-year classes, with the first two years in an easily accessible place. The selected mapping MUST identify the actual class, triggering event and current rule, rather than impose a receipt-wide 2192-day or 1096-day formula. The 2022 adopting release is a source for that amendment, not a substitute for checking later amendments to the current rule.

CIRCIA: Provisional Evidence MappingUnder 6 U.S.C. 681b(a)(7), the reporting and preservation requirements in paragraphs (a)(1) through (a)(4) take effect on dates prescribed in the final rule; see . This mapping remains provisional because the 13 September 2026 review did not establish an operative final rule. It does not assert a present reporting duty for any particular entity. A regulatory-agenda target for publication is not a published final rule or an effective date.

Incident Evidence SupportAn Audit Pack MAY support preparation of a report by identifying the relevant retained records, known coverage gaps and bounded time evidence. A receipt's declared incident class does not establish that the statutory definition is met. The responsible entity determines coverage, reporting triggers, exceptions, deadlines and required content under the operative rule.

Preservation RuleSection 681b(a)(4) requires preservation under the final rule's procedures, and Section 681b(c)(6) assigns the preservation period to that rule; see . A proposed retention period is not an established current legal floor. A selected mapping MUST identify the operative instrument, applicability date, relevant records, preservation period and exceptions. An organization may adopt a lawful interim policy, labeled as its own policy, without implying that a proposal is law.

Attestation Statements and Authoritative Re-Derivation This section is normative. It defines an attestation statement envelope that the issuing platform emits on top of, and distinct from, the Compliance Receipt envelope of . The receipt envelope of remains the unit that the European Union and United States regime bindings bind to; the attestation statement defined here is an additional, independently verifiable artifact that wraps a claim about an Action (or about a code change) in a form a third party can re-derive from independent evidence. An implementation MAY emit attestation statements in addition to receipts; a Compliance Receipt remains conformant whether or not any attestation statement is emitted. The attestation statement does not modify the receipt envelope, the canonicalization rule of , the signature scope and the hash chain of , or the anchoring rules of .

Attestation Statement Envelope An attestation statement is a Dead Simple Signing Envelope (DSSE, ) whose payload is an in-toto Statement v1 ( ) and whose signature is computed over the DSSE Pre-Authentication Encoding (PAE) of that payload. The envelope and the pre-image are distinct objects and this profile keeps them distinct. The issuing platform MUST emit a DSSE JSON envelope carrying payload (the base64 encoding of the serialized Statement bytes), payloadType, and a signatures array; the PAE never appears in an envelope, and the envelope is not itself signed. The value of payloadType MUST be exactly application/vnd.in-toto+json. Stating it is relevant rather than editorial: the PAE is "DSSEv1" SP LEN(payloadType) SP payloadType SP LEN(body) SP body, so the pre-image depends on the exact octets and the octet length of that string, and a verifier given no value cannot compute the bytes the signature covers. The issuing platform MUST sign PAE(payloadType, serialized Statement bytes) with ML-DSA-65 ( ) under the service identity of ; the signature MUST NOT be computed over any ad-hoc serialization of the statement. The in-toto Statement MUST set _type to exactly https://in-toto.io/Statement/v1, which is the member that identifies it as a v1 Statement, and MUST set predicateType to a versioned value under the asqav predicate namespace https://asqav.com/, of the form https://asqav.com/receipt/<namespace>/<verb>/v1, so the predicate type carries its own major version as requires of a TypeURI. The statement's subject array carries one or more subjects, each identified by an in-toto DigestSet. The DSSE PAE defined by is the signing pre-image and is independent of the JCS rule that governs the receipt envelope of . Two tiers of attestation statement are defined. The tier is a property the issuing platform sets and a verifier reads from the statement; a caller MUST NOT select the tier.

Voluntary (observation) attestation:

The statement's subject digest is a caller-supplied digest. The issuing platform signs the digest the caller supplied without independently re-deriving it. This tier is a voluntary cryptographic attestation: it supplies cryptographic attribution within the authorized signing key's scope (the signature authenticates the platform's assertion of the supplied digest and timestamp; an independent time bound requires separately verified timestamp evidence), but it is explicitly NOT a capture and is NOT unbypassable. The producer-asserted receipts of and are the receipt-layer expression of this tier: the platform signs the producer's asserted values and never re-fetches, re-diffs, re-runs, or otherwise re-derives them. A verifier MUST NOT read a voluntary attestation as evidence that the attested content corresponds to any independently observed fact.

Authoritative attestation:

The statement's subject digest is server-re-derived by the issuing platform from independent evidence, per . The caller-supplied digest, if any, is advisory only and is never the signed subject. This tier is the only tier that supports the independent re-derivation check of .

Authoritative Code-Authorship Re-Derivation This section is normative and is the principal addition of revision -08. For an authoritative attestation whose subject is a code change, the issuing platform (acting as verifier of the change) MUST re-derive the subject digest from the source host rather than trust any client-supplied digest. The canonical re-derivation rule is as follows. The re-derivation input is a commit RANGE, not a single commit. A change authored as a pull request ordinarily carries more than one commit, so a digest computed over the named commit alone would cover only part of the authored change. The issuing platform MUST therefore resolve a base commit identifier for the range before fetching, in the following order, and MUST NOT silently guess one: (a) the base identifier supplied with the attestation request, where it is a full 40-character lowercase hexadecimal object name (this request parameter is distinct from the producer-asserted base_sha receipt field of , which is bound into the signed bytes and never fetched); (b) otherwise the base the source host records for the pull request associated with commit_sha, which the host reports as a field distinct from the merge base (it is the three-dot form of the comparison, stated below, that anchors the diff at the merge base and keeps it stable across merge and squash commits); (c) otherwise, where commit_sha names a parentless commit, the empty tree object name 4b825dc642cb6eb9a060e54bf8d69288fbee4904. Where none of (a) through (c) yields a base, the platform MUST refuse to emit an authoritative attestation rather than infer a base from the commit parents, which are ambiguous for merge and squash commits. Given that resolved base identifier, the named commit identifier commit_sha (the field of ) and the named repository repo_ref, the issuing platform MUST fetch the raw unified diff for the range from the source host (for a GitHub-hosted repository, the REST comparison endpoint /repos/{repo}/compare/{base}...{commit_sha}, whose three-dot form is what anchors the comparison at the merge base of the two revisions rather than at the base revision itself) with the HTTP Accept header set to application/vnd.github.diff, so that the response body is the raw unified diff of that range. The subject digest the platform signs is the SHA-256 digest computed over the exact response bytes returned by that fetch, with no re-encoding, re-serialization, whitespace normalization, or truncation applied before hashing. The digest is carried in the subject entry as an in-toto DigestSet, that is {"sha256": "<64 lowercase hex chars>"}, with the algorithm in the member name and a bare lowercase hexadecimal value. The sha256:-prefixed wire form used elsewhere in this profile is NOT valid in a DigestSet and MUST NOT appear there: it is 71 characters and is not hexadecimal, so a consumer reading the statement as defines it cannot parse it. The prefixed form stops at the receipt layer. Scope of this rule: the canonical re-derivation rule is defined for GitHub-hosted repositories only. It depends on a proprietary, unregistered media type (application/vnd.github.diff) and on GitHub's diff rendering (rename detection, context lines, binary-file stubs), which is not a versioned specification; if that rendering changes, digests signed under the earlier rendering no longer re-derive, which the detection rule below surfaces rather than hides. Repositories hosted elsewhere require a host-specific rule defined on the same principle - fetch the host's raw diff rendering of the range and hash the exact response bytes - and this revision defines no such rule. A client-supplied digest (for example a value the caller placed in change_digest of ) is ADVISORY only under the authoritative tier. The issuing platform MAY compare the advisory digest to the re-derived digest and SHOULD flag a mismatch in the attestation predicate, but the signed subject digest MUST be the re-derived value; the advisory value MUST NOT be substituted for it, signed in its place, or treated as the subject under any mismatch handling. A mismatch is evidence that the client's view of the change diverges from the source host's view; it does not promote the client value to the signed subject. The property reproducibility gives an authoritative attestation is unforgeability, not unbypassability: any third party holding repo_ref, commit_sha, and the base identifier recorded in the attestation predicate can re-fetch the same range from the source host under the same Accept: application/vnd.github.diff rule, recompute SHA-256 over the exact response bytes, and obtain the same digest the platform signed, without trusting the platform and without trusting the client. Reproducibility does NOT make the attestation unbypassable: a client that never requests an attestation bypasses it entirely, and unbypassability is a property of the deployment per , never of this digest rule. The canonical re-derivation rule above is therefore stated precisely so that the recomputation is byte-for-byte deterministic across independent verifiers. Where the source host returns different bytes for the same range at different times (for example after a force-push that rewrites the commit), the re-derived digest changes and the earlier attestation no longer re-derives; this is the intended detection behaviour, not a failure of the rule. The platform MUST record both the commit_sha and the resolved base identifier it re-fetched in the attestation predicate, so that the whole re-derivation input is named and no verifier has to infer the range. A verifier MUST re-derive over the range the predicate names and MUST NOT substitute a range of its own choosing. The signed subject digest is a claim about exactly that range, and it is not a claim that the range covers every change the producer authored.

Capture-Layer Integrity This section is normative. The attestation predicate carries a server-derived capture_layer member that names the independent evidence the issuing platform relied on, and a server-enforced receipt_type member that encodes whether the statement is authoritative or an observation. Both members are set by the issuing platform at signing time; a caller-supplied value for either member MUST be dropped before signing, in the same manner as the server-built fields of . The capture_layer member MUST be derived from independent evidence rather than asserted by the caller. The following values are defined.

github_sha_pull:

The platform re-fetched the raw unified diff for the named commit range from the source host per . This is independent evidence and supports an authoritative attestation.

network_proxy:

The platform observed the Action as routed HTTP egress through a proxy under the deployer's control (the topology catalogued as network_proxy in ). This is independent evidence for the routed egress the proxy actually saw and supports an authoritative attestation for that egress only.

in_process_sdk:

The evidence originates from an SDK linked into the application's own process (the topology catalogued as in_process_sdk in ). This is OBSERVATION only: the evidence is produced by the same process whose behaviour is being attested, so it is not independent. An in_process_sdk capture layer MUST NOT mint an authoritative decision attestation; it yields a voluntary observation attestation only.

passive_telemetry:

The evidence originates from a post-hoc telemetry ingestion pipeline (the topology catalogued as passive_telemetry in ). This is OBSERVATION only and MUST NOT mint an authoritative decision attestation.

The capture_layer vocabulary of this section and the capture_topology vocabulary of are distinct vocabularies at distinct layers: capture_layer names the evidence class an attestation statement relied on (the four values above), while capture_topology names the emission topology of a receipt (six values). Emission topologies with no independent-evidence capture_layer counterpart (browser_extension, ebpf_observer, mcp_proxy) can never mint an authoritative attestation; conversely github_sha_pull is a re-derivation evidence class and has no emission-topology counterpart. A deployment mapping one vocabulary onto the other MUST do so per this paragraph and MUST NOT invent values in either. Within this attestation schema, receipt_type is authoritative only for the independently re-derived evidence paths github_sha_pull and network_proxy; in_process_sdk and passive_telemetry use observation. This classification describes subject-evidence provenance, not all possible enforcement mechanisms. Native harness enforcement is evaluated separately under . If required independent evidence is unavailable, the signer MUST refuse an authoritative attestation or emit a correctly labelled observation. It MUST reject an inconsistent type and layer combination.

Independent Verification Protocol A third party evaluates an attestation using authenticated verification material and independently obtained or retained subject evidence. The checks can require access to a source host or an authorized egress-log export. A network dependency is identified explicitly; protected evidence need not be public. Retained evidence can support offline checks when it preserves the required source binding. Missing evidence is unverifiable, while a demonstrated digest or signature mismatch is invalid.

• Fetch the verification key from the issuing platform's published JWK Set at /.well-known/jwks.json (), narrowing the candidate keys by the signature's keyid where one is present. names this member keyid, makes it OPTIONAL, treats an unset value as set-but-empty, and states that it MUST NOT be used for security decisions because it sits outside the PAE and is therefore unauthenticated; this profile does not override that. A verifier MUST therefore treat keyid only as a hint that orders the keys it tries, and MUST base rejection on the signature failing to verify under every candidate key in the resolved set rather than on the hint failing to resolve. An envelope carries a signatures array and MAY carry more than one signature; a verifier evaluates each. The verifier MUST NOT trust a verification key embedded in the attestation statement itself, mirroring the rule of for receipts.
• Verify the ML-DSA-65 signature () over the DSSE PAE of the in-toto Statement, per . A signature that does not verify under the resolved key MUST cause the attestation to be rejected.
• Re-derive the subject digest from independent evidence using the same canonical rule the platform used: for a code subject, re-fetch the raw unified diff for the range named in the predicate (its base identifier and commit_sha) from the source host under Accept: application/vnd.github.diff and recompute SHA-256 over the exact response bytes per ; for a routed-egress subject, read the deployer's egress log for the observed flow. The verifier MUST require equality between the re-derived digest and the signed subject digest; a mismatch MUST cause the attestation to be rejected.

These checks supplement receipt verification. Successful recomputation establishes agreement with the evidence and source boundary actually checked. It does not prove code authorship, source-host honesty, complete capture or the behavior of an executed artifact. The verifier reports which assertions were independently checked and which remain producer assertions.

Honest Tiering of Capture Claims This section is normative and states, precisely and without overclaim, what each deployment tier does and does not capture. The two product tiers and their honest guarantees are as follows.

SaaS-SDK tier:

This tier produces a voluntary cryptographic attestation per . The attestation supplies cryptographic attribution within the authorized signing key's scope (the signature authenticates the platform's assertion of the supplied digest and timestamp; an independent time bound requires separately verified timestamp evidence), but it is NOT a capture and is NOT unbypassable: the platform signs what the client presents and does not independently observe the client's behaviour. A verifier or regulator MUST NOT read a SaaS-SDK-tier attestation as evidence that the attested action is the complete set of actions the client performed.

Enterprise-proxy tier:

This tier produces a real capture, but only for routed HTTP egress to public model APIs that actually traverses the deployer's proxy, and only when the deployer both firewalls egress so that the model-API traffic is forced through the proxy and configures the proxy and signer to fail closed. Under those deployer-controlled conditions the capture is authoritative for the egress the proxy observed, per the network_proxy capture layer of . The unbypassability of this tier is a property of the deployer's network policy (the firewalling and fail-closed configuration), NOT a property of the product: a deployer that does not firewall egress, or that configures fail-open, has not deployed an unbypassable capture, and the product MUST NOT be represented as providing one in that configuration. This profile does NOT claim, and the Enterprise-proxy tier does NOT provide, host-level capture of arbitrary process behaviour: it does not claim eBPF-based or shell-based capture of actions that do not traverse the routed HTTP egress. The eBPF-observer and passive-telemetry topologies catalogued in remain observation-only evidence classes under and do not mint authoritative attestations.

Service Identity, JWKS, and Revocation Attestation statements use a dedicated ML-DSA-65 service identity, distinct from an agent or deployer identity. Public keys are published as RFC 9964 AKP JWKs with kty, alg and unpadded-base64url pub. The profile uses /.well-known/jwks.json as a documented implementation location; the path is not presented as an IANA registration. The relying party authenticates the origin or obtains a trusted export. DSSE keyid and a JSON receipt's external signature.kid are key-selection hints, not independently signed authority claims. Authorization follows and .Publish historical public keys and authenticated status information sufficient for the retention policy. A verifier MUST distinguish key retirement, revocation, compromise and an unknown status. It evaluates the relevant authorization period using its trust policy and available time evidence. An issuer-declared timestamp alone cannot prove that a signature preceded compromise. A demonstrated authorization violation is invalid; missing reliable historical status is unverifiable. Neither can support full verification. Current rotation alone does not invalidate all earlier receipts.

Audit Pack Composition This section is normative. It defines the contents of an Audit Pack as introduced in , on which the resolution requirements of and depend. An Audit Pack contains the following items.

• The set of Compliance Receipts covered by the requested time window, in the envelope form defined by , preserving each receipt's authenticated representation.
• The chain commitments that link the receipts: for each receipt, the value of previousReceiptHash and the recomputed chain-link digest of its predecessor per .
• The anchor evidence: tokens, OpenTimestamps proofs, or both. Each anchor item MUST be associated, by hash, with the receipt or aggregate it covers.
• The trust anchor metadata that identifies the Deployer or other regulated entity associated with each issuer_id value.
• The verification key material for every kid value present, in a form that does not require online retrieval.
• Vocabularies referenced by reason, risk_class, incident_class, and extension fields, embedded as JSON arrays with a stable identifier. The Audit Pack MUST expose a digest-resolution facility that, given a policy_digest, returns the retained artefact.
• A regime mapping document that names which receipts the producer asserts as evidence under any of the regimes addressed by the EU and US evidence mappings of this document (EU AI Act Article 12, EU AI Act Article 26, EU AI Act Article 50, DORA Article 17, NIST AI RMF, Colorado Automated Decision-Making Technology Act, Texas Responsible AI Governance Act, NYDFS Part 500, HIPAA Security Rule, SEC Rule 17a-4, and the provisional CIRCIA evidence mapping).
• The chain heads valid at the start and end of the time window, signed by the Deployer or other regulated entity.

The deterministic APS gateway fixtures at aps-gateway-enforcement/2-external-verification in the corpus use a public test seed. Their signature covers the whole receipt object minus the signature field, a different scope from the signature scope defined in . A verifier processing a mixed corpus therefore has to select the signature scope by the receipt's format, never assume it. The fixture illustrates a format difference; it does not establish deployment, ecosystem adoption or general interoperability.An Audit Pack MUST carry the signed-bundle construction of . The required fields include bundle_digest, bundle_signature, bundle_signature_algorithm, bundle_public_key and algorithm_registry_version. Their scope and authorization rules are defined locally.The following manifest-level fields SHOULD appear on an Audit Pack bundle when the underlying receipt stream exposes the corresponding semantics. Each is informative and does not alter the wire shape of individual receipts.

regime_mapping_disclaimer:

String emitted on bundles whose per-receipt regime predicates derive from mapping logic the original producing system did not sign. The value identifies the producer of the mapping, the document version under which it was computed, and a disclaimer that the regime-satisfaction flags are advisory and remain subject to the verifier's own check against the EU and US evidence mappings.

stale_pending:

Boolean flag set per bundle entry whose anchor evidence is still pending after the bound of (7 days for OpenTimestamps; synchronous for RFC 3161). When true, the entry has exceeded that bound, which fails a selected policy requiring the upgrade under rather than making the receipt non-conformant on its own, and a Compliance Verifier consumes the flag to drive anchor_valid_* false in its per-axis report (see ). A verify endpoint over the same bundle SHOULD surface stale_pending in its response.

Signed Audit Pack ProjectionThis section defines the JSON bundle construction. The digest and signature cover a projection P of the delivered bundle, not archive-container bytes. P contains exactly these required members: organization_id (string), start and end (RFC 3339 strings), agent_id (string or null), only_compliance (boolean), algorithm_registry_version (string), receipt_count (nonnegative integer), receipts (array of objects), revocation_manifest (array of objects) and regime_mapping (object mapping regime strings to arrays of receipt identifiers). The receipt count MUST equal the array length. Array order and strings are preserved. The interval start MUST NOT be later than end.Each receipt entry referenced by regime_mapping carries a nonempty string signature_id. These identifiers MUST be unique within the bundle and each mapping reference MUST resolve to exactly one entry. For a core receipt entry, extract only payload, signature and, when present, anchors as the receipt envelope. Other entry members are bundle metadata and MUST NOT enter receipt signature, anchor or counterparty calculations. A separately selected historical transport defines its own original envelope boundary.If present and non-null, copy content_disclosure (object), regime_mapping_disclaimer (string), regime_provenance (string), jwks (JWK Set object) and exit_manifest (object) into P. Copy attested_framework_coverage when it is a nonempty object. Absent optional members stay absent; null optional values are not copied. Other bundle members, including the digest, signature, algorithm label and public-key carrier, are excluded from P. A verifier MUST NOT describe an excluded member as authenticated by this bundle signature. New bundles that declare regimes MUST include regime_provenance, stating that regimes_satisfied records signature-gated membership in producer-supplied mapping lists, not independent evaluation or legal compliance. The existing regime_mapping_disclaimer remains a separate signal about missing per-receipt evidence. Historical bundles that omit regime_provenance retain their original projection; a verifier may explain their producer-asserted mapping semantics in its report, but MUST NOT represent that generated explanation as text signed in the historical bundle. Unknown required extensions make full bundle verification unverifiable rather than silently entering the projection.Let B be UTF8(JCS(P)), subject to . bundle_digest MUST equal "sha256:" || lowercase_hex(SHA-256(B)). bundle_signature is a base64 string carrying a pure ML-DSA-65 signature over B with an empty context; it does not sign the digest string or the 32 digest octets. bundle_signature_algorithm is the string ML-DSA-65. bundle_public_key is a base64 string carrying the 1952 public-key octets. For this bundle transport, base64 uses the standard alphabet and padding rules of Section 4; the receipt's signature.sig encoding is a separate field. A legacy transport may document another original encoding without changing retained bytes.The algorithm_registry_version value for the currently defined registry edition is 2026-05-04.v1. It identifies algorithm policy, not a licence to change P or the wire shape. New-revision issuance uses the ML-DSA-65 contract above. An unknown registry edition or a different historical algorithm requires an explicitly selected policy and cannot silently change verification. A revised bundle projection needs its own identified transport revision; it MUST NOT reuse these semantics without disclosing the change. The regime_provenance inclusion rule belongs to this revision of the bundle profile. Its absence in a retained bundle does not establish the bundle's issuance date or profile revision; select historical interpretation from authenticated revision information or an explicitly configured compatibility policy.The verifier recomputes B and the digest, verifies the signature and independently authenticates the bundle signer's authority to export for the named organization. It MUST NOT trust the carried public key solely because it verifies the bundle. Each receipt, timestamp, policy artifact and key-status claim still requires its own applicable verification. The bundle signature proves inclusion of the projected content, not the truth of the assertions or completeness of the export window. Externally resolved artifacts require their own verified digest commitments; a locator is not such a commitment. Required unavailable evidence prevents full verification.The projection above records the selected target contract. Historical bundles retain their original projection and encoding. A flat stored receipt inside a bundle is evaluated under its original receipt format; the bundle signature does not make that receipt conformant to this profile.

Verifier Behaviour A verifier conformant to this profile is referred to as a Compliance Verifier.

Verifier IndependenceVerification of the receipt's signature and other checks for which the holder has the required evidence MUST be possible without asking the issuer to compute or approve the verdict. The profile's verification procedure and required public-key representations MUST be documented. A holder must be able to export lawfully available receipt bytes, proofs and historical public verification material for use by another implementation.Independence does not require unrestricted public access to private records, source code or personal data. A verifier MAY receive protected evidence through lawful access controls or an authorized export. Missing access leaves the affected axis unverifiable; it does not make the evidence false or the available cryptographic checks invalid. An issuer-operated service alone is insufficient if no independent implementation can evaluate the exported evidence.Reproducible verdicts require the same receipt bytes, evidence set, profile revision, verification time and trust policy. Operators with different trust roots or access to different evidence can reach different results. Offline checks use retained evidence; live checks identify their network dependencies. Both report those limits explicitly under .

Mandatory Checks A Compliance Verifier MUST perform at minimum all of the following checks before treating a receipt as a Compliance Receipt, together with the conditional checks of (pending-anchor bound and witness quorum), , , and .

• Verify the signature over the signed bytes defined in , using the permitted algorithm and signing-input rules of .
• Resolve candidate keys from independently authenticated JWK Sets, configured trust anchors or authenticated historical exports under and . The profile documents /.well-known/jwks.json as its key location. A verifier MUST establish the key-to-issuer authorization and algorithm policy independently of the received envelope or bundle. A carried public key alone is not a trust anchor.
• Verify that all fields marked REQUIRED by are present and well-formed.
• Verify the hash-chain linkage by recomputing the chain-link digest of the immediately preceding receipt per and comparing the lowercase hex encoding to previousReceiptHash. An explicit JSON null, an empty string, or an absent member is a malformed chain link, not a genesis marker; the genesis value is the all-zero SHA-256 value of .
• Evaluate presented anchors and any declared witness policy per . Apply the selected relying-party or regulatory-evidence floor, report absent or unvalidated evidence explicitly, and never derive validity from metadata presence.
• Verify the future-skew bound on issued_at per . Past skew MUST NOT cause non-conformance when the receipt is within retention.
• Where the receipt carries expires_at, reject a downstream action that replays that decision after expires_at per ; the receipt itself MUST NOT be rejected solely because expires_at has elapsed. Where the verifier maintains a seen-nonce index, a duplicate nonce under the same issuer_id MUST be flagged as a replay candidate on the reporting axis of .
• Where policy_digest is non-null and required for the selected receipt type, resolve the policy artifact and recompute its defined digest. JSON artifacts use JCS; other formats require an explicit canonical-byte rule. Missing required evidence is unverifiable and a demonstrated mismatch is invalid. The defined no-policy lifecycle path permits null and is reported as not applicable for this axis, rather than as successful policy evaluation.
• Where the receipt carries key_thumbprint per , recompute the RFC 7638 thumbprint of the resolved verification key per and require equality. A mismatch is a key-substitution failure and MUST be reported as non-conformant, never downgraded to a warning or reported as verified. Absence of the field is the legacy case of and is not itself a failure.
• Where a non-null context and payload_digest are carried, select the computation from the signed hash_algo and the versioned contract. For sha256, recompute SHA-256 over JCS(context). For hmac-sha256, recompute HMAC-SHA256 over the same bytes with authorized holder key material. Missing required content or key material makes this axis unverifiable; a demonstrated mismatch is invalid. payload_digest.size is the byte length of that canonical context. Compare the decoded digest bytes to payload_digest.hash, not differently prefixed strings. When context is absent or null, this carried-context consistency check is not applicable; any separate requirement to resolve the underlying commitment is reported under the selected policy. A hash-only commitment does not prove that the issuer saw its input.
• When required by the selected evidence policy, resolve the retained Action descriptor, recompute action_ref under and report the action-descriptor check separately. Missing required descriptor evidence is unverifiable; a demonstrated mismatch is invalid. When the check is not required and is not performed, report it as unchecked, not valid.

A demonstrated mismatch fails its applicable check. Unavailable evidence or unsupported evaluation is reported unverifiable. Both prevent full verification when the axis is required, but neither changes the result of independently evaluable axes. Verification keys carried in an Audit Pack are not automatically trusted. The verifier MUST establish the issuer and key authorization through its configured trust policy, preserve historical key-purpose and revocation semantics, and refuse ambiguous key resolution. Current key rotation alone does not invalidate an earlier valid signature.

Optional Checks A Compliance Verifier MAY additionally perform any of the following.

• Cross-check the issuer_id against an external registry (LEI, EIN, CIK, NPI, GLEIF, or a Deployer-published list).
• Resolve the policy artifact referenced by policy_digest and compare it to a Provider-supplied or Deployer-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.

Reporting A verifier MUST distinguish the signature, schema, chain, digest, key authorization, anchor, witness policy, freshness, replay observation and any applicable extension checks. Each reported axis identifies its input scope, policy and trust material and has a state of valid, invalid, unverifiable, pending, unchecked or not_applicable, with a reason. unchecked means an applicable check was not performed; not_applicable means its applicability condition is false, not that evidence is missing. The receipt-declared witness-policy axis may additionally be undeclared as specified in . Missing evidence, unsupported implementation and an unavailable dependency MUST NOT be reported as a valid check. A structured report SHOULD carry axes, a map from the axis name to an object with status, reason and required, together with the evaluated profile revision, verification time and trust-policy identity. These are verifier-report fields, not new signed-payload members. The required-axis set comes from the selected profile and relying-party policy, not a test fixture or producer's preferred declaration. A report MUST NOT claim full verification when a required axis is invalid, pending, unverifiable, unchecked or undeclared. A fixture testing only the chain axis cannot waive required production checks. Legacy boolean fields such as anchor_valid_ots, anchor_valid_rfc3161 and policy_digest_resolved MAY remain for compatibility, accompanied by the corresponding explicit axis status. A false value must not be interpreted as a demonstrated mismatch when the check was not performed. Likewise, duplicate_emission_candidate=false means no duplicate was found only when an index with a stated scope was actually checked; without such an index the replay-observation axis is unverifiable. In the retained Audit Pack compatibility report, regimes_satisfied lists the keys in the producer-supplied regime_mapping whose receipt-ID lists contain the receipt, and is populated only after the receipt signature check passes. This is signature-gated mapping membership, not independent evaluation of the mapped requirements or a legal-compliance conclusion. Reports MUST label this provenance explicitly. Any independently evaluated technical binding has its own evidence, applicability and per-axis results. Unevaluated applicability remains unknown. The compatibility key colorado_ai is retained; in the mapping revision defined here it identifies the SB26-189 binding in . colorado_admt is the source-register identifier, not a newly introduced wire alias. A mapping identifies its instrument version and relevant decision date; historical signed mappings MUST NOT be relabeled as compliance with a later law. Independent implementations are compared using the same receipt bytes, available evidence, verification time, profile and trust policy. The summary vocabulary in remains separate from per-axis results. A cryptographic mismatch is distinguished from an inability to evaluate. A valid signature can coexist with an unverified overall result. An undeclared witness-policy axis prevents full verification when the selected external policy requires a signed declaration. It MUST NOT be counted as a satisfied quorum. When no declaration is required, the verifier still reports that none was presented.

Verification Verdict and Hash-Algorithm Vocabulary The summary vocabulary is verified, verified_keyed and unverified. It summarizes the required axes selected under . Optional missing evidence is still reported on its own axis. A summary never means that every underlying claim is true or that a legal obligation is satisfied.

verified

All required axes passed. Any context commitment is unkeyed. The report identifies whether the underlying content was actually available and recomputed; signature verification alone does not establish the content.

verified_keyed

All required axes passed and the receipt carries a keyed context commitment. The report states whether the verifier actually recomputed that commitment with an authorized key. Where the selected policy requires recomputation and the key or content is unavailable, the result is unverified, not this state.

unverified

At least one required axis failed or could not be completed. A pending required anchor prevents full verification. An optional pending anchor does not by itself invalidate an otherwise passing summary, and remains pending on its own axis.

hash_algo identifies sha256 or hmac-sha256. Under the retained hash-mode contract, the hash string uses the sha256: prefix for both, while payload_digest.hash is unprefixed. The signed algorithm member, not that historical prefix, identifies the computation. A keyed commitment MUST carry hash_algo=hmac-sha256. Absence means unkeyed only where the selected version explicitly defines that default. Unknown algorithms are unverifiable. Historical bytes are preserved. A holder salt means the secret HMAC key. It MUST NOT be included in a public receipt, anchor or ordinary Audit Pack export. Where authorized recomputation is required, key access is supplied separately under the holder's policy. Destruction of that key does not prove erasure of every source record or identifying link. For a non-passing summary, failure_class distinguishes a demonstrated cryptographic or policy mismatch (invalid) from unavailable evidence or unsupported computation (unverifiable). If both occur, the report retains both per-axis findings and uses invalid for the summary class. A legacy display label MUST NOT override the required-axis result or turn a missing check into success.The retained hosted display vocabulary is a separate compatibility surface: verified, verified_keyed, not_rederivable, pending and failed, alongside a separate boolean verified. The boolean is not a sixth string label. A valid_commitment_not_rederivable detail selects not_rederivable before the boolean is considered. Otherwise a true boolean selects verified_keyed only when the keyed-digest check passes, or verified. With a false boolean, a valid signature, the anchor_pending_no_cryptographic_proof detail, no false counterparty-binding result and no stale-pending indication select pending; other cases select failed. The display mapping does not change the boolean.These compatibility labels MUST NOT be used as a substitute for the required-axis summary. In particular, failed does not distinguish a proven mismatch from unavailable evidence, and not_rederivable cannot satisfy a policy that requires recomputation of the unavailable claim. The hosted keyed check recomputes a mint-time keyed-digest tag with the held holder salt; that check alone does not demonstrate recomputation from the original content. An adapter reports the input surface and version and derives the current summary from actual axis results, rather than renaming failed to unverified and assuming equivalence.

Security Considerations The security requirements are stated in this document: canonicalization and scope validation, issuer/key authorization, compromise and revocation, replay appraisal, privacy, evidence availability and incomplete-chain limits. No external receipt draft supplies additional unstated security requirements. A verifier MUST place its own identity and results in a separate report; adding them to an existing receipt does not authenticate them under the original signature. Unsupported evidence extensions MUST NOT receive a positive assurance merely because they are present.

Tamper Resistance Signatures and chain links expose changes to the committed bytes under their cryptographic assumptions. A signer with a compromised key can create alternative signed history. Independently retained checkpoints and verified timestamp evidence can constrain that attack, but they do not eliminate all rollback or omission windows. The verifier states which history and checkpoint it actually received and the limits described in .

Chain- and Signature-Scope Confusion A verifier that processes more than one receipt format MUST determine the signature scope and the chain-digest scope from the receipt's format before it begins verification, and MUST NOT retry verification under a different scope when the first attempt fails. For Compliance Receipts both scopes are fixed by : the signature covers the JCS-canonical serialization of the payload member, and the chain link digests the predecessor's payload member R. Receipts of the bare format chain over the whole-receipt object including the signature, and the cited APS fixtures sign the receipt object minus the signature field (the APS gateway receipts in the corpus, per ); this profile's receipts are identified by the REQUIRED v member of , per the interoperability note of , and not by the top-level anchors key. A scope-derived verification failure MUST be reported distinctly from an integrity failure under the correct scope: retrying the alternate scope on failure converts a format mismatch into an apparent integrity result, concealing both the wrong-format case and the tampered case from the consumer of the verification report.

Chain Availability Under Single-Linear Per-Agent Serialization This section is informative. The single-linear per-agent chain requirement of serializes receipt emission for a given issuer_id through a single predecessor pointer. A denial-of-service against the predecessor pointer (database row lock contention, network partition between the emitter and the predecessor store, slow IO, or an adversary deliberately holding the chain-tail lock) therefore bounds the per-agent emission throughput, because every new receipt MUST resolve the digest of the immediately prior receipt before it can be linked. A partial-write failure between predecessor-pointer commit and signature commit can additionally produce chain-head ambiguity if not handled defensively. Issuers SHOULD use a bounded predecessor-lookup timeout (operator-tuned, typically on the order of seconds rather than tens of seconds) and SHOULD emit a structured audit event with type protectmcp:lifecycle and a stable reason code (RECOMMENDED: chain_emission_blocked) when the timeout fires, rather than silently dropping the receipt or stalling caller threads. Issuers SHOULD additionally document a chain-head recovery procedure for crashed emitters: on restart, the issuer re-reads the predecessor row, verifies that no orphan signature exists for the next sequence position, and resumes emission. Operators that require parallel per-issuer throughput beyond what a single linear chain sustains MUST use distinct issuer_id values per parallel path, with separate signing keys and chains rooted at the all-zero genesis value, per the rule in . The threat profile here is availability, not confidentiality or integrity: a successful chain-availability attack delays or drops emission, but it cannot tamper with already-emitted receipts (those are protected by ) and it cannot forge receipts (those are protected by ). The chain_emission_blocked lifecycle receipt is itself a Compliance Receipt and therefore links into the chain once emission resumes, so the gap is detectable rather than silent.

Key Compromise On suspected compromise, the responsible operator publishes authenticated key-status information identifying the key, known or suspected compromise interval and affected use. It preserves historical public verification material where lawful and follows for status evaluation.A producer's issued_at cannot by itself prove pre-compromise issuance. A verifier uses the available independent time evidence and its historical authorization policy. A demonstrated unauthorized signature is invalid; insufficient reliable history is unverifiable. An untrusted revoked_at value in a supplied Audit Pack cannot establish revocation or authorize a different key.

Retention and Long-Term VerifiabilityLong-term verification depends on retained receipt bytes, proofs, historical public keys, key authorization records and the applicable trust policy. The retention schedule follows . Implementations SHOULD plan cryptographic renewal and preserve the evidence needed to interpret older formats without rewriting their committed bytes.The omission and rollback limits of are constrained only by checkpoint, witness and anchor evidence that is still available when a verifier needs it. An operator whose completeness claims rely on independently retained checkpoints SHOULD retain that material, together with the inclusion evidence a verifier needs to use it, for at least the retention period of the receipts it covers, and SHOULD keep at least one copy recoverable independently of the log that produced it. A checkpoint recoverable only with that log is not independently retained: the same event removes both, and it then constrains a compromised signer no more than the log's own history does. Loss of that material does not invalidate a retained receipt; it narrows the window in which an omission is detectable, and the verifier reports the narrowed limit rather than claiming complete history.ML-DSA is a digital-signature standard, not an encryption mechanism. Its use can address a post-quantum signature requirement; it does not protect stored personal data from disclosure or prove that the signer was authorized. Algorithm selection and migration follow the relying party's documented threat model and policy. Public verification keys SHOULD remain available for the lawful evidence window even after the private signing key is retired.

PrivacySigned payloads MUST NOT contain raw prompts, tool arguments, credentials or free-text personal data in taxonomy fields. Producers SHOULD minimize stable identifiers and linkable metadata. Digests, public keys, timestamps and opaque references may still identify a person in context; hashing alone does not establish anonymity. See and the distinctions in . Underlying content is stored separately with appropriate access controls, a documented purpose and a lawful retention schedule. Access to a receipt or Audit Pack does not authorize disclosure of its referenced content. Public anchoring SHOULD disclose only the commitment needed for verification. An organization must assess whether even that commitment exposes protected information or creates a restricted transfer. A receipt does not supply consent or a transfer mechanism. A valid erasure, correction or restriction obligation applies to every affected copy within its legal scope, including receipt metadata and backups. This profile does not require retaining a receipt when the applicable law requires its deletion. Where continued retention is lawful, the organization records its basis and minimizes the retained information. A correction may be linked to an earlier record without presenting the earlier statement as current truth. Lawful deletion may leave a verification gap; the verifier MUST report that limit rather than claim complete history. Low-entropy environment identifiers MUST NOT be committed using an unkeyed hash. Where this profile permits hmac-sha256, use a secret, high-entropy key with separation between holders and purposes, following . A so-called holder salt is a secret HMAC key, not a public salt. Its destruction can prevent later digest recomputation, but does not prove that all copies, auxiliary data or identifying links have been erased. The privacy assessment must consider the whole deployment.

Anchor TrustRFC 3161 evidence depends on the selected timestamp authority and its certificate, time and revocation policy. OpenTimestamps evidence depends on its verified commitment path and the selected Bitcoin chain and confirmation policy. Different protocol labels do not establish independent operators. A verifier evaluates the construction and failure assumptions of each witness under ; it MUST NOT count an unverified proof or two labels controlled by one operator as two independent witnesses.The optional tsa_url and operator_id members are producer-supplied metadata. They do not authorize a trust root or network request. The verifier MUST resolve trust independently and MUST NOT fetch a supplied URL merely because it appears in a receipt. Unknown trust material produces an unverifiable anchor axis, not a valid timestamp.

Replay An action_ref mismatch detects a change in the committed Action descriptor. Equality does not establish identical arguments, execution identity or absence of replay. Applicable context commitments, nonces and replay indexes are evaluated separately. The 300-second issued_at skew bound of bounds only future skew: it rejects receipts dated ahead of the verifier's clock and places no lower bound on past skew, so it does not by itself bound the window in which a replayed receipt can be presented as recent. Clock-based replay bounding is available only through the OPTIONAL validity-window fields of : expires_at, which the verifier enforces against replayed decisions, and nonce, which flags duplicate emission where the verifier maintains a seen-nonce index. A receipt carrying neither is bounded only by retention: a replayed receipt whose issued_at lies within the applicable retention window passes the skew check of , and its replay is detectable only through action_ref, chain-link, or index evidence. 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.

Cross-Regime ConflictThe organization determines which laws and policies apply using . It cannot resolve a conflict between laws by comparing this document's MUST and SHOULD words or by always choosing the longer retention period. Legal hierarchy, territorial scope, exceptions, regulatory orders and the actual record class require separate assessment.When an applicable requirement remains unresolved, a verifier MUST report the affected evidence-policy axis as unverifiable. The system MUST NOT claim that all relevant regimes are satisfied. Whether the underlying activity, storage or disclosure may continue is a decision under the applicable law and authority. A minimal conflict record MAY be retained where lawful; this profile does not impose a recursive duty to issue another receipt or a duty to create prohibited records.

Algorithm Agility Historical algorithm acceptance and key authorization follow the selected trust policy, authenticated historical status and available time evidence. The issuer's issued_at assertion alone cannot establish eligibility for an earlier policy. Later retirement or revocation does not automatically invalidate every earlier signature. A demonstrated historical violation is invalid; unresolved authorization is unverifiable.Receipts under this profile are signed with ML-DSA-65 , whose security rests on lattice assumptions, and retention obligations in the regimes this profile addresses run for years. Carrying a single family of hardness assumptions across that window is the profile's principal long-horizon exposure. The hedge this profile intends is to place a second, independent assumption at the periodic-checkpoint layer rather than on each receipt, so that receipts stay lattice-signed while the integrity of retained history can rest on hash assumptions; the checkpoint structure and its verification rules are not defined in this revision. Per-receipt dual signing is out of scope. An SLH-DSA-SHA2-192s signature is 16224 octets against 3309 octets for ML-DSA-65 , roughly five times the signature bytes on an artifact minted once per Action, and the "s" parameter sets are the ones characterises as favouring small signatures rather than fast signature generation, so that size is not bought back in signing speed. Independently, defines eighteen composite combinations and requests their registration and every one pairs ML-DSA with a traditional algorithm; none pairs ML-DSA with SLH-DSA or with any other post-quantum algorithm, so a dual-signed receipt would be defining its own profile rather than following the combinations in that work-in-progress proposal.

Issuer-Misrepresentation Residual Per-agent hash chains under detect tampering inside a single issuer's stream but not the cross-agent attack in which a compromised intermediary silently swaps payload bytes between two honest agents. Both per-agent chains validate; action_ref binds the Action descriptor of , not the peer receipt envelope. Without a cross-agent binding primitive, a regulator obtains no cryptographic answer to "did the acknowledging agent acknowledge the bytes the originating agent actually sent". This profile defines counterparty_binding () as the partial mitigation; the following residuals remain.

• Endpoint collusion. If both signing keys are compromised by the same attacker, the attacker produces a coordinated forgery; no signature scheme defends against this case.
• Intermediary holds the originating agent's key. In hosted-agent deployments where the intermediary possesses the originating agent's private key, it can sign anything as either party. Remote attestation of key origin is the appropriate countermeasure and is out of scope here.
• Originator offline at verification time. requires the originating envelope to be retrievable; if unpublished, offline, or rate-limited, the binding becomes unverifiable (liveness loss, observable as failure).
• Fan-out witness gap. When an originator broadcasts to N acknowledgers, each emits an independent pairwise binding; none witnesses any other. Append-only log profiles (future SCITT-style transparency) are deferred to a later revision.
• Key rotation orphan. If the originating agent rotates keys after emission but before an acknowledger binds it, the storage obligation of still requires the old envelope to remain retrievable; if retention discipline fails, the binding orphans.
• Privacy of envelope hashes. envelope_hash is computed over A's envelope-minus-anchors object, which carries A's signature bytes; an observer of B's receipt learns a stable identifier for A's exact action and therefore can correlate B's behaviour across receipts even when A's payload is otherwise confidential. Where this correlation is unacceptable, a commitment scheme (for example, HMAC over the envelope with a per-counterparty key disclosed only to the verifier) is appropriate; this profile does not specify one.
• Real-time prevention. counterparty_binding is detective, not preventive: B has already accepted the bytes by the time the binding is signed. Verifiers detect tampering only at audit time; the in-flight bytes were not blocked. Where prevention is required, transport-level integrity per is the appropriate primitive in addition to (not instead of) this profile.
• A commitment establishes equality only under its defined framing and byte construction. In JSON framing, whitespace or member-order changes that preserve the JCS representation are not detected. Changed signed values or a different retained signature string change the commitment. This is evidence about the defined representation, not every original transport byte.

Cross-Agent Integrity Trust Boundary This section is informative. It records operator guidance for cases where channel-level protection is the only available defense and counterparty_binding per has not yet been adopted by both endpoints. For channels between named principals, implementers should secure the channel using mutually authenticated TLS 1.3 per ; may use the tls-exporter channel binding per derived via where higher channel uniqueness is required; and may layer HTTP Message Signatures per where intermediaries perform legitimate transformations. Operators must not interpret transport-layer security alone as evidence of cross-agent byte equality. Only counterparty_binding produces application-layer, signed, replay-after-the-fact evidence answering that question. Topologies where the intermediary terminates TLS (CDN edges, MCP servers, message buses, orchestrators) defeat transport-layer integrity against the threat case of ; in those topologies counterparty_binding is the only defence this profile offers, and the absence of channel-binding evidence in the Audit Pack should be documented as a known residual.

Compromised Intermediary Between Two Honest Endpoints This section is informative. Where an Action travels from a sending agent A to a receiving agent B through one or more intermediary processes M, and where M is compromised in such a way that M presents byte sequence X to A and a different byte sequence X' to B, neither A's nor B's cryptographic signature detects the divergence in isolation: each endpoint signs the bytes it observed, and each endpoint's per-agent hash chain per remains internally valid. Absent the counterparty_binding primitive this profile introduces, the only available cross-agent primitive is action_ref as a SHA-256 join key per ; both A's chain and B's chain remain valid in isolation, and divergence is only recoverable through a regulator-driven post-hoc comparison of the two chains. counterparty_binding introduced in closes the case where M silently swaps bytes between two honest endpoints A and B. An acknowledging receipt under this binding is required to carry an envelope_hash computed over the exact byte stream B received (SHA-256(A's envelope) under the digest-scope rule of ), as specified normatively in . A verifier resolves receipt_ref to A's stored envelope, recomputes the digest, and compares; a mismatch indicates that the bytes B signed are not the bytes A signed, and the acknowledging receipt is reported non-conformant per . The binding is detective rather than preventive: it does not stop M from performing the swap in flight, but it produces signed, replay-after-the-fact evidence that the swap occurred. The following residuals remain and are not closed by counterparty_binding alone. The list is intentionally honest about the audit-time, not sign-time, nature of the detective evidence: a verifier resolves receipt_ref to A's retained envelope and recomputes the digest at audit time, so any residual reasoning that depends on "A is not in the loop at sign time" is rhetorical, not relevant.

• Collusion of M and B. If M and B are jointly compromised, M swaps the bytes in flight and B issues an acknowledging receipt carrying an envelope_hash computed over the altered bytes that B signs as if they were A's. Under counterparty_binding the audit-time verifier resolves receipt_ref to A's retained envelope and recomputes the digest, so the binding is reported non-conformant when A's storage is honest and reachable; M+B collusion alone does NOT silently succeed. M+B collusion silently succeeds only when the collusion ALSO extends to corrupting A's retained envelope, suppressing A's chain segment, or making A's storage unreachable to the auditor; that is, the true residual is M+B+(A's-storage compromise or unavailability). Operator mitigation: anchor A's chain on independent witnesses (combined + anchors per , and OPTIONAL deployer-operated transparency logs) so that A's anchored chain-segment digests are independently recoverable from public evidence; regulator-side comparison of A's anchored chain against B's stored chain detects the divergence even when A's local storage is impeached.
• Collusion of M and A. If M and A are jointly compromised, A signs a fabricated envelope at M's direction and M relays it to B; B verifies M's relay normally, B's counterparty_binding correctly digests the bytes A signed, A's per-agent chain validates, and B's per-agent chain validates. Every cryptographic invariant in this profile holds because the binding correctly attests that the bytes B received were the bytes A signed; the fraud is in A's intent, not in any byte mismatch. This residual is fundamentally outside the receipt model's threat surface: no application-layer cryptographic primitive in this profile distinguishes a fraudulent A-signed envelope from an honest A-signed envelope when M is also colluding to corroborate plausibility (relay logs, timestamping, message ordering). Operator mitigation: separation of duties between issuer (A) and intermediary (M) so that the same operator cannot control both signing keys and relay logs; anchor evidence on independent witnesses under different trust roots so that an attacker controlling A and M still cannot retroactively coordinate anchor inclusion across uncolluding timestamping authorities; out-of-band attestation by the regulator or auditor of A's operational context (provenance, code signing, runtime attestation) where the policy regime authorises it.
• Compromise of B itself. A B that has been compromised (private key extraction, supply-chain compromise, or insider operation) can sign any envelope_hash the attacker chooses; counterparty_binding proves only that the signing key acknowledged some bytes, not that those bytes match what an honest B would have observed.
• Loss of A's stored envelope. counterparty_binding requires the verifier to resolve receipt_ref to A's signed envelope; if A's chain segment is unavailable (retention discipline failure, key rotation orphan, deliberate withholding), the binding becomes unverifiable and the receipt is reported non-conformant on liveness grounds rather than on byte-equality grounds. An adversary who can arrange A-envelope unavailability and then re-emit colluding bytes can degrade the binding from a byte-equality check to a liveness-loss flag.
• Anchor stripping by the intermediary. Because the anchors array is outside the issuer's signature, M can remove entries from what it relays, and B sees a receipt carrying fewer witnesses than A emitted. This is a reduction, not a forgery: each surviving entry still re-verifies against SHA-256(JCS(envelope_minus_anchors)), and M cannot fabricate an entry that does so without the cooperation of a timestamp authority or the Bitcoin chain. The visible effect is that a witness_policy quorum A believed it had satisfied may not be satisfiable from B's copy. Operator mitigation: the holder's retained copy and the Audit Pack manifest record the anchors as issued, so a stripped relay is detectable by comparison at audit time rather than by B in flight.

Operators concerned about these residuals in the absence of single-point cryptographic defense should:

• Anchor receipts to multiple independent witnesses. Where both and anchors are present per , a coordinated M-B collusion attack must also induce both timestamping authorities to anchor the colluding bytes within the operator's anchor interval, raising the conjunction-cost of the attack. Operators may add further anchors (e.g. a Deployer-operated transparency log or a witness service) without changing the wire format defined here.
• Use side-by-side chain comparison under regulator subpoena. The audit-trail alternative semantics established for SEC 17a-4 recordkeeping (see ) and the post-market surveillance regime of EU AI Act Articles 12 and 26 (see and ) authorise the regulator to compel both A's and B's Audit Packs and to reconstruct the relay by joining on action_ref per . counterparty_binding reduces the regulator's workload from "compare both chains and detect divergence" to "verify B's bound digest against A's stored envelope"; the underlying subpoena-and-compare workflow remains the regulator's ultimate authority and remains operative when the binding is unverifiable.
• Document M's relay logs out-of-band. Where the intermediary M is identifiable (a named MCP server, message bus, orchestrator, or relay), the operator should require M to produce signed relay logs covering the time window of the Action and should submit those logs to the same Audit Pack production layer as A's and B's chains. Out-of-band relay logs do not require a wire-format change in this profile; they are operational evidence that complements counterparty_binding rather than replacing it.

Detection depends on the selected anchoring schedule, successful commitment, monitoring and availability of the evidence needed for comparison. The selected profile MUST state these assumptions. No fixed detection interval is established here by DORA, NYDFS Part 500 or CIRCIA, and an anchor alone does not guarantee recovery of records that are unavailable.

What a Compliance Receipt Does Not Prove The preceding subsections state the residual attacks case by case. This subsection consolidates the limits of the artifact itself, so that a regulator or auditor appraising a Compliance Receipt does not credit it with guarantees the format does not provide. A Compliance Receipt, even one that passes every check of , does not prove any of the following.

• That the Action was executed, completed, or produced any outcome, or that its effect occurred exactly once. A receipt binds the issuer's recorded claims and committed bytes; it does not independently prove that those bytes passed through a named agent. Timestamp evidence establishes only the time property of its authenticated construction. For example, an RFC 3161 token supports the existence of committed data by the stated time under the TSA trust policy, not the Action's execution at that exact time (). A fresh nonce distinguishes receipt emissions, not effects. The optional duplicate-emission observation under is not a count of executed effects. Effect idempotency is the receiving system's responsibility.
• That two byte sequences are semantically equivalent under a downstream tool. The chain layer checks commitments to canonical bytes under its cryptographic assumptions; keyword case folding, path normalization, Unicode normalization, and numeric tolerance are out of scope per .
• That the policy was correct, lawful, complete or retained. policy_digest commits a digest value. Only resolving and recomputing the artifact under establishes its correspondence to that value; the digest alone proves neither availability nor retention. Policy suitability and retention require separate evidence.
• That the execution environment was intact. The core receipt signature does not establish environment integrity. The optional claims in are appraised separately under an explicit trust policy and remain limited by their provenance and coverage.
• That the issuer has a particular real-world identity merely because a signature verifies. requires independent key-to-principal authorization. The resulting identity assurance is limited by that trust policy and its evidence; an opaque identifier or a self-supplied Audit Pack key cannot establish it.
• That the signing key remained uncompromised, or that the endpoints did not collude. Signature validity is bounded by the revocation discipline of , and the collusion and key-compromise residuals are stated in and .
• That a declared constraint was enforced at runtime. An expires_at claim does not itself stop execution (). The producer-asserted fields in , and bind the producer's assertions, including its asserted time; they do not independently establish those assertions or their timing. A voluntary-tier attestation is not a capture and is not unbypassable ().
• That the Action was prevented in real time. The receipt is detective, audit-time evidence; it does not block in-flight bytes ().
• That the artifact is tamper-proof. Signature and link checks detect changes inconsistent with the presented signatures and commitments. Detecting removal, replacement or re-signed history also depends on independently retained receipts, authenticated checkpoints or anchors under . A self-consistent replacement history cannot be distinguished solely by verifying its newly produced signatures. These checks reveal specified inconsistencies; they do not prevent alteration or omission.
• That the receipt is neutral third-party attestation. The producer's signature binds its claims. Counterparty or environment signatures can bind assertions by separately authorized parties, within their stated scopes, but a separate or unaffiliated signer does not by itself establish independent observation or the truth of every claim. A report identifies the attester, asserted fact, verification scope and trust evidence ().
• That the underlying transaction was delivered, settled or otherwise reached commercial finality. Delivery, settlement and payment finality are out of scope. When cited alongside a payment-gate format such as , the receipt supplies only its stated action-side claims and evidence.
• That every Action produced a receipt. A chain that passes every mandatory check of establishes the checked signature and link relationships among the receipts presented; it is silent about an Action for which no receipt was ever minted. Selective omission is therefore invisible to chain integrity: an omitted Action leaves the chain verifying exactly as it would if the Action had never occurred, because the counter of advances only when a receipt is minted and so cannot register an Action that produced none. Counters reveal internal discontinuities or repeats. Detecting a missing prefix or tail requires an authenticated boundary, checkpoint or independently retained receipt. Where the counter is absent, which stays conformant, a truncated tail is still itself a valid chain, and the anchors of fix the presented receipts in time without revealing that later ones were withheld. Completeness comes from deployment, not from the format. Fail-closed capture () refuses the Action when no receipt can be minted, and an Acceptor () refuses to act on an Action that arrives without a verifiable receipt. The issuer evidences the gaps it can itself observe: a signer outage through unsigned_gap (), and a blocked emission through the chain_emission_blocked lifecycle receipt (). Independent custody of later receipts, whether by a counterparty whose counterparty_binding () digests them, by the Acceptor that gated on them, or by the holder of an Audit Pack () covering them, turns a truncated tail from invisible into contradicted. carries these cases as conformance vectors (asqav-14-omitted-action-chain, asqav-15-unsigned-gap, and asqav-16-chain-emission-blocked); these illustrate that chain integrity alone cannot detect an unrecorded Action and that a signed gap report can remain structurally conformant. Their fixture outcomes are not a substitute for the required checks of a selected production policy.

IANA Considerations This document requests one allocation from an existing IANA registry, and requests no new IANA registry. The allocation is the counterparty_binding CWT claim of , which Section 2 of permits an Independent Submission to request because the registry already exists and the document follows its assignment policy. This Independent Stream document requests no new IANA registry. RFC 8726 generally prohibits new IANA registries for this stream, with a narrow exception for subcode registries tied to an allocated code point. That exception does not establish authority for the standalone tables here. These are externally maintained profile tables. Any future IANA request must satisfy the applicable registration policy and publication procedure. See .Administration therefore sits outside IANA, at , whose registration process is published at . That is a commit-pinned citation of the procedure this document was written against, so a reader can retrieve the exact text; the living procedure is maintained on the repository default branch and a later revision of it does not change what this document specifies. The tables below remain the normative definition of the initial contents; the external registry administers additions and never overrides this document for an entry defined here. A future proposal to move these external tables to IANA would require an explicit registration request under the applicable procedures and approvals. Section 6 of concerns transfer of control of an existing IANA registry between streams; it does not itself authorize migration of these external tables.

Regime Mapping VocabularyThe following identifiers have distinct scopes. They do not establish legal applicability or compliance, and they do not add signed-payload fields.

• colorado_ai: retained compatibility key for the Colorado mapping. In this revision its mapping concerns SB 26-189, as described in . Interpret historical evidence with its recorded mapping revision, legal-source edition and applicable decision date; do not rewrite signed bytes or silently reinterpret an earlier statutory mapping.
• colorado_admt: source-mapping identifier for the SB 26-189 mapping, not a new wire alias for colorado_ai.

Compliance Receipt Extension Fields Registry This table defines the extension fields of this profile. It is administered at the external registry named in under the registry title "Compliance Receipt Extension Fields", and is not a requested IANA registry. This registry covers both signed-payload fields and envelope-level fields (siblings of payload and signature), as well as declarations that govern signing but never appear on the wire; each entry's Scope value identifies which. Each entry contains:

• Field Name: the exact, case-sensitive JSON object key. New names use lowercase ASCII letters, digits and underscore; the initial entry previousReceiptHash preserves its established spelling.
• Scope: one of signed-payload, envelope-level, signing-time declaration, or anchor entry, disambiguating fields inside the signed payload from envelope-level fields, from declarations that are not wire members, and from members carried inside an entry of the anchors array rather than at the top level of the receipt.
• 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.
• Change Controller: the party authorized to request changes to the entry. For the initial entries defined by this Independent Submission, it is the document author identified in the front matter. This designation does not imply IETF ownership or endorsement.

A registration is accepted when the field name does not collide with a common field defined in or a field already present in this table, the Reference is a stable and dereferenceable specification, and the Vocabulary is documented sufficiently for an independent verifier to validate values. These are this external registry's review criteria. They do not appoint an IANA Designated Expert or establish an IANA registration policy. Registrations are made through the published registration process and are reviewed against these criteria in public. Initial registry contents:

• seq - Scope: signed payload. Optional positive integer in the single issuer chain. Continuity exposes an inconsistency within observed evidence; it does not prove withholding or reveal an omitted tail without a later trusted checkpoint. Defined in .
• risk_class - Scope: signed-payload - Risk classification term under the Deployer's risk management documentation; defined in - This document - Vocabulary referenced in Audit Pack metadata.
• incident_class - Scope: signed-payload - Incident classification term spanning DORA Article 18(1) (with further specification in and the canonical reporting enumeration of Annex II field 3.23 of ), 23 NYCRR 500.1 Cybersecurity Event/Incident, Covered Cyber Incident subject to the operative-rule conditions of the provisional mapping in , and HIPAA security incident under 45 CFR 164.304; defined in - This document - Audit Pack metadata.
• counterparty_binding - Scope: signed-payload - Signed-payload object carrying a base64url-encoded SHA-256 digest (envelope_hash) of a peer agent's envelope-minus-anchors object, which includes that peer's signature bytes and excludes its anchors array, a REQUIRED digest-scope declaration (scope, whose only defined value is envelope_minus_anchors and whose absence marks a legacy binding under the superseded three-key scope of revisions -04 through -08), a resolvable opaque locator (receipt_ref), an optional expected-acknowledger identifier (expect_ack_from), and an optional operational transport_label; see for the full member set and the digest-scope rule - This document - Member vocabulary defined in , including the scope value set {envelope_minus_anchors}; digest algorithm is SHA-256 under with base64url encoding per Section 5.
• result_digest - Scope: signed-payload - JSON string in the self-describing form sha256:<64 lowercase hex chars> carrying a SHA-256 digest of the downstream Action's result body. It is not an object and does not carry the payload_digest members size or preview; defined in - This document - Digest algorithm is SHA-256 with hex encoding under the sha256:<64 hex> form.
• expires_at - Scope: signed-payload - RFC 3339 timestamp with an explicit UTC offset declaring the wall-clock time after which the producing system considers the decision result stale and not safe to replay; declared, not enforced, against the receipt itself (the receipt record never expires); defined in - This document - RFC 3339 JSON string with an explicit UTC offset.
• nonce - Scope: signed-payload - Producer-generated string unique across the producer's emission stream for the lifetime of kid; defined in - This document - Any unique string; the lowercase hexadecimal encoding of 12 random bytes (24 hexadecimal characters) is the recommended form.
• hash_algo - Scope: signed-payload - Member of the payload recording how the receipt's context digest was produced; sha256 denotes an unkeyed SHA-256 digest and hmac-sha256 an HMAC-SHA256 keyed digest under a holder salt; the hash-only hash member keeps the sha256:<64 hex> wire form in both cases and the algorithm is read from hash_algo, never from the label; defined in - This document - Value vocabulary {sha256, hmac-sha256} per .
• tool_fingerprint - Scope: signed-payload - JSON string of 32 lowercase hex characters carrying the truncated (first 128 bits) SHA-256 digest of the JCS-canonical () serialization of the JSON object {"tool_name": <tool name>, "schema": <declared input schema>}; defined in - This document - Digest algorithm is SHA-256 over canonical bytes, truncated to its first 32 hexadecimal characters.
• config_manifest_digest - Scope: signed-payload - JSON string formatted sha256:<64 hex> over the canonical bytes of the producer's configuration manifest in effect at signing time; defined in - This document - Manifest content is operator-defined; canonicalization rule is operator-declared in the Audit Pack manifest entry.
• cve_inventory_digest - Scope: signed-payload - JSON string formatted sha256:<64 hex> over the canonical bytes of the producer's CVE inventory at signing time; defined in - This document - Inventory content lists CVE identifiers per the producer's accepted-residual rationale.
• executable_hash - Scope: signed-payload - JSON string formatted sha256:<64 hex> identifying the exact OCI image manifest or observed binary file under the digest and evidence rules of ; defined in - This document - Digest algorithm is SHA-256.
• sbom_digest - Scope: signed-payload - JSON string formatted sha256:<64 hex> over the canonical bytes of the CycloneDX or SPDX SBOM document covering the executing image; defined in - This document - SBOM format, exact version and digest input rule declared in the Audit Pack manifest entry; current-profile JCS and explicit legacy handling are defined in .
• slsa_provenance_pointer - Scope: signed-payload - JSON string carrying an https URL resolving to the SLSA provenance attestation envelope for the build of the executable identified by executable_hash; defined in - This document - Target should be the SLSA Provenance v1.0 in-toto statement form.
• supply_chain_pointer - Scope: signed-payload - JSON string carrying an HTTPS URL for transparency-log evidence concerning the build artifact identified by executable_hash; defined in - This document - Supported log and entry format, artifact binding and authenticated inclusion evidence are checked under the selected verification policy.
• anchors - Scope: envelope-level - Envelope-level array of timestamping anchors covering the signed envelope; entries carry a required type discriminator (rfc3161 or opentimestamps; transparency-log pointers are not anchor types) and a required value field, plus optional informational members status (anchored / pending / failed) and anchor_block_hash (string Bitcoin block hash for upgraded OpenTimestamps entries); full schema is defined in - This document - Anchor type vocabulary: rfc3161 per , opentimestamps per .
• witness_policy - Scope: signed-payload - OPTIONAL quorum declaration with required and distinct operator identifiers in witnesses; authenticated threshold, missing-policy state and independently trusted operator counting are defined in - This document - Profile-specific witness policy.
• mitre_techniques - Scope: signed-payload - JSON array of MITRE ATT&CK technique identifiers (for example T1059, T1078) self-declared by the producer; not verifier-checked by the issuing platform; flips framework_mappings_self_declared to true when populated; defined in - This document - Vocabulary referenced by id from the MITRE ATT&CK enterprise matrix.
• mitre_atlas - Scope: signed-payload - JSON array of MITRE ATLAS identifiers (for example AML.T0051) covering AI-system-specific adversary techniques; self-declared; flips framework_mappings_self_declared to true when populated; defined in - This document - Vocabulary referenced by id from the MITRE ATLAS catalogue.
• owasp_llm_top10 - Scope: signed-payload - JSON array of OWASP Top 10 for LLM Applications identifiers (edition-qualified, for example LLM01:2025; a bare LLM01 is rejected); self-declared; flips framework_mappings_self_declared to true when populated; defined in - This document - Vocabulary referenced by id from the OWASP Top 10 for LLM Applications publication.
• owasp_agentic_top10 - Scope: signed-payload - JSON array of OWASP Top 10 for Agentic Applications 2026 identifiers; the exact edition and identifier convention are defined in ; self-declared; flips framework_mappings_self_declared to true when populated - This document.
• nist_ai_rmf - Scope: signed-payload - JSON array of NIST AI Risk Management Framework function identifiers and subcategories (for example GOVERN-1.1, MEASURE-2.7); self-declared; flips framework_mappings_self_declared to true when populated; defined in - This document - Vocabulary referenced from NIST AI RMF 1.0.
• iso_42001 - Scope: signed-payload - JSON array of ISO/IEC 42001:2023 control identifiers (for example A.6.2.6); self-declared; flips framework_mappings_self_declared to true when populated; defined in - This document - Vocabulary referenced from ISO/IEC 42001:2023.
• eu_ai_act_articles - Scope: signed-payload - JSON array of EU AI Act article identifiers (for example Article-12, Article-15, Article-50); self-declared; flips framework_mappings_self_declared to true when populated; defined in - This document - Vocabulary referenced from .
• rfc3161_timestamp - Scope: signed-payload - JSON string carrying a base64-encoded RFC 3161 TimeStampResp (DER) supplied by the producer at signing time and preserved verbatim on the receipt for offline TSA chain verification independent of any platform-issued anchors; payload entry is an opaque caller-supplied token, not the per-receipt anchor produced by the platform; defined in - This document - Bytes are an RFC 3161 TimeStampResp per ; base64 encoding per .
• framework_mappings_self_declared - Scope: signed-payload - JSON boolean false-attestation guard set by the issuing platform to true whenever any of mitre_techniques, mitre_atlas, owasp_llm_top10, owasp_agentic_top10, nist_ai_rmf, iso_42001, or eu_ai_act_articles is populated; a producer-supplied value of false alongside a populated taxonomy field is overridden by the issuing platform; defined in - This document - Boolean.
• authorized_under_mandate - Scope: signed-payload - Server-built object recording a self-declared authorizing mandate the Action was signed under; carries required mandate_id, required issuer_id, a required scope_digest formatted sha256:<64 hex> over the mandate's authorized-action-types scope, and a required verified boolean whose only conformant value is true, asserting self-declared issuer authority (the same trust level as framework_mappings_self_declared, never issuing-platform-verified third-party authorization); a present-but-malformed object, including one carrying verified=false, is rejected at signing time by the false_mandate_attestation_guard; defined in - This document - Member vocabulary defined in ; scope_digest digest algorithm is SHA-256.
• controls_evaluated - Scope: signed-payload - Server-built object enumerating the enforcement controls that genuinely fired on this sign plus the allow result; member keys are a closed set (emergency_halt, delegation_scope, quorum, mandate, policy, content_scan, result) and an unknown key is rejected; a key is present only when its control ran (omission-over-false attestation), quorum requires fired=true plus a 64-hex attestation_hash, and a policy member asserting evaluation requires matched_count at least 1; a caller-supplied value is dropped before signing (the false_control_attestation_guard); defined in - This document - Control-key vocabulary defined in .
• approver_id - Scope: signed-payload - Producer-asserted identity (bare kid or issuer_id) that authored a risk acceptance on a protectmcp:lifecycle:risk_acceptance receipt; a FIELD bound into the signed bytes with NO authority check, NO authentication, and NO identity resolution performed by the issuing platform, only the string-equality refusal against initiator_id applied to Compliance Receipts (the risk_acceptance_self_approval_guard); required on the receipt type and enforced by the risk_acceptance_missing_required_field false-attestation guard; defined in - This document - Bare-identifier form per .
• judged_action_refs - Scope: signed-payload - Non-empty array of action_ref values naming the receipts an oversight ruling judges; REQUIRED on protectmcp:lifecycle:oversight_ruling and enforced at signing time; an entry that does not resolve is a non-conformance of the ruling receipt and not of any judged receipt; defined in - This document - Values are action_ref digests per .
• ruling - Scope: signed-payload - The human ruling recorded by an oversight ruling receipt; REQUIRED on protectmcp:lifecycle:oversight_ruling and enforced at signing time; defined in - This document - One of confirm, override, escalate, flag.
• ruling_reason - Scope: signed-payload - OPTIONAL machine-readable reason code accompanying a ruling; defined in - This document - Vocabulary referenced in Audit Pack metadata.
• reviewer - Scope: signed-payload - Object naming the natural person who ruled, by opaque principal and role, with an OPTIONAL attestation whose method and evidence record how that person was authenticated; REQUIRED on protectmcp:lifecycle:oversight_ruling; absent attestation, or method manual_assertion, leaves the human-review claim unverified; defined in - This document - method is one of sso, hardware_key, signed_statement, manual_assertion.
• initiator_id - Scope: signed-payload - Producer-asserted identity (bare kid or issuer_id) that requested the acceptance; a FIELD bound into the signed bytes; for a Compliance Receipt a value that string-equals approver_id is refused at signing time by the risk_acceptance_self_approval_guard (a string-incoherence check, not identity resolution; an absent field never fires it); defined in - This document - Bare-identifier form per .
• acceptance_reason - Scope: signed-payload - Free-text producer rationale for accepting a risk; binds the issuer to the recorded rationale and asserted issued_at, never parsed or scored; required on the risk-acceptance receipt type and enforced by the risk_acceptance_missing_required_field guard; defined in - This document - Free-form string.
• accepted_at - Scope: signed-payload - Producer-asserted acceptance-authoring time, encoded as an RFC 3339 JSON string with an explicit UTC offset; distinct from the asserted receipt issuance time and any independently verified anchor time evidence; defined in - This document - RFC 3339 string with explicit UTC offset.
• supersedes - Scope: signed-payload - Producer-asserted pointer (opaque receipt locator OR sha256:<64 hex>) to the prior risk-acceptance receipt this one replaces; binds the supersession claim and asserted issued_at; the issuing platform NEVER invalidates the prior receipt (the recorded signed bytes remain unchanged; this later statement points to the earlier receipt); defined in - This document - Opaque locator or sha256:<64 hex> digest.
• sarif_digest - Scope: signed-payload - JSON string formatted sha256:<64 hex> over the producer-declared canonical bytes of the SARIF scan artifact the acceptance rested on; a producer-supplied commitment whose syntax alone establishes neither the artifact's existence nor its existence at the asserted time; the issuing platform NEVER parses, fetches, re-runs, or validates the scan; defined in - This document - Digest algorithm is SHA-256; canonicalization rule declared in the Audit Pack manifest entry.
• finding_ref - Scope: signed-payload - Producer-asserted opaque free-text pointer to a finding or rule id inside the SARIF artifact; binds the asserted reference and issued_at, never resolved or validated; defined in - This document - Free-form string.
• approval_ref - Scope: signed-payload - Producer-asserted opaque free-text correlation pointer to a human-in-the-loop approval id or external ticket; binds the asserted pointer and issued_at, never resolved or validated; defined in - This document - Free-form string.
• risk_snapshot - Scope: signed-payload - Object carrying a producer-asserted point-in-time snapshot of THIRD-PARTY risk signals (snapshot_at, snapshot_source, optional epss, cvss, cvss_vector, kev_listed, cve_ids); the issuing platform does NOT fetch, compute, verify, query, or vouch for these values, and the snapshot is explicitly NOT reproducible from any input the platform holds; numerics are strings (floats prohibited per ) and snapshot_source is required whenever any of epss, cvss, cvss_vector, or kev_listed is populated (a populated signal without it is rejected at signing time by the risk_snapshot_numeric_requires_snapshot_source guard) so a value can never be read as a platform-derived or verified score; defined in - This document - Third-party feed vocabulary named per-receipt in snapshot_source; the platform defines no controlled vocabulary for the signal values.
• repo_ref - Scope: signed-payload - Producer-asserted opaque pointer to the repository a change was authored against, carried on a protectmcp:lifecycle:code_authorship receipt; required on the receipt type and enforced by the code_authorship_missing_required_field false-attestation guard; free-text, binds the asserted reference and issued_at, never resolved, cloned, or validated by the issuing platform; defined in - This document - Free-form string.
• commit_sha - Scope: signed-payload - Producer-asserted commit identifier of the authored change; required on the receipt type and enforced by the code_authorship_missing_required_field false-attestation guard; bound into the signed bytes only, NEVER fetched or verified by the issuing platform, binds the producer assertion and asserted issued_at; defined in - This document - Free-form string.
• base_sha - Scope: signed-payload - Producer-asserted base commit identifier the change was authored on top of; bound into the signed bytes only, NEVER fetched or verified by the issuing platform; defined in - This document - Free-form string.
• change_digest - Scope: signed-payload - JSON string formatted sha256:<64 hex> over the producer-declared canonical bytes of the change; a producer-supplied commitment whose syntax alone establishes neither the artifact's existence nor its existence at the asserted time; the issuing platform NEVER fetches, re-diffs, or re-computes the change; a value outside the sha256:<64 hex> wire form is rejected at signing time by the change_digest_not_sha256_wire_form guard; defined in - This document - Digest algorithm is SHA-256; canonicalization rule declared in the Audit Pack manifest entry.
• change_ref - Scope: signed-payload - Producer-asserted opaque free-text pointer to the change as a unit (for example a pull-request id); binds the asserted reference and issued_at, never resolved or validated; defined in - This document - Free-form string.
• change_approval_ref - Scope: signed-payload - Producer-asserted opaque free-text correlation pointer to a human-in-the-loop approval id or external review ticket for the change; binds the asserted pointer and issued_at, never resolved or validated; defined in - This document - Free-form string.
• change_class - Scope: signed-payload - Producer-asserted class of the change drawn from the closed vocabulary read, write, delete, execute, deploy; self-declared, the issuing platform records but does NOT verify the change matches the class; a value outside the closed vocabulary is rejected at signing time as an out-of-vocabulary value; defined in - This document - Closed vocabulary {read, write, delete, execute, deploy}.
• authored_by - Scope: signed-payload - Object carrying a producer-asserted description of the authoring agent (agent_id, model_id, model_version, tool, attestation_source); the issuing platform does NOT verify the named model; attestation_source is required whenever model_id or model_version is populated (a populated model field without it is rejected at signing time by the authored_by_model_requires_attestation_source guard) so a model claim can never be read as a platform-verified attestation; defined in - This document - Member vocabulary defined in ; the platform defines no controlled vocabulary for the member values.
• unsigned_gap - Scope: signed-payload - Server-built object evidencing a signer outage that preceded this receipt: count (REQUIRED integer greater than or equal to 1, the number of Actions the issuer attempted to sign and could not while the signer was unavailable), from and to (REQUIRED ISO 8601 timestamps with explicit timezone bounding the outage, with from not later than to). Absent when no outage preceded the receipt. The member is populated by the issuing platform from its own signer-failure tally, never carried in the producer's signing request, and a caller-supplied value MUST be dropped before signing. It makes a gap in the Action stream evidenced rather than silent: the chain links only receipts that exist, so without this member an Action for which no receipt could be minted leaves no trace. A verifier MUST NOT read the member as an assertion that the unsigned Actions were policy-evaluated; defined in - This document - count is a JSON integer; timestamps follow .
• The entries that follow are IMPLEMENTATION MEMBERS. Every one is signed into receipts the reference issuing platform emits today, and each is registered here because a registry that omits what the wire carries understates the signed surface a verifier must preserve byte-for-byte under .
• action_id - Scope: signed-payload - REQUIRED JSON string carrying the issuing platform's identifier for the Action the receipt covers, in the form act_<opaque>. It is an identifier, never a digest, and MUST NOT be read as one; the digest of the Action is action_ref. - This document - Implementation member of the reference issuing platform; carried under the signature on production receipts.
• agent_id - Scope: signed-payload - REQUIRED JSON string identifying the agent within the issuing platform, in the form agt_<opaque>. It is not globally unique and does not establish issuer or key authority. The local meaning applies to every selected receipt type without importing additional fields from another draft. - This document.
• org_id - Scope: signed-payload - REQUIRED JSON string carrying the identifier of the organization the signing agent belongs to, as a UUID. It is an internal tenancy identifier and is NOT the legal-entity identifier a verifier resolves; that is issuer_id. A verifier MUST NOT resolve a key through this member. - This document - Implementation member of the reference issuing platform; carried under the signature on production receipts.
• action_type - Scope: signed payload. Presence is mode-conditioned: required for the defined payload mode; not a member emitted by the defined hash mode. Unsupported or malformed mode combinations are not silently repaired. Defined in .
• context - Scope: signed-payload - OPTIONAL JSON object carrying the Action's input as the producer supplied it. Most receipts omit it and carry only payload_digest, which is the privacy-preserving default; when both are present the recomputation of applies. An explicit JSON null reads as absent. - This document - Implementation member of the reference issuing platform; carried under the signature on production receipts.
• mode - Scope: signed payload. Both core modes use a nested signed payload. Mode determines the required content and digest interpretation; flat legacy inputs use a separately selected adapter. Defined in .
• hash - Scope: signed payload. Hash-mode commitment string. Its digest bytes equal payload_digest.hash under that mode; the former has the retained prefix and the latter is unprefixed. Algorithm interpretation follows the signed hash_algo and selected version. Defined in .
• metadata - Scope: signed-payload - OPTIONAL JSON object carrying operational annotations supplied by the producer or issuing platform. The issuing platform may filter or interpret these annotations before signing. The signature binds the retained object; it does not establish that each annotation is true. - This document - Implementation member of the reference issuing platform; carried under the signature on production receipts.
• decision - Scope: signed payload. Required value governed by the receipt type. Decision types record an actual policy evaluation; defined no-policy types use observation. Defined in .
• policy_decision - Scope: signed-payload - OPTIONAL JSON string carrying the policy engine's own verdict, for example permit. It is the engine's vocabulary rather than this profile's, and a verifier MUST NOT map it onto decision without the producer's documented mapping. - This document - Implementation member of the reference issuing platform; carried under the signature on production receipts.
• receipt_type - Scope: signed-payload - OPTIONAL JSON string mirroring type for implementations that read a distinct member. Where both are present they MUST carry the same value, and a receipt whose two members disagree is non-conformant. This entry registers the receipt payload member ONLY. It is distinct from, and shares nothing but its name with, the server-enforced receipt_type member of the attestation statement predicate defined in , whose value is drawn from authoritative or observation and which never appears in a receipt payload. An implementation MUST resolve the name by the object it appears in. - This document - Implementation member of the reference issuing platform; carried under the signature on production receipts.
• server_timestamp - Scope: signed-payload - REQUIRED on a hash-mode Compliance Receipt and absent from the reference payload-mode receipt, which carries timestamp in its place (see ). JSON string carrying an RFC 3339 timestamp with explicit timezone assigned by the issuing platform for signing. The reference platform assigns the same clock value to this member and issued_at. This is a signed platform-clock assertion, not independent evidence of the Action time or the completion of signing; anchor evidence is evaluated separately under . - This document - Implementation member of the reference issuing platform; carried under the signature on production receipts.
• derived_from - Scope: signed-payload - OPTIONAL JSON array of parent lineage references naming the receipts a derived Action was computed from. Each entry is a lineage reference object as defined in , and the array MUST be byte-sorted by its merkle_root member before signing so that independent producers of the same child compute identical signed bytes. The member sits inside the signature scope of , so re-pointing a parent breaks the child's signature. It is omitted rather than emitted empty when there is no parent. - This document - Implementation member of the reference issuing platform; carried under the signature on production receipts.
• timestamp - Scope: signed payload. Presence and meaning follow the selected mode and version. Do not treat a payload-mode requirement as universally optional or as an independently trusted event time. Defined in .
• previousReceiptHash - Scope: signed-payload - REQUIRED on every receipt including a chain's first, where it carries the all-zero SHA-256 value of ; an absent member, a JSON null and an empty string are each a malformed chain link and never a genesis marker. JSON string carrying the unprefixed lowercase hexadecimal SHA-256 of the predecessor receipt under the chain scope of . The member name is deliberately camel-case, matching the deployed wire, and MUST NOT be normalized to snake case, which would change the canonical bytes and break every signature. - This document - Implementation member of the reference issuing platform; carried under the signature on production receipts.
• tool_name - Scope: signed payload. Required for protectmcp:decision and otherwise governed by the selected type and mode. It is not universally optional. Defined in .
• beacon_ref - Scope: signed-payload - OPTIONAL JSON object carrying the reference platform's cached drand Quicknet beacon reference: source (the string drand), chain (the 64-character lowercase hexadecimal chain hash), round (a positive JSON integer), signature (the 48-byte Quicknet BLS signature, encoded as 96 lowercase hexadecimal characters), and observed_at (an RFC 3339 timestamp recording when the platform cached the response). Its evidence limits are defined in . It is not an anchor and MUST NOT count toward the anchoring requirement or a witness quorum. - This document - Implementation member of the reference issuing platform; carried under the signature on production receipts.
• v - Scope: signed payload. Required nested payload version for the core format. Known shapes and legacy adapters are explicitly selected. A version-2 canary does not define a released production contract, and unknown versions are unverifiable. Defined in .
• tsa_url - Scope: anchor entry - OPTIONAL producer-supplied string naming the timestamp authority an rfc3161 anchor entry was obtained from. It is an operational label only. A verifier MUST NOT fetch it and MUST NOT treat it as a trust decision: a caller-supplied URL naming its own timestamp authority is an assertion by the party being checked, not evidence about it, and trust in a TSA comes from key material the verifier holds independently per - This document - No vocabulary; the value is a JSON string.
• key_thumbprint - Scope: signed-payload - Server-built JSON string formatted sha256:<64 hex> carrying the RFC 7638 JWK Thumbprint of the receipt's signing key, committing the receipt to the exact key material so a key substituted under the same identifier is detected at verification; a caller-supplied value is dropped before signing; verifiers recompute the thumbprint of the resolved key and report mismatch as non-conformant, while absence is the legacy case and not itself a failure; defined in - This document - Digest algorithm is SHA-256 over the RFC 7638 canonical JWK form per .
• environment_attestation - Scope: signed-payload - Normative-optional object carrying pre-action boolean environment-state claims (claims) attested under a distinct environment key (attester_kid, attested_at, detached sig over the attestation object minus sig); informs the policy gate and the Audit Pack evidence list but never replaces the gate; a stale or unverifiable attestation is reported on its own axis; defined in - This document - Member vocabulary defined in ; claim names are free-form booleans.
• heartbeat_interval_seconds - Scope: signed-payload - Positive safe-integer declared heartbeat interval; missing observations do not prove missing actions. Defined in - This document - Profile-specific lifecycle evidence.

This document additionally requests that IANA register counterparty_binding as a new claim in the "CBOR Web Token (CWT) Claims" registry established by Section 9.1 of , with the semantics defined in . The requested claim key is to be allocated by IANA under the Specification Required policy of that registry, from the integer range 256 to 65535 (or equivalently from the range -65536 to -257); this document does not request a specific value, so as not to consume the Standards Action space of the -256 to 255 range. The registration template of Section 9.1.1 is completed as follows.

Claim Name:

counterparty_binding

Claim Description:

Cross-agent envelope binding: an object carrying a base64url-encoded SHA-256 digest of a peer agent's envelope-minus-anchors object, which includes that peer's signature bytes and excludes its anchors array, a REQUIRED digest-scope declaration, a resolvable opaque locator for that envelope, and optional members, as defined in the Counterparty Binding section of the specification document below.

JWT Claim Name:

N/A. The claim is specific to the compliance-receipt envelope of this profile; no equivalent JWT claim exists.

Claim Key:

To be allocated by IANA from the Specification Required range.

Claim Value Type(s):

Map (CBOR major type 5).

Change Controller:

Joao Andre Gomes Marques, the document author identified in the front matter.

Specification Document(s):

This document, the section titled "Counterparty Binding" ().

The JSON-form claim name is the literal string counterparty_binding as registered above in the Compliance Receipt Extension Fields Registry. The environment_attestation field carries the environment-state claims defined in . This document does not define a dedicated RATS attestation-result format. A proposal to add such a format would be reviewed under the external registration process in this section and would need a stable specification of its semantics. No new IANA registry or Designated Expert is created for that purpose. Anchor-entry metadata operator_id, tsa_url, status and anchor_block_hash are scoped to the unsigned anchor object and have the semantics in . They are not additional signed-payload fields or independent trust assertions.

Compliance Receipt Type Namespaces Registry This table defines the receipt type namespaces of this profile. It is administered at the same external registry named in , under the registry title "Compliance Receipt Type Namespaces", and is not a requested IANA registry. 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.

A registration is accepted when the namespace does not collide with any namespace already in this table, and the Reference is a stable specification. As in , these are registration review criteria applied through the published registration process rather than an IANA registration policy. Sub-namespaces are delegated to this registry: a namespace of the form parent:suffix under a registered namespace (for example a further sub-namespace under protectmcp:lifecycle or protectmcp:observation) is registered by a request that names the parent entry and the suffix, under the same registration review criteria and with the same Change Controller as the parent entry. Initial registry contents:

• protectmcp:acknowledgment - A receipt emitted by the acknowledging party ("B") in a counterparty_binding pair under the emitter behaviour of , carrying the counterparty_binding object that digests the bound A-party envelope per - This document.
• protectmcp:decision - A receipt recording a policy evaluation outcome (allow, deny, rate_limit) for an MCP-mediated tool call where a policy was actually evaluated; observation is reserved to protectmcp:lifecycle and protectmcp:observation per - This document.
• protectmcp:restraint - A receipt recording the application of an enforcement restraint on an agent (e.g., quota, rate limit, sandbox tightening); emission otherwise follows the decision path of - This document.
• protectmcp:lifecycle - A receipt recording an agent or system lifecycle event (e.g., configuration change, key rotation, oversight review, or a decision=observation record indicating an Action was signed without policy evaluation per ) - This document.
• protectmcp:lifecycle:configuration_change - A receipt recording a configuration change to an agent or producing system, including changes that disable or re-enable receipt generation (see ); a registered sub-namespace under protectmcp:lifecycle that the reference cloud implementation emits today; a receipt of this type that lacks a well-formed config_manifest_digest () is rejected at signing time per the type-bound presence rule of - This document.
• protectmcp:lifecycle:risk_acceptance - A receipt recording a producer's acceptance of a known risk, security finding, or policy exception; a registered sub-namespace under protectmcp:lifecycle that signs through the no-policy lifecycle path (decision=observation, no policy evaluated) and carries the risk-acceptance extension fields of - This document.
• protectmcp:lifecycle:oversight_ruling - A receipt recording a human ruling made about one or more previously recorded Actions, referencing them by action_ref; a registered sub-namespace under protectmcp:lifecycle that signs through the no-policy lifecycle path (decision=observation, no policy evaluated) and carries the oversight-ruling fields of . Absent a reviewer attestation, the human-review claim it carries is unverified - This document.
• protectmcp:lifecycle:code_authorship - A receipt recording a producer's assertion that an agent-authored change to a code repository existed at a point in time; a registered sub-namespace under protectmcp:lifecycle that signs through the no-policy lifecycle path (decision=observation, no policy evaluated) and carries the code-authorship extension fields of ; the receipt binds the issuer to the recorded change assertion; it does not establish the change's existence or exact execution time, and the issuing platform never clones the repository, re-diffs the change, verifies the code, or verifies the model - This document.
• protectmcp:observation - A receipt recording passive telemetry about an Action that was signed without a policy evaluation, emitted under one of the capture topologies catalogued in (typically network_proxy, browser_extension, ebpf_observer, or mcp_proxy) where the originating application could not call the receipt-emitting SDK directly; the reference cloud implementation rejects at signing time, as the false_attestation_guard, a receipt that declares the passive_telemetry capture topology but carries a type outside protectmcp:observation and its sub-namespaces - This document.
• protectmcp:observation:result_bound - A sub-namespace under protectmcp:observation for a follow-up observation receipt that carries a result_digest () binding the byte-equality of a downstream Action's result to the originating protectmcp:decision receipt identified by action_ref; the reference cloud implementation emits this type for tool calls whose downstream result is regulator-relevant (LLM completions under EU AI Act Article 12, audit-log entries under HIPAA 164.312(b), broker-dealer communications under SEC 17a-4); a receipt of this type that lacks a well-formed result_digest is rejected at signing time per the type-bound presence rule of - This document.

Related WorkThese references explain nearby technical approaches. Published RFCs and W3C Recommendations have the status stated by their publishers. Individual Internet-Drafts are work in progress and do not imply IETF endorsement or consensus. No reference in this section requires adoption of another product or guarantees interoperability.

• describes SCITT transparency architecture. Registration and receipt verification support evidence about registered statements; they do not establish the truth of those statements. This profile also separates issuer claims, evidence availability and relying-party trust.
• describes Certificate Transparency. Its append-only log mechanisms offer a useful comparison for inclusion and consistency evidence, but its certificate-specific semantics do not automatically apply to agent actions.
• and provide the RATS architecture and a message wrapper. Device or environment evidence must be appraised within that trust model; it does not by itself prove which application action occurred. is related work in progress on this composition.
• describes post-hoc action evidence. Its explicit evidence limits and verification states are relevant comparisons. This profile defines its own framing, issuer and chain rules, with timestamp policy under ; no byte-level interoperability is implied.
• addresses screening receipts for agentic payments. This profile supplies action-side evidence; it defines neither payment settlement nor a universal delegation authorization system.
• and address credential exchange and integrity. Wrapping a receipt in another signed format does not replace verification of the embedded receipt or establish the truth of its claims.

Implementation and conformance-corpus references identify inspectable artifacts. A first-party corpus demonstrates the cases it contains; it is not independent certification or proof that every mandatory clause has shipped. External comparisons must identify the versions and trust assumptions used.

Implementation Status This section identifies the reference implementation surfaces for the target design, following . It is removed before RFC publication. Implementation listings are not endorsements. The normative body defines the intended behavior; a release evidence record identifies the exact versions and clauses verified for any particular release.The record distinguishes platform behavior, installed Python and TypeScript entry points, retained historical formats and optional extensions. It records the source revision, package digest, conformance inputs, trust policy, results and independent reviewer. No aggregate test count substitutes for coverage of each applicable clause. This edition makes no claim about paying customers, unlisted implementations or independently reproduced test totals.

Asqav Platform The issuer and hosted verifier maintain the receipt chain, publish authorized verification material and export retained evidence. The implementation follows the selected capture, key, witness and evidence policies.The release evidence record identifies the distributed artifact, license, dependency scope and independently reproduced acceptance. See for the cited source artifact.

Python Verifier The Python verification surface evaluates exported receipts and evidence under an explicit profile and trust policy. Offline operation does not require an issuer account or an issuer-computed verdict.The release evidence record identifies the distributed artifact, license, dependency scope and independently reproduced acceptance. See for the cited source artifact.

TypeScript Verifier The TypeScript verification surface applies the same versioned contract and conformance inputs. Cross-language agreement is evaluated with equivalent evidence and policy inputs; it does not establish organizational independence.The release evidence record identifies the distributed artifact, license, dependency scope and independently reproduced acceptance. See for the cited source artifact.This revision defines Python and TypeScript verification surfaces. A separate WebAssembly verifier is not required. Offline verification claims identify the actual surface, build and supported cryptographic capabilities in the release evidence record.

Acknowledgements The author thanks Tom Farley for , on which this profile is built. This profile would not exist without the field catalogue and envelope structure that the upstream draft defines. The author thanks Anton Sokolov (Tyche Institute) for review of the attestation and validity-window surface and for , and Michael Msebenzi for technical reviews of the published -07 and -08 that corrected the signature-scope and envelope-shape text. The author also thanks the Asqav community for review of early drafts. Acknowledgement of review does not imply endorsement of this document's content by any reviewer named here.

Normative References National Institute of Standards and Technology National Institute of Standards and Technology OpenTimestamps Source revision 3af46432efc4a4c4e7bba439c1f49bce808eb3e5; accessed 12 September 2026. This implementation or project specification is not an IETF standard. ISO W3C in-toto project, a Cloud Native Computing Foundation project Source revision 2dcd055e9f72e746687c306e35f4e59720ff45be; accessed 12 September 2026. This implementation or project specification is not an IETF standard. Secure Systems Lab, New York University Source revision 1d3370f62565bca041e97c8310b873ac340edc2e; accessed 12 September 2026. This implementation or project specification is not an IETF standard. drand Protocol Specification, commit 0a551bdc229a139c1a6862306bcbf0899ee3ea53; accessed 13 September 2026. European Parliament and Council European Parliament and Council of the European Union OJ L 2026/1744, 24.7.2026 European Parliament and Council European Commission European Commission State of Colorado, Seventy-Fifth General Assembly, Second Regular Session State of Texas, 89th Legislature, Regular Session United States Department of Health and Human Services New York State Department of Financial Services United States Securities and Exchange Commission United States CongressUnited States Code, 2024 Edition, Title 6, Chapter 1, Subchapter XVIII, Part D, Section 681b. Official GPO source read 13 September 2026. The edition marker was read from the govinfo granule metadata record (accessId USCODE-2024-title6-chap1-subchapXVIII-partD-sec681b, baseEditionYear 2024, isCurrentEdition true); the section PDF itself carries no edition string. Access route: the citation resolver https://www.govinfo.gov/link/uscode/6/681b redirected to this edition-pinned granule on that date. The resolver is not version-pinned and will move to a later edition once one is published, so the granule above is the citation of record. The corresponding House U.S. Code section URL was attempted but retrieval timed out; the successful GPO access is recorded separately. United States Congress National Institute of Standards and Technology Informative References IETF LAMPS Working Group Work in Progress. Citation does not imply IETF endorsement or publication as an RFC. National Institute of Standards and Technology Work in Progress. Citation does not imply IETF endorsement or publication as an RFC. Tyche Institute Work in Progress. Citation does not imply IETF endorsement or publication as an RFC. Headless Oracle Work in Progress. Citation does not imply IETF endorsement or publication as an RFC. Asqav ScopeBlind AnthropicAccessed 12 September 2026; runtime-specific behavior is version-dependent.Model Context Protocol contributorsAccessed 12 September 2026; runtime-specific behavior is version-dependent. W3C W3C European Parliament and CouncilOfficial source; accessed 12 September 2026.Information Commissioner's OfficeOfficial source; accessed 12 September 2026.Chrome for DevelopersOfficial source; accessed 12 September 2026.Chrome for DevelopersOfficial source; accessed 12 September 2026.RFC EditorOfficial source; accessed 12 September 2026. Work in Progress. Citation does not imply IETF endorsement or publication as an RFC.

Worked Examples (Informative) This appendix shows two receipts and one member. The first receipt is a Compliance Receipt exactly as the reference issuing platform emitted it in production on 2026-09-04 (signature identifier sig_XcmE-To6pSVUUJI6SUGx9g, issued under the platform operator's own organisation): a hash-mode protectmcp:lifecycle receipt signed with ML-DSA-65, carrying seq 63, a key_thumbprint, and both anchor types, with the OpenTimestamps commitment upgraded to Bitcoin block 965451. It is published byte-exact, with its seq 62 predecessor and the key set that resolves it, as conformance vector asqav-24-anchor-block-hash-prod in the receipt corpus (verifier/conformance-vectors/) of , so every value below can be checked against the bytes. The second receipt is illustrative: a payload-mode protectmcp:decision receipt for the binding, carrying the member set the reference implementation emits in payload mode, with abbreviated values and placeholder signature and anchors. The third fragment shows the counterparty_binding member of , which no production receipt carried on 2026-09-04 and which is therefore shown separately and marked illustrative. Rendering conventions, both examples: members appear in JCS-canonical lexicographic order (), which is the byte order the signature and every digest of this profile are computed over; digest-valued strings are shown as their first sixteen and last eight hexadecimal characters joined by an ellipsis; the three long base64 values of the first receipt (the signature, 4412 characters; the RFC 3161 token, 6528 characters; the OpenTimestamps proof, 1772 characters) are elided with their lengths stated, and every other value of the first receipt is verbatim.

A production receipt, byte-exact in the corpus The receipt: { "anchors": [ { "type": "rfc3161", "value": "<6528 base64 characters, elided>" }, { "anchor_block_hash": "0000000000000000...6499b499", "status": "anchored", "type": "opentimestamps", "value": "<1772 base64 characters, elided>" } ], "payload": { "action_id": "act_yDx9hcwMgBqewK1mktn1Fg", "action_ref": "sha256:b15eeb40a51b1a0d...a1908488", "agent_id": "agt_uJgllxkGt5xQ6Xks", "decision": "observation", "hash": "sha256:b15eeb40a51b1a0d...a1908488", "hash_algo": "sha256", "issued_at": "2026-09-04T07:20:51.935103Z", "issuer_id": "f94f66c0-c580-432d-a041-29374f7aee07", "key_thumbprint": "sha256:5b98a75dd05ba63d...8ad848bb", "metadata": { "heartbeat_description": { "idle_seconds": 3617, "interval_seconds": 3600 } }, "mode": "hash", "org_id": "f94f66c0-c580-432d-a041-29374f7aee07", "payload_digest": { "hash": "b15eeb40a51b1a0d...a1908488", "size": 45 }, "policy_digest": "sha256:5ad43b4f60033435...836e467c", "previousReceiptHash": "1149a5d06a774a3c...48f4f5f7", "seq": 63, "server_timestamp": "2026-09-04T07:20:51.935103Z", "type": "protectmcp:lifecycle", "v": 1 }, "signature": { "alg": "ML-DSA-65", "kid": "f94f66c0-c580-432d-a041-29374f7aee07", "sig": "<4412 base64 characters, elided>" } } The key set entry it resolves to, as published at the platform's /.well-known/jwks.json (). The pub member is the raw ML-DSA-65 public key, 1952 bytes, in unpadded base64url; recomputing SHA-256 over the JCS form of {"alg","kty","pub"} from this entry reproduces the receipt's key_thumbprint (). { "agent_id": "agt_uJgllxkGt5xQ6Xks", "alg": "ML-DSA-65", "issuer_id": "f94f66c0-c580-432d-a041-29374f7aee07", "key_thumbprint": "sha256:5b98a75dd05ba63d...8ad848bb", "kid": "YS-AwmqpURR7omdnBsGU0A", "kty": "AKP", "org_id": "f94f66c0-c580-432d-a041-29374f7aee07", "pub": "<2603 base64 characters, elided>", "status": "active" } What an offline verifier establishes from these bytes and this key set, and what it cannot:

• Signature: ML-DSA-65 over the JCS serialization of the payload member verifies under the published key. The kid in the signature object carries the issuing organisation's identifier on the hosted tier; the signing key is selected through the signed agent_id and confirmed by key_thumbprint, so a key substituted under the same identifier is detected ().
• Chain: SHA-256 over the JCS serialization of the predecessor's payload member equals previousReceiptHash (), and seq 63 follows the predecessor's 62 with nothing withheld between them ().
• payload_digest: This receipt carries no context, so the recomputation of does not apply; the separate hash member holds the self-describing fingerprint of the Action, and hash_algo records how it was produced.
• Anchors (): the RFC 3161 token binds the envelope-minus-anchors digest and verifies only against the issuing TSA's key material; the OpenTimestamps proof carries a Bitcoin attestation at height 965451 and completes only against a Bitcoin header source. The corpus ships neither, so a conforming verifier run on the corpus alone reports the anchoring axis as unverifiable rather than failed, and reports status and anchor_block_hash as the informational members they are. With a header source, the block whose hash is the anchor_block_hash shown is the one the proof resolves into.

An illustrative decision receipt for the Article 26 binding This synthetic example illustrates a payload-mode decision receipt. Values are placeholders or abbreviated, and it is not a cryptographically valid test vector. It MUST NOT be replayed or trusted. Reproducible conformance vectors require complete source-bound bytes, keys, expected results and the selected verification policy. { "payload": { "action_id": "act_5f4nc7MqiGHwN5_RRgOXqw", "action_ref": "sha256:fc9deb0c3dc4acf2...e8482781", "action_type": "tool_call", "agent_id": "agt_DAsgntrbV_VAIBbl", "context": { "tool": "deploy", "target_digest": "sha256:3c0f1a...9e21" }, "controls_evaluated": { "content_scan": {"blocking": false, "ran": true}, "emergency_halt": {"checked": true, "halted": false}, "policy": {"evaluated": true, "matched_count": 1}, "result": "allowed" }, "decision": "allow", "expires_at": "2026-09-02T21:17:18.504801Z", "issued_at": "2026-09-01T21:17:18.504801Z", "issuer_id": "00000000000000000098", "iteration_id": "task-2026-09-01-01a3", "key_thumbprint": "sha256:8fd93ce505a84acf...d405c1e2", "mode": "payload", "nonce": "59d1668bab924760317f4c39", "org_id": "f94f66c0-c580-432d-a041-29374f7aee07", "payload_digest": { "hash": "0a44d2c8e3f5b7a9...e7f9b2a4", "size": 61 }, "policy_digest": "sha256:7eb08c4ee16e9744...51935a1c", "previousReceiptHash": "3fd8f9f8093db756...d5618f38", "reason": "policy:within_limits", "risk_class": "deployer:financial:medium", "sandbox_state": "enabled", "seq": 10, "timestamp": "2026-09-01T21:17:18.504801Z", "tool_name": "deploy", "type": "protectmcp:decision", "v": 1 }, "signature": { "alg": "ML-DSA-65", "kid": "00000000000000000098", "sig": "<4412 base64url characters, placeholder>" }, "anchors": [ {"type": "rfc3161", "value": "<placeholder>"}, {"type": "opentimestamps", "value": "<placeholder>", "status": "anchored", "anchor_block_hash": "<64 lowercase hex, placeholder>"} ] } The example illustrates these profile fields:

• issuer_id resolves through the trust anchor metadata in the Audit Pack to the named Deployer (shown here as a 20-character ISO 17442 Legal Entity Identifier; the reference platform's hosted tier emits the organisation identifier, as the first example shows);
• policy_digest resolves to a retained policy artefact and controls_evaluated records which controls ran, per the false-attestation guard of the extension registry;
• sandbox_state records the producer's sandbox assertion. It does not establish an OS boundary or satisfy a statutory sandbox requirement.
• previousReceiptHash and seq link the receipt into the chain per and ;
• both an RFC 3161 anchor and an OpenTimestamps anchor are present per .

For each selected legal mapping, the verifier checks the applicable record-specific evidence policy and reports unavailable evidence or unresolved applicability. Incident classification is checked only where that mapping applies. These technical checks do not establish legal compliance.

The counterparty_binding member (illustrative) When agent B's receipt binds agent A's receipt, B's signed payload carries the member below (, ): receipt_ref names A's receipt, envelope_hash is the base64url SHA-256 digest of A's envelope-minus-anchors object as A served it, and scope declares that digest scope. The fragment is illustrative and makes no claim about production issuance. "counterparty_binding": { "receipt_ref": "sig_ptqHVATi_BiVw8I4ASihcA", "envelope_hash": "<43 base64url characters>", "scope": "envelope_minus_anchors" }

Change LogThis appendix records the scope of the local working revision. Earlier editorial detail remains in the preserved source revision and its audit archive. It is historical, not an additional set of conformance requirements. Remove this appendix before RFC publication.

Changes in draft -09The local 12 September 2026 reconciliation clarifies wire and digest scopes, version handling, optional anchors, signed operator-based witness policy, capture limits, heartbeat evidence and per-axis unknown results. It removes unsupported legal retention floors and evidence guarantees, corrects legal applicability and privacy rules, and revises reference status and language. These changes describe target behavior pending implementation acceptance.This edition makes the receipt definitions, Action-descriptor digest, signature contract, signed Audit Pack projection, key trust and extension rules self-contained. ACTA remains an informative antecedent. OpenTimestamps, DSSE and in-toto remain technical dependencies; drand is pinned and normative for the selected beacon verification feature. Catalogue-only APKI, AML, AAT and delegation references are removed, and fixture claims are limited to the cited corpus. These specification changes require implementation and vector reconciliation; this note is not a claim that those checks have passed.The base profile recommends timestamp anchoring with SHOULD so that issuance and offline evidence retention do not depend on immediate access to an external timestamp service. A selected binding or relying-party policy can require an anchor and then withhold full verification while it is pending. This choice does not require a particular hosted service tier or establish a statutory timestamp requirement. The signed-optional witness-policy design binds any producer-declared quorum to the receipt while allowing relying parties to impose stronger external requirements; absent declarations are reported explicitly rather than assumed satisfied.

Changes in draft -08Historical revision. Its changes are incorporated only to the extent retained in the current normative body; superseded wording does not govern this revision.

Changes in draft -07Historical revision. Its changes are incorporated only to the extent retained in the current normative body; superseded wording does not govern this revision.

Changes in draft -06Historical revision. Its changes are incorporated only to the extent retained in the current normative body; superseded wording does not govern this revision.

Changes in draft -05Historical revision. Its changes are incorporated only to the extent retained in the current normative body; superseded wording does not govern this revision.

Changes in draft -04Historical revision. Its changes are incorporated only to the extent retained in the current normative body; superseded wording does not govern this revision.

Changes in draft -03Historical revision. Its changes are incorporated only to the extent retained in the current normative body; superseded wording does not govern this revision.

Changes in draft -02Historical revision. Its changes are incorporated only to the extent retained in the current normative body; superseded wording does not govern this revision.

Changes in draft -01Historical revision. Its changes are incorporated only to the extent retained in the current normative body; superseded wording does not govern this revision.

Changes in draft -00Historical revision. Its changes are incorporated only to the extent retained in the current normative body; superseded wording does not govern this revision.

Capture Topologies for Compliance Receipt Emission This appendix describes deployment patterns and their limits. Placement alone does not establish payload visibility, identity, enforcement or complete capture. Each implementation documents the actual transport, permissions, configuration and failure behavior. The coverage requirements in are normative; the topology examples are informative.capture_topology MAY appear as an informational Audit Pack attribute. It does not change the receipt signature or authorize a stronger verification claim. A new topology needs an explicit evidence mapping rather than an assumed IANA registration.

In-Process SDKAn application may link the receipt SDK and invoke it in the action path. The application process is the trust boundary; sibling or alternative execution paths are outside that coverage unless separately controlled. Captured fields depend on the configured privacy mode, and a digest does not imply the SDK retained full request or response content. Enforcing callbacks and passive callbacks must be distinguished by their documented native semantics under .

Network-Layer Egress Proxy An in-path proxy records the traffic that actually passes through its supported transport. TLS payload visibility requires an applicable termination or application integration; DNS rewriting or an SNI router alone does not decrypt payloads or prove that alternate routes are blocked. Certificate pinning and encrypted handshake metadata can constrain visibility.Vocabulary value: network_proxy. Coverage depends on routing, identity binding and the deployment's failure policy. A proxy record attests to what the proxy observed. It does not by itself identify the initiating employee or prove that every application used the proxy. Sensitive network identifiers remain subject to .

Browser Extension A browser extension can observe or instrument supported page activity within its granted permissions and execution contexts. Content scripts normally run in an isolated world; intercepting page-defined functions requires a deliberately designed integration. Extension APIs and permissions do not imply access to every response body, stream, frame or browser session.Vocabulary value: browser_extension. The implementation declares which requests and fields it captures, when instrumentation begins and which contexts are excluded. Installing an enterprise certificate authority is not a general prerequisite for content-script access to page data and does not establish complete capture. A separate network interception design has separate TLS requirements. See and .

eBPF SNI Observer A host sensor can record the kernel events and metadata exposed by its installed probes and permissions. Available fields depend on the operating system, probe placement, application transport and encryption. Encrypted ClientHello can conceal the inner server name; see . A connection event alone does not prove that a particular model call occurred or identify the responsible employee.Vocabulary value: ebpf_observer. The report distinguishes observed process or connection metadata from inferred activity. It does not claim prompt or response visibility without a separate demonstrated capture path. This topology is an observation pattern, not proof of complete host enforcement.

MCP Transparent Proxy An MCP proxy observes messages that traverse the transports it implements. It declares the protocol revision, request and response coverage, identity source and authentication boundary. HTTP authorization and local stdio credentials are distinct deployment concerns under .Vocabulary value: mcp_proxy. A proxy may record a request and its observed response. Two receipts signed only by that proxy remain two proxy assertions; they are not independent endpoint acknowledgements and cannot expose a proxy that deliberately fabricates both. A counterparty binding supplies independent evidence only to the extent that the peer's independently authenticated signature and scope support it. Bypassed traffic and unsupported methods remain outside the measured coverage.

Passive Telemetry Ingestion A passive ingestion pipeline reads structured records the originating application or its runtime has already emitted (for example, OpenTelemetry spans, application access logs, vendor-managed observability exports, or batch CSV drops) and synthesises a Compliance Receipt for each record after the fact. The synthesiser holds the signing key, applies the receipt-format wire profile, and emits the receipt to the same downstream sink that the in-process SDK and network-proxy paths feed. Vocabulary value: passive_telemetry. Trust boundary: the telemetry pipeline operator's signing key plus the integrity of the upstream observability source; the receipt binds the producer of the telemetry, not the originating application's per-request principal. Threat-model note: captures whatever the upstream telemetry source preserved (typically a subset of the action's bytes and metadata, often without request or response payload) plus the wall-clock and counterparty identifiers visible in the telemetry record; does NOT capture data the upstream source dropped, sampled out, or never emitted, and inherits any tampering risk the upstream source carries between emission and ingestion. Useful when the in-process SDK, network proxy, browser extension, eBPF observer, and MCP proxy topologies are all operationally infeasible (legacy applications without instrumentation hooks, third-party SaaS with read-only export, fleet migrations where the producer has only logs to work from) but the operator still needs a signed evidence artefact tied to the historical action. Reference implementation hint: any OpenTelemetry collector exporter feeding a conformant receipt-emitting signer; the upstream telemetry source is out of scope of this profile.

capture_topology Vocabulary and Considerations for a Future IANA Registry The six values defined in this appendix (in_process_sdk, network_proxy, browser_extension, ebpf_observer, mcp_proxy, passive_telemetry) form the closed initial vocabulary for the capture_topology attribute. The attribute is optional at the wire layer and, where present, appears only in the Audit Pack manifest entry for the receipt, never inside the signed payload object, so that the topology declaration is producer-side metadata that does not alter the receipt's signed bytes. A verifier must not treat the absence of a capture_topology attribute as a non-conformance condition: absence simply means the producer did not declare a topology, and neither nor lists the attribute among the verifier's checks. This Independent Stream document requests no IANA action for capture_topology. RFC 8726 generally prohibits new IANA registries for this stream, with a narrow exception for subcode registries tied to an allocated code point. That exception does not establish authority for the standalone tables here. These are externally maintained profile tables. Any future IANA request must satisfy the applicable registration policy and publication procedure. See .

Regulatory Currency and Verification DatesThis appendix is informative. Sources and their applicability must be checked when this draft is revised and before a deployment selects a legal mapping. A successful link check is not a legal review, and an inaccessible page is not evidence that the law has not changed. The local audit preserves a separate reference inventory with retrieval results and source hashes; this draft makes no claim that a scheduled source-monitoring service has been implemented.The 12 September 2026 review checked official EU AI Act and amendment text, the Commission's Article 50 guidance, DORA, official Texas legislation, the NYDFS amended rule, the SEC 2022 adopting release, HHS Security Rule guidance, RFC publications and current native integration documentation. Some sources required an alternate official access path. ISO catalog pages establish publication metadata, not a reading of the full paid standards. During that 12 September review, eCFR access was restricted; the SEC release and HHS guidance do not establish the absence of later amendments.CIRCIA remains provisional in this draft because this review did not verify an operative final rule. Colorado's implementing rules and effective-date conditions require a final check before the mapping is used. The current legal text and applicable exceptions control over any summary here. This is a bounded review of named mappings, not a catalogue of every law worldwide.A bounded follow-up on 13 September 2026 read DORA Articles 2 and 64, current eCFR Sections 164.302, 164.304 and 164.316, the official SB 26-189 session law, and 6 U.S.C. 681b through . Current eCFR access succeeded for those sections. The corresponding House U.S. Code section was attempted but timed out; this review used the official GPO alternative and does not claim a successful House reread. The official CIRCIA agenda entry listed a September 2026 target; the review did not establish an operative final rule.For every legal mapping, maintain a record of the official source, exact provision and version, publication and applicability dates, verification date, reviewer, pending changes, and any retrieval gap. Do not label a claim verified solely because a URL is reachable. A changed source or unresolved legal conflict requires review of the mapping and its conformance examples.