> ## Documentation Index > Fetch the complete documentation index at: https://docs.aigoframework.com/llms.txt > Use this file to discover all available pages before exploring further. # 03 AIGO Cross Framework Evidence Mapping v0.1 # AIGO — Cross-Framework Evidence Mapping ## 1. Document Purpose This document defines the cross-framework evidence architecture for the AIGO mapping layer connecting: * the EU AI Act; * ISO/IEC 42001:2023; and * NIST AI RMF 1.0. Its purpose is to establish how a common AIGO Evidence infrastructure can support multiple framework requirements while preserving: * source-framework identity; * applicability; * evidence sufficiency; * evidence quality; * legal or normative significance; * version; * lifecycle state; * assurance criteria; and * historical traceability. The objective is: ```text theme={null} Framework Requirement ↓ AIGO Control ↓ AIGO Activity ↓ Evidence Record ↓ Validation ↓ Framework-Specific Assurance ``` This document does not declare that one evidence record automatically proves compliance with every framework mapped to the same control. *** # 2. Mapping Information | Field | Value | | ----------------------- | ---------------------------------------------------- | | Mapping | AIGO Cross-Framework Evidence Mapping | | Version | 0.1 | | Status | Draft | | Document Identifier | `AIGO-MAP-XFW-003` | | Document Type | Cross-Framework Evidence Mapping | | Mapping Package | `AIGO-MAP-XFW` | | Architecture | `AIGO-MAP-XFW-ARCH-001` | | Registry | `00-AIGO-Cross-Framework-Mapping-Registry-v0.1.json` | | Primary Function | Evidence harmonization and traceability | | Primary Evidence Schema | AIGO Evidence Schema | *** # 3. Evidence Architecture Principle The AIGO evidence model is: ```text theme={null} External Requirement ↓ Applicability ↓ AIGO Control ↓ Operational Activity ↓ Evidence Record ↓ Evidence Validation ↓ Framework-Specific Assurance ``` The evidence record is the reusable operational artifact. The requirement relationship remains framework-specific. *** # 4. Evidence Non-Equivalence Principle A shared evidence record does not mean: ```text theme={null} Evidence = Universal Compliance ``` Instead: ```text theme={null} One Evidence Record ↓ Relationship A → Framework A Criterion Relationship B → Framework B Criterion Relationship C → Framework C Criterion ``` Each relationship must be independently assessed for sufficiency. *** # 5. Evidence Relationship Types The cross-framework evidence layer uses: ```text theme={null} SHARED SHARED_WITH_EXTENSIONS FRAMEWORK_SPECIFIC SUPPORTING PARTIAL INSUFFICIENT NOT_APPLICABLE HISTORICAL SUPERSEDED ``` ## SHARED The evidence substantially satisfies the evidence need for multiple framework relationships. ## SHARED\_WITH\_EXTENSIONS The core evidence is shared, but one or more frameworks require additional information. ## FRAMEWORK\_SPECIFIC Evidence is required only because of a particular framework. ## SUPPORTING Evidence strengthens a requirement relationship but is not independently sufficient. ## PARTIAL Evidence covers only part of the relevant criterion. ## INSUFFICIENT Evidence exists but does not adequately address the applicable criterion. ## NOT\_APPLICABLE The evidence relationship is not applicable. ## HISTORICAL The evidence belongs to a prior controlled state. ## SUPERSEDED The evidence has been replaced by a newer record while remaining historically relevant. *** # 6. Evidence Quality Model Evidence quality should be evaluated across: ```text theme={null} Authenticity Integrity Completeness Relevance Currency Attribution Traceability Availability Consistency Sufficiency ``` A high-quality evidence record should be demonstrably connected to the control and activity that produced it. *** # 7. Evidence Identity Every evidence item should have a stable identifier. Recommended format: ```text theme={null} AIGO-EVD-- ``` Examples: ```text theme={null} AIGO-EVD-RSK-001 AIGO-EVD-CTRL-001 AIGO-EVD-MON-001 AIGO-EVD-ASSR-001 ``` The actual evidence identifier must resolve to the AIGO Evidence Schema. *** # 8. Evidence Metadata A material evidence record should contain, directly or through governed references: * evidence ID; * evidence type; * system ID; * control ID; * activity ID; * framework relationships; * source; * owner; * creation date; * effective period; * review date; * version; * status; * integrity information; * retention information. *** # 9. Evidence Status Evidence records should support: ```text theme={null} DRAFT COLLECTED VALIDATED APPROVED IN_USE EXPIRED SUPERSEDED ARCHIVED RETIRED ``` Evidence status is distinct from framework compliance status. *** # 10. Evidence Lifecycle The common evidence lifecycle is: ```text theme={null} Requirement ↓ Evidence Need ↓ Evidence Generation ↓ Evidence Collection ↓ Validation ↓ Approval / Acceptance ↓ Use ↓ Review ↓ Supersession / Archive ``` *** # 11. Evidence Need Identification Evidence should be identified from: ```text theme={null} Framework Requirement ↓ AIGO Control ↓ Evidence Requirement ``` This avoids collecting large volumes of evidence without a defined governance purpose. *** # 12. Evidence Categories Initial evidence categories include: ```text theme={null} GOVERNANCE POLICY CONTEXT APPLICABILITY CLASSIFICATION RISK IMPACT DATA CONTROL OPERATION TEST PERFORMANCE MONITORING INCIDENT CHANGE COMPETENCE TRANSPARENCY HUMAN_OVERSIGHT DOCUMENTATION ASSURANCE MANAGEMENT_REVIEW IMPROVEMENT RETIREMENT REGULATORY EXTERNAL_ASSURANCE ``` *** # 13. Governance Evidence Potential governance evidence includes: * governance charter; * role assignment; * accountability matrix; * committee records; * management decisions; * policy approval; * escalation decisions. ### Framework relationships **EU AI Act:** supports organizational governance and role obligations. **ISO/IEC 42001:** supports leadership, roles, policy, and management-system governance. **NIST AI RMF:** supports GOVERN. ### Evidence relationship `SHARED` where the same record genuinely supports the applicable criteria. *** # 14. Policy Evidence Potential evidence: * approved AI policy; * policy review; * policy communication; * policy change history. ### Framework relationships * EU AI Act: supporting organizational evidence; * ISO/IEC 42001: direct management-system evidence; * NIST AI RMF: GOVERN implementation evidence. ### Evidence model `SHARED_WITH_EXTENSIONS` because the exact policy content may differ by framework. *** # 15. Context Evidence Potential evidence: * organizational context; * AI system profile; * intended purpose; * deployment context; * stakeholders; * affected persons; * system dependencies. ### Framework relationships * EU AI Act: applicability/classification/context; * ISO/IEC 42001: organizational context; * NIST AI RMF: MAP. ### Evidence model `SHARED` where the record contains sufficient framework-specific fields. *** # 16. Applicability Evidence Applicability evidence should establish why a requirement applies or does not apply. Potential evidence: * regulatory applicability assessment; * AIMS scope statement; * AI RMF adoption scope; * legal analysis; * system classification. ### Important distinction A single document may contain multiple applicability decisions, but each decision should retain its source framework. *** # 17. Classification Evidence Classification evidence should distinguish: ```text theme={null} Legal Classification Internal Risk Classification Framework Adoption Classification ``` For example: ```text theme={null} EU AI Act: Legal Risk Category AIGO: Internal Risk Rating NIST: Selected RMF Scope ``` These must not be collapsed into one field. *** # 18. Risk Evidence Potential evidence: * risk assessment; * risk register; * risk scoring; * treatment decision; * residual-risk review; * monitoring record. ### Framework relationships Risk evidence is a major candidate for shared evidence across: * EU AI Act; * ISO/IEC 42001; * NIST AI RMF. ### Evidence model Usually: `SHARED_WITH_EXTENSIONS` because each framework can require different criteria. *** # 19. Risk Assessment Evidence Extensions A common risk assessment may require additional framework-specific fields. Example: ```text theme={null} Common Risk Assessment │ ├── EU AI Act extension ├── ISO AIMS extension └── NIST RMF extension ``` The base assessment should remain reusable. *** # 20. Impact Evidence Potential evidence: * impact assessment; * rights impact assessment; * affected-person analysis; * stakeholder assessment; * impact mitigation; * residual impact decision. ### Framework relationships * EU AI Act: applicable impact and fundamental-rights evidence; * ISO/IEC 42001: AIMS risk/impact governance; * NIST AI RMF: MAP context and impact evidence. ### Evidence model `SHARED_WITH_EXTENSIONS` *** # 21. Data Evidence Potential evidence: * dataset inventory; * data provenance; * data-quality assessment; * data-governance record; * bias evaluation; * privacy assessment; * data lineage. ### Framework relationships Data evidence may simultaneously support multiple requirements but often requires framework-specific extensions. *** # 22. Control Evidence Potential evidence: * control assessment; * control execution record; * configuration; * procedure; * approval; * exception; * control monitoring. A common AIGO Control may generate evidence reused across several mapping packages. *** # 23. Operational Evidence Potential evidence: * workflow record; * execution logs; * transaction record; * deployment record; * operational approval; * system activity. The evidence must be linked to the relevant system and period. *** # 24. Testing Evidence Potential evidence: * test plan; * test dataset; * methodology; * result; * expected result; * exception; * reviewer; * system/model version. ### Framework relationships * EU AI Act: applicable technical/performance requirements; * ISO/IEC 42001: operational and performance evidence; * NIST AI RMF: MEASURE evidence. *** # 25. Performance Evidence Potential evidence: * accuracy; * reliability; * robustness; * availability; * safety indicators; * fairness indicators; * security indicators; * monitoring results. The specific metrics must remain context-dependent. *** # 26. Monitoring Evidence Potential evidence: * monitoring record; * metric result; * threshold evaluation; * alert; * trend analysis; * escalation; * action. ### Framework relationships Monitoring is a strong candidate for shared operational evidence across all three mapping packages. *** # 27. Incident Evidence Potential evidence: * incident record; * severity; * impact; * containment; * investigation; * notification decision; * corrective action; * lessons learned. ### Critical boundary An incident record can support multiple frameworks, but legal notification evidence remains framework-specific. Example: ```text theme={null} Incident Record │ ├── EU notification relationship ├── ISO nonconformity relationship └── NIST incident-management relationship ``` *** # 28. Change Evidence Potential evidence: * change request; * impact assessment; * risk reassessment; * approval; * testing; * deployment; * post-change review. This is another major candidate for shared evidence. *** # 29. Competence Evidence Potential evidence: * role profile; * training record; * qualification; * experience; * competence assessment; * awareness record. ### Framework distinction EU AI Act AI-literacy evidence, ISO competence evidence, and NIST governance-capability evidence may overlap but are not automatically equivalent. *** # 30. Human-Oversight Evidence Potential evidence: * oversight assignment; * procedure; * intervention authority; * escalation mechanism; * training; * intervention record; * override record; * monitoring. The exact requirements are framework-specific. *** # 31. Transparency Evidence Potential evidence: * user notice; * transparency statement; * system documentation; * explanation; * disclosure record; * communication. ### Critical distinction EU AI Act transparency evidence must be evaluated against the applicable statutory provision. NIST transparency evidence and ISO transparency evidence cannot be treated as substitutes without criteria validation. *** # 32. Documentation Evidence Potential evidence: * controlled policies; * technical documentation; * procedures; * system profiles; * risk assessments; * approval records. The evidence registry should identify whether a document is: ```text theme={null} CONTROLLED_DOCUMENT RECORD TECHNICAL_ARTIFACT EXTERNAL_DOCUMENT REGULATORY_SUBMISSION ``` *** # 33. Management Review Evidence Potential evidence: * meeting record; * agenda; * inputs; * decisions; * actions; * resource decisions; * improvement actions. This is especially relevant to ISO/IEC 42001, but may also provide broader AIGO governance evidence. *** # 34. Assurance Evidence Potential evidence: * assurance plan; * test procedure; * workpapers; * evidence samples; * findings; * assurance report; * follow-up. The assurance record must identify the framework criteria evaluated. *** # 35. Improvement Evidence Potential evidence: * corrective action; * root-cause analysis; * improvement plan; * implementation record; * verification; * lessons learned. *** # 36. Retirement Evidence Potential evidence: * retirement approval; * system shutdown; * final risk state; * residual obligations; * retained records; * lessons learned. *** # 37. Regulatory Evidence Regulatory evidence may include: * regulatory submission; * registration; * declaration; * conformity documentation; * authority communication; * corrective action correspondence. These records are generally framework-specific. They should not automatically become shared evidence. *** # 38. External Assurance Evidence Potential evidence: * certification-body report; * external audit report; * supplier assurance report; * independent evaluation; * technical assessment. The evidence record should preserve: * issuer; * scope; * date; * criteria; * conclusion; * limitations. *** # 39. Evidence Source Classification Each evidence record should identify its source: ```text theme={null} INTERNAL EXTERNAL THIRD_PARTY REGULATORY_AUTHORITY CERTIFICATION_BODY INDEPENDENT_ASSESSOR SYSTEM_GENERATED HUMAN_GENERATED ``` *** # 40. Evidence Ownership Material evidence should have: * evidence owner; * control owner; * system owner where applicable; * reviewer. Ownership should remain clear even when evidence is shared across frameworks. *** # 41. Evidence Period Evidence should identify: * creation date; * effective date; * applicable period; * expiration/review date where appropriate. This prevents old evidence from being reused indefinitely. *** # 42. Evidence Versioning Where evidence is associated with an AI system, the record should identify relevant versions: ```text theme={null} System Version Model Version Data Version Control Version AIGO Version Framework Version ``` This is essential for historical traceability. *** # 43. Evidence Integrity Integrity controls should address: * unauthorized modification; * deletion; * corruption; * provenance; * timestamping; * access control. AIGO Document Integrity and Repository Health mechanisms should support these requirements. *** # 44. Evidence Authentication Where evidence may be contested, AIGO should preserve evidence that establishes: * who created it; * when it was created; * how it was generated; * which system produced it; * whether it was subsequently modified. *** # 45. Evidence Completeness Completeness should be evaluated relative to the specific criterion. For example: ```text theme={null} Risk Assessment ↓ Complete for NIST ↓ Incomplete for EU AI Act ``` This is possible and should be representable. *** # 46. Evidence Relevance Evidence must address the criterion being assessed. A broadly related document is not automatically relevant evidence. *** # 47. Evidence Currency The currency requirement depends on: * framework requirement; * system lifecycle; * risk; * change; * evidence type. There should be no universal AIGO evidence expiration period. *** # 48. Evidence Traceability The minimum relationship is: ```text theme={null} Evidence ↓ AIGO Control ↓ Framework Requirement ``` The full relationship should support: ```text theme={null} Evidence ↓ Activity ↓ Control ↓ Requirement ↓ Framework ``` *** # 49. Reverse Evidence Traceability The system should be able to determine: ```text theme={null} Framework Requirement ↓ Control ↓ Evidence ``` and: ```text theme={null} Evidence ↓ Control ↓ All Supported Requirements ``` *** # 50. Evidence Reuse Decision Before reusing evidence across frameworks, check: ```text theme={null} Same AI System? ↓ Same Version? ↓ Same Evidence Period? ↓ Compatible Scope? ↓ Criterion Addressed? ↓ Sufficient Quality? ↓ Framework-Specific Extensions? ``` Only then should the evidence be marked shared. *** # 51. Shared Evidence A record can be marked: `SHARED` when the same evidence directly supports several framework relationships without significant extensions. Example: ```text theme={null} Approved AI System Profile ├── ISO context ├── NIST MAP └── EU applicability support ``` The actual sufficiency still requires framework-specific validation. *** # 52. Shared Evidence with Extensions Most complex evidence will likely be: `SHARED_WITH_EXTENSIONS` Example: ```text theme={null} Common Risk Assessment ├── common risk analysis ├── EU regulatory fields ├── ISO management-system fields └── NIST contextual fields ``` *** # 53. Framework-Specific Evidence Examples: ```text theme={null} EU AI Act: Regulatory registration evidence ISO: Management-system internal-audit record NIST: Selected AI RMF implementation rationale ``` These should remain framework-specific. *** # 54. Evidence Sufficiency Matrix | Evidence Type | EU AI Act | ISO/IEC 42001 | NIST AI RMF | Typical Reuse | | ----------------------------- | ----------------------- | ----------------- | ----------------- | -------------------- | | AI System Profile | Supporting | Direct | Direct | High | | Risk Assessment | Direct where applicable | Direct | Direct | High with extensions | | Control Assessment | Supporting | Direct | Supporting | Medium | | Monitoring Record | Direct where applicable | Direct | Direct | High | | Incident Record | Direct where applicable | Supporting/direct | Direct | High with extensions | | Change Record | Conditional | Direct | Direct | High | | Competence Record | Conditional | Direct | Supporting | Medium | | Transparency Evidence | Direct where applicable | Supporting | Supporting | Low/medium | | Regulatory Submission | Direct | N/A | N/A | Framework-specific | | Internal Audit | N/A | Direct | Supporting | Framework-specific | | NIST Implementation Rationale | N/A | N/A | Supporting/direct | NIST-specific | *** # 55. Evidence and Framework Extensions A shared record may have extensions: ```text theme={null} Evidence │ ├── EU extension ├── ISO extension └── NIST extension ``` The extension should not duplicate the core record. *** # 56. Evidence Relationship Identifier Recommended format: ```text theme={null} XFW-EVD-REL- ``` Example: ```text theme={null} XFW-EVD-REL-001 ``` Each relationship should identify: * evidence ID; * AIGO control ID; * framework IDs; * sufficiency; * status. *** # 57. Evidence Registry Relationship The machine-readable registry should connect: ```text theme={null} Evidence ↓ AIGO Control ↓ Framework IDs ``` This allows evidence reuse and gap analysis. *** # 58. Evidence Coverage The cross-framework evidence system should calculate: ```text theme={null} Applicable Requirement ↓ Expected Evidence ↓ Evidence Available ↓ Evidence Validated ↓ Evidence Sufficient ``` *** # 59. Evidence Gap Categories Potential gap categories: ```text theme={null} NO_EVIDENCE MISSING_FIELD INSUFFICIENT STALE BROKEN_REFERENCE WRONG_SYSTEM WRONG_VERSION WRONG_SCOPE FRAMEWORK_EXTENSION_MISSING INTEGRITY_FAILURE ``` *** # 60. Evidence Integrity Finding An integrity finding may occur when: * the record cannot be attributed; * the timestamp is missing; * modification history is unclear; * source provenance is unavailable; * evidence has been altered unexpectedly. *** # 61. Evidence Version Finding A finding should occur when: ```text theme={null} Evidence: Model v2 Assurance: Model v1 ``` and no justified relationship exists. Potential finding: `EVIDENCE_VERSION_MISMATCH` *** # 62. Evidence Scope Finding A finding should occur when evidence is outside the applicable scope. Example: ```text theme={null} AIMS Scope: Business Unit A Evidence: Business Unit B ``` Potential finding: `EVIDENCE_SCOPE_MISMATCH` *** # 63. Evidence Currency Finding If evidence has become obsolete because of: * system change; * regulatory change; * control change; * framework version change; the evidence should be re-evaluated. Potential finding: `EVIDENCE_STALE` *** # 64. Evidence and Change Management A material change should trigger evidence review: ```text theme={null} Change ↓ Affected Evidence ↓ Revalidate ↓ Replace / Supplement ↓ Assurance ``` *** # 65. Evidence and Incident Management A significant incident should trigger review of: * risk evidence; * control evidence; * monitoring evidence; * assurance evidence. The incident record should link to affected evidence. *** # 66. Evidence and Improvement Improvement actions should produce new evidence demonstrating implementation. The lifecycle is: ```text theme={null} Finding ↓ Improvement ↓ Implementation ↓ New Evidence ↓ Verification ``` *** # 67. Evidence and Management Review Management Review may consume: * control evidence; * monitoring evidence; * assurance results; * incident evidence; * risk evidence. The record should preserve source relationships. *** # 68. Evidence and Retirement When a system is retired: * operational evidence may become historical; * required records must remain retained; * active monitoring evidence should stop only when appropriate; * legal retention obligations must remain respected. *** # 69. Evidence Security and Privacy Evidence repositories may contain: * personal data; * confidential information; * model details; * security information; * proprietary data. Access controls should therefore reflect evidence sensitivity. *** # 70. Evidence Classification AIGO may classify evidence sensitivity as: ```text theme={null} PUBLIC INTERNAL CONFIDENTIAL RESTRICTED HIGHLY_RESTRICTED ``` This is an AIGO information-governance classification. *** # 71. Evidence Retention Retention should consider: * applicable law; * contractual requirements; * regulatory obligations; * AIMS requirements; * audit requirements; * incident investigations; * organizational policy. A universal retention period should not be invented. *** # 72. Evidence Disposal Evidence disposal should be controlled. Possible states: ```text theme={null} ELIGIBLE_FOR_DISPOSAL DISPOSAL_APPROVED DISPOSED LEGAL_HOLD REGULATORY_HOLD INVESTIGATION_HOLD ``` *** # 73. Legal Hold Evidence subject to: * litigation; * regulatory investigation; * audit; * incident investigation; must not be disposed of until the applicable hold is released. *** # 74. Evidence and Regulatory Deadlines Where a framework requires specific documentation or notification by a deadline, the evidence record should capture: * requirement; * deadline; * responsible owner; * submission; * acknowledgement; * follow-up. The deadline itself remains framework-specific. *** # 75. EU AI Act Evidence Boundary EU AI Act evidence should remain tied to: * applicable legal provision; * role; * system classification; * lifecycle status; * legal timeline; * required documentation. A common AIGO evidence record can support this, but the legal interpretation remains within the EU AI Act mapping. *** # 76. ISO/IEC 42001 Evidence Boundary ISO evidence should remain tied to: * AIMS scope; * management-system requirement; * control; * documented information; * internal audit; * management review; * improvement. *** # 77. NIST AI RMF Evidence Boundary NIST evidence should remain tied to: * selected AI RMF functions; * categories; * outcomes; * organizational rationale; * measurement; * management response. NIST AI RMF remains voluntary and should not be represented as a statutory evidentiary scheme. ([airc.nist.gov](https://airc.nist.gov/airmf-resources/?utm_source=chatgpt.com)) *** # 78. Evidence and Cross-Framework Auditability The evidence model should permit an auditor or reviewer to reconstruct: ```text theme={null} Evidence ↓ Control ↓ Framework ↓ Requirement ↓ Applicability ↓ Assurance ``` *** # 79. Evidence Dashboard Potential metrics: | Metric | Purpose | | --------------------------------------- | --------------- | | Evidence Records | Inventory | | Shared Evidence | Efficiency | | Framework-Specific Evidence | Differentiation | | Evidence Gaps | Risk | | Stale Evidence | Currency | | Version Mismatches | Integrity | | Unvalidated Evidence | Assurance | | Evidence Supporting Multiple Controls | Reuse | | Evidence Supporting Multiple Frameworks | Harmonization | *** # 80. Evidence Quality Score AIGO may use an internal evidence quality model: ```text theme={null} AUTHENTIC INTEGRAL COMPLETE RELEVANT CURRENT TRACEABLE SUFFICIENT ``` The result is an AIGO governance indicator. It is not a legal or certification score. *** # 81. Evidence Assurance The Evidence Coverage and Assurance mechanisms should verify: ```text theme={null} Evidence Exists ↓ Correct Source ↓ Correct System ↓ Correct Version ↓ Correct Period ↓ Correct Scope ↓ Criterion Addressed ↓ Sufficient Quality ``` *** # 82. Common Evidence Example A common AI risk assessment might support: ```text theme={null} EU AI Act → applicable risk-management criterion ISO/IEC 42001 → AIMS risk-management requirement NIST AI RMF → MAP / MANAGE outcome ``` The assessment itself is shared, but each relationship should identify any additional required fields. *** # 83. Common Monitoring Example A monitoring record may support: ```text theme={null} EU AI Act → applicable monitoring/post-market relationship ISO/IEC 42001 → performance evaluation NIST AI RMF → MEASURE / MANAGE ``` Again, the record is shared operationally while the criteria remain separate. *** # 84. Common Change Example A change record may support: ```text theme={null} EU AI Act → significant-change assessment ISO/IEC 42001 → AIMS change planning NIST AI RMF → risk/context reassessment ``` Each relationship requires independent evaluation. *** # 85. Common Assurance Example An assurance report may contain: ```text theme={null} Section A: ISO/IEC 42001 criteria Section B: NIST AI RMF criteria Section C: EU AI Act readiness criteria ``` The combined report should not imply that the conclusions are legally interchangeable. *** # 86. Evidence Reuse Rule The preferred sequence is: ```text theme={null} Existing Evidence ↓ Assess Relevance ↓ Assess Sufficiency ↓ Add Framework Relationship ↓ Reuse ``` not: ```text theme={null} Framework Mapping ↓ Assume Existing Evidence Is Sufficient ``` *** # 87. Evidence Creation Rule Create new evidence only when: * existing evidence is insufficient; * framework-specific information is required; * scope differs; * timing differs; * assurance criteria differ. This reduces evidence duplication. *** # 88. Evidence Extension Rule When possible: ```text theme={null} Existing Evidence + Framework Extension ``` should be preferred over creating a duplicate evidence record. *** # 89. Evidence De-duplication Evidence de-duplication should identify: * duplicate risk assessments; * duplicate monitoring records; * duplicate control tests; * duplicate assurance evidence. Human review should confirm whether records are actually equivalent before consolidation. *** # 90. Evidence Ownership and Accountability A shared evidence record should not have multiple ambiguous owners. One accountable evidence owner should be identified, with framework-specific reviewers where needed. *** # 91. Evidence Review Frequency Review frequency should be determined by: * risk; * system changes; * framework requirements; * evidence type; * operational activity. *** # 92. Evidence Review Triggers Triggers include: * material AI-system change; * new regulation; * framework revision; * incident; * assurance finding; * control change; * management-review decision. *** # 93. Evidence Historical State Historical evidence must remain associated with: * system version; * control version; * framework version; * relevant period. Historical evidence should not be modified to reflect later changes. *** # 94. Evidence Supersession A newer record should reference the older record where it supersedes it. Example: ```text theme={null} EVD-001 ↓ SUPERSEDED BY ↓ EVD-027 ``` Historical auditability must remain intact. *** # 95. Evidence Repository Structure The actual evidence records should remain in the operational evidence repository rather than being duplicated under every mapping package. Conceptually: ```text theme={null} Evidence Repository ↓ AIGO Control ↓ Framework Relationships ``` *** # 96. Cross-Framework Evidence Registry The cross-framework registry should support: ```text theme={null} Evidence ID AIGO Control ID Framework IDs Sufficiency Status Review Date ``` This is defined structurally in: `00-AIGO-Cross-Framework-Mapping-Registry-v0.1.json` *** # 97. Validation Architecture The evidence layer should be checked by: ```text theme={null} Schema Validator Reference Validator Traceability Validator Evidence Coverage Validator Framework Consistency Checker Document Integrity Checker Repository Health Checker ``` *** # 98. Evidence Validation Rules The validation system should verify: ```text theme={null} Evidence ID Exists ↓ Control Exists ↓ Framework Relationship Exists ↓ Applicable Requirement Exists ↓ Scope Matches ↓ Version Matches ↓ Evidence Status Valid ``` *** # 99. Evidence Findings Potential findings include: ```text theme={null} XFW-EVIDENCE-MISSING XFW-EVIDENCE-INSUFFICIENT XFW-EVIDENCE-STALE XFW-EVIDENCE-SCOPE-MISMATCH XFW-EVIDENCE-VERSION-MISMATCH XFW-EVIDENCE-REFERENCE-BROKEN XFW-EVIDENCE-FRAMEWORK-EXTENSION-MISSING XFW-EVIDENCE-INTEGRITY-FAILURE XFW-EVIDENCE-OWNER-MISSING XFW-EVIDENCE-REVIEW-OVERDUE ``` *** # 100. Critical Evidence Findings Potential critical findings include: * a material legal requirement has no evidence; * a critical control lacks evidence; * evidence refers to the wrong AI-system version; * evidence used for regulatory purposes cannot be authenticated; * evidence reused across frameworks does not satisfy one of the criteria; * historical evidence has been altered. *** # 101. Coverage Calculation The evidence coverage calculation should be framework-specific: ```text theme={null} Framework Applicable Requirements ↓ Requirements With Evidence Need ↓ Requirements With Evidence ↓ Requirements With Validated Evidence ↓ Requirements With Sufficient Evidence ``` *** # 102. No Universal Evidence Percentage A combined: `90% evidence coverage` would be misleading if it aggregates different framework requirements. Instead report: ```text theme={null} EU AI Act Evidence Coverage ISO/IEC 42001 Evidence Coverage NIST AI RMF Evidence Coverage ``` and optionally: ```text theme={null} Shared Evidence Reuse ``` as a separate efficiency indicator. *** # 103. Cross-Framework Evidence Maturity AIGO may use: ```text theme={null} Level 1 — Separate Evidence Level 2 — Reusable Evidence Level 3 — Shared Evidence Level 4 — Governed Evidence Relationships Level 5 — Automated Evidence Traceability ``` This is an AIGO maturity model. *** # 104. Evidence and Automation Eventually the AIGO tools should be able to answer: ```text theme={null} Which requirements lack evidence? Which evidence is stale? Which controls have no evidence? Which evidence supports multiple frameworks? Which evidence references obsolete system versions? ``` *** # 105. Evidence and Release Validation Before the AIGO v1 release gate: ```text theme={null} Evidence Schema Valid ↓ Evidence References Valid ↓ Cross-Framework Relationships Valid ↓ Coverage Calculated ↓ No Critical Evidence Gaps ``` Any accepted exceptions must be explicitly recorded. *** # 106. Final Evidence Architecture The complete evidence relationship is: ```text theme={null} Framework ↓ Requirement ↓ Applicability ↓ AIGO Control ↓ Activity ↓ Evidence ↓ Evidence Validation ↓ Framework-Specific Assurance ↓ Finding ↓ Improvement ``` *** # 107. Final Principle The AIGO cross-framework evidence architecture follows one central rule: > **Reuse evidence operationally where justified, but evaluate evidence sufficiency separately for each framework relationship.** One governed evidence record can support many requirements, but no evidence record should be assumed to prove legal, normative, or voluntary-framework obligations without explicit traceability and sufficiency validation. *** # 108. Document Control | Field | Value | | ------------------- | ------------------------------------- | | Document | AIGO Cross-Framework Evidence Mapping | | Version | 0.1 | | Status | Draft | | Document Identifier | `AIGO-MAP-XFW-003` | | Document Type | Cross-Framework Evidence Mapping | | Mapping Package | `AIGO-MAP-XFW` | | Source Frameworks | EU AI Act, ISO/IEC 42001, NIST AI RMF | | Primary Schema | AIGO Evidence Schema | | Owner | | | Framework Reviewers | | | Evidence Reviewer | | | Assurance Reviewer | | | Governance Reviewer | | | Framework Architect | | | Approved By | | | Effective Date | | | Next Review Date | | *** # 109. Document Status **Document:** AIGO — Cross-Framework Evidence Mapping **Version:** 0.1 **Status:** Draft **Working Name:** AIGO **Full Name:** AI Governance Operating Framework **Document Identifier:** `AIGO-MAP-XFW-003` **Document Type:** Cross-Framework Evidence Mapping This document establishes the common evidence architecture for the EU AI Act, ISO/IEC 42001, and NIST AI RMF mappings, enabling controlled evidence reuse and bidirectional traceability while preserving framework-specific applicability, sufficiency, legal or normative significance, versioning, and assurance criteria. End of Document