Compliance Profile of Signed Action Receipts for AI Agents

1.1. Profile and Explicit Overrides

This specification draws on the receipt model in [ACTA-RECEIPTS]. Its conformance requirements are defined here and in its normative references. ACTA records design history; its requirements are not incorporated by reference. Implementers use Section 3, Section 4 and Section 5. Shared names do not establish wire compatibility.¶

1.2. 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 [EU-AI-ACT] 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.¶

5.1. Signature Object and Algorithm Contract

The 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 Section 5.2.5. 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 [RFC9964]. The public key is 1952 octets and the signature is 3309 octets under [FIPS204].¶

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 [ACTA-RECEIPTS], which is Ed25519 under [RFC8032], 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 [RFC9964] algorithm string and AKP JWK form, the Section 5.2.10 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 [RFC4648]. COSE and JWS use their own protected framing and signing-input rules under [RFC9964], [RFC9052] and [RFC7515]; 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 [RFC8032] 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.¶

5.2. Common Payload Fields

5.3. 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 Section 5.3.2. 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.¶

5.4. 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 Section 5.1. 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 [ACTA-RECEIPTS] 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, Section 5.8 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 Section 7.4.2, Section 8.5.1, and Section 8.6.1), 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 [ACTA-RECEIPTS] format chain over the whole-receipt object that includes the signature; the two wire formats are distinguished by the REQUIRED v member of Section 5.2.1: 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 Section 5.5 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 ([ASQAV-SDK], 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 [RFC8032]. JWK algorithm identifiers are interpreted with [RFC7518] and the profile-specific algorithm rules. A verifier MUST NOT infer an algorithm from the key identifier alone or silently substitute another algorithm.¶

5.5. 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 [RFC3161] and [OPENTIMESTAMPS], 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 Section 5.5, Paragraph 11. 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.¶

RFC 3161 certificate identification uses the applicable update in [RFC5816]. Successful token parsing is separate from certificate-path, historical validity, message-imprint and trust-policy checks.¶

5.6. Signer-Outage Evidence (unsigned_gap)

This section is normative. The hash chain of Section 5.4 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 Section 5.3. The member is server-built in the sense of Section 5.11: a caller-supplied value MUST be dropped before signing. A verifier MUST NOT read it as evidence that the unsigned Actions were policy-evaluated.¶

5.7. Extension Fields

This profile registers extension fields across seven groupings that MAY appear in the signed payload object alongside the common fields defined in Section 5.2: (a) regulatory classification fields (risk_class, incident_class) defined in this section; (b) the cross-agent envelope-binding field counterparty_binding defined in Section 5.8; (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 Section 5.9 and Section 5.10; (d) server-built enforcement-control record fields (authorized_under_mandate, controls_evaluated) defined in Section 5.11; (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 Section 5.12; (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 Section 5.14; 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 Section 5.15. All extension fields appear inside the signed payload object and are therefore covered by the signature scope defined in Section 5.4.¶

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 [EU-AI-ACT], 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 [COLORADO-ADMT], 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 [DORA], with classification criteria in [REG-2024-1772] and the canonical reporting enumeration of Annex II data glossary, field 3.23 (Type of the incident) of [REG-2025-302] (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 [NYDFS-500]; a Covered Cyber Incident under [CIRCIA] 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 [HIPAA-SECURITY]. Implementations MAY refine the set, provided the flattened mapping in the Audit Pack manifest (Section 10) 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 Section 13.¶

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 Section 5.4 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 Section 5.2.1 governs it. An unrecognised member carries no protectmcp semantics, and a claim about such semantics is reported under Section 13.3 rather than inferred from the member name.¶

5.8. 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 Section 5.4 validate independently regardless of whether B's observed bytes equal A's signed bytes. action_ref binds an Action descriptor under Section 5.2.7; 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.¶

"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"
}

5.9. 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 Section 5.4.¶

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 Section 5.2.4; 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 ([RFC8785]) 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 [EU-AI-ACT] and the intentional and substantial modification definition in Section 6-1-1701(12) of [COLORADO-ADMT]. 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 [EU-AI-ACT] 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 Section 13.3 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 Section 13.3) 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 Section 11.2, and a verifier that maintains a seen-nonce index flags duplicate emissions on the duplicate_emission_candidate axis of Section 11.4. 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 [DRAFT-SOKOLOV-AEP-COMPOSITION] 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.¶

5.10. 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 Section 5.4. 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 Section 11.5.¶

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 [RFC8785] 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.¶

5.11. 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 Section 5.4. 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 Section 5.15 and the witness_policy quorum guard of Section 5.5. 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 Section 5.2.5), 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 Section 5.15, 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 Section 12): 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.¶

5.12. 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 Section 13.3), 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 Section 5.3, 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 (Section 5.4, Section 5.5); 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 Section 5.2.5 (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 Section 13.2.¶

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 (Section 5.2.4) and the anchors evidence (Section 5.5). 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 Section 5.9.¶

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 Section 4; 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 Section 13.2, 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 Section 5.9 to declare the wall-clock time after which the Deployer considers the acceptance stale, and the server-built authorized_under_mandate field of Section 5.11. Consistent with Section 5.9, 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.¶

5.13. Oversight Ruling Receipts

This section is normative. It defines the sub-namespace protectmcp:lifecycle:oversight_ruling (registered in Section 13.3) 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 Section 5.3, carries decision observation and the policy_digest of the sentinel artefact, exactly as Section 5.12 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 Section 10 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 Section 5.3.¶

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 Section 11.4. 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 Section 7.2.2 an oversight ruling receipt can contribute to evidence of the human-oversight assignment Article 26(2) requires. Under Section 8.2.3 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.¶

5.14. Code-Authorship Extensions

This section defines extension fields in the signed payload of a protectmcp:lifecycle:code_authorship receipt (Section 13.3). It records a producer's assertion about a repository change. The receipt uses the no-policy lifecycle path in Section 5.3, 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 (Section 5.4, Section 5.5). 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 Section 9.2 reports the specific source bytes it actually fetched and recomputed. Required but unavailable rederivation prevents full verification under Section 11.4.¶

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 Section 13.2.¶

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 Section 5.12 and config_manifest_digest of Section 5.9. 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 Section 5.12.¶

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 Section 13.2, 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 Section 5.11 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 Section 5.11, 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 Section 9.2 and reports its actual scope and result.¶

5.15. 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 Section 5.4, 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 [NIST-AI-RMF]. 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 [EU-AI-ACT]. When populated the issuing platform MUST set framework_mappings_self_declared to true.¶

rfc3161_timestamp:

OPTIONAL JSON string carrying a base64-encoded [RFC3161] 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 Section 5.5; the base64 encoding is per [RFC4648]. It never counts toward the anchoring requirement of Section 5.5 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 Section 5.11 and the witness_policy quorum guard of Section 5.5. 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.¶

5.16. Environment Attestation Extensions (Normative-Optional)

This optional extension carries signed environment-state claims asserted before an Action, drawing on the environment-record concept in [DRAFT-MSEBENZI-EVIDENCE-ACTION]. 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 Section 11.4.¶

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 [RFC8785] 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 Section 5.4 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 Section 11.5.¶

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.¶

5.17. 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 Section 13.2. Lineage is a directed acyclic graph over receipts: node and edge identity reuse the SHA-256 and JCS canonicalization already defined in Section 4, 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 Section 5.4: 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 Section 11.2. 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 (Section 11.4).¶

5.18. Heartbeat and Denial Evidence

A heartbeat is a lifecycle observation with type=protectmcp:lifecycle, action_type=asqav:heartbeat, decision=observation and the no-policy JSON null value of Section 5.3. 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.¶

5.19. Capture Coverage and Enforcement Authority

Capture 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 [CLAUDE-HOOKS].¶

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 [MCP-AUTH] for the applicable HTTP transport.¶

7.1. 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.¶

7.2. EU AI Act Article 26 Binding

7.3. 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 (Section 5.15), 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.¶

7.4. DORA Article 17 Binding

8.1. NIST AI RMF Binding

[NIST-AI-RMF] 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. [NIST-GENAI-PROFILE] 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.¶

8.2. Colorado Automated Decision-Making Technology Act (SB 26-189) Binding

SB 26-189, [COLORADO-ADMT], 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.¶

8.3. 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 [TEXAS-TRAIGA] 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.¶

8.4. 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 [HIPAA-SECURITY]. 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).¶

