> ## 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.

# 01 AIGO Cross Framework Control Mapping v0.1

# AIGO — Cross-Framework Control Mapping

## 1. Document Purpose

This document establishes the cross-framework control mapping between:

* the EU AI Act;
* ISO/IEC 42001:2023; and
* NIST AI RMF 1.0;

and the common AIGO control architecture.

The purpose is to identify where multiple external frameworks can be operationalized through a single AIGO control while preserving the individual framework's source requirements, applicability, evidence expectations, and assurance conclusions.

The cross-framework layer is therefore an **integration layer**, not a replacement for the individual framework mappings.

The current framework baselines are:

* Regulation (EU) 2024/1689, as amended by Regulation (EU) 2026/1744, for the EU AI Act mapping.
* ISO/IEC 42001:2023 for the AI management-system mapping. ISO lists it as the published first edition from December 2023.
* NIST AI RMF 1.0 / NIST AI 100-1 for the NIST mapping. NIST describes AI RMF as voluntary and states that version 1.0 is currently being updated.

This document does not establish legal compliance, ISO certification, NIST endorsement, or statutory conformity.

***

# 2. Mapping Information

| Field               | Value                                                |
| ------------------- | ---------------------------------------------------- |
| Mapping             | AIGO Cross-Framework Control Mapping                 |
| Version             | 0.1                                                  |
| Status              | Draft                                                |
| Document Identifier | `AIGO-MAP-XFW-001`                                   |
| Document Type       | Cross-Framework Control Mapping                      |
| Mapping Package     | `AIGO-MAP-XFW`                                       |
| Architecture        | `AIGO-MAP-XFW-ARCH-001`                              |
| Registry            | `00-AIGO-Cross-Framework-Mapping-Registry-v0.1.json` |
| Primary Function    | Shared control harmonization                         |

***

# 3. Core Principle

The cross-framework architecture is:

```text theme={null}
EU AI Act Requirement
        │
ISO/IEC 42001 Requirement
        │
NIST AI RMF Outcome
        │
        ▼
AIGO Common Control
        │
        ▼
AIGO Process
        │
        ▼
Evidence
        │
        ▼
Monitoring
        │
        ▼
Assurance
```

The existence of a shared control does **not** mean the underlying requirements are legally or normatively identical.

***

# 4. Source Framework Characteristics

| Framework     | Source Character       | Cross-Framework Treatment          |
| ------------- | ---------------------- | ---------------------------------- |
| EU AI Act     | Binding EU regulation  | Legal requirement                  |
| ISO/IEC 42001 | International Standard | Management-system requirement      |
| NIST AI RMF   | Voluntary framework    | Risk-management guidance/framework |

NIST explicitly describes AI RMF as intended for voluntary use.

ISO describes ISO/IEC 42001 as specifying requirements for an AI Management System.

The EU AI Act is an EU regulation, and Regulation (EU) 2026/1744 amends Regulation (EU) 2024/1689.

***

# 5. Mapping Relationship Types

This document uses:

```text theme={null}
DIRECT
PARTIAL
SUPPORTING
OVERLAPPING
INTEGRATED
CONDITIONAL
COMPLEMENTARY
CONFLICTING
NO_DIRECT_EQUIVALENT
```

These describe relationships between requirements and controls. They are not legal equivalence statements.

***

# 6. Common-Control Model

The preferred AIGO architecture is:

```text theme={null}
Requirement A ──┐
Requirement B ──┼──► AIGO Common Control
Requirement C ──┘
```

rather than creating separate operational controls for every external source.

A common control should only be shared when its design, operating procedure, evidence, and monitoring can genuinely address the relevant requirements.

***

# 7. Framework-Specific Extension Model

Where a common control is not sufficient:

```text theme={null}
AIGO Base Control
       +
Framework-Specific Extension
```

For example:

```text theme={null}
Common Risk Control
       +
EU AI Act high-risk extension
```

This allows the common operational control to remain reusable while preserving source-specific requirements.

***

# 8. Common Control Domains

The initial cross-framework common-control domains are:

```text theme={null}
GOV   Governance
CTX   Context
APP   Applicability
CLS   Classification
RSK   Risk
IMP   Impact
DATA  Data Governance
LIFE  Lifecycle
OPS   Operations
DOC   Documentation
REC   Records
HUM   Human Oversight
TRANS Transparency
PERF  Performance
SAFE  Safety
SEC   Security
PRIV  Privacy
FAIR  Fairness / Bias
MON   Monitoring
INC   Incident
CHG   Change
TPG   Third-Party Governance
COMP  Competence
EVD   Evidence
ASSR  Assurance
MREV  Management Review
IMPR  Improvement
RET   Retirement
```

