AIGO — Cross-Framework Mapping Architecture

1. Document Purpose

This document defines the architecture for the AIGO cross-framework mapping layer. The cross-framework layer provides the integration mechanism between the AIGO operational control architecture and multiple external frameworks, standards, regulations, guidance documents, and organizational requirements. The initial framework sources are:

EU AI Act
ISO/IEC 42001
NIST AI RMF

The objective is to establish a common relationship model:

External Requirement
        ↓
Framework Mapping
        ↓
AIGO Common Control
        ↓
AIGO Process
        ↓
Evidence
        ↓
Monitoring
        ↓
Assurance
        ↓
Finding
        ↓
Improvement

This architecture prevents the individual mapping packages from becoming isolated compliance documents.

2. Mapping Information

Field	Value
Mapping	AIGO Cross-Framework Mapping Architecture
Version	0.1
Status	Draft
Document Identifier	`AIGO-MAP-XFW-ARCH-001`
Document Type	Cross-Framework Architecture
Mapping Package	`AIGO-MAP-XFW`
Primary Purpose	Cross-framework harmonization
Repository Path	`mappings/cross-framework/`
Current Framework Sources	EU AI Act, ISO/IEC 42001, NIST AI RMF
AIGO Control Layer	Existing AIGO Control Schema

3. Architectural Problem

AIGO contains multiple external mappings:

EU AI Act
ISO/IEC 42001
NIST AI RMF

Each framework has different:

terminology;
scope;
legal or normative status;
structure;
applicability;
assessment expectations;
evidence expectations.

Without a cross-framework layer, organizations may create duplicated controls. The cross-framework architecture therefore establishes:

Many External Requirements
             ↓
      Common AIGO Controls
             ↓
    Common Operating Processes
             ↓
      Common Evidence
             ↓
       Common Assurance

4. Core Principle

AIGO is the operational integration layer. The external framework remains authoritative for its own requirements. Therefore:

External Framework
       ≠
AIGO Control

Instead:

External Framework Requirement
       ↓
Mapping Relationship
       ↓
AIGO Control

AIGO must not alter the meaning of the source requirement.

5. Framework Status Distinction

The cross-framework layer must preserve the status of each source.

Source	General Character
EU AI Act	Binding European Union regulation
ISO/IEC 42001	International management-system standard
NIST AI RMF	Voluntary risk-management framework

This distinction is mandatory. A common AIGO control does not make the underlying frameworks equivalent.

6. Cross-Framework Architecture

The architecture is:

                  External Sources
                        │
        ┌───────────────┼────────────────┐
        │               │                │
    EU AI Act       ISO/IEC 42001   NIST AI RMF
        │               │                │
        └───────────────┼────────────────┘
                        ↓
              Framework Requirements
                        ↓
               Applicability Layer
                        ↓
                AIGO Common Controls
                        ↓
              AIGO Operating Processes
                        ↓
                 Evidence Layer
                        ↓
                Monitoring Layer
                        ↓
                Assurance Layer
                        ↓
             Improvement / Change

7. Cross-Framework Mapping Layers

The package consists of the following logical layers:

Layer 1 — External Source
Layer 2 — Requirement
Layer 3 — Applicability
Layer 4 — AIGO Control
Layer 5 — AIGO Process
Layer 6 — Evidence
Layer 7 — Monitoring
Layer 8 — Assurance
Layer 9 — Findings
Layer 10 — Improvement

No layer should be assumed to automatically satisfy the next layer.

8. Framework Package Architecture

Each external framework maintains its own package. Current structure:

mappings/
├── eu-ai-act/
├── iso-42001/
├── nist-ai-rmf/
└── cross-framework/

The individual packages remain authoritative for their own mappings. The cross-framework package only integrates their relationships.

9. Cross-Framework Responsibilities

The cross-framework package shall:

identify equivalent or overlapping control areas;
identify shared AIGO controls;
identify framework-specific requirements;
identify gaps;
identify conflicts;
identify evidence reuse opportunities;
identify assurance reuse opportunities;
maintain cross-framework traceability.

It shall not replace the individual framework mappings.

10. Source Authority

For a specific requirement:

EU AI Act requirement
→ EU AI Act mapping is authoritative

ISO/IEC 42001 requirement
→ ISO/IEC 42001 mapping is authoritative

NIST AI RMF outcome
→ NIST AI RMF mapping is authoritative

The cross-framework layer is authoritative only for the relationship among those sources and AIGO.

11. Mapping Relationship Types

The registry shall support:

DIRECT
PARTIAL
SUPPORTING
OVERLAPPING
INTEGRATED
CONDITIONAL
CROSS_REFERENCE
DERIVED
CONFLICTING
COMPLEMENTARY
NO_DIRECT_EQUIVALENT

DIRECT