8.5. NYDFS Cybersecurity Regulation Binding (23 NYCRR Part 500)

[NYDFS-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.¶

8.6. 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 [SEC-17A-4].¶

8.7. CIRCIA: Provisional Evidence Mapping

Under 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 [CIRCIA-681B]. 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.¶

9.1. Attestation Statement Envelope

An attestation statement is a Dead Simple Signing Envelope (DSSE, [DSSE]) whose payload is an in-toto Statement v1 ( [IN-TOTO-ATTESTATION]) 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 ( [FIPS204]) under the service identity of Section 9.6; 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 [IN-TOTO-ATTESTATION] 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 [DSSE] is the signing pre-image and is independent of the JCS rule that governs the receipt envelope of Section 5¶

.¶

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 Section 5.14 and Section 5.12 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 Section 9.2. 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 Section 9.4.¶

9.2. 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 Section 5.14, 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 Section 5.14) 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 [IN-TOTO-ATTESTATION] 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 Section 5.14) 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 Section 9.5, 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.¶

9.3. 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 Section 5.11.¶

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 Section 9.2. 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 Appendix C). 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 Appendix C). 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 Appendix C). 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 Appendix C 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 Section 5.19. 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.¶

9.4. 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 (Section 9.6), narrowing the candidate keys by the signature's keyid where one is present. [DSSE] 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 Section 11.2 for receipts.¶
• Verify the ML-DSA-65 signature ([FIPS204]) over the DSSE PAE of the in-toto Statement, per Section 9.1. 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 Section 9.2; 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.¶