***

# 9. GOV-001 — AI Governance and Accountability

**AIGO Control:** `AIGO-XFW-GOV-001`

**Objective:** Establish accountable governance for AI systems, AI risk, controls, decisions, and oversight.

### Framework relationships

**EU AI Act:** Governance and organizational obligations; framework-specific regulatory governance requirements.

**ISO/IEC 42001:** Leadership, policy, organizational roles, responsibilities, authorities, and AIMS governance.

**NIST AI RMF:** GOVERN function, including organizational governance, accountability, policies, and processes.

**Relationship:** `DIRECT / INTEGRATED`

### Evidence

* governance charter;
* role assignments;
* accountability matrix;
* decision authority;
* management-review records.

### Assurance

Verify that assigned owners have actual authority and that governance decisions are evidenced.

***

# 10. GOV-002 — AI Policy and Governance Policy

**AIGO Control:** `AIGO-XFW-GOV-002`

**Objective:** Establish and maintain governing policies for AI use and AI risk management.

### Framework relationships

**EU AI Act:** Supports organizational governance and applicable policy obligations.

**ISO/IEC 42001:** AI policy and management-system governance.

**NIST AI RMF:** GOVERN policies and organizational practices.

**Relationship:** `DIRECT / SUPPORTING`

### Evidence

* approved AI policy;
* version history;
* approval;
* communication;
* review.

***

# 11. CTX-001 — AI System Context

**AIGO Control:** `AIGO-XFW-CTX-001`

**Objective:** Maintain a current description of the AI system, intended purpose, deployment environment, dependencies, users, and affected parties.

### Framework relationships

**EU AI Act:** Supports applicability, classification, risk, transparency, rights, and lifecycle decisions.

**ISO/IEC 42001:** Context of the organization and AI-system management.

**NIST AI RMF:** MAP function.

NIST's AI RMF Core uses MAP to establish context and understand AI risks across the lifecycle.

**Relationship:** `DIRECT / INTEGRATED`

***

# 12. CTX-002 — Stakeholder and Affected-Person Context

**AIGO Control:** `AIGO-XFW-CTX-002`

**Objective:** Identify relevant stakeholders, users, affected persons, and communities.

### Framework relationships

**EU AI Act:** Supports fundamental-rights and transparency-oriented governance.

**ISO/IEC 42001:** Interested parties and organizational context.

**NIST AI RMF:** MAP and multidisciplinary stakeholder considerations.

**Relationship:** `DIRECT / COMPLEMENTARY`

***

# 13. APP-001 — Regulatory and Framework Applicability

**AIGO Control:** `AIGO-XFW-APP-001`

**Objective:** Determine which requirements from each framework apply to a specific organization, AI system, activity, or lifecycle stage.

### Framework relationships

**EU AI Act:** Legal applicability and classification.

**ISO/IEC 42001:** AIMS scope and applicable management-system requirements.

**NIST AI RMF:** Organizational selection and tailoring of applicable AI RMF outcomes.

NIST's framework is designed to be flexible and tailored by organizations rather than used as a mandatory checklist.

**Relationship:** `DIRECT / INTEGRATED`

### Critical rule

An applicable legal requirement must not be marked optional merely because the corresponding NIST outcome is voluntary.

***

# 14. CLS-001 — AI Classification and Risk Categorization

**AIGO Control:** `AIGO-XFW-CLS-001`

**Objective:** Determine the relevant regulatory, governance, and risk classification of an AI system.

### Framework relationships

**EU AI Act:** AI-system classification and applicable risk category.

**ISO/IEC 42001:** Contextual AI-system management and risk determination.

**NIST AI RMF:** MAP-based risk context.

**Relationship:** `DIRECT / COMPLEMENTARY`

The legal classification under the EU AI Act must remain separate from an organization's internal risk rating.

***

# 15. RSK-001 — AI Risk Management

**AIGO Control:** `AIGO-XFW-RSK-001`

**Objective:** Identify, analyze, evaluate, prioritize, treat, monitor, and reassess AI risks.

### Framework relationships

**EU AI Act:** Risk-management requirements for applicable AI systems.

**ISO/IEC 42001:** AI-related risks and opportunities within the AIMS.

**NIST AI RMF:** MAP and MANAGE functions.

**Relationship:** `DIRECT / INTEGRATED`

### Evidence

* risk assessment;
* risk register;
* treatment;
* residual-risk decision;
* monitoring.

***

# 16. RSK-002 — Residual Risk Management

**AIGO Control:** `AIGO-XFW-RSK-002`

**Objective:** Maintain a documented decision concerning risk remaining after controls.

### Framework relationships

**EU AI Act:** Supports residual-risk and risk-management analysis where applicable.

