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:

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:

Source Coverage
Applicability Coverage
Requirement Coverage
Control Coverage
Implementation Coverage
Evidence Coverage
Monitoring Coverage
Assurance Coverage
Remediation Coverage
Version Coverage
Traceability Coverage
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:

EU AI Act
ISO/IEC 42001:2023
NIST AI RMF 1.0

6. Source Coverage Status

Possible values:

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:

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:

UNMAPPED
MAPPED
PARTIALLY_MAPPED
NOT_APPLICABLE
CONDITIONAL
SUPERSEDED
HISTORICAL

10. Requirement Coverage Gap

A requirement gap occurs when:

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:

Requirement
      ↓
AIGO Control
      ↓
Control Objective
      ↓
Owner

12. Control Coverage Status

Possible values:

NO_CONTROL
PARTIAL_CONTROL
COMMON_CONTROL
FRAMEWORK_SPECIFIC_CONTROL
CONTROL_EXTENDED
CONTROL_IMPLEMENTED
CONTROL_ASSURED

13. Control Gap

A control gap exists when:

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:

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:

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:

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:

NOT_IMPLEMENTED
PLANNED
PARTIALLY_IMPLEMENTED
IMPLEMENTED
IMPLEMENTED_WITH_EXCEPTION
SUPERSEDED

18. Implementation Gap

A control is mapped but not implemented:

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:

Requirement
      ↓
Control
      ↓
Evidence Need
      ↓
Evidence

21. Evidence Coverage Status

Possible values:

NO_EVIDENCE
PARTIAL_EVIDENCE
EVIDENCE_AVAILABLE
EVIDENCE_VALIDATED
EVIDENCE_SUFFICIENT
EVIDENCE_CURRENT
EVIDENCE_ASSURED

22. Evidence Gap

Potential findings:

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:

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:

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:

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:

NOT_ASSURED
PLANNED
IN_PROGRESS
ASSURED
FINDINGS_OPEN
FOLLOW_UP_REQUIRED
VERIFIED

28. Assurance Gap

Potential findings:

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:

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:

Finding
      ↓
Root Cause
      ↓
Corrective Action
      ↓
Implementation
      ↓
Evidence
      ↓
Verification
      ↓
Closure

31. Remediation Status

Possible values:

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:

Framework Version
      +
Requirement Version
      +
AIGO Mapping Version
      +
AIGO Control Version
      +
Evidence Version
      +
Assurance Version

34. Version Gap

Potential findings:

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:

Framework
      ↓
Requirement
      ↓
Applicability
      ↓
AIGO Control
      ↓
Process
      ↓
Evidence
      ↓
Monitoring
      ↓
Assurance
      ↓
Finding
      ↓
Improvement

39. Traceability Gap

Potential findings:

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

AIGO Control
      ↓
EU AI Act
ISO/IEC 42001
NIST AI RMF

From evidence

Evidence
      ↓
Control
      ↓
Framework Requirements

From finding

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:

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:

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:

UNMAPPED
   ↓
MAPPED
   ↓
CONTROLLED
   ↓
IMPLEMENTED
   ↓
EVIDENCED
   ↓
MONITORED
   ↓
ASSURED
   ↓
VERIFIED

At any stage, a gap may send the relationship to:

GAP

which then enters the improvement process.

46. Requirement Coverage State

UNMAPPED
    ↓
MAPPED
    ↓
APPLICABILITY_CONFIRMED
    ↓
CONTROLLED
    ↓
EVIDENCED
    ↓
ASSURED

47. Control Coverage State

CONTROL_DEFINED
    ↓
OWNER_ASSIGNED
    ↓
IMPLEMENTED
    ↓
EVIDENCED
    ↓
MONITORED
    ↓
ASSURED

48. Evidence Coverage State

EVIDENCE_EXPECTED
      ↓
EVIDENCE_COLLECTED
      ↓
EVIDENCE_VALIDATED
      ↓
EVIDENCE_CURRENT
      ↓
EVIDENCE_SUFFICIENT
      ↓
EVIDENCE_ASSURED

49. Assurance Coverage State

ASSURANCE_REQUIRED
      ↓
ASSURANCE_PLANNED
      ↓
ASSURANCE_EXECUTED
      ↓
RESULT_RECORDED
      ↓
FINDINGS_RESOLVED
      ↓
ASSURANCE_VERIFIED

50. Gap Taxonomy

The master taxonomy should include:

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:

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:

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:

AIGO Common Control
      +
Framework-Specific Requirement
      ↓
Extension Missing

Example:

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:

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:

Control
   ✓
