Evidence Library · Framework map
Evidence concepts, mapped to review frameworks
This draft identifies where selected elements of an AAES authorization-decision record may support a review. It does not map every schema field or establish compliance with a framework. Exported records are one source of evidence within an AI management system, a SOC 2 examination, or an applicable AI Act assessment.
Read this first
This is an engineering-authored draft v0.1 compiled from our framework notes and internal mapping. The aaes.export/v1 specification and a synthetic sample export are public. AAES is pre-launch, and the verifier is open source at github.com/aaes-ai/aaesverify under Apache-2.0. No auditor has reviewed this map. Verify the applicable provisions and assessment scope against the official sources before relying on it. This page is not a certification, attestation, or legal opinion.
The evidence being mapped
The public aaes.export/v1 specification defines a JSONL export containing header, action-entry, and anchor values. This map concerns the authorization-decision evidence represented by action entries, not proof that every action was captured or executed. The concepts discussed below include actor, capability, authorization scope, permit or refusal, recorded rationale, approver attribution, estimated-cost and budget information, grant identifier and expiry where applicable, and decision timestamps. These are conceptual labels, not exact schema property names. The evaluation verifier checks the export offline using supplied trust material.
The mapping (draft)
| Evidence concept | ISO/IEC 42001 (AIMS) | SOC 2 (TSC) | EU AI Act |
|---|---|---|---|
| Cryptographically protected authorization-decision entries | Potential documented information about AI-system operation within the defined AIMS scope; not evidence of AIMS conformity on its own | Potential input to system-operations evidence under CC7, where the assessed controls use these records; record integrity does not establish monitoring effectiveness | Potential input to Article 12 logging for applicable high-risk systems; coverage of required events and logging capability must be assessed separately |
| Actor, capability, and authorization scope | Potential evidence of recorded identities and authorized scope; not proof of identity accuracy or actual execution | Potential logical-access evidence under CC6, subject to authenticated identities, policy context, and the assessed control | May contribute to event traceability; no standalone Article 12 or Article 14 conclusion follows from these fields |
| Authorization decision and recorded rationale | Potential evidence of a recorded control decision; enforcement and operating effectiveness require additional evidence | Potential CC6 evidence where the decision implements a logical-access control; not change-management evidence merely because a decision was recorded | May document an authorization control relevant to the system's intended use and risks; does not establish legal adequacy of that control |
| Approver attribution | Potential attribution to an assigned role; authentication, authority, and actual participation require additional evidence | Recorded attribution only; not proof that an accountable person authorized the action | Potential supporting information for Article 14 oversight arrangements; attribution alone does not demonstrate effective human oversight |
| Estimated-cost commitment and budget state | Potential evidence of an organization-defined resource control; no specific monetary-budget requirement is asserted | Relevant only where the assessed control and selected criteria include this limit; not a general TSC requirement | No direct Article 12 or Article 14 mapping established; may support an organization-defined risk control |
| Grant identifier, expiry, and recorded decision timestamps | Potential documented information about intended authorization duration; not proof that expiry was enforced | Potential CC6 evidence of time-limited authorization; enforcement and clock reliability require separate assessment | May contribute to Article 12 event context where applicable; grant expiry does not establish logging duration or retention |
| Recorded refusals and permits | Potential examples of recorded control decisions; not evidence that all decisions were captured | Potential CC6 evidence and, where used in operational monitoring, CC7 input; effectiveness requires additional evidence | May contribute to Article 12 logs where relevant to the system's risks and intended purpose; no universal requirement for these specific fields is asserted |
Separately, GDPR Article 22 concerns decisions based solely on automated processing that produce legal or similarly significant effects on an individual, subject to its exceptions and applicable safeguards. A recorded approver identifier does not establish meaningful human involvement or satisfaction of those safeguards. Applicability requires a separate assessment of the decision process.
What the evidence does not establish (print beside every use)
Successful cryptographic verification establishes that the supplied export satisfies the checked integrity rules and that its signed head verifies under the supplied public key. Interpreting that key as belonging to the claimed signer requires authenticated key provenance. Verification does not establish capture completeness, the truth of recorded inputs, the absence of omitted actions, that the supplied head is the latest head, legal non-repudiation, policy correctness, or successful downstream execution. The recorded approver identifier does not establish that the person was authenticated, authorized, or meaningfully involved. An external timestamp can provide evidence about the existence of committed data at a time; it does not by itself authenticate each recorded event time. No external timestamp authority or independent witness is configured by default. Offline verification is not independence from AAES.
How this map matures
Before external reliance, check the applicable framework provisions against official sources and add exact schema paths, control references, and example evidence. Ask a design-partner auditor to review an evaluation export using the scoped verifier and record the questions they permit us to retain. Accepted mapping changes will inform framework-map draft v0.2; changes to the export format follow its separate versioning policy. The vendor-neutral RFP evidence clause is available on request through the contact page.
Reviewing AAES against your own control framework? The specification and the synthetic sample export are available starting points.
Related pages: Specification: https://aaes.ai/spec.html · Offline verification: https://aaes.ai/library/verification.html · Evaluation contact: https://aaes.ai/contact.html?ref=framework-map