**ISO/IEC 42001:** Risk treatment and management-system planning.

**NIST AI RMF:** MANAGE risk treatment and prioritization.

**Relationship:** `DIRECT / SUPPORTING`

***

# 17. IMP-001 — AI Impact Assessment

**AIGO Control:** `AIGO-XFW-IMP-001`

**Objective:** Identify and evaluate potential impacts on people, groups, organizations, and society.

### Framework relationships

**EU AI Act:** Fundamental-rights and applicable impact-assessment obligations.

**ISO/IEC 42001:** Impact and risk-related management activities.

**NIST AI RMF:** MAP context and impacts.

**Relationship:** `COMPLEMENTARY / INTEGRATED`

Impact assessment is not necessarily identical across frameworks, so the evidence requirement must remain framework-specific where necessary.

***

# 18. DATA-001 — AI Data Governance

**AIGO Control:** `AIGO-XFW-DATA-001`

**Objective:** Govern data used by AI systems according to applicable quality, provenance, privacy, fairness, security, and lifecycle requirements.

### Framework relationships

**EU AI Act:** Data-governance and data-quality obligations for applicable AI systems.

**ISO/IEC 42001:** AI data governance and related controls.

**NIST AI RMF:** Measurement, risk, validity, fairness, privacy, and trustworthiness considerations.

**Relationship:** `DIRECT / INTEGRATED`

***

# 19. LIFE-001 — AI Lifecycle Governance

**AIGO Control:** `AIGO-XFW-LIFE-001`

**Objective:** Apply governance controls throughout the AI lifecycle.

```text theme={null}
Planning
↓
Design
↓
Development / Acquisition
↓
Testing
↓
Approval
↓
Deployment
↓
Operation
↓
Monitoring
↓
Change
↓
Retirement
```

### Framework relationships

**EU AI Act:** Lifecycle-oriented regulatory obligations.

**ISO/IEC 42001:** AIMS operational planning and AI-system lifecycle management.

**NIST AI RMF:** AI RMF functions apply across the AI lifecycle.

NIST explicitly states that AI RMF risk management is intended to continue throughout the AI-system lifecycle.

**Relationship:** `DIRECT / INTEGRATED`

***

# 20. CTRL-001 — Common AI Control Management

**AIGO Control:** `AIGO-XFW-CTRL-001`

**Objective:** Establish, maintain, assign, monitor, and review AI governance controls.

### Framework relationships

All three frameworks use control or risk-management mechanisms that can be operationalized through this common AIGO control layer.

**Relationship:** `INTEGRATED`

***

# 21. DOC-001 — AI Documentation Governance

**AIGO Control:** `AIGO-XFW-DOC-001`

**Objective:** Maintain controlled AI governance documentation and technical/governance documentation appropriate to the applicable framework.

### Framework relationships

**EU AI Act:** Technical documentation and required records where applicable.

**ISO/IEC 42001:** Documented information.

**NIST AI RMF:** Documentation and evidence supporting governance, measurement, and risk-management activities.

**Relationship:** `DIRECT / INTEGRATED`

***

# 22. REC-001 — AI Record Keeping

**AIGO Control:** `AIGO-XFW-REC-001`

**Objective:** Preserve material AI governance records with appropriate attribution, integrity, retention, and retrieval.

### Framework relationships

**EU AI Act:** Applicable record-keeping and logging obligations.

**ISO/IEC 42001:** Documented information and retained records.

**NIST AI RMF:** Evidence supporting governance and risk-management activities.

**Relationship:** `DIRECT / INTEGRATED`

***

# 23. HUM-001 — Human Oversight

**AIGO Control:** `AIGO-XFW-HUM-001`

**Objective:** Establish and maintain appropriate human oversight for AI systems where required by context, risk, or law.

### Framework relationships

**EU AI Act:** Human-oversight requirements for applicable systems.

**ISO/IEC 42001:** Human-related AI governance and operational controls.

**NIST AI RMF:** Human and organizational considerations within trustworthy AI and risk management.

**Relationship:** `DIRECT / COMPLEMENTARY`

The EU AI Act relationship is source-specific and must not be inferred solely from NIST or ISO mappings.

***

# 24. TRANS-001 — AI Transparency

**AIGO Control:** `AIGO-XFW-TRANS-001`

**Objective:** Govern relevant transparency information made available to users, affected persons, operators, and other stakeholders.

### Framework relationships

**EU AI Act:** Statutory transparency obligations.

**ISO/IEC 42001:** Transparency-related management-system controls.

**NIST AI RMF:** Accountable and transparent trustworthiness characteristics.

NIST's AI RMF Core identifies accountability and transparency as trustworthiness considerations.

