Conformance Mapping
NIST AI RMF, EU AI Act Article 12, and ISO/IEC 42001 mapped to deployed Asqav evidence
This page maps three governance regimes to the Asqav capabilities that already run in production. The three regimes are the ones the IETF Internet-Draft draft-marques-asqav-compliance-receipts binds the receipt format to: the NIST AI Risk Management Framework, EU AI Act Article 12 (record-keeping), and ISO/IEC 42001:2023.
Every capability named below is published on /.well-known/governance.json. Asqav signs each AI agent action server-side, as an operator unaffiliated with the agent's operator, so the recorded party cannot forge or backdate its own record. The signed receipt supports the recordkeeping obligations these regimes describe and provides verifiable evidence an auditor reads.
Three of the wire fields below - nist_ai_rmf, eu_ai_act_articles, and iso_42001 - are caller-supplied taxonomy lists. The cloud preserves the producer's claim verbatim inside the signed envelope and sets the framework_mappings_self_declared guard, so a downstream reader knows the mapping came from the producer, not from Asqav.
The boundary these capabilities are checked against is published as the Conformance Profile: five testable principles that define a verifiable governance receipt, each pinned by a machine-checked fixture.
NIST AI RMF
The draft binds the format to the AI RMF functions: signed receipts provide evidence under MEASURE and structured input to GOVERN, MAP, and MANAGE.
| Function | What Asqav provides | Deployed capability |
|---|---|---|
| GOVERN | Asqav records each action under server-side policy enforcement, providing structured input to the GOVERN function. | policy_enforcement capability; protectmcp:decision receipt type. |
| MAP | Asqav binds each receipt to a stable agent identity, so the system map persists across policy revisions. | GET /api/v1/agents/{agent_id}/card; GET /api/v1/public/attestation/{agent_id}. |
| MEASURE | Asqav supplies per-action signed evidence that anyone can verify without an API key, providing verifiable evidence under the MEASURE function. | sign and verify capabilities; GET /api/v1/verify/{signature_id}; ML-DSA-65 (FIPS 204), key at /.well-known/jwks.json. |
| MANAGE | Asqav records risk-treatment and halt events inside the signed chain, providing structured input to the MANAGE function. | emergency_halt capability; protectmcp:lifecycle:risk_acceptance receipt type. |
| Function taxonomy | Asqav preserves the producer-declared RMF function ids verbatim in the signed envelope and marks them self-declared. | nist_ai_rmf wire field; framework_mappings_self_declared guard. |
EU AI Act Article 12 (record-keeping)
Article 12 asks High-Risk AI Systems to allow the automatic recording of events over the lifetime of the system. The draft binds each Article 12 clause to a receipt field.
| Clause | What Asqav provides | Deployed capability |
|---|---|---|
| Article 12(1) automatic recording of events | Asqav records a signed receipt for each action, and records a lifecycle receipt when receipt generation is switched off. | sign capability; protectmcp:decision and protectmcp:lifecycle:configuration_change receipt types. |
| Article 12(2)(a) identifying risk situations | Asqav carries a producer-declared risk and incident classification on each receipt, providing verifiable evidence of the situations flagged at sign-time. | risk_class and incident_class wire fields. |
| Article 12(2)(b) post-market monitoring (Article 72) | Asqav exports the retained receipts as an offline evidence pack and replays the trail, supporting post-market monitoring. | audit_export_json, audit_export_csv, audit_trail_replay capabilities; GET /api/v1/audit-pack/example. |
| Article 12(2)(c) monitoring operation (Article 26(5)) | Asqav binds each action outcome to its decision receipt, providing verifiable evidence of the operation monitored. | protectmcp:observation:result_bound receipt type; result_digest wire field. |
| Record integrity across the retention window (Article 26(6)) | Asqav anchors each receipt to an RFC 3161 or OpenTimestamps witness, providing verifiable evidence of the record's existence date. | rfc3161 and opentimestamps witnesses. |
ISO/IEC 42001:2023
ISO/IEC 42001 asks an organisation to keep records that prove the controls it claims are in place. Asqav is the signed record layer an auditor reads for the operational-evidence clauses.
| Clause area | What Asqav provides | Deployed capability |
|---|---|---|
| Clause 7.5 / 9.1 documented information and monitoring records | Asqav signs each action into a tamper-evident record and publishes the verify key independently of the producer, providing verifiable evidence for the operational-record clauses. | sign and verify capabilities; ML-DSA-65 (FIPS 204); key at /.well-known/jwks.json. |
| Clause 8 Operation: evidence the controls ran | Asqav records which enforcement controls fired on each signed action under an omission-over-false design, providing verifiable evidence that a control ran. | controls_evaluated server-built field; generate_attestation capability. |
| Clause 9.2 / 10 internal audit and improvement | Asqav replays the signed trail and records who accepted which residual risk, supporting internal audit and corrective action. | audit_trail_replay capability; protectmcp:lifecycle:risk_acceptance receipt type. |
| Control taxonomy | Asqav preserves the producer-declared control ids verbatim in the signed envelope and marks them self-declared. | iso_42001 wire field; framework_mappings_self_declared guard. |
Asqav supports the recordkeeping obligations these regimes describe and provides verifiable evidence an auditor reads. This page does not constitute legal advice and does not certify conformance with any of these regimes. Certification, where a regime provides for it, is issued by the relevant authority or an accredited body after its own assessment. The taxonomy entries on a receipt are caller-supplied, not Asqav-verified. See the docs for the full mapping and the IETF draft for the binding text. Related pages: NIST AI RMF, EU AI Act Article 12, ISO/IEC 42001.