Evidence
   ✓
Assurance
   ✗

59. Version Gap

A source framework changed but the AIGO mapping has not been updated. Example:

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:

Identify
 ↓
Analyze
 ↓
Document
 ↓
Resolve
 ↓
Approve
 ↓
Validate

Not silent consolidation.

61. Coverage Report Structure

A generated cross-framework coverage report should contain:

Executive Summary
Framework Status
Applicability
Requirement Coverage
Control Coverage
Evidence Coverage
Monitoring Coverage
Assurance Coverage
Open Gaps
Critical Findings
Cross-Framework Overlap
Framework-Specific Extensions
Version Currency
Remediation Status
Management Actions

62. Framework Summary

The summary should identify:

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:

AIGO = 95% compliant

based on three framework coverage percentages. Instead report:

EU AI Act coverage
ISO/IEC 42001 coverage
NIST AI RMF coverage

separately.

64. Common-Control Coverage

AIGO may additionally report:

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:

AI System
   ↓
Applicable Frameworks
   ↓
Requirements
   ↓
Controls
   ↓
Evidence
   ↓
Assurance
   ↓
Open Gaps

69. Portfolio-Level Coverage

Coverage should also roll up:

AI System
    ↓
Business Unit
    ↓
AI Portfolio
    ↓
Enterprise

Aggregation must retain source identities.

70. Control-Level Coverage

For each AIGO control:

AIGO Control
   ↓
Framework Relationships
   ↓
Applicable Requirements
   ↓
Evidence
   ↓
Assurance
   ↓
Findings

71. Evidence-Level Coverage

For each evidence record:

Evidence
   ↓
Controls Supported
   ↓
Frameworks Supported
   ↓
Sufficiency
   ↓
Currentness

72. Assurance-Level Coverage

For each assurance activity:

Assurance
   ↓
Criteria
   ↓
Controls
   ↓
Evidence
   ↓
Findings
   ↓
Conclusion

73. Coverage Automation

The AIGO validators should eventually calculate coverage automatically. Conceptual pipeline:

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:

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:

PASS
PASS_WITH_WARNINGS
FAIL
NOT_APPLICABLE

Example:

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:

ACCEPTED_EXCEPTION

must include:

rationale;
owner;
authority;
expiry;
compensating control.

78. V1 Release Gate

For AIGO v1, the cross-framework layer should require:

✓ 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:

gapId
frameworkId
requirementId
aigoControlId
gapType
severity
status
owner
discoveredDate
dueDate
evidenceIds
assuranceIds
correctiveActionIds

82. Gap Status

Possible values:

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:

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:

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:

New Gaps
-
Closed Gaps
=
Net Gap Change

over time. This is useful for management review.

89. Repeat-Finding Trend

Track:

Repeat Findings
/
Total Findings

as an internal control-maturity indicator.

90. Evidence-Gap Trend

Track:

Evidence Gaps
/
Applicable Requirements

separately by framework.

91. Assurance-Gap Trend

Track:

Unassured Applicable Requirements
/
Applicable Requirements

separately by framework.

92. Common-Control Efficiency

AIGO may track:

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:

Framework Relationships Supported by Shared Evidence
/
Total Evidence Relationships

This is an operational efficiency metric.

94. Shared-Assurance Efficiency

AIGO may track:

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:

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:

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:

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:

Control:
Effective

EU Extension:
Open

Therefore gap closure is relationship-specific.

100. Gap Escalation

Critical or overdue gaps should escalate to:

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:

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:

ACTIVE
HISTORICAL
SUPERSEDED

states.

105. Cross-Framework Gap and Coverage Report

The final generated report should contain:

Executive Summary
Source / Version Status
Applicability Coverage
Requirement Coverage
Control Coverage
Implementation Coverage
Evidence Coverage
Monitoring Coverage
Assurance Coverage
Open Gaps
Critical Gaps
Remediation
Cross-Framework Harmonization
Framework-Specific Extensions
Version Currency
Release-Gate Status

106. Executive Summary Example

A future generated report may state:

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:

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:

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:

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:

Source Validation
      ↓
Requirement Validation
      ↓
Control Validation
      ↓
Evidence Validation
      ↓
Assurance Validation
      ↓
Gap Validation
      ↓
Repository Health
      ↓
Release Gate

112. V1 Release Status

Possible repository-level statuses:

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:

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:

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:

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

​AIGO — Cross-Framework Gap and Coverage Mapping

​1. Document Purpose

​2. Mapping Information

​3. Core Principle

​4. Coverage Dimensions

​5. Source Coverage