**Relationship:** `COMPLEMENTARY / INTEGRATED`

***

# 25. PERF-001 — AI Performance Evaluation

**AIGO Control:** `AIGO-XFW-PERF-001`

**Objective:** Evaluate whether AI-system performance is appropriate for the intended purpose and risk context.

### Framework relationships

**EU AI Act:** Accuracy, robustness, reliability, and other applicable performance requirements.

**ISO/IEC 42001:** Performance evaluation and AI-system governance.

**NIST AI RMF:** Valid and reliable trustworthiness characteristic and MEASURE function.

**Relationship:** `DIRECT / INTEGRATED`

***

# 26. SAFE-001 — AI Safety Governance

**AIGO Control:** `AIGO-XFW-SAFE-001`

**Objective:** Identify, evaluate, mitigate, and monitor safety risks.

### Framework relationships

**EU AI Act:** Applicable safety requirements.

**ISO/IEC 42001:** AI risk and operational controls.

**NIST AI RMF:** Safe trustworthiness characteristic.

**Relationship:** `DIRECT / COMPLEMENTARY`

***

# 27. SEC-001 — AI Security and Resilience

**AIGO Control:** `AIGO-XFW-SEC-001`

**Objective:** Govern cybersecurity, resilience, integrity, and recovery risks associated with AI systems.

### Framework relationships

**EU AI Act:** Cybersecurity and robustness requirements where applicable.

**ISO/IEC 42001:** AI security-related management-system controls.

**NIST AI RMF:** Secure and resilient trustworthiness characteristic and MEASURE/MANAGE activities.

**Relationship:** `DIRECT / INTEGRATED`

***

# 28. PRIV-001 — AI Privacy Risk Governance

**AIGO Control:** `AIGO-XFW-PRIV-001`

**Objective:** Identify and manage privacy risks arising from AI systems and associated data.

### Framework relationships

**EU AI Act:** Privacy-related AI governance interfaces.

**ISO/IEC 42001:** AI privacy-related management controls.

**NIST AI RMF:** Privacy-enhanced trustworthiness characteristic.

**Relationship:** `SUPPORTING / COMPLEMENTARY`

Privacy laws such as the GDPR remain separate legal sources.

***

# 29. FAIR-001 — Fairness and Harmful Bias

**AIGO Control:** `AIGO-XFW-FAIR-001`

**Objective:** Identify, evaluate, mitigate, and monitor harmful bias and fairness risks.

### Framework relationships

**EU AI Act:** Applicable bias, discrimination, and rights-related obligations.

**ISO/IEC 42001:** AI risk and impact governance.

**NIST AI RMF:** Fairness with harmful bias managed.

**Relationship:** `DIRECT / COMPLEMENTARY`

***

# 30. EXP-001 — Explainability and Interpretability

**AIGO Control:** `AIGO-XFW-EXP-001`

**Objective:** Govern explanation and interpretability capabilities appropriate to the AI system and its context.

### Framework relationships

**EU AI Act:** Applicable transparency and human-information requirements.

**ISO/IEC 42001:** Explainability and transparency-related AIMS controls.

**NIST AI RMF:** Explainable and interpretable trustworthiness characteristic.

**Relationship:** `COMPLEMENTARY`

***

# 31. MON-001 — AI Monitoring and Measurement

**AIGO Control:** `AIGO-XFW-MON-001`

**Objective:** Continuously or periodically monitor AI-system risks, performance, controls, incidents, and relevant trustworthiness indicators.

### Framework relationships

**EU AI Act:** Applicable monitoring and post-market requirements.

**ISO/IEC 42001:** Monitoring, measurement, analysis, and evaluation.

**NIST AI RMF:** MEASURE and MANAGE, with continuous lifecycle application.

NIST describes risk management as continuous and intended to operate across the AI lifecycle.

**Relationship:** `DIRECT / INTEGRATED`

***

# 32. INC-001 — AI Incident Management

**AIGO Control:** `AIGO-XFW-INC-001`

**Objective:** Detect, classify, investigate, contain, report where required, remediate, and learn from AI-related incidents.

### Framework relationships

**EU AI Act:** Applicable serious-incident and regulatory reporting requirements.

**ISO/IEC 42001:** Nonconformity, incident, and improvement processes.

**NIST AI RMF:** MANAGE incident response and learning.

**Relationship:** `DIRECT / INTEGRATED`

The regulatory reporting obligation itself remains framework-specific.

***

# 33. CHG-001 — AI Change Management

**AIGO Control:** `AIGO-XFW-CHG-001`

**Objective:** Ensure material AI-system and governance changes are evaluated for risk, control, documentation, evidence, and assurance impact.

### Framework relationships