The AIGO control directly addresses the source requirement.

PARTIAL

The control addresses only part of the requirement.

SUPPORTING

The control supports implementation but does not itself satisfy the requirement.

OVERLAPPING

Two or more source frameworks address substantially similar governance subject matter.

INTEGRATED

Several AIGO controls collectively address the mapped requirement set.

CONDITIONAL

The relationship applies under specific conditions.

CROSS_REFERENCE

An existing relationship elsewhere is authoritative.

DERIVED

The relationship is derived from another controlled relationship.

CONFLICTING

The framework requirements or interpretations materially differ and cannot simply be merged.

COMPLEMENTARY

The frameworks address different aspects of the same governance area.

NO_DIRECT_EQUIVALENT

No common operational control currently provides an adequate relationship.

12. Framework Requirement Identity

Every external requirement must retain its original identity. Example:

EUAI:
Article 9

ISO:
ISO/IEC 42001 clause reference

NIST:
GOVERN / MAP / MEASURE / MANAGE category or subcategory

A common AIGO control must never replace the original source identifier.

13. AIGO Control Identity

The AIGO Control Schema remains the authoritative source of control identity. A cross-framework record should therefore contain:

sourceRequirementId
frameworkId
aigoControlId
relationshipType
applicability
status

The mapping record is a relationship, not a duplicate control definition.

14. Common-Control Principle

The preferred architecture is:

Requirement A ──┐
Requirement B ──┼──→ AIGO Control
Requirement C ──┘

rather than:

Requirement A → AIGO Control A
Requirement B → AIGO Control B
Requirement C → AIGO Control C

when one operational AIGO control genuinely addresses all three.

15. No False Equivalence

Similarity between requirements does not automatically establish equivalence. For example:

Similar governance subject
        ≠
Same requirement

A cross-framework mapping should therefore distinguish:

same objective;
overlapping objective;
supporting relationship;
partial relationship;
legally distinct obligation.

16. Requirement Comparison

A cross-framework comparison should consider:

purpose;
scope;
actor;
applicability;
timing;
control objective;
evidence;
assurance;
legal/normative status.

17. Applicability Layer

Before combining framework relationships, applicability must be determined. Example:

Requirement
    ↓
Is framework applicable?
    ↓
Is requirement applicable?
    ↓
Is AIGO control applicable?

A requirement that is not applicable should not artificially inflate control coverage.

18. Multi-Framework Applicability

A single AI system may be:

EU AI Act → Applicable
ISO/IEC 42001 → Organization adopts
NIST AI RMF → Organization adopts

The cross-framework layer should represent these independently.

19. Control Applicability

A common AIGO control may be:

Applicable to all frameworks
Applicable to two frameworks
Applicable to one framework
Conditional
Not applicable

This must be explicitly recorded.

20. Cross-Framework Control Domains

The initial harmonization domains are:

GOV     Governance
CTX     Context
APP     Applicability
CLS     Classification
RSK     Risk
IMP     Impact
DATA    Data Governance
CTRL    Controls
OPS     Operations
DOC     Documentation
REC     Records
TRANS   Transparency
HUM     Human Oversight
PERF    Performance
SAFE    Safety
SEC     Security
PRIV    Privacy
FAIR    Fairness / Bias
EXP     Explainability
MON     Monitoring
INC     Incident
CHG     Change
TPG     Third-Party Governance
COMP    Competence / Literacy
CONF    Conformity / Certification
EVD     Evidence
ASSR    Assurance
MREV    Management Review
IMPX    Improvement
RET     Retirement

21. Core Shared-Control Areas

The first cross-framework harmonization should prioritize:

governance;
risk management;
AI system inventory;
lifecycle governance;
impact assessment;
controls;
monitoring;
documentation;
evidence;
incident management;
change management;
assurance;
continual improvement.

These are natural common-control candidates.

22. Framework-Specific Areas

The cross-framework architecture must also preserve source-specific areas. Examples include:

EU AI Act

prohibited AI practices;
statutory high-risk classification;
conformity assessment;
registration;
GPAI obligations;
statutory transparency;
regulatory enforcement.

ISO/IEC 42001

AIMS scope;
management-system requirements;
internal audit;
management review;
continual improvement;
Annex A controls.

NIST AI RMF

GOVERN;
MAP;
MEASURE;
MANAGE;
trustworthiness characteristics;
voluntary implementation profiles.

These should not be artificially collapsed.

23. Common Risk Architecture

The shared risk layer should support:

Context
 ↓
Risk Identification
 ↓
Analysis
 ↓
Evaluation
 ↓
Prioritization
 ↓
Treatment
 ↓
Residual Risk
 ↓
Monitoring
 ↓
Reassessment

The individual framework mappings define the specific source requirements.

24. Common Governance Architecture