9.5. 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 Section 9.1. 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 Section 9.3. 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 Appendix C remain observation-only evidence classes under Section 9.3 and do not mint authoritative attestations.¶

9.6. 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 Section 5.2.5 and Section 9.4.¶

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.¶

10.1. Signed Audit Pack Projection

This 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 Section 4. 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 [RFC4648] 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.¶

11.1. Verifier Independence

Verification 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 Section 11.4.¶

11.2. 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 Section 5.5 (pending-anchor bound and witness quorum), Section 5.8.3, Section 5.9, and Section 5.11.¶

• Verify the signature over the signed bytes defined in Section 5.4, using the permitted algorithm and signing-input rules of Section 5.1.¶
• Resolve candidate keys from independently authenticated JWK Sets, configured trust anchors or authenticated historical exports under Section 5.2.5 and Section 9.6. 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 Section 5 are present and well-formed.¶
• Verify the hash-chain linkage by recomputing the chain-link digest of the immediately preceding receipt per Section 5.4 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 Section 5.4.¶
• Evaluate presented anchors and any declared witness policy per Section 5.5. 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 Section 5.2.4. 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 Section 5.9; 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 Section 11.4.¶
• 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 Section 5.2.10, recompute the RFC 7638 thumbprint of the resolved verification key per [RFC7638] 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 Section 5.2.10 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 Section 5.2.7 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.¶

11.3. 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.¶

11.4. 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 Section 5.5. 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 Section 8.2. 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 Section 11.5 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.¶

11.5. Verification Verdict and Hash-Algorithm Vocabulary

The summary vocabulary is verified, verified_keyed and unverified. It summarizes the required axes selected under Section 11.4. 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.¶

12.1. 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 Section 12.14.¶