**EU AI Act:** Applicable change and significant-change consequences.

**ISO/IEC 42001:** Management-system change planning.

**NIST AI RMF:** Reassessment as risk context evolves.

**Relationship:** `DIRECT / INTEGRATED`

***

# 34. TPG-001 — AI Third-Party Governance

**AIGO Control:** `AIGO-XFW-TPG-001`

**Objective:** Govern externally provided AI models, data, software, services, and infrastructure.

### Framework relationships

**EU AI Act:** Applicable provider, deployer, downstream, and supply-chain obligations.

**ISO/IEC 42001:** Externally provided processes and services.

**NIST AI RMF:** Supply-chain and third-party risk.

**Relationship:** `DIRECT / INTEGRATED`

***

# 35. COMP-001 — AI Competence and Literacy

**AIGO Control:** `AIGO-XFW-COMP-001`

**Objective:** Ensure personnel have competence and awareness appropriate to their AI governance responsibilities.

### Framework relationships

**EU AI Act:** AI literacy requirements where applicable.

**ISO/IEC 42001:** Competence and awareness.

**NIST AI RMF:** Governance, multidisciplinary capability, and responsible AI risk management.

**Relationship:** `INTEGRATED / CONDITIONAL`

The legal AI-literacy requirement remains separately mapped in the EU AI Act package.

***

# 36. EVD-001 — Common Evidence Management

**AIGO Control:** `AIGO-XFW-EVD-001`

**Objective:** Maintain a common evidence management process while preserving framework-specific evidence requirements.

### Framework relationships

All three frameworks can use a common AIGO Evidence infrastructure.

**Relationship:** `INTEGRATED`

### Evidence metadata

* evidence ID;
* system ID;
* control ID;
* framework relationship;
* source;
* version;
* period;
* owner;
* status;
* integrity;
* review.

***

# 37. EVD-002 — Evidence Traceability

**AIGO Control:** `AIGO-XFW-EVD-002`

**Objective:** Maintain bidirectional traceability between external requirements, AIGO controls, evidence, and assurance.

```text theme={null}
Requirement
   ↓
Control
   ↓
Evidence
   ↓
Assurance
```

and:

```text theme={null}
Evidence
   ↓
Control
   ↓
Requirement(s)
```

**Relationship:** `DIRECT / CRITICAL`

***

# 38. ASSR-001 — Common Assurance Framework

**AIGO Control:** `AIGO-XFW-ASSR-001`

**Objective:** Provide a shared assurance process while preserving framework-specific criteria and conclusions.

### Framework relationships

* NIST AI RMF assurance;
* ISO/IEC 42001 management-system assurance;
* EU AI Act readiness / regulatory assurance.

**Relationship:** `INTEGRATED`

### Critical boundary

```text theme={null}
Common AIGO Assurance
        ≠
EU statutory conformity assessment
        ≠
ISO certification
        ≠
NIST certification
```

***

# 39. ASSR-002 — Relationship-Specific Assurance

**AIGO Control:** `AIGO-XFW-ASSR-002`

**Objective:** Ensure assurance conclusions are calculated against the correct framework criterion.

A single control may therefore have:

```text theme={null}
NIST:
Effective

ISO:
Effective with Observation

EU AI Act:
Partial
```

This relationship-specific model is required to avoid false cross-framework conclusions.

***

# 40. MREV-001 — Cross-Framework Management Review

**AIGO Control:** `AIGO-XFW-MREV-001`

**Objective:** Provide management with a consolidated view of framework coverage, gaps, findings, and regulatory exposure.

### Inputs

* control coverage;
* evidence coverage;
* assurance coverage;
* open findings;
* regulatory changes;
* framework changes;
* material incidents.

### Outputs

* priorities;
* resource decisions;
* corrective actions;
* control changes;
* mapping changes.

***

# 41. IMPR-001 — Common Continual Improvement

**AIGO Control:** `AIGO-XFW-IMPR-001`

**Objective:** Feed cross-framework findings into the common AIGO improvement process.

```text theme={null}
Framework Finding
       ↓
Root Cause
       ↓
Shared Control Improvement
       ↓
Change
       ↓
New Evidence
       ↓
Reassurance
```

***

# 42. RET-001 — Common AI Retirement Governance

**AIGO Control:** `AIGO-XFW-RET-001`

**Objective:** Ensure retirement decisions consider all applicable framework obligations and preserve required historical evidence.

### Framework relationships

* EU AI Act lifecycle and retention requirements where applicable;
* ISO/IEC 42001 lifecycle governance;
* NIST AI RMF MANAGE and lifecycle risk management.

**Relationship:** `COMPLEMENTARY / INTEGRATED`

***