AIGO provides common governance mechanisms for:

accountability;
roles;
policy;
decision rights;
escalation;
management review;
evidence;
assurance.

External mappings attach their requirements to these mechanisms.

25. Common Lifecycle Architecture

The common AI lifecycle is:

Planning
 ↓
Design
 ↓
Development / Acquisition
 ↓
Testing
 ↓
Approval
 ↓
Deployment
 ↓
Operation
 ↓
Monitoring
 ↓
Change
 ↓
Improvement
 ↓
Retirement

Each framework may place different requirements on the same lifecycle stages.

26. Common Evidence Architecture

The unified evidence chain is:

Framework Requirement
        ↓
AIGO Control
        ↓
Activity
        ↓
Evidence
        ↓
Validation
        ↓
Assurance

One evidence record may support multiple framework requirements where its scope is sufficient.

27. Evidence Reuse Rules

Evidence may be reused when:

the system is the same;
the relevant version is compatible;
the evidence period is valid;
the evidence addresses the required criterion;
the relationship is explicitly recorded.

28. Evidence Non-Equivalence

Evidence must not be reused merely because it has a similar title. Example:

"Risk Assessment"

may have different scope or criteria under:

NIST;
ISO/IEC 42001;
EU AI Act.

The cross-framework relationship must therefore be evidence-specific.

29. Common Monitoring Architecture

AIGO Monitoring should support:

risk indicators;
control indicators;
AI-system performance;
incidents;
changes;
evidence currency;
framework deadlines.

Framework-specific metrics remain separately traceable.

30. Common Incident Architecture

The unified incident lifecycle is:

Detection
 ↓
Classification
 ↓
Containment
 ↓
Investigation
 ↓
Impact Assessment
 ↓
Notification Decision
 ↓
Corrective Action
 ↓
Verification
 ↓
Lessons Learned

Legal notification requirements must remain framework-specific.

31. Common Change Architecture

Material change should trigger:

Change
 ↓
Applicability Review
 ↓
Risk Review
 ↓
Control Review
 ↓
Evidence Review
 ↓
Assurance Review

Different frameworks may produce different consequences from the same change.

32. Common Assurance Architecture

The shared assurance chain is:

Requirement
 ↓
Control
 ↓
Evidence
 ↓
Criteria
 ↓
Test
 ↓
Finding
 ↓
Corrective Action
 ↓
Verification

The criteria remain source-specific.

33. Assurance Non-Equivalence

One assurance conclusion should not automatically be copied between frameworks. For example:

NIST assurance
       ≠
ISO certification
       ≠
EU AI Act conformity

A shared assurance activity may support multiple assessments only when each framework’s criteria are separately evaluated.

34. Certification and Regulatory Boundary

The cross-framework layer must preserve:

NIST AI RMF
→ Voluntary framework

ISO/IEC 42001
→ Management-system standard

EU AI Act
→ Binding law

A common assurance process does not erase these differences.

35. Control Coverage Model

The unified control coverage model is:

Framework Requirement
       ↓
AIGO Control
       ↓
Applicable?
       ↓
Implemented?
       ↓
Evidenced?
       ↓
Assured?

36. Cross-Framework Coverage

The coverage engine should be able to answer:

Which EU AI Act requirements map to this AIGO control?

Which ISO requirements map to this AIGO control?

Which NIST outcomes map to this AIGO control?

Which evidence supports the control?

Which assurance activities cover it?

37. Gap Types

Cross-framework gap categories should include:

NO_MAPPING
PARTIAL_MAPPING
NO_CONTROL
CONTROL_GAP
EVIDENCE_GAP
ASSURANCE_GAP
APPLICABILITY_GAP
TIMELINE_GAP
VERSION_GAP
SOURCE_CONFLICT
CONTROL_OVERLAP
DUPLICATE_CONTROL

38. Overlap Analysis

The harmonization layer should identify:

COMMON
SIMILAR
COMPLEMENTARY
FRAMEWORK_SPECIFIC
CONFLICTING

This supports rational control design.

39. Common-Control Candidate

A requirement should be considered a common-control candidate where:

objectives materially overlap;
operational activities overlap;
evidence can be shared;
control owner is compatible;
framework-specific differences remain manageable.

40. Framework-Specific Extension

Where a common control is insufficient:

Common AIGO Control
       +
Framework-Specific Extension

Example:

Common Risk Control
       +
EU AI Act high-risk requirements

This prevents unnecessary duplication.

41. Control Extension Model

A control extension should identify:

baseControlId
frameworkId
extensionId
additionalRequirements
additionalEvidence
additionalAssurance

The base control remains unchanged where possible.

42. Cross-Framework Control Inheritance

A framework mapping may inherit:

common control;
common procedure;
common evidence;
common monitoring.

But source-specific requirements must be added explicitly.