12.2. 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 Section 5.4: 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 [ACTA-RECEIPTS] 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 [SCOPEBLIND] corpus, per Section 10); this profile's receipts are identified by the REQUIRED v member of Section 5.2.1, per the interoperability note of Section 5.4, 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.¶

12.3. Chain Availability Under Single-Linear Per-Agent Serialization

This section is informative. The single-linear per-agent chain requirement of Section 5.4 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 Section 5.4.¶

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 Section 12.1) and it cannot forge receipts (those are protected by Section 12.4). 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.¶

12.4. 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 Section 9.6 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.¶

12.5. Retention and Long-Term Verifiability

Long-term verification depends on retained receipt bytes, proofs, historical public keys, key authorization records and the applicable trust policy. The retention schedule follows Section 6. 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 Section 12.14 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.¶

12.6. Privacy

Signed 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 [GDPR] and the distinctions in [ICO-ANON].¶

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 [RFC2104]. 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.¶

12.7. Anchor Trust

RFC 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 Section 5.5; 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.¶

12.8. 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 Section 5.2.4 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 Section 5.9: 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 Section 5.2.4, 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.¶

12.9. Cross-Regime Conflict

The organization determines which laws and policies apply using Section 6. 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.¶

12.10. 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 [FIPS204], 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 [FIPS205] against 3309 octets for ML-DSA-65 [FIPS204], roughly five times the signature bytes on an artifact minted once per Action, and the "s" parameter sets are the ones [FIPS205] characterises as favouring small signatures rather than fast signature generation, so that size is not bought back in signing speed. Independently, [LAMPS-COMPOSITE] 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.¶

12.11. Issuer-Misrepresentation Residual

Per-agent hash chains under Section 5.4 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 Section 5.2.7, 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 (Section 5.8) 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. Section 5.8.3 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 Section 5.8.3 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 Section 12.12 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.¶

12.12. 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 Section 5.8 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 [RFC9846]; may use the tls-exporter channel binding per [RFC9266] derived via [RFC5705] where higher channel uniqueness is required; and may layer HTTP Message Signatures per [RFC9421] 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 Section 12.11; 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.¶

12.13. 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 Section 5.4 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 Section 5.2.7; 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 Section 5.8 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 Section 5.8.1), as specified normatively in Section 5.8.1. 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 Section 5.8.3. 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 [RFC3161] + [OPENTIMESTAMPS] anchors per Section 5.5, 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 [RFC3161] and [OPENTIMESTAMPS] anchors are present per Section 5.5, 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 Section 8.6.1) and the post-market surveillance regime of EU AI Act Articles 12 and 26 (see Section 7.1 and Section 7.2) authorise the regulator to compel both A's and B's Audit Packs and to reconstruct the relay by joining on action_ref per Section 5.2.7. 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.¶

12.14. 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 Section 11.2, 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 ([RFC3161]). A fresh nonce distinguishes receipt emissions, not effects. The optional duplicate-emission observation under Section 12.8 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 Section 4.¶
• That the policy was correct, lawful, complete or retained. policy_digest commits a digest value. Only resolving and recomputing the artifact under Section 5.3.2 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 Section 5.16 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. Section 5.2.5 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 Section 12.4, and the collusion and key-compromise residuals are stated in Section 12.11 and Section 12.13.¶
• That a declared constraint was enforced at runtime. An expires_at claim does not itself stop execution (Section 5.9). The producer-asserted fields in Section 5.15, Section 5.12 and Section 5.14 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 (Section 9.5).¶
• That the Action was prevented in real time. The receipt is detective, audit-time evidence; it does not block in-flight bytes (Section 12.11).¶
• 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 Section 12.1. 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 (Section 12.11).¶
• 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 [DRAFT-HOPLEY-X402], 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 Section 11.2 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 Section 5.2.11 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 Section 5.5 fix the presented receipts in time without revealing that later ones were withheld. Completeness comes from deployment, not from the format. Fail-closed capture (Section 9.5) refuses the Action when no receipt can be minted, and an Acceptor (Section 2) 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 (Section 5.6), and a blocked emission through the chain_emission_blocked lifecycle receipt (Section 12.3). Independent custody of later receipts, whether by a counterparty whose counterparty_binding (Section 5.8) digests them, by the Acceptor that gated on them, or by the holder of an Audit Pack (Section 10) covering them, turns a truncated tail from invisible into contradicted. [ASQAV-SDK] 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.¶

