> ## 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. # 00 AIGO Cross Framework Mapping Architecture v0.1 # 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: ```text theme={null} EU AI Act ISO/IEC 42001 NIST AI RMF ``` The objective is to establish a common relationship model: ```text theme={null} 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: ```text theme={null} 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: ```text theme={null} 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: ```text theme={null} External Framework ≠ AIGO Control ``` Instead: ```text theme={null} 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: ```text theme={null} 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: ```text theme={null} 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: ```text theme={null} 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: ```text theme={null} 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: ```text theme={null} 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: ```text theme={null} 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: ```text theme={null} 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: ```text theme={null} Requirement A ──┐ Requirement B ──┼──→ AIGO Control Requirement C ──┘ ``` rather than: ```text theme={null} 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: ```text theme={null} 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: ```text theme={null} 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: ```text theme={null} 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: ```text theme={null} 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: ```text theme={null} 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: ```text theme={null} 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: ```text theme={null} 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: ```text theme={null} 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: ```text theme={null} "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: ```text theme={null} 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: ```text theme={null} 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: ```text theme={null} 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: ```text theme={null} 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: ```text theme={null} 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: ```text theme={null} Framework Requirement ↓ AIGO Control ↓ Applicable? ↓ Implemented? ↓ Evidenced? ↓ Assured? ``` *** # 36. Cross-Framework Coverage The coverage engine should be able to answer: ```text theme={null} 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: ```text theme={null} 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: ```text theme={null} 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: ```text theme={null} Common AIGO Control + Framework-Specific Extension ``` Example: ```text theme={null} Common Risk Control + EU AI Act high-risk requirements ``` This prevents unnecessary duplication. *** # 41. Control Extension Model A control extension should identify: ```text theme={null} 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: ```text theme={null} 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 ```text theme={null} 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 ```text theme={null} 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 ```text theme={null} 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 ```text theme={null} 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: ```text theme={null} Framework ↓ Requirement ↓ AIGO Control ↓ Evidence ↓ Assurance ``` A more complete chain is: ```text theme={null} Framework ↓ Requirement ↓ Applicability ↓ AIGO Control ↓ Process ↓ Evidence ↓ Monitoring ↓ Assurance ↓ Finding ↓ Improvement ``` *** # 49. Traceability Direction The repository should support both directions. ### Forward ```text theme={null} Requirement → Control → Evidence ``` ### Reverse ```text theme={null} Evidence → Control → Requirements ``` This is important for audit and reuse. *** # 50. Cross-Framework Control Registry A future machine-readable cross-framework registry should contain: ```text theme={null} 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: ```text theme={null} 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: ```text theme={null} APPLICABLE CONDITIONAL NOT_APPLICABLE FUTURE TRANSITIONAL HISTORICAL ``` *** # 54. Framework Version Metadata Every relationship should be version-specific. Example: ```text theme={null} framework: NIST AI RMF version: 1.0 ``` and separately: ```text theme={null} 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: ```text theme={null} Requirement version + AIGO control version + Evidence version + Assurance version ``` *** # 56. Common Evidence Registry The common evidence architecture should eventually enable: ```text theme={null} 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: ```text theme={null} SHARED SHARED_WITH_EXTENSIONS FRAMEWORK_SPECIFIC INSUFFICIENT_FOR_ONE_OR_MORE_FRAMEWORKS ``` *** # 58. Assurance Registry The cross-framework assurance registry should contain: ```text theme={null} assuranceId frameworkId requirementId controlId evidenceIds criteria method reviewer scope period status findingIds conclusion ``` *** # 59. Cross-Framework Finding Model A finding may be: ```text theme={null} 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: ```text theme={null} 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: ```text theme={null} 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: ```text theme={null} 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: ```text theme={null} 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: ```text theme={null} 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: ```text theme={null} Common AIGO Control + Framework Extension ``` Example: ```text theme={null} Common Transparency Control + EU AI Act Article 50-specific obligation ``` *** # 71. Control Inheritance The relationship model may use: ```text theme={null} 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: ```text theme={null} 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: ```text theme={null} Source Change ↓ Mapping Review ↓ Affected Control Identification ↓ Evidence Impact ↓ Assurance Impact ↓ Repository Update ``` *** # 76. Version Conflict Management If mappings refer to different source versions: ```text theme={null} 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: ```text theme={null} Framework ↓ Profile ↓ Requirement ↓ AIGO Control ``` *** # 79. Future Framework Expansion The architecture is intentionally extensible. Potential future packages might include: ```text theme={null} 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: ```text theme={null} 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: ```text theme={null} 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: ```text theme={null} 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: ```text theme={null} Framework Package Health + Cross-Framework Relationship Health + Control Coverage + Evidence Coverage + Assurance Coverage + Version Currency ``` *** # 87. Machine-Readable Relationship Model A conceptual record is: ```json theme={null} { "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: ```json theme={null} { "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: ```json theme={null} { "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. ```text theme={null} 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. ```text theme={null} EU AI Act ↓ Statutory conformity assessment ``` There may be: ```text theme={null} ISO/IEC 42001 ↓ Management-system assessment ``` and: ```text theme={null} 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: ```text theme={null} 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: ```text theme={null} 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: ```text theme={null} 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: ```text theme={null} One Operational Activity ↓ Multiple Explicit Relationships ``` rather than: ```text theme={null} 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: ```text theme={null} Effective for NIST ``` while: ```text theme={null} 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: ```text theme={null} 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: ```text theme={null} Sufficient for NIST Sufficient for ISO Insufficient for EU AI Act ``` where requirements differ. *** # 102. Relationship-Specific Coverage Coverage should therefore be computed: ```text theme={null} By Framework By Requirement By Control By Evidence By Assurance ``` and not solely at repository level. *** # 103. Common-Control Maturity AIGO may track: ```text theme={null} 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: ```text theme={null} 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: ```text theme={null} 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: ```text theme={null} 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: ```text theme={null} 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: ```text theme={null} 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: ```text theme={null} 00 Architecture 00 Registry 01 Control Mapping 02 Requirements Mapping 03 Evidence Mapping 04 Assurance Mapping 05 Gap and Coverage Mapping README ``` *** # 115. Final Directory Architecture The intended structure is: ```text theme={null} 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: ```text theme={null} 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