43. Example — Risk Management

Conceptually:

NIST MAP / MANAGE
        │
ISO/IEC 42001 Risk Planning
        │
EU AI Act Risk Management
        │
        ↓
AIGO Risk Management Control
        ↓
Risk Assessment
        ↓
Treatment
        ↓
Monitoring

This is an example of common-control harmonization, not a claim that the three requirements are legally identical.

44. Example — Monitoring

NIST MEASURE / MANAGE
        │
ISO Performance Evaluation
        │
EU AI Act Monitoring
        │
        ↓
AIGO Monitoring Control
        ↓
Monitoring Record
        ↓
Evidence

Framework-specific thresholds and mandatory monitoring obligations must remain distinct.

45. Example — Change Management

NIST MANAGE
        │
ISO Change Planning
        │
EU AI Act Significant-Change Analysis
        │
        ↓
AIGO Change Control
        ↓
Impact Assessment
        ↓
Approval
        ↓
Reassessment

The EU AI Act relationship may produce legal consequences that do not exist in the NIST framework.

46. Example — Evidence

NIST Evidence
ISO Documented Information
EU AI Act Regulatory Evidence
        ↓
AIGO Evidence Record

The underlying evidence classification and legal significance remain different.

47. Example — Assurance

NIST Risk Assurance
ISO AIMS Assurance
EU AI Act Regulatory / Conformity Evidence
        ↓
AIGO Assurance

The AIGO assurance mechanism supports the process but does not replace statutory or certification functions.

48. Cross-Framework Traceability

The minimum traceability model is:

Framework
 ↓
Requirement
 ↓
AIGO Control
 ↓
Evidence
 ↓
Assurance

A more complete chain is:

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

49. Traceability Direction

The repository should support both directions.

Forward

Requirement → Control → Evidence

Reverse

Evidence → Control → Requirements

This is important for audit and reuse.

50. Cross-Framework Control Registry

A future machine-readable cross-framework registry should contain:

relationshipId
frameworkId
sourceRequirementId
aigoControlId
relationshipType
applicability
priority
status
evidenceRequirements
monitoringRequirements
assuranceRequirements
notes

51. Source Metadata

Every relationship should preserve:

framework;
source document;
version;
requirement identifier;
source date;
review date.

52. Legal / Normative Status Metadata

The registry should distinguish:

BINDING_LAW
INTERNATIONAL_STANDARD
VOLUNTARY_FRAMEWORK
OFFICIAL_GUIDANCE
VOLUNTARY_CODE
ORGANIZATIONAL_REQUIREMENT
CONTRACTUAL_REQUIREMENT

This is critical to prevent false equivalence.

53. Applicability Metadata

The registry should support:

APPLICABLE
CONDITIONAL
NOT_APPLICABLE
FUTURE
TRANSITIONAL
HISTORICAL

54. Framework Version Metadata

Every relationship should be version-specific. Example:

framework:
NIST AI RMF

version:
1.0

and separately:

framework:
ISO/IEC 42001

version:
2023

The same principle applies to the EU AI Act and amendments.

55. AIGO Control Version

The relationship should also identify the AIGO control version. This supports historical reconstruction:

Requirement version
       +
AIGO control version
       +
Evidence version
       +
Assurance version

56. Common Evidence Registry

The common evidence architecture should eventually enable:

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

where applicable.

57. Evidence Conflict

Where one evidence record supports multiple frameworks but satisfies different criteria differently, the repository must preserve the distinction. Potential status:

SHARED
SHARED_WITH_EXTENSIONS
FRAMEWORK_SPECIFIC
INSUFFICIENT_FOR_ONE_OR_MORE_FRAMEWORKS

58. Assurance Registry

The cross-framework assurance registry should contain:

assuranceId
frameworkId
requirementId
controlId
evidenceIds
criteria
method
reviewer
scope
period
status
findingIds
conclusion

59. Cross-Framework Finding Model

A finding may be:

FRAMEWORK_SPECIFIC
SHARED_CONTROL_FAILURE
SHARED_EVIDENCE_FAILURE
PROCESS_FAILURE
CONTROL_DESIGN_FAILURE
CONTROL_EFFECTIVENESS_FAILURE

60. Shared-Control Failure

A shared AIGO control failure may affect several frameworks. Example:

AIGO Risk Control Failure
       ↓
NIST finding
ISO finding
EU AI Act finding

Each resulting finding remains separately traceable.

61. Root Cause Analysis

Cross-framework findings should preferably share a root-cause analysis when the underlying failure is common. Example:

Root Cause
    ↓
Shared Control Failure
    ├── NIST Finding
    ├── ISO Finding
    └── EU AI Act Finding

This reduces duplicate corrective actions.

62. Corrective Action Harmonization