13.1. Regime Mapping Vocabulary

The 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 Section 8.2. 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.¶

13.2. Compliance Receipt Extension Fields Registry

This table defines the extension fields of this profile. It is administered at the external registry named in Section 13 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 Section 5.2 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 Section 5.2.11.¶
• risk_class - Scope: signed-payload - Risk classification term under the Deployer's risk management documentation; defined in Section 5.7 - 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 [REG-2024-1772] and the canonical reporting enumeration of Annex II field 3.23 of [REG-2025-302]), 23 NYCRR 500.1 Cybersecurity Event/Incident, [CIRCIA] Covered Cyber Incident subject to the operative-rule conditions of the provisional mapping in Section 8.7, and HIPAA security incident under 45 CFR 164.304; defined in Section 5.7 - 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 Section 5.8 for the full member set and the digest-scope rule - This document - Member vocabulary defined in Section 5.8.1, including the scope value set {envelope_minus_anchors}; digest algorithm is SHA-256 under Section 5.8.1 with base64url encoding per [RFC4648] 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 Section 5.9 - 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 Section 5.9 - 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 Section 5.9 - 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 Section 11.5 - This document - Value vocabulary {sha256, hmac-sha256} per Section 11.5.¶
• 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 ([RFC8785]) serialization of the JSON object {"tool_name": <tool name>, "schema": <declared input schema>}; defined in Section 5.9 - This document - Digest algorithm is SHA-256 over [RFC8785] 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 Section 5.9 - 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 Section 5.9 - 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 Section 5.10; defined in Section 5.10 - 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 Section 5.10 - 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 Section 5.10.¶
• 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 Section 5.10 - 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 Section 5.10 - 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 Section 5.5 - This document - Anchor type vocabulary: rfc3161 per [RFC3161], opentimestamps per [OPENTIMESTAMPS].¶
• 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 Section 5.5 - 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 Section 5.15 - 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 Section 5.15 - 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 Section 5.15 - 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 Section 5.15; 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 Section 5.15 - 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 Section 5.15 - 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 Section 5.15 - This document - Vocabulary referenced from [EU-AI-ACT].¶
• 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 Section 5.15 - This document - Bytes are an RFC 3161 TimeStampResp per [RFC3161]; base64 encoding per [RFC4648].¶
• 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 Section 5.15 - 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 Section 5.11 - This document - Member vocabulary defined in Section 5.11; 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 Section 5.11 - This document - Control-key vocabulary defined in Section 5.11.¶
• 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 Section 5.12 - This document - Bare-identifier form per Section 5.2.5.¶
• 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 Section 5.13 - This document - Values are action_ref digests per Section 5.7.¶
• 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 Section 5.13 - This document - One of confirm, override, escalate, flag.¶
• ruling_reason - Scope: signed-payload - OPTIONAL machine-readable reason code accompanying a ruling; defined in Section 5.13 - 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 Section 5.13 - 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 Section 5.12 - This document - Bare-identifier form per Section 5.2.5.¶
• 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 Section 5.12 - 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 Section 5.12 - 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 Section 5.12 - 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 Section 5.12 - 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 Section 5.12 - 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 Section 5.12 - 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 Section 4) 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 Section 5.12 - 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 Section 5.14 - 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 Section 5.14 - 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 Section 5.14 - 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 Section 5.14 - 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 Section 5.14 - 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 Section 5.14 - 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 Section 5.14 - 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 Section 5.14 - This document - Member vocabulary defined in Section 5.14; 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 Section 5.6 - This document - count is a JSON integer; timestamps follow [RFC3339].¶
• 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 Section 5.7.¶
• 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 Section 5.2.2.¶
• 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 Section 11.2 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 Section 5.2.2.¶
• 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 Section 5.2.2.¶
• 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 Section 5.3.¶
• 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 Section 9.3, 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 Section 5.2.2). 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 Section 5.5. - 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 Section 5.17, 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 Section 5.4, 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 Section 5.2.2.¶
• previousReceiptHash - Scope: signed-payload - REQUIRED on every receipt including a chain's first, where it carries the all-zero SHA-256 value of Section 5.4; 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 Section 5.4. 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 Section 5.3.¶
• 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 Section 5.5, Paragraph 11. 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 Section 5.2.1.¶
• 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 Section 12.7 - 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 Section 5.2.10 - This document - Digest algorithm is SHA-256 over the RFC 7638 canonical JWK form per [RFC7638].¶
• 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 Section 5.16 - This document - Member vocabulary defined in Section 5.16; 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 Section 5.18 - 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 [RFC8392], with the semantics defined in Section 5.8. 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 [RFC8392] 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" (Section 5.8).¶

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 Section 5.16. 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 Section 5.5. They are not additional signed-payload fields or independent trust assertions.¶