​6. Source Coverage Status

​7. Applicability Coverage

​8. Applicability Gap

​9. Requirement Coverage

​10. Requirement Coverage Gap

​11. Control Coverage

​12. Control Coverage Status

​13. Control Gap

​14. Framework-Specific Control Gap

​15. Duplicate-Control Gap

​16. False-Equivalence Gap

​17. Implementation Coverage

​18. Implementation Gap

​19. Control Ownership Coverage

​20. Evidence Coverage

​21. Evidence Coverage Status

​22. Evidence Gap

​23. Shared Evidence Coverage

​24. Evidence Reuse Efficiency

​25. Monitoring Coverage

​26. Monitoring Gap

​27. Assurance Coverage

​28. Assurance Gap

​29. Framework-Specific Assurance Coverage

​30. Remediation Coverage

​31. Remediation Status

​32. Remediation Gap

​33. Version Coverage

​34. Version Gap

​35. Current EU AI Act Baseline

​36. Current ISO Baseline

​37. Current NIST Baseline

​38. Traceability Coverage

​39. Traceability Gap

​40. Reverse Traceability

​From control

​From evidence

​From finding

​41. Cross-Framework Harmonization Coverage

​42. Harmonization Gap

​43. Harmonization Boundary

​44. Coverage Matrix

​45. Coverage State Machine

​46. Requirement Coverage State

​47. Control Coverage State

​48. Evidence Coverage State

​49. Assurance Coverage State

​50. Gap Taxonomy

​51. Gap Severity

​52. Criticality Rule

​53. Priority Factors

​54. Gap Prioritization

​55. Framework-Specific Gap

​56. Common-Control Gap

​57. Evidence Gap

​58. Assurance Gap

​59. Version Gap

​60. Conflict Gap

​61. Coverage Report Structure

​62. Framework Summary

​63. Do Not Aggregate Compliance Scores

​64. Common-Control Coverage

​65. Gap Aging

​66. Overdue Gaps

​67. Repeat Gaps

​68. System-Level Coverage

​69. Portfolio-Level Coverage

​70. Control-Level Coverage

​71. Evidence-Level Coverage

​72. Assurance-Level Coverage

​73. Coverage Automation

​74. Validation Rules

​75. Coverage Validator Outputs

​76. Warning vs Failure

AIGO — Cross-Framework Gap and Coverage Mapping

1. Document Purpose

2. Mapping Information

3. Core Principle

4. Coverage Dimensions

5. Source Coverage

6. Source Coverage Status

7. Applicability Coverage

8. Applicability Gap

9. Requirement Coverage

10. Requirement Coverage Gap

11. Control Coverage

12. Control Coverage Status

13. Control Gap

14. Framework-Specific Control Gap

15. Duplicate-Control Gap

16. False-Equivalence Gap

17. Implementation Coverage

18. Implementation Gap

19. Control Ownership Coverage

20. Evidence Coverage

21. Evidence Coverage Status

22. Evidence Gap

23. Shared Evidence Coverage

24. Evidence Reuse Efficiency

25. Monitoring Coverage

26. Monitoring Gap

27. Assurance Coverage

28. Assurance Gap

29. Framework-Specific Assurance Coverage

30. Remediation Coverage

31. Remediation Status

32. Remediation Gap

33. Version Coverage

34. Version Gap

35. Current EU AI Act Baseline

36. Current ISO Baseline

37. Current NIST Baseline

38. Traceability Coverage

39. Traceability Gap

40. Reverse Traceability

From control

From evidence

From finding

41. Cross-Framework Harmonization Coverage

42. Harmonization Gap

43. Harmonization Boundary

44. Coverage Matrix

45. Coverage State Machine

46. Requirement Coverage State

47. Control Coverage State

48. Evidence Coverage State

49. Assurance Coverage State

50. Gap Taxonomy

51. Gap Severity

52. Criticality Rule

53. Priority Factors

54. Gap Prioritization

55. Framework-Specific Gap

56. Common-Control Gap

57. Evidence Gap

58. Assurance Gap

59. Version Gap

60. Conflict Gap

61. Coverage Report Structure

62. Framework Summary

63. Do Not Aggregate Compliance Scores

64. Common-Control Coverage

65. Gap Aging

66. Overdue Gaps

67. Repeat Gaps

68. System-Level Coverage

69. Portfolio-Level Coverage

70. Control-Level Coverage

71. Evidence-Level Coverage

72. Assurance-Level Coverage

73. Coverage Automation

74. Validation Rules

75. Coverage Validator Outputs

76. Warning vs Failure