A single corrective action may address several frameworks. The action record should identify all affected relationships. Example:

Corrective Action
      ├── EU AI Act
      ├── ISO/IEC 42001
      └── NIST AI RMF

63. Improvement Architecture

Cross-framework improvement should feed the common AIGO Improvement Schema. The lifecycle is:

Finding
 ↓
Root Cause
 ↓
Improvement
 ↓
Change
 ↓
Evidence
 ↓
Assurance

64. Management Review Integration

Cross-framework management review should provide a consolidated view of:

control coverage;
evidence coverage;
assurance coverage;
open findings;
regulatory exposure;
framework changes;
emerging risks.

65. Cross-Framework Dashboard

Potential dashboard measures:

Measure	Purpose
Requirements Across Frameworks	Scope
Common Controls	Harmonization
Framework-Specific Controls	Differentiation
Shared Evidence	Efficiency
Control Gaps	Risk
Evidence Gaps	Demonstrability
Assurance Gaps	Validation
Conflicting Requirements	Resolution
Duplicate Controls	Simplification
Open Findings	Remediation

66. Coverage Matrix

A future cross-framework coverage table should be conceptually:

AIGO Control	EU AI Act	ISO/IEC 42001	NIST AI RMF
Governance	Mapped	Mapped	Mapped
Risk	Mapped	Mapped	Mapped
Lifecycle	Mapped	Mapped	Mapped
Monitoring	Mapped	Mapped	Mapped
Incident	Mapped	Mapped	Mapped
Change	Mapped	Mapped	Mapped
Evidence	Mapped	Mapped	Mapped
Assurance	Mapped	Mapped	Mapped

This table should eventually be generated from machine-readable relationships rather than maintained manually.

67. Gap Analysis

Cross-framework gap analysis should identify:

Framework Gap

Requirement exists in one framework but not another.

Control Gap

Requirement has no adequate AIGO control.

Evidence Gap

Control exists but evidence is insufficient.

Assurance Gap

Evidence exists but assurance is missing.

Applicability Gap

Requirement applicability is unresolved.

Version Gap

Mapping uses an outdated source.

68. Duplicate-Control Analysis

The cross-framework layer should identify controls that appear operationally duplicated. Potential result:

Duplicate Candidates
        ↓
Compare Objectives
        ↓
Compare Procedures
        ↓
Compare Evidence
        ↓
Merge / Retain Separately

Merging should only occur where equivalence is genuine.

69. Control Rationalization

Control rationalization should reduce:

duplicate procedures;
duplicate evidence requests;
duplicate monitoring;
duplicate assurance.

It should not eliminate framework-specific requirements.

70. Framework-Specific Additions

Where a common control is insufficient:

Common AIGO Control
      +
Framework Extension

Example:

Common Transparency Control
      +
EU AI Act Article 50-specific obligation

71. Control Inheritance

The relationship model may use:

BASE_CONTROL
EXTENDED_CONTROL
SPECIALIZED_CONTROL

This should remain an AIGO architectural concept rather than changing external framework terminology.

72. Cross-Framework Priority

Cross-framework control priority should consider:

highest applicable risk;
legal criticality;
safety;
rights;
regulatory exposure;
business impact.

A common control should not be downgraded simply because one of its framework relationships is voluntary.

73. Cross-Framework Assurance Priority

Higher priority should be given where:

one control supports binding law;
system impact is high;
multiple frameworks identify similar risks;
the control is weak;
evidence is missing.

74. Cross-Framework Change Management

Any change to a shared AIGO control should trigger impact analysis against:

EU AI Act
ISO/IEC 42001
NIST AI RMF

and any future mapping packages.

75. Cross-Framework Source Change

A source-framework change should trigger:

Source Change
 ↓
Mapping Review
 ↓
Affected Control Identification
 ↓
Evidence Impact
 ↓
Assurance Impact
 ↓
Repository Update

76. Version Conflict Management

If mappings refer to different source versions:

Current
Historical
Draft

must be explicitly distinguished. The repository must not silently merge different versions.

77. Historical Traceability

A historical relationship should preserve:

source version;
AIGO mapping version;
AIGO control version;
evidence period;
assurance period.

78. Cross-Framework Profiles

Future framework packages may contain profiles or sector-specific variants. The cross-framework architecture should identify these separately. Example:

Framework
 ↓
Profile
 ↓
Requirement
 ↓
AIGO Control

79. Future Framework Expansion

The architecture is intentionally extensible. Potential future packages might include:

other/
├── sector-specific-regulation
├── privacy-framework
├── cybersecurity-framework
└── industry-requirements

New frameworks should attach to the same AIGO common-control architecture.

80. No Framework Lock-In

The AIGO Control Schema must remain framework-neutral. Controls should describe operational governance, not duplicate the vocabulary of one external framework. This allows future mappings to reuse the same controls.

