> ## 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. # 05 AIGO Cross Framework Gap and Coverage Mapping v0.1 # AIGO — Cross-Framework Gap and Coverage Mapping ## 1. Document Purpose This document defines the cross-framework gap-analysis and coverage model for the AIGO mapping layer connecting: * the European Union Artificial Intelligence Act; * ISO/IEC 42001:2023; and * NIST AI RMF 1.0. Its purpose is to determine, for each applicable framework relationship, whether the relevant requirement or outcome is: * mapped; * controlled; * implemented; * evidenced; * monitored; * assured; * subject to a gap; * subject to a framework-specific extension; or * subject to a version or applicability issue. The model is designed to support the AIGO v1 validation and release process. The current EU AI Act baseline must account for Regulation (EU) 2024/1689 and applicable amendments, including Regulation (EU) 2026/1744, which amended Regulation (EU) 2024/1689 and entered into force on 27 July 2026. ISO/IEC 42001:2023 remains the published first edition of the AI management-system standard. NIST AI RMF 1.0 remains the baseline used by the AIGO NIST mapping package; future NIST revisions must be separately versioned and assessed before changing the baseline. This document defines an AIGO governance and validation model. It does not issue legal-compliance, certification, accreditation, or conformity conclusions. *** # 2. Mapping Information | Field | Value | | ------------------- | ----------------------------------------------------------- | | Mapping | AIGO Cross-Framework Gap and Coverage Mapping | | Version | 0.1 | | Status | Draft | | Document Identifier | `AIGO-MAP-XFW-005` | | Document Type | Cross-Framework Gap and Coverage Mapping | | Mapping Package | `AIGO-MAP-XFW` | | Architecture | `AIGO-MAP-XFW-ARCH-001` | | Registry | `00-AIGO-Cross-Framework-Mapping-Registry-v0.1.json` | | Primary Function | Gap detection, coverage analysis, validation, and reporting | *** # 3. Core Principle Cross-framework coverage is not the same as legal or normative compliance. The canonical chain is: ```text theme={null} Framework ↓ Applicable Requirement / Outcome ↓ AIGO Control ↓ Implementation ↓ Evidence ↓ Monitoring ↓ Assurance ↓ Finding ↓ Improvement ``` Coverage must be measured at each layer. A requirement that is mapped but not implemented is not an implemented requirement. A control that is implemented but unsupported by evidence is not an evidenced requirement. Evidence without applicable assurance criteria is not automatically assured. *** # 4. Coverage Dimensions The AIGO coverage model uses the following dimensions: ```text theme={null} 1. Source Coverage 2. Applicability Coverage 3. Requirement Coverage 4. Control Coverage 5. Implementation Coverage 6. Evidence Coverage 7. Monitoring Coverage 8. Assurance Coverage 9. Remediation Coverage 10. Version Coverage 11. Traceability Coverage 12. Cross-Framework Harmonization Coverage ``` Each dimension should be reported separately. *** # 5. Source Coverage Source coverage asks: > Are all declared framework sources and versions represented correctly in the repository? The repository should identify: * framework; * version; * publication; * effective date where relevant; * mapping version; * source status; * review date. For the current package: ```text theme={null} EU AI Act ISO/IEC 42001:2023 NIST AI RMF 1.0 ``` *** # 6. Source Coverage Status Possible values: ```text theme={null} SOURCE_REGISTERED SOURCE_VERIFIED SOURCE_CURRENT SOURCE_UNDER_REVIEW SOURCE_SUPERSEDED SOURCE_RETIRED ``` *** # 7. Applicability Coverage Applicability coverage asks: > Has the organization determined which requirements apply? The model is: ```text theme={null} Framework ↓ Organization ↓ AI Activity ↓ Role ↓ AI System ↓ Classification / Scope ↓ Applicable Requirements ``` *** # 8. Applicability Gap An applicability gap exists when: * the framework applies but no assessment exists; * system role is unresolved; * classification is unresolved; * AIMS scope is unclear; * selected NIST scope is undocumented; * applicability evidence is stale. Potential finding: `XFW-APPLICABILITY-GAP` *** # 9. Requirement Coverage Requirement coverage asks: > Has every applicable framework requirement or selected NIST outcome been mapped to AIGO? Possible statuses: ```text theme={null} UNMAPPED MAPPED PARTIALLY_MAPPED NOT_APPLICABLE CONDITIONAL SUPERSEDED HISTORICAL ``` *** # 10. Requirement Coverage Gap A requirement gap occurs when: ```text theme={null} Applicable Requirement ↓ No AIGO Mapping ``` Potential finding: `XFW-REQUIREMENT-UNMAPPED` This is a higher-priority issue for binding legal requirements than for voluntary framework guidance. *** # 11. Control Coverage Control coverage asks: > Does every applicable requirement have an adequate AIGO control or documented framework-specific extension? The model is: ```text theme={null} Requirement ↓ AIGO Control ↓ Control Objective ↓ Owner ``` *** # 12. Control Coverage Status Possible values: ```text theme={null} NO_CONTROL PARTIAL_CONTROL COMMON_CONTROL FRAMEWORK_SPECIFIC_CONTROL CONTROL_EXTENDED CONTROL_IMPLEMENTED CONTROL_ASSURED ``` *** # 13. Control Gap A control gap exists when: ```text theme={null} Applicable Requirement ↓ No Adequate Control ``` Potential finding: `XFW-CONTROL-GAP` *** # 14. Framework-Specific Control Gap A common AIGO control may exist while a framework-specific extension is missing. Example: ```text theme={null} Common Risk Control + EU AI Act Extension ✗ ``` Potential finding: `XFW-FRAMEWORK-EXTENSION-GAP` This is distinct from a complete absence of a base control. *** # 15. Duplicate-Control Gap Duplicate-control analysis identifies cases where: ```text theme={null} Framework A Mapping ↓ Control A Framework B Mapping ↓ Control B ``` but both controls are operationally equivalent. Potential finding: `XFW-DUPLICATE-CONTROL` The result is a harmonization candidate, not automatically a defect. *** # 16. False-Equivalence Gap A false-equivalence gap occurs when: ```text theme={null} Requirement A ↓ Common Control ↓ Claimed to satisfy Requirement B ``` without evaluating B's distinct criteria. Potential finding: `XFW-FALSE-EQUIVALENCE` This is a critical architectural validation rule. *** # 17. Implementation Coverage Implementation coverage asks: > Has the mapped AIGO control actually been established? Possible states: ```text theme={null} NOT_IMPLEMENTED PLANNED PARTIALLY_IMPLEMENTED IMPLEMENTED IMPLEMENTED_WITH_EXCEPTION SUPERSEDED ``` *** # 18. Implementation Gap A control is mapped but not implemented: ```text theme={null} Requirement ↓ Control ↓ Not Implemented ``` Potential finding: `XFW-IMPLEMENTATION-GAP` *** # 19. Control Ownership Coverage Every material control should have: * control owner; * accountable owner; * operational owner; * evidence owner; * assurance owner where applicable. Potential finding: `XFW-CONTROL-OWNER-GAP` *** # 20. Evidence Coverage Evidence coverage asks: > Is there sufficient evidence supporting the implementation of the relevant control and requirement? The model is: ```text theme={null} Requirement ↓ Control ↓ Evidence Need ↓ Evidence ``` *** # 21. Evidence Coverage Status Possible values: ```text theme={null} NO_EVIDENCE PARTIAL_EVIDENCE EVIDENCE_AVAILABLE EVIDENCE_VALIDATED EVIDENCE_SUFFICIENT EVIDENCE_CURRENT EVIDENCE_ASSURED ``` *** # 22. Evidence Gap Potential findings: ```text theme={null} XFW-EVIDENCE-MISSING XFW-EVIDENCE-INSUFFICIENT XFW-EVIDENCE-STALE XFW-EVIDENCE-SCOPE-MISMATCH XFW-EVIDENCE-VERSION-MISMATCH XFW-EVIDENCE-INTEGRITY-FAILURE ``` *** # 23. Shared Evidence Coverage AIGO should distinguish: ```text theme={null} SHARED SHARED_WITH_EXTENSIONS FRAMEWORK_SPECIFIC INSUFFICIENT_FOR_ONE_OR_MORE_FRAMEWORKS ``` A shared evidence record is efficient, but each framework relationship must retain its own sufficiency result. *** # 24. Evidence Reuse Efficiency AIGO may report: ```text theme={null} Shared Evidence Reuse Rate ``` as an operational efficiency metric. It should not be treated as a compliance metric. *** # 25. Monitoring Coverage Monitoring coverage asks: > Are implemented controls and AI-system risks being monitored where monitoring is required or appropriate? The model is: ```text theme={null} Control ↓ Indicator ↓ Measurement ↓ Threshold ↓ Analysis ↓ Action ``` *** # 26. Monitoring Gap A monitoring gap exists where: * monitoring is required but absent; * metrics exist but are not analyzed; * thresholds are undefined where needed; * alerts do not generate action; * monitoring evidence is stale. Potential finding: `XFW-MONITORING-GAP` *** # 27. Assurance Coverage Assurance coverage asks: > Has the applicable requirement/control/evidence relationship been independently or objectively evaluated according to the defined AIGO assurance scope? Possible statuses: ```text theme={null} NOT_ASSURED PLANNED IN_PROGRESS ASSURED FINDINGS_OPEN FOLLOW_UP_REQUIRED VERIFIED ``` *** # 28. Assurance Gap Potential findings: ```text theme={null} XFW-ASSURANCE-GAP XFW-ASSURANCE-CRITERIA-GAP XFW-ASSURANCE-EVIDENCE-GAP XFW-ASSURANCE-SCOPE-GAP XFW-ASSURANCE-VERSION-GAP XFW-FALSE-ASSURANCE ``` *** # 29. Framework-Specific Assurance Coverage Coverage must be calculated independently for: ```text theme={null} EU AI Act ISO/IEC 42001 NIST AI RMF ``` Do not combine the three into a single compliance score. *** # 30. Remediation Coverage Remediation coverage asks: > Are identified gaps being corrected and independently verified? The model is: ```text theme={null} Finding ↓ Root Cause ↓ Corrective Action ↓ Implementation ↓ Evidence ↓ Verification ↓ Closure ``` *** # 31. Remediation Status Possible values: ```text theme={null} OPEN ACTION_PLANNED ACTION_IN_PROGRESS ACTION_IMPLEMENTED VERIFICATION_PENDING VERIFIED_EFFECTIVE VERIFIED_INEFFECTIVE CLOSED ``` *** # 32. Remediation Gap A remediation gap exists when: * critical findings remain overdue; * corrective actions lack owners; * evidence is missing; * verification has not occurred; * repeated findings remain unresolved. Potential finding: `XFW-REMEDIATION-GAP` *** # 33. Version Coverage Version coverage asks: > Does each mapping relationship reference the correct source version? The model is: ```text theme={null} Framework Version + Requirement Version + AIGO Mapping Version + AIGO Control Version + Evidence Version + Assurance Version ``` *** # 34. Version Gap Potential findings: ```text theme={null} XFW-VERSION-GAP XFW-VERSION-CONFLICT XFW-STALE-MAPPING XFW-STALE-EVIDENCE XFW-STALE-ASSURANCE ``` *** # 35. Current EU AI Act Baseline The current legal mapping must identify the AI Act's governing text and applicable amendments. Regulation (EU) 2026/1744 amended Regulation (EU) 2024/1689 and entered into force on 27 July 2026. The cross-framework coverage engine must therefore not treat an older unamended AI Act snapshot as the current legal baseline. *** # 36. Current ISO Baseline The ISO mapping baseline remains: `ISO/IEC 42001:2023` ISO lists the standard as published, Edition 1, with publication date December 2023. Future revisions or related standards must be separately versioned. *** # 37. Current NIST Baseline The NIST package uses: `NIST AI RMF 1.0` Any future NIST revision must trigger controlled impact analysis before it changes coverage conclusions. *** # 38. Traceability Coverage Traceability coverage asks whether the complete relationship chain can be reconstructed: ```text theme={null} Framework ↓ Requirement ↓ Applicability ↓ AIGO Control ↓ Process ↓ Evidence ↓ Monitoring ↓ Assurance ↓ Finding ↓ Improvement ``` *** # 39. Traceability Gap Potential findings: ```text theme={null} XFW-TRACEABILITY-GAP XFW-BROKEN-REFERENCE XFW-ORPHAN-CONTROL XFW-ORPHAN-EVIDENCE XFW-ORPHAN-ASSURANCE ``` *** # 40. Reverse Traceability Coverage should also work in reverse. ### From control ```text theme={null} AIGO Control ↓ EU AI Act ISO/IEC 42001 NIST AI RMF ``` ### From evidence ```text theme={null} Evidence ↓ Control ↓ Framework Requirements ``` ### From finding ```text theme={null} Finding ↓ Control ↓ Evidence ↓ Frameworks ``` *** # 41. Cross-Framework Harmonization Coverage This dimension asks: > How effectively has the organization reduced duplicate operational mechanisms while retaining framework-specific requirements? Possible statuses: ```text theme={null} SEPARATE PARTIALLY_HARMONIZED COMMON_CONTROL COMMON_EVIDENCE COMMON_ASSURANCE FULLY_INTEGRATED ``` *** # 42. Harmonization Gap A harmonization gap exists when: * identical operational processes are duplicated unnecessarily; * common controls are defined separately without justification; * evidence is duplicated; * assurance is duplicated. Potential finding: `XFW-HARMONIZATION-GAP` *** # 43. Harmonization Boundary Harmonization must stop where source-specific legal, normative, or technical requirements diverge. Therefore: ```text theme={null} Common Operations + Framework Extensions ``` is preferred over forced full consolidation. *** # 44. Coverage Matrix The cross-framework package should maintain a conceptual matrix: | Coverage Dimension | EU AI Act | ISO/IEC 42001 | NIST AI RMF | | ----------------------- | ------------------------- | --------------------------- | ----------------------------- | | Source | Required | Required | Required | | Applicability | Required | Required | Required | | Requirements / Outcomes | Required | Required | Selected | | AIGO Controls | Required | Required | Required | | Implementation | Required | Required | Adopted scope | | Evidence | Required | Required | Required for adopted outcomes | | Monitoring | Applicable | Required where defined | Risk-based | | Assurance | Framework-specific | Internal/assessment context | Organization-defined | | Remediation | Required where applicable | Required | Risk-based | | Versioning | Required | Required | Required | This matrix is descriptive and should ultimately be generated from machine-readable registry relationships. *** # 45. Coverage State Machine The preferred lifecycle is: ```text theme={null} UNMAPPED ↓ MAPPED ↓ CONTROLLED ↓ IMPLEMENTED ↓ EVIDENCED ↓ MONITORED ↓ ASSURED ↓ VERIFIED ``` At any stage, a gap may send the relationship to: ```text theme={null} GAP ``` which then enters the improvement process. *** # 46. Requirement Coverage State ```text theme={null} UNMAPPED ↓ MAPPED ↓ APPLICABILITY_CONFIRMED ↓ CONTROLLED ↓ EVIDENCED ↓ ASSURED ``` *** # 47. Control Coverage State ```text theme={null} CONTROL_DEFINED ↓ OWNER_ASSIGNED ↓ IMPLEMENTED ↓ EVIDENCED ↓ MONITORED ↓ ASSURED ``` *** # 48. Evidence Coverage State ```text theme={null} EVIDENCE_EXPECTED ↓ EVIDENCE_COLLECTED ↓ EVIDENCE_VALIDATED ↓ EVIDENCE_CURRENT ↓ EVIDENCE_SUFFICIENT ↓ EVIDENCE_ASSURED ``` *** # 49. Assurance Coverage State ```text theme={null} ASSURANCE_REQUIRED ↓ ASSURANCE_PLANNED ↓ ASSURANCE_EXECUTED ↓ RESULT_RECORDED ↓ FINDINGS_RESOLVED ↓ ASSURANCE_VERIFIED ``` *** # 50. Gap Taxonomy The master taxonomy should include: ```text theme={null} SOURCE_GAP APPLICABILITY_GAP REQUIREMENT_GAP CONTROL_GAP FRAMEWORK_EXTENSION_GAP IMPLEMENTATION_GAP OWNER_GAP EVIDENCE_GAP MONITORING_GAP ASSURANCE_GAP REMEDIATION_GAP TRACEABILITY_GAP VERSION_GAP HARMONIZATION_GAP CONFLICT_GAP DUPLICATION_GAP ``` *** # 51. Gap Severity AIGO may classify a gap as: ```text theme={null} CRITICAL HIGH MEDIUM LOW INFORMATIONAL ``` Severity should consider: * legal status; * AI-system impact; * safety; * fundamental rights; * risk; * control criticality; * evidence; * recurrence. *** # 52. Criticality Rule A gap related to a binding legal requirement should generally receive higher priority than an otherwise comparable gap concerning an optional framework recommendation. However, actual severity remains dependent on the system and context. *** # 53. Priority Factors Potential scoring dimensions: | Factor | Consideration | | ---------------- | ----------------------------------- | | Normative Status | Binding vs voluntary | | AI Impact | Potential harm | | Risk | Severity / likelihood | | Rights | Fundamental-rights impact | | Safety | Safety consequence | | Scope | Number of systems affected | | Recurrence | Repeat finding | | Evidence | Demonstrability | | Deadline | Regulatory or organizational timing | *** # 54. Gap Prioritization AIGO should prioritize: ```text theme={null} Legal / Critical ↓ High Risk ↓ High Control Criticality ↓ Evidence / Assurance ↓ Operational Efficiency ``` This avoids spending excessive effort on low-value harmonization while critical requirements remain uncovered. *** # 55. Framework-Specific Gap A framework-specific gap should be recorded when: ```text theme={null} AIGO Common Control + Framework-Specific Requirement ↓ Extension Missing ``` Example: ```text theme={null} Common Transparency Control + EU statutory transparency detail ✗ ``` *** # 56. Common-Control Gap A common-control gap exists when several frameworks require related governance capabilities but no adequate AIGO control exists. Potential finding: `XFW-COMMON-CONTROL-GAP` *** # 57. Evidence Gap A common control exists and operates, but insufficient evidence exists. Example: ```text theme={null} Control ✓ Implementation ✓ Evidence ✗ ``` This is a critical distinction from a control-design failure. *** # 58. Assurance Gap Evidence exists but no assurance has been performed where assurance is required or planned. Example: ```text theme={null} Control ✓ Evidence ✓ Assurance ✗ ``` *** # 59. Version Gap A source framework changed but the AIGO mapping has not been updated. Example: ```text theme={null} New Source Version ↓ Old Mapping ✗ ``` Potential status: `STALE_MAPPING` *** # 60. Conflict Gap A conflict exists where two requirements impose materially different obligations or interpretations. The correct response is: ```text theme={null} Identify ↓ Analyze ↓ Document ↓ Resolve ↓ Approve ↓ Validate ``` Not silent consolidation. *** # 61. Coverage Report Structure A generated cross-framework coverage report should contain: ```text theme={null} 1. Executive Summary 2. Framework Status 3. Applicability 4. Requirement Coverage 5. Control Coverage 6. Evidence Coverage 7. Monitoring Coverage 8. Assurance Coverage 9. Open Gaps 10. Critical Findings 11. Cross-Framework Overlap 12. Framework-Specific Extensions 13. Version Currency 14. Remediation Status 15. Management Actions ``` *** # 62. Framework Summary The summary should identify: ```text theme={null} EU AI Act Requirements applicable: Mapped: Controlled: Evidenced: Assured: Critical gaps: ISO/IEC 42001 Requirements applicable: Mapped: Controlled: Evidenced: Assured: Critical gaps: NIST AI RMF Outcomes selected: Mapped: Controlled: Evidenced: Assured: Critical gaps: ``` Actual figures should be generated from validated repository data. *** # 63. Do Not Aggregate Compliance Scores The report must not claim: ```text theme={null} AIGO = 95% compliant ``` based on three framework coverage percentages. Instead report: ```text theme={null} EU AI Act coverage ISO/IEC 42001 coverage NIST AI RMF coverage ``` separately. *** # 64. Common-Control Coverage AIGO may additionally report: ```text theme={null} Common Controls Shared Evidence Shared Assurance Framework Extensions ``` These are operational harmonization metrics rather than compliance scores. *** # 65. Gap Aging Each open gap should record: * discovery date; * due date; * current status; * owner; * severity; * days open. Potential metric: `OPEN_GAP_AGE` *** # 66. Overdue Gaps A gap may become: `OVERDUE` when its approved remediation date has passed. Critical overdue gaps should be escalated through governance. *** # 67. Repeat Gaps If the same or materially similar gap recurs: `REPEAT_GAP` should be recorded. This can indicate: * ineffective corrective action; * control-design weakness; * governance weakness; * insufficient monitoring. *** # 68. System-Level Coverage Coverage should ultimately be computable per AI system: ```text theme={null} AI System ↓ Applicable Frameworks ↓ Requirements ↓ Controls ↓ Evidence ↓ Assurance ↓ Open Gaps ``` *** # 69. Portfolio-Level Coverage Coverage should also roll up: ```text theme={null} AI System ↓ Business Unit ↓ AI Portfolio ↓ Enterprise ``` Aggregation must retain source identities. *** # 70. Control-Level Coverage For each AIGO control: ```text theme={null} AIGO Control ↓ Framework Relationships ↓ Applicable Requirements ↓ Evidence ↓ Assurance ↓ Findings ``` *** # 71. Evidence-Level Coverage For each evidence record: ```text theme={null} Evidence ↓ Controls Supported ↓ Frameworks Supported ↓ Sufficiency ↓ Currentness ``` *** # 72. Assurance-Level Coverage For each assurance activity: ```text theme={null} Assurance ↓ Criteria ↓ Controls ↓ Evidence ↓ Findings ↓ Conclusion ``` *** # 73. Coverage Automation The AIGO validators should eventually calculate coverage automatically. Conceptual pipeline: ```text theme={null} Registry ↓ Load Frameworks ↓ Load Requirements ↓ Load Controls ↓ Resolve Relationships ↓ Evaluate Applicability ↓ Evaluate Evidence ↓ Evaluate Assurance ↓ Generate Coverage ``` *** # 74. Validation Rules The cross-framework coverage validator should verify: ```text theme={null} Every Applicable Requirement → Has Mapping Every Mapping → Has Valid Control Every Common Control → Resolves to AIGO Control Every Evidence Relationship → Resolves to Evidence Every Assurance Relationship → Resolves to Assurance Every Critical Gap → Has Owner or Accepted Exception ``` *** # 75. Coverage Validator Outputs Potential output categories: ```text theme={null} PASS PASS_WITH_WARNINGS FAIL NOT_APPLICABLE ``` Example: ```text theme={null} EU AI Act: FAIL — 2 critical control gaps ISO/IEC 42001: PASS_WITH_WARNINGS — 3 evidence gaps NIST AI RMF: PASS — selected outcomes covered ``` *** # 76. Warning vs Failure A warning may represent: * optional evidence enhancement; * low-priority gap; * future framework change; * harmonization opportunity. A failure should represent: * critical missing requirement; * broken traceability; * invalid reference; * critical evidence failure; * critical assurance failure. *** # 77. Accepted Exceptions Not every gap must block release if it is: * documented; * risk-assessed; * approved; * time-bounded; * monitored. Exception status: ```text theme={null} ACCEPTED_EXCEPTION ``` must include: * rationale; * owner; * authority; * expiry; * compensating control. *** # 78. V1 Release Gate For AIGO v1, the cross-framework layer should require: ```text theme={null} ✓ Framework sources verified ✓ Versions verified ✓ Requirements mapped ✓ Applicability model defined ✓ Common controls mapped ✓ Framework-specific extensions identified ✓ Evidence relationships validated ✓ Assurance relationships validated ✓ Critical gaps resolved or formally accepted ✓ No false-equivalence findings ✓ Registry synchronized ``` *** # 79. V1 Critical-Failure Conditions The cross-framework package should fail the v1 gate when: * a binding legal requirement is unmapped; * a critical control has no owner; * a critical requirement has no evidence; * critical evidence references the wrong system/version; * assurance claims exceed their criteria; * source versions conflict without resolution; * framework-specific obligations are incorrectly merged. *** # 80. V1 Non-Blocking Conditions Potential non-blocking items include: * low-priority evidence enhancement; * future profile mappings; * additional harmonization opportunities; * optimized evidence reuse; * low-risk duplicate-control candidates. These should be recorded as backlog items. *** # 81. Cross-Framework Gap Registry The machine-readable registry should eventually support: ```text theme={null} gapId frameworkId requirementId aigoControlId gapType severity status owner discoveredDate dueDate evidenceIds assuranceIds correctiveActionIds ``` *** # 82. Gap Status Possible values: ```text theme={null} OPEN UNDER_REVIEW ACTION_PLANNED IN_REMEDIATION MITIGATED ACCEPTED_EXCEPTION VERIFICATION_PENDING VERIFIED CLOSED SUPERSEDED ``` *** # 83. Gap Relationship to AIGO Schemas | Gap Function | Primary Schema | | ------------------------- | -------------------- | | Requirement applicability | Assessment | | Control gap | Control / Assessment | | Evidence gap | Evidence | | Assurance gap | Assurance | | Incident-related gap | Incident | | Corrective action | Improvement | | Change-driven gap | Change | | Management escalation | Management Review | | Retirement gap | Retirement | | Governance ownership | Governance | *** # 84. Gap Relationship to Tools The following tools should eventually consume gap data: ```text theme={null} Reference Validator Traceability Validator Control Coverage Validator Evidence Coverage Validator Framework Consistency Checker Document Integrity Checker Repository Health Checker ``` The Schema Validator should validate the machine-readable gap data once a dedicated gap record schema is introduced. *** # 85. Cross-Framework Consistency The consistency checker should identify: * same requirement mapped to contradictory controls; * same control assigned different meanings; * inconsistent framework versions; * incompatible applicability; * duplicate control identifiers; * incompatible evidence relationships. *** # 86. Repository Health Integration Repository health should include: ```text theme={null} Source Currency + Mapping Coverage + Control Coverage + Evidence Coverage + Assurance Coverage + Gap Status + Traceability + Reference Integrity ``` *** # 87. Management Dashboard The consolidated dashboard should show: ### Framework Risk * open critical gaps; * high-risk gaps; * overdue gaps. ### Control Risk * control gaps; * ineffective controls; * shared-control failures. ### Evidence Risk * evidence gaps; * stale evidence; * integrity problems. ### Assurance Risk * assurance gaps; * overdue assurance; * repeat findings. ### Harmonization * common controls; * shared evidence; * shared assurance; * framework-specific extensions. *** # 88. Gap Trend The system should support tracking: ```text theme={null} New Gaps - Closed Gaps = Net Gap Change ``` over time. This is useful for management review. *** # 89. Repeat-Finding Trend Track: ```text theme={null} Repeat Findings / Total Findings ``` as an internal control-maturity indicator. *** # 90. Evidence-Gap Trend Track: ```text theme={null} Evidence Gaps / Applicable Requirements ``` separately by framework. *** # 91. Assurance-Gap Trend Track: ```text theme={null} Unassured Applicable Requirements / Applicable Requirements ``` separately by framework. *** # 92. Common-Control Efficiency AIGO may track: ```text theme={null} Requirements Supported by Shared Controls / Total Mapped Requirements ``` This measures harmonization efficiency. It must not be interpreted as evidence that requirements are equivalent. *** # 93. Shared-Evidence Efficiency AIGO may track: ```text theme={null} Framework Relationships Supported by Shared Evidence / Total Evidence Relationships ``` This is an operational efficiency metric. *** # 94. Shared-Assurance Efficiency AIGO may track: ```text theme={null} Framework Criteria Assessed Through Combined Assurance / Total Assurance Relationships ``` Again, this is not a compliance measure. *** # 95. Framework-Specific Burden The cross-framework layer should identify the additional operational burden created by framework-specific requirements. Examples: * extra evidence fields; * extra testing; * extra reporting; * statutory deadlines; * additional approval; * external assessment. *** # 96. Harmonization Decision Model For each potential overlap: ```text theme={null} Potential Overlap ↓ Compare Requirements ↓ Compare Objective ↓ Compare Scope ↓ Compare Evidence ↓ Compare Assurance ↓ Common Control? ┌───┴───┐ YES NO ↓ ↓ Harmonize Extension / Separate Control ``` *** # 97. Gap Closure Model A gap is closed only when: ```text theme={null} Issue Identified ↓ Root Cause ↓ Action ↓ Implementation ↓ Evidence ↓ Verification ↓ Effective ``` A management statement alone is insufficient. *** # 98. Framework-Specific Closure A common control may close one framework gap while another remains open. Example: ```text theme={null} Common Control ↓ EU Gap: CLOSED ISO Gap: CLOSED NIST Gap: OPEN ``` This is valid and must be represented. *** # 99. Control-Specific Closure A control may be effective operationally while a framework-specific documentation extension remains open. Example: ```text theme={null} Control: Effective EU Extension: Open ``` Therefore gap closure is relationship-specific. *** # 100. Gap Escalation Critical or overdue gaps should escalate to: ```text theme={null} Control Owner ↓ Governance Owner ↓ Management Review ``` and to legal/compliance leadership where required. *** # 101. Legal Escalation Legal or regulatory uncertainty should be routed to appropriate legal/compliance review rather than resolved by an automated equivalence algorithm. *** # 102. Source-Update Impact A framework change should produce: ```text theme={null} Source Update ↓ Affected Requirements ↓ Affected Mappings ↓ Affected Controls ↓ Affected Evidence ↓ Affected Assurance ↓ Affected Gaps ``` *** # 103. Historical Gap State Historical gaps should retain: * original requirement; * version; * finding; * remediation; * evidence; * closure; * assurance. This supports auditability. *** # 104. Gap Archive Closed gaps should be archived, not deleted. The system should support: ```text theme={null} ACTIVE HISTORICAL SUPERSEDED ``` states. *** # 105. Cross-Framework Gap and Coverage Report The final generated report should contain: ```text theme={null} 01 Executive Summary 02 Source / Version Status 03 Applicability Coverage 04 Requirement Coverage 05 Control Coverage 06 Implementation Coverage 07 Evidence Coverage 08 Monitoring Coverage 09 Assurance Coverage 10 Open Gaps 11 Critical Gaps 12 Remediation 13 Cross-Framework Harmonization 14 Framework-Specific Extensions 15 Version Currency 16 Release-Gate Status ``` *** # 106. Executive Summary Example A future generated report may state: ```text theme={null} EU AI Act Critical gaps: 0 High gaps: 3 Evidence gaps: 5 Assurance gaps: 2 ISO/IEC 42001 Critical gaps: 0 High gaps: 1 Evidence gaps: 3 Assurance gaps: 1 NIST AI RMF Critical gaps: 0 High gaps: 2 Evidence gaps: 2 Assurance gaps: 1 ``` The values must be generated from actual validated repository data. *** # 107. No Manual Coverage Claims Coverage percentages should not be typed manually into mapping documents. They should be derived from: * the registry; * validated requirements; * controls; * evidence; * assurance; * gap records. *** # 108. Registry as Coverage Source The cross-framework registry should become the machine-readable source for: ```text theme={null} Framework Requirement Control Evidence Assurance Gap Version Applicability ``` The narrative documents explain the model. The registry supplies machine-readable relationships. *** # 109. Coverage Automation Architecture The intended future pipeline is: ```text theme={null} Mapping Registry ↓ Requirement Loader ↓ Control Resolver ↓ Applicability Evaluator ↓ Evidence Resolver ↓ Assurance Resolver ↓ Gap Engine ↓ Coverage Engine ↓ Report Generator ``` *** # 110. Validation Output The cross-framework validator should produce structured results such as: ```text theme={null} PASS WARN FAIL NOT_APPLICABLE ``` with: * identifier; * severity; * source framework; * requirement; * control; * evidence; * assurance; * recommended action. *** # 111. Repository-Level Release Gate AIGO v1 should use the following sequence: ```text theme={null} Source Validation ↓ Requirement Validation ↓ Control Validation ↓ Evidence Validation ↓ Assurance Validation ↓ Gap Validation ↓ Repository Health ↓ Release Gate ``` *** # 112. V1 Release Status Possible repository-level statuses: ```text theme={null} NOT_READY READY_WITH_WARNINGS READY BLOCKED ``` *** # 113. V1 Blocking Rule A repository should be: `BLOCKED` when any unaccepted critical issue exists in: * source integrity; * requirement mapping; * control coverage; * evidence; * assurance; * traceability; * versioning. *** # 114. V1 Warning Rule A repository may be: `READY_WITH_WARNINGS` when only: * low-risk gaps; * planned improvements; * future framework updates; * optional harmonization improvements; remain. *** # 115. V1 Ready Rule A repository may be: `READY` when: ```text theme={null} All Critical Checks Pass + All Critical Gaps Closed or Formally Accepted + Registry Synchronized + Traceability Valid + Coverage Generated + Known Limitations Documented ``` *** # 116. Known-Limitations Register The cross-framework package should maintain explicit limitations where: * source interpretation is unresolved; * framework guidance is evolving; * evidence is unavailable; * legal applicability needs counsel; * an external certification decision remains outstanding. *** # 117. Governance of Gap Decisions Gap acceptance should identify: * decision-maker; * rationale; * risk; * compensating control; * expiry date; * next review. *** # 118. Cross-Framework Gap Ownership Each material gap should have: ```text theme={null} Gap Owner Control Owner Evidence Owner Assurance Owner Governance Owner ``` where applicable. *** # 119. Gap Review Frequency Open gaps should be reviewed according to: * severity; * regulatory deadlines; * risk; * remediation complexity; * framework requirement. Critical gaps should receive frequent management review. *** # 120. Final Coverage Architecture The full model is: ```text theme={null} Framework ↓ Requirement ↓ Applicability ↓ Control ↓ Implementation ↓ Evidence ↓ Monitoring ↓ Assurance ↓ Gap ↓ Remediation ↓ Verification ↓ Coverage ``` Coverage is therefore a lifecycle property, not a single checkbox. *** # 121. Final Principle The AIGO cross-framework gap and coverage architecture follows one central principle: > **Measure coverage separately at every governance layer and separately for every framework, then use the common AIGO control architecture to identify where operational mechanisms can be shared and where framework-specific gaps remain.** This prevents a common control, shared evidence record, or combined assurance activity from being mistaken for universal compliance. *** # 122. Document Control | Field | Value | | ------------------- | ------------------------------------------------- | | Document | AIGO Cross-Framework Gap and Coverage Mapping | | Version | 0.1 | | Status | Draft | | Document Identifier | `AIGO-MAP-XFW-005` | | Document Type | Cross-Framework Gap and Coverage Mapping | | Mapping Package | `AIGO-MAP-XFW` | | Source Frameworks | EU AI Act, ISO/IEC 42001, NIST AI RMF | | Primary Function | Gap analysis, coverage, and v1 release validation | | Owner | | | Framework Reviewers | | | Governance Reviewer | | | Control Reviewer | | | Evidence Reviewer | | | Assurance Reviewer | | | Framework Architect | | | Approved By | | | Effective Date | | | Next Review Date | | *** # 123. Document Status **Document:** AIGO — Cross-Framework Gap and Coverage Mapping **Version:** 0.1 **Status:** Draft **Working Name:** AIGO **Full Name:** AI Governance Operating Framework **Document Identifier:** `AIGO-MAP-XFW-005` **Document Type:** Cross-Framework Gap and Coverage Mapping This document establishes the cross-framework gap taxonomy, coverage lifecycle, evidence and assurance coverage model, version controls, harmonization metrics, remediation workflow, and AIGO v1 release-gate criteria for the EU AI Act, ISO/IEC 42001, and NIST AI RMF mapping packages. End of Document