13.3. 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 Section 13, 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 Section 13.2, 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 Section 5.8.2, carrying the counterparty_binding object that digests the bound A-party envelope per Section 5.8 - 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 Section 5.3 - 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 Section 5.3 - 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 Section 5.3) - 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 Section 7.1.1); 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 (Section 5.9) is rejected at signing time per the type-bound presence rule of Section 5.9 - 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 Section 5.12 - 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 Section 5.13. 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 Section 5.14; 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 Appendix C (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 (Section 5.9) 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 Section 5.9 - This document.¶

15.1. 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 [ASQAV-SDK] for the cited source artifact.¶

15.2. 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 [ASQAV-SDK] for the cited source artifact.¶

15.3. 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 [ASQAV-SDK] 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.¶

A.1. 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 (Section 9.6). 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 (Section 5.2.10).¶

{
  "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 (Section 5.2.10).¶
• Chain: SHA-256 over the JCS serialization of the predecessor's payload member equals previousReceiptHash (Section 5.4), and seq 63 follows the predecessor's 62 with nothing withheld between them (Section 5.2.11).¶
• payload_digest: This receipt carries no context, so the recomputation of Section 11.2 does not apply; the separate hash member holds the self-describing fingerprint of the Action, and hash_algo records how it was produced.¶
• Anchors (Section 5.5): 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.¶

A.2. 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 Section 5.4 and Section 5.2.11;¶
• both an RFC 3161 anchor and an OpenTimestamps anchor are present per Section 5.5.¶

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.¶

A.3. The counterparty_binding member (illustrative)

When agent B's receipt binds agent A's receipt, B's signed payload carries the member below (Section 5.8, Section 5.8.1): 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"
}

B.1. Changes in draft -09

The 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.¶

B.2. Changes in draft -08

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

B.3. Changes in draft -07

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

B.4. Changes in draft -06

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

B.5. Changes in draft -05

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

B.6. Changes in draft -04

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

B.7. Changes in draft -03

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

B.8. Changes in draft -02

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

B.9. Changes in draft -01

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

B.10. Changes in draft -00

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

C.1. In-Process SDK

An 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 Section 5.19.¶

C.2. 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 Section 12.6.¶

C.3. 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 [CHROME-CONTENT-SCRIPTS] and [CHROME-WEBREQUEST].¶

C.4. 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 [RFC9849]. 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.¶

C.5. 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 [MCP-AUTH].¶

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.¶

C.6. 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.¶

C.7. 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 Section 11.2 nor Section 11.3 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 [RFC8726].¶

C.8. Regulatory Currency and Verification Dates

This 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 [CIRCIA-681B]. 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.¶