81. Cross-Framework Registry

The future registry should eventually describe:

Frameworks
Requirements
Relationships
Controls
Evidence
Assurance
Versions
Coverage
Conflicts

It should not duplicate the entire contents of the individual mapping files.

82. Validation Architecture

Cross-framework validation should include:

Structural Validation

Expected files exist.

Registry Validation

Registry entries match files.

Relationship Validation

Referenced framework and control IDs exist.

Control Validation

AIGO control IDs resolve.

Evidence Validation

Evidence relationships resolve.

Assurance Validation

Assurance relationships resolve.

Version Validation

Source versions are explicit.

Conflict Validation

Known conflicts are recorded.

Coverage Validation

All applicable mapped requirements have controls or documented exceptions.

83. Cross-Framework Tools

The existing AIGO tools should eventually consume the cross-framework layer:

Schema Validator
Reference Validator
Traceability Validator
Control Coverage Validator
Evidence Coverage Validator
Framework Consistency Checker
Document Integrity Checker
Repository Health Checker

The tools should not require framework-specific custom implementations where generic relationship validation is sufficient.

84. Cross-Framework Findings

Potential findings include:

XFW_MAPPING_MISSING
XFW_CONTROL_GAP
XFW_CONTROL_DUPLICATE
XFW_EVIDENCE_GAP
XFW_ASSURANCE_GAP
XFW_APPLICABILITY_GAP
XFW_VERSION_CONFLICT
XFW_SOURCE_CONFLICT
XFW_TRACEABILITY_GAP
XFW_REFERENCE_BROKEN
XFW_FRAMEWORK_STATUS_CONFLICT

85. Critical Cross-Framework Findings

Potential critical findings include:

a binding legal requirement has no applicable AIGO control;
a common control is incorrectly represented as satisfying a legal requirement;
framework versions conflict;
regulatory evidence is incorrectly treated as voluntary guidance;
an important control has no evidence across multiple frameworks;
shared control failure affects multiple material requirements.

86. Repository Health

The Repository Health Checker should eventually summarize:

Framework Package Health
+
Cross-Framework Relationship Health
+
Control Coverage
+
Evidence Coverage
+
Assurance Coverage
+
Version Currency

87. Machine-Readable Relationship Model

A conceptual record is:

{
  "relationshipId": "XFW-REL-001",
  "frameworkId": "EU-AI-ACT",
  "sourceRequirementId": "EUAI-...",
  "aigoControlId": "AIGO-CTRL-...",
  "relationshipType": "DIRECT",
  "applicability": "CONDITIONAL",
  "status": "MAPPED"
}

The actual registry should follow the controlled schema created for the cross-framework package.

88. Cross-Framework Evidence Model

A conceptual evidence relationship is:

{
  "evidenceId": "EVD-001",
  "aigoControlId": "AIGO-CTRL-...",
  "frameworkRelationships": [
    "EUAI-...",
    "ISO42001-...",
    "NIST-AIRMF-..."
  ]
}

The Evidence Schema remains authoritative for the actual record.

89. Cross-Framework Assurance Model

A conceptual assurance relationship is:

{
  "assuranceId": "ASSR-001",
  "aigoControlId": "AIGO-CTRL-...",
  "criteria": [
    "EUAI-...",
    "ISO42001-...",
    "NIST-AIRMF-..."
  ]
}

The Assurance Schema remains authoritative.

90. Cross-Framework Example

Consider a common AI risk-management control.

EU AI Act
   ↓
High-risk risk management requirement

ISO/IEC 42001
   ↓
AIMS risk planning

NIST AI RMF
   ↓
MAP / MANAGE outcomes

        ↓

AIGO Risk Management Control

        ↓

Risk Assessment

        ↓

Treatment

        ↓

Monitoring

        ↓

Evidence

        ↓

Assurance

This is the intended harmonization model.

91. Cross-Framework Non-Equivalence Example

Consider statutory conformity assessment.

EU AI Act
   ↓
Statutory conformity assessment

There may be:

ISO/IEC 42001
   ↓
Management-system assessment

and:

NIST AI RMF
   ↓
Risk-management evaluation

These are not equivalent activities. The architecture must therefore preserve three separate relationships even if they share evidence.

92. Source-Specific Assurance

The assurance layer should identify:

framework
criteria
assuranceType
authority
conclusion

This prevents accidental representation of an internal AIGO assurance activity as:

EU regulatory approval;
ISO certification;
NIST endorsement.

93. Evidence-Specific Legal Status

Evidence should identify whether it is:

INTERNAL_GOVERNANCE_EVIDENCE
REGULATORY_EVIDENCE
CERTIFICATION_EVIDENCE
TECHNICAL_EVIDENCE
OPERATIONAL_EVIDENCE
EXTERNAL_ASSURANCE_EVIDENCE