# 43. Common-Control Matrix

| AIGO Control                     | EU AI Act               | ISO/IEC 42001     | NIST AI RMF            |
| -------------------------------- | ----------------------- | ----------------- | ---------------------- |
| `XFW-GOV-001` Governance         | Direct / supporting     | Direct            | Direct                 |
| `XFW-APP-001` Applicability      | Direct                  | Direct            | Conditional / tailored |
| `XFW-CTX-001` Context            | Direct                  | Direct            | Direct                 |
| `XFW-RSK-001` Risk               | Direct                  | Direct            | Direct                 |
| `XFW-IMP-001` Impact             | Conditional             | Supporting        | Complementary          |
| `XFW-DATA-001` Data              | Direct where applicable | Direct/supporting | Supporting             |
| `XFW-LIFE-001` Lifecycle         | Direct / supporting     | Direct            | Direct                 |
| `XFW-DOC-001` Documentation      | Direct where applicable | Direct            | Supporting             |
| `XFW-HUM-001` Human Oversight    | Direct where applicable | Supporting        | Complementary          |
| `XFW-TRANS-001` Transparency     | Direct where applicable | Supporting        | Complementary          |
| `XFW-PERF-001` Performance       | Direct where applicable | Direct            | Direct                 |
| `XFW-SAFE-001` Safety            | Direct where applicable | Supporting        | Direct                 |
| `XFW-SEC-001` Security           | Direct where applicable | Supporting        | Direct                 |
| `XFW-PRIV-001` Privacy           | Supporting              | Supporting        | Direct                 |
| `XFW-FAIR-001` Fairness/Bias     | Direct where applicable | Supporting        | Direct                 |
| `XFW-MON-001` Monitoring         | Direct where applicable | Direct            | Direct                 |
| `XFW-INC-001` Incident           | Direct where applicable | Direct            | Direct                 |
| `XFW-CHG-001` Change             | Conditional             | Direct            | Direct                 |
| `XFW-TPG-001` Third Party        | Direct where applicable | Direct            | Direct                 |
| `XFW-COMP-001` Competence        | Direct where applicable | Direct            | Supporting             |
| `XFW-EVD-001` Evidence           | Direct/supporting       | Direct            | Supporting             |
| `XFW-ASSR-001` Assurance         | Framework-specific      | Direct            | Supporting             |
| `XFW-MREV-001` Management Review | Supporting              | Direct            | Supporting             |
| `XFW-IMPR-001` Improvement       | Supporting              | Direct            | Direct                 |
| `XFW-RET-001` Retirement         | Conditional             | Supporting        | Supporting             |

This matrix is an architectural harmonization view. The individual framework mappings remain authoritative for exact requirements.

***

# 44. Framework-Specific Extensions

Common controls frequently require extensions.

### Example: Risk

```text theme={null}
XFW-RSK-001
      │
      ├── EU AI Act risk-management extension
      ├── ISO AIMS risk extension
      └── NIST risk-management extension
```

### Example: Transparency

```text theme={null}
XFW-TRANS-001
      │
      ├── EU statutory transparency extension
      ├── ISO transparency extension
      └── NIST transparency/trustworthiness extension
```

### Example: Assurance

```text theme={null}
XFW-ASSR-001
      │
      ├── EU regulatory/readiness criteria
      ├── ISO AIMS audit criteria
      └── NIST outcome criteria
```

***

# 45. Control Effectiveness by Framework

A control's effectiveness must be relationship-specific.

Example:

```text theme={null}
AIGO-XFW-RSK-001

NIST AI RMF:
ASSURED

ISO/IEC 42001:
ASSURED_WITH_OBSERVATION

EU AI Act:
PARTIALLY_IMPLEMENTED
```

This is preferable to one universal status because the source requirements may differ.

***

# 46. Evidence Reuse Model

A shared evidence record may support multiple framework relationships:

```text theme={null}
Evidence EVD-001
      │
      ├── EU AI Act
      ├── ISO/IEC 42001
      └── NIST AI RMF
```

The registry should preserve the relationship and sufficiency for each framework.

***

# 47. Evidence Sufficiency

The cross-framework registry should distinguish:

```text theme={null}
SHARED
SHARED_WITH_EXTENSIONS
FRAMEWORK_SPECIFIC
INSUFFICIENT_FOR_ONE_OR_MORE_FRAMEWORKS
```

An evidence record cannot be treated as universally sufficient merely because it is shared.

***

# 48. Assurance Reuse Model

A single assurance activity may cover multiple frameworks where:

* all relevant criteria are defined;
* evidence is sufficient;
* reviewer competence is appropriate;
* scope is explicit.

The final conclusions must remain framework-specific.

***