94. Common Operational Procedure

Where frameworks have overlapping requirements, a single AIGO procedure may support them. Example:

AIGO Risk Assessment Procedure
        ├── NIST
        ├── ISO
        └── EU AI Act

The procedure should contain framework-neutral operational steps plus necessary framework-specific extensions.

95. Common Template

A single AIGO template may support multiple framework mappings where appropriate. Example: 05-AIGO-AI-Risk-Assessment-Template-v0.1.md may support:

NIST risk assessment;
ISO AIMS risk planning;
EU AI Act risk-management evidence.

However, each mapping must specify the additional information required for its source framework.

96. Common Evidence Record

16-AIGO-AI-Evidence-Record-Template-v0.1.md may capture:

evidence source;
control;
framework relationship;
system;
version;
reviewer;
period.

This enables evidence reuse without losing traceability.

97. Cross-Framework Operational Efficiency

The architecture should reduce:

duplicated assessments;
duplicated control procedures;
duplicated evidence collection;
duplicated monitoring;
duplicated assurance.

The goal is:

One Operational Activity
        ↓
Multiple Explicit Relationships

rather than:

Three Separate Operational Activities

where one would suffice.

98. Efficiency Boundary

Efficiency must not become false equivalence. The framework may consolidate operations only where the combined process actually meets the individual requirements.

99. Cross-Framework Control Effectiveness

A control can be:

Effective for NIST

while:

Insufficient for EU AI Act

This is possible and must be representable. Therefore effectiveness is relationship-specific.

100. Relationship-Specific Assurance Conclusion

The system should support:

AIGO Control:
Effective

NIST Relationship:
Effective

ISO Relationship:
Effective with Observation

EU AI Act Relationship:
Partial

This is more accurate than one universal control status.

101. Relationship-Specific Evidence

Similarly, an evidence record may be:

Sufficient for NIST
Sufficient for ISO
Insufficient for EU AI Act

where requirements differ.

102. Relationship-Specific Coverage

Coverage should therefore be computed:

By Framework
By Requirement
By Control
By Evidence
By Assurance

and not solely at repository level.

103. Common-Control Maturity

AIGO may track:

CONTROL_EXISTS
CONTROL_SHARED
CONTROL_STANDARDIZED
CONTROL_AUTOMATED
CONTROL_ASSURED

These are AIGO maturity states.

104. Cross-Framework Maturity

A future maturity model may assess:

Level 1 — Separate mappings
Level 2 — Shared controls
Level 3 — Shared evidence
Level 4 — Integrated assurance
Level 5 — Automated cross-framework governance

This should remain an AIGO maturity model.

105. Release Gate

The cross-framework package should not be marked validated until:

Frameworks Identified
       ✓
Requirements Traceable
       ✓
Shared Controls Identified
       ✓
Framework-Specific Controls Identified
       ✓
Evidence Relationships Defined
       ✓
Assurance Relationships Defined
       ✓
Conflicts Identified
       ✓
Versions Defined
       ✓
Registry Validated
       ✓

106. Initial Framework Set

Version 0.1 explicitly covers:

EU AI Act
ISO/IEC 42001
NIST AI RMF 1.0

Future frameworks should be added through controlled extension.

107. Future Framework Addition Process

A new framework should follow:

New Framework
      ↓
Source Registration
      ↓
Mapping Package
      ↓
Requirement Mapping
      ↓
Control Relationship
      ↓
Evidence Relationship
      ↓
Assurance Relationship
      ↓
Cross-Framework Integration
      ↓
Validation

108. Framework Onboarding Criteria

A future framework should provide:

authoritative source;
version;
applicability;
requirements;
mapping package;
control relationships;
evidence relationships;
assurance relationships.

109. Framework Retirement

A framework mapping may be retired when:

the source is superseded;
organizational adoption ends;
a new version replaces it;
the mapping is no longer maintained.

Historical relationships should remain retained.

110. Cross-Framework Historical State

The repository should allow reconstruction of:

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

This is important for audits and regulatory investigations.

111. Cross-Framework Change Control

Changes to this architecture should be managed through the AIGO Change Management process. Material changes require:

impact analysis;
review;
approval;
version update;
validation.

112. Cross-Framework Governance

Recommended ownership:

Role	Responsibility
Cross-Framework Owner	Package ownership
Framework Owners	Individual source accuracy
Control Owner	Common control integrity
Evidence Owner	Common evidence
Assurance Owner	Assurance model
Governance Owner	Conflicts and decisions
Framework Architect	Architecture

113. Cross-Framework Review

The cross-framework package should be reviewed:

annually;
after framework changes;
after material AIGO control changes;
after significant assurance findings;
when a new framework is onboarded.

114. Cross-Framework Documentation

The package should contain:

Architecture
Registry
Control Mapping
Requirements Mapping
Evidence Mapping
Assurance Mapping
Gap and Coverage Mapping
README

115. Final Directory Architecture

The intended structure is:

mappings/
│
├── eu-ai-act/
├── iso-42001/
├── nist-ai-rmf/
├── other/
└── cross-framework/

The cross-framework directory is an integration layer, not another standalone regulatory framework.

116. Final Cross-Framework Model

The complete AIGO architecture is:

EU AI Act ──────────┐
ISO/IEC 42001 ──────┼────→ AIGO Common Controls
NIST AI RMF ────────┘             │
                                  ↓
                           AIGO Procedures
                                  ↓
                            AIGO Records
                                  ↓
                              Evidence
                                  ↓
                             Monitoring
                                  ↓
                              Assurance
                                  ↓
                              Findings
                                  ↓
                             Improvement

117. Core Architectural Principle

The most important rule is:

Map many frameworks to one operational control architecture; do not build one operational control system per framework.

This makes AIGO scalable to additional regulations, standards, contracts, and governance frameworks.

118. Document Control

Field	Value
Document	AIGO Cross-Framework Mapping Architecture
Version	0.1
Status	Draft
Document Identifier	`AIGO-MAP-XFW-ARCH-001`
Document Type	Cross-Framework Architecture
Mapping Package	`AIGO-MAP-XFW`
Primary Frameworks	EU AI Act, ISO/IEC 42001, NIST AI RMF
Owner
Framework Reviewers
Governance Reviewer
Control Reviewer
Evidence Reviewer
Assurance Reviewer
Framework Architect
Approved By
Effective Date
Next Review Date

119. Document Status

Document: AIGO — Cross-Framework Mapping Architecture Version: 0.1 Status: Draft Working Name: AIGO Full Name: AI Governance Operating Framework Document Identifier: AIGO-MAP-XFW-ARCH-001 Document Type: Cross-Framework Architecture This document establishes the architecture for integrating the AIGO EU AI Act, ISO/IEC 42001, and NIST AI RMF mappings through a shared operational control, evidence, monitoring, assurance, and improvement layer while preserving the distinct legal, normative, and voluntary status of each source framework. End of Document

​AIGO — Cross-Framework Mapping Architecture

​1. Document Purpose

​2. Mapping Information

​3. Architectural Problem

​4. Core Principle

​5. Framework Status Distinction

​6. Cross-Framework Architecture

​7. Cross-Framework Mapping Layers

​8. Framework Package Architecture

​9. Cross-Framework Responsibilities

​10. Source Authority

​11. Mapping Relationship Types

​DIRECT

​PARTIAL

​SUPPORTING

​OVERLAPPING

​INTEGRATED

​CONDITIONAL

​CROSS_REFERENCE

​DERIVED

​CONFLICTING

​COMPLEMENTARY

​NO_DIRECT_EQUIVALENT

​12. Framework Requirement Identity

​13. AIGO Control Identity

​14. Common-Control Principle

​15. No False Equivalence

​16. Requirement Comparison

​17. Applicability Layer

​18. Multi-Framework Applicability

​19. Control Applicability

​20. Cross-Framework Control Domains

​21. Core Shared-Control Areas

​22. Framework-Specific Areas

​EU AI Act

​ISO/IEC 42001

​NIST AI RMF

​23. Common Risk Architecture

​24. Common Governance Architecture

​25. Common Lifecycle Architecture

​26. Common Evidence Architecture

​27. Evidence Reuse Rules

​28. Evidence Non-Equivalence

​29. Common Monitoring Architecture

​30. Common Incident Architecture

​31. Common Change Architecture

​32. Common Assurance Architecture

​33. Assurance Non-Equivalence

​34. Certification and Regulatory Boundary

​35. Control Coverage Model

​36. Cross-Framework Coverage

​37. Gap Types

​38. Overlap Analysis

​39. Common-Control Candidate

​40. Framework-Specific Extension

​41. Control Extension Model

​42. Cross-Framework Control Inheritance

​43. Example — Risk Management

​44. Example — Monitoring

​45. Example — Change Management

​46. Example — Evidence

​47. Example — Assurance

​48. Cross-Framework Traceability

​49. Traceability Direction

​Forward

​Reverse

​50. Cross-Framework Control Registry

​51. Source Metadata

​52. Legal / Normative Status Metadata

​53. Applicability Metadata

​54. Framework Version Metadata

​55. AIGO Control Version

​56. Common Evidence Registry

​57. Evidence Conflict

​58. Assurance Registry

​59. Cross-Framework Finding Model

​60. Shared-Control Failure

​61. Root Cause Analysis

​62. Corrective Action Harmonization

​63. Improvement Architecture