# 49. Shared Finding Model

Where a common AIGO control fails:

```text theme={null}
Control Failure
      ↓
Root Cause
      ↓
 ┌────┼────┐
 ↓    ↓    ↓
EU   ISO  NIST
Finding Finding Finding
```

This supports one root-cause and one improvement process without losing framework-specific traceability.

***

# 50. Cross-Framework Gap Model

The cross-framework engine should distinguish:

```text theme={null}
NO_MAPPING
NO_CONTROL
PARTIAL_CONTROL
EVIDENCE_GAP
ASSURANCE_GAP
APPLICABILITY_GAP
VERSION_GAP
CONFLICT
DUPLICATION
```

These should not be combined into one generic "compliance gap."

***

# 51. Conflict Management

A `CONFLICTING` relationship requires:

* explicit identification;
* source citations;
* applicability analysis;
* resolution decision;
* responsible reviewer;
* versioned outcome.

The cross-framework layer must not resolve legal conflicts by silently selecting a preferred framework.

***

# 52. Duplicate-Control Detection

If two framework-specific mappings point to operationally identical AIGO controls, the validator should flag potential duplication.

Potential result:

`XFW-CONTROL-DUPLICATE-CANDIDATE`

Human review should determine whether controls can be consolidated.

***

# 53. Control Rationalization

Where rationalization is appropriate:

```text theme={null}
Duplicate Controls
      ↓
Objective Comparison
      ↓
Evidence Comparison
      ↓
Procedure Comparison
      ↓
Common Control
      +
Framework Extensions
```

***

# 54. Cross-Framework Coverage

The cross-framework coverage model should support:

```text theme={null}
By framework
By requirement
By AIGO control
By evidence
By assurance
By AI system
```

The same control can therefore be evaluated from multiple perspectives.

***

# 55. Reverse Traceability

The system should answer:

### From requirement

```text theme={null}
Requirement
 → AIGO Control
 → Evidence
 → Assurance
```

### From control

```text theme={null}
AIGO Control
 → EU AI Act relationships
 → ISO relationships
 → NIST relationships
```

### From evidence

```text theme={null}
Evidence
 → Control
 → Framework relationships
```

### From assurance

```text theme={null}
Assurance
 → Control
 → Evidence
 → Framework criteria
```

***

# 56. Machine-Readable Relationship Example

```json theme={null}
{
  "relationshipId": "XFW-REL-001",
  "frameworkId": "NIST-AIRMF",
  "sourceRequirementId": "NIST-MANAGE",
  "aigoControlId": "AIGO-XFW-RSK-001",
  "relationshipType": "DIRECT",
  "applicability": "APPLICABLE",
  "priority": "HIGH",
  "mappingStatus": "MAPPED"
}
```

The actual registry is defined separately in:

`00-AIGO-Cross-Framework-Mapping-Registry-v0.1.json`

***

# 57. Cross-Framework Control Governance

Each common control should have:

* owner;
* description;
* objective;
* applicability;
* frequency;
* evidence;
* monitoring;
* assurance;
* framework relationships;
* version.

The underlying operational definition belongs to the AIGO Control architecture.

***

# 58. Registry Integration

This document must remain aligned with:

`00-AIGO-Cross-Framework-Mapping-Registry-v0.1.json`

The registry is the machine-readable relationship authority.

***

# 59. Existing Mapping Integration

This mapping consumes the existing packages:

```text theme={null}
mappings/eu-ai-act/
mappings/iso-42001/
mappings/nist-ai-rmf/
```

The cross-framework layer should not duplicate their narrative content.

***

# 60. Existing AIGO Control Integration

The common-control layer must ultimately resolve to the controls represented in:

```text theme={null}
schemas/03-control/
```

and the corresponding control documentation.

The cross-framework mapping should not create a second uncontrolled control database.

***

# 61. Evidence Integration

Evidence relationships should resolve to:

```text theme={null}
schemas/10-evidence/
```

and the AIGO Evidence Record template.

***

# 62. Assurance Integration

Assurance relationships should resolve to:

```text theme={null}
schemas/09-assurance/
```

and the AIGO Assurance template.

***

# 63. Risk Integration

Risk relationships should resolve to:

```text theme={null}
schemas/02-risk/
```

and the AIGO Risk Assessment template.

***

# 64. Assessment Integration

Applicability and framework-impact assessments should use:

```text theme={null}
schemas/04-assessment/
```

rather than creating framework-specific assessment record structures unnecessarily.

***

# 65. Change Integration

Cross-framework impacts of system or framework changes should use:

```text theme={null}
schemas/08-change/
```

and the AIGO Change Management template.

***

# 66. Improvement Integration

Cross-framework remediation should use:

```text theme={null}
schemas/12-improvement/
```

and the AIGO Continuous Improvement template.

***

# 67. Management Review Integration

Cross-framework management reporting should use:

```text theme={null}
schemas/11-management-review/
```

and the AIGO Management Review template.

***

# 68. Retirement Integration

Historical cross-framework relationships should remain linked to retired systems through:

```text theme={null}
schemas/13-retirement/
```

***

# 69. Validation Requirements

The mapping should pass:

```text theme={null}
Framework Reference Validation
Requirement Reference Validation
Control Reference Validation
Cross-Framework Traceability
Control Coverage
Evidence Coverage
Assurance Coverage
Version Consistency
Conflict Detection
Duplicate-Control Detection
Framework Consistency
Repository Health
```

***

# 70. Cross-Framework Findings

Potential findings:

```text theme={null}
XFW_MAPPING_MISSING
XFW_CONTROL_GAP
XFW_CONTROL_DUPLICATE
XFW_EVIDENCE_GAP
XFW_ASSURANCE_GAP
XFW_APPLICABILITY_GAP
XFW_VERSION_GAP
XFW_SOURCE_CONFLICT
XFW_TRACEABILITY_GAP
XFW_REFERENCE_BROKEN
XFW_FRAMEWORK_STATUS_CONFLICT
```

***

# 71. Critical Cross-Framework Findings

Potential critical findings include:

* a binding requirement has no applicable control;
* a common control is incorrectly presented as legal equivalence;
* evidence is reused across frameworks despite insufficient scope;
* assurance conclusions are incorrectly transferred between frameworks;
* source versions conflict;
* a framework-specific statutory obligation is hidden inside a generic control.

***

# 72. V1 Control-Harmonization Objective

The v1 objective is not to maximize the number of mapped relationships.

It is to establish a **defensible common-control model** in which:

```text theme={null}
Less Duplication
+
More Traceability
+
Explicit Framework Differences
+
Reusable Evidence
+
Reusable Assurance
```

are achieved without false equivalence.

***

# 73. Current Framework Baselines

### EU AI Act

The current legal source includes Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744. EUR-Lex identifies Regulation (EU) 2026/1744 as the Digital Omnibus on AI amendment adopted on 8 July 2026 and published on 24 July 2026.

### ISO/IEC 42001

ISO/IEC 42001:2023 remains the published first edition.

### NIST AI RMF

NIST AI RMF 1.0 remains the current mapping baseline while NIST is updating the framework.

***

# 74. Version-Control Rule

Every cross-framework relationship must identify the source version it was mapped against.

The repository must never infer:

```text theme={null}
Current
```

from:

```text theme={null}
Latest file present
```

without explicit version metadata.

***

# 75. Historical Mapping

Historical mappings must remain reconstructable:

```text theme={null}
Framework Version
      +
Requirement Version
      +
AIGO Control Version
      +
Evidence Period
      +
Assurance Period
```

***

# 76. Future Framework Expansion

Future mappings can be integrated through the same architecture:

```text theme={null}
New Framework
      ↓
Framework Package
      ↓
Requirement Mapping
      ↓
Control Relationships
      ↓
Evidence Relationships
      ↓
Assurance Relationships
      ↓
Cross-Framework Harmonization
```

The common AIGO control architecture therefore becomes the scalable integration point.

***

# 77. Final Control Architecture

The complete relationship is:

```text theme={null}
External Framework
      ↓
Requirement / Outcome
      ↓
Applicability
      ↓
AIGO Common Control
      ↓
AIGO Process
      ↓
Evidence
      ↓
Monitoring
      ↓
Assurance
      ↓
Finding
      ↓
Corrective Action
      ↓
Improvement
```

***

# 78. Final Principle

The AIGO cross-framework control architecture follows one central rule:

> **Map multiple frameworks to a common operational control system, but never erase the distinctions between their requirements, applicability, evidence, assurance, and legal or normative status.**

The goal is one AIGO operating model with multiple explicit framework relationships—not one separate governance system for every framework.

***

# 79. Document Control

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

***

# 80. Document Status

**Document:** AIGO — Cross-Framework Control Mapping

**Version:** 0.1

**Status:** Draft

**Working Name:** AIGO

**Full Name:** AI Governance Operating Framework

**Document Identifier:** `AIGO-MAP-XFW-001`

**Document Type:** Cross-Framework Control Mapping

This document establishes the shared AIGO control layer connecting the EU AI Act, ISO/IEC 42001, and NIST AI RMF mappings to reusable operational controls, evidence, monitoring, assurance, findings, corrective action, and continual improvement while preserving each source framework's distinct legal, normative, voluntary, and version-specific characteristics.

End of Document