AIGO — Cross-Framework Evidence Mapping

1. Document Purpose

This document defines the cross-framework evidence architecture for the AIGO mapping layer connecting:

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

Its purpose is to establish how a common AIGO Evidence infrastructure can support multiple framework requirements while preserving:

source-framework identity;
applicability;
evidence sufficiency;
evidence quality;
legal or normative significance;
version;
lifecycle state;
assurance criteria; and
historical traceability.

The objective is:

Framework Requirement
        ↓
AIGO Control
        ↓
AIGO Activity
        ↓
Evidence Record
        ↓
Validation
        ↓
Framework-Specific Assurance

This document does not declare that one evidence record automatically proves compliance with every framework mapped to the same control.

2. Mapping Information

Field	Value
Mapping	AIGO Cross-Framework Evidence Mapping
Version	0.1
Status	Draft
Document Identifier	`AIGO-MAP-XFW-003`
Document Type	Cross-Framework Evidence Mapping
Mapping Package	`AIGO-MAP-XFW`
Architecture	`AIGO-MAP-XFW-ARCH-001`
Registry	`00-AIGO-Cross-Framework-Mapping-Registry-v0.1.json`
Primary Function	Evidence harmonization and traceability
Primary Evidence Schema	AIGO Evidence Schema

3. Evidence Architecture Principle

The AIGO evidence model is:

External Requirement
        ↓
Applicability
        ↓
AIGO Control
        ↓
Operational Activity
        ↓
Evidence Record
        ↓
Evidence Validation
        ↓
Framework-Specific Assurance

The evidence record is the reusable operational artifact. The requirement relationship remains framework-specific.

4. Evidence Non-Equivalence Principle

A shared evidence record does not mean:

Evidence = Universal Compliance

Instead:

One Evidence Record
        ↓
Relationship A → Framework A Criterion
Relationship B → Framework B Criterion
Relationship C → Framework C Criterion

Each relationship must be independently assessed for sufficiency.

5. Evidence Relationship Types

The cross-framework evidence layer uses:

SHARED
SHARED_WITH_EXTENSIONS
FRAMEWORK_SPECIFIC
SUPPORTING
PARTIAL
INSUFFICIENT
NOT_APPLICABLE
HISTORICAL
SUPERSEDED

SHARED

The evidence substantially satisfies the evidence need for multiple framework relationships.

SHARED_WITH_EXTENSIONS

The core evidence is shared, but one or more frameworks require additional information.

FRAMEWORK_SPECIFIC

Evidence is required only because of a particular framework.

SUPPORTING

Evidence strengthens a requirement relationship but is not independently sufficient.

PARTIAL

Evidence covers only part of the relevant criterion.

INSUFFICIENT

Evidence exists but does not adequately address the applicable criterion.

NOT_APPLICABLE

The evidence relationship is not applicable.

HISTORICAL

The evidence belongs to a prior controlled state.

SUPERSEDED

The evidence has been replaced by a newer record while remaining historically relevant.

6. Evidence Quality Model

Evidence quality should be evaluated across:

Authenticity
Integrity
Completeness
Relevance
Currency
Attribution
Traceability
Availability
Consistency
Sufficiency

A high-quality evidence record should be demonstrably connected to the control and activity that produced it.

7. Evidence Identity

Every evidence item should have a stable identifier. Recommended format:

AIGO-EVD-<DOMAIN>-<SEQUENCE>

Examples:

AIGO-EVD-RSK-001
AIGO-EVD-CTRL-001
AIGO-EVD-MON-001
AIGO-EVD-ASSR-001

The actual evidence identifier must resolve to the AIGO Evidence Schema.

8. Evidence Metadata

A material evidence record should contain, directly or through governed references:

evidence ID;
evidence type;
system ID;
control ID;
activity ID;
framework relationships;
source;
owner;
creation date;
effective period;
review date;
version;
status;
integrity information;
retention information.

9. Evidence Status

Evidence records should support:

DRAFT
COLLECTED
VALIDATED
APPROVED
IN_USE
EXPIRED
SUPERSEDED
ARCHIVED
RETIRED

Evidence status is distinct from framework compliance status.

10. Evidence Lifecycle

The common evidence lifecycle is:

Requirement
   ↓
Evidence Need
   ↓
Evidence Generation
   ↓
Evidence Collection
   ↓
Validation
   ↓
Approval / Acceptance
   ↓
Use
   ↓
Review
   ↓
Supersession / Archive

11. Evidence Need Identification

Evidence should be identified from:

Framework Requirement
        ↓
AIGO Control
        ↓
Evidence Requirement

This avoids collecting large volumes of evidence without a defined governance purpose.

12. Evidence Categories

Initial evidence categories include:

GOVERNANCE
POLICY
CONTEXT
APPLICABILITY
CLASSIFICATION
RISK
IMPACT
DATA
CONTROL
OPERATION
TEST
PERFORMANCE
MONITORING
INCIDENT
CHANGE
COMPETENCE
TRANSPARENCY
HUMAN_OVERSIGHT
DOCUMENTATION
ASSURANCE
MANAGEMENT_REVIEW
IMPROVEMENT
RETIREMENT
REGULATORY
EXTERNAL_ASSURANCE

13. Governance Evidence

Potential governance evidence includes:

governance charter;
role assignment;
accountability matrix;
committee records;
management decisions;
policy approval;
escalation decisions.

Framework relationships

EU AI Act: supports organizational governance and role obligations. ISO/IEC 42001: supports leadership, roles, policy, and management-system governance. NIST AI RMF: supports GOVERN.

Evidence relationship

SHARED where the same record genuinely supports the applicable criteria.

14. Policy Evidence

Potential evidence:

approved AI policy;
policy review;
policy communication;
policy change history.

Framework relationships

EU AI Act: supporting organizational evidence;
ISO/IEC 42001: direct management-system evidence;
NIST AI RMF: GOVERN implementation evidence.

Evidence model

SHARED_WITH_EXTENSIONS because the exact policy content may differ by framework.

15. Context Evidence

Potential evidence:

organizational context;
AI system profile;
intended purpose;
deployment context;
stakeholders;
affected persons;
system dependencies.

Framework relationships

EU AI Act: applicability/classification/context;
ISO/IEC 42001: organizational context;
NIST AI RMF: MAP.

Evidence model

SHARED where the record contains sufficient framework-specific fields.

16. Applicability Evidence

Applicability evidence should establish why a requirement applies or does not apply. Potential evidence:

regulatory applicability assessment;
AIMS scope statement;
AI RMF adoption scope;
legal analysis;
system classification.

Important distinction

A single document may contain multiple applicability decisions, but each decision should retain its source framework.

17. Classification Evidence

Classification evidence should distinguish:

Legal Classification
Internal Risk Classification
Framework Adoption Classification

For example:

EU AI Act:
Legal Risk Category

AIGO:
Internal Risk Rating

NIST:
Selected RMF Scope

These must not be collapsed into one field.

18. Risk Evidence

Potential evidence:

risk assessment;
risk register;
risk scoring;
treatment decision;
residual-risk review;
monitoring record.

Framework relationships

Risk evidence is a major candidate for shared evidence across:

EU AI Act;
ISO/IEC 42001;
NIST AI RMF.

Evidence model

Usually: SHARED_WITH_EXTENSIONS because each framework can require different criteria.

19. Risk Assessment Evidence Extensions

A common risk assessment may require additional framework-specific fields. Example:

Common Risk Assessment
      │
      ├── EU AI Act extension
      ├── ISO AIMS extension
      └── NIST RMF extension

The base assessment should remain reusable.

20. Impact Evidence

Potential evidence:

impact assessment;
rights impact assessment;
affected-person analysis;
stakeholder assessment;
impact mitigation;
residual impact decision.

Framework relationships

EU AI Act: applicable impact and fundamental-rights evidence;
ISO/IEC 42001: AIMS risk/impact governance;
NIST AI RMF: MAP context and impact evidence.

Evidence model

SHARED_WITH_EXTENSIONS

21. Data Evidence

Potential evidence:

dataset inventory;
data provenance;
data-quality assessment;
data-governance record;
bias evaluation;
privacy assessment;
data lineage.

Framework relationships

Data evidence may simultaneously support multiple requirements but often requires framework-specific extensions.

22. Control Evidence

Potential evidence:

control assessment;
control execution record;
configuration;
procedure;
approval;
exception;
control monitoring.

A common AIGO Control may generate evidence reused across several mapping packages.

23. Operational Evidence

Potential evidence:

workflow record;
execution logs;
transaction record;
deployment record;
operational approval;
system activity.

The evidence must be linked to the relevant system and period.

24. Testing Evidence

Potential evidence:

test plan;
test dataset;
methodology;
result;
expected result;
exception;
reviewer;
system/model version.

Framework relationships

EU AI Act: applicable technical/performance requirements;
ISO/IEC 42001: operational and performance evidence;
NIST AI RMF: MEASURE evidence.

25. Performance Evidence

Potential evidence:

accuracy;
reliability;
robustness;
availability;
safety indicators;
fairness indicators;
security indicators;
monitoring results.

The specific metrics must remain context-dependent.

26. Monitoring Evidence

Potential evidence:

monitoring record;
metric result;
threshold evaluation;
alert;
trend analysis;
escalation;
action.

Framework relationships

Monitoring is a strong candidate for shared operational evidence across all three mapping packages.

27. Incident Evidence

Potential evidence:

incident record;
severity;
impact;
containment;
investigation;
notification decision;
corrective action;
lessons learned.

Critical boundary

An incident record can support multiple frameworks, but legal notification evidence remains framework-specific. Example:

Incident Record
     │
     ├── EU notification relationship
     ├── ISO nonconformity relationship
     └── NIST incident-management relationship

28. Change Evidence

Potential evidence:

change request;
impact assessment;
risk reassessment;
approval;
testing;
deployment;
post-change review.

This is another major candidate for shared evidence.

29. Competence Evidence

Potential evidence:

role profile;
training record;
qualification;
experience;
competence assessment;
awareness record.

Framework distinction

EU AI Act AI-literacy evidence, ISO competence evidence, and NIST governance-capability evidence may overlap but are not automatically equivalent.

30. Human-Oversight Evidence

Potential evidence:

oversight assignment;
procedure;
intervention authority;
escalation mechanism;
training;
intervention record;
override record;
monitoring.

The exact requirements are framework-specific.

31. Transparency Evidence

Potential evidence:

user notice;
transparency statement;
system documentation;
explanation;
disclosure record;
communication.

Critical distinction

EU AI Act transparency evidence must be evaluated against the applicable statutory provision. NIST transparency evidence and ISO transparency evidence cannot be treated as substitutes without criteria validation.

32. Documentation Evidence

Potential evidence:

controlled policies;
technical documentation;
procedures;
system profiles;
risk assessments;
approval records.

The evidence registry should identify whether a document is:

CONTROLLED_DOCUMENT
RECORD
TECHNICAL_ARTIFACT
EXTERNAL_DOCUMENT
REGULATORY_SUBMISSION

33. Management Review Evidence

Potential evidence:

meeting record;
agenda;
inputs;
decisions;
actions;
resource decisions;
improvement actions.

This is especially relevant to ISO/IEC 42001, but may also provide broader AIGO governance evidence.

34. Assurance Evidence

Potential evidence:

assurance plan;
test procedure;
workpapers;
evidence samples;
findings;
assurance report;
follow-up.

The assurance record must identify the framework criteria evaluated.

35. Improvement Evidence

Potential evidence:

corrective action;
root-cause analysis;
improvement plan;
implementation record;
verification;
lessons learned.

36. Retirement Evidence

Potential evidence:

retirement approval;
system shutdown;
final risk state;
residual obligations;
retained records;
lessons learned.

37. Regulatory Evidence

Regulatory evidence may include:

regulatory submission;
registration;
declaration;
conformity documentation;
authority communication;
corrective action correspondence.

These records are generally framework-specific. They should not automatically become shared evidence.

38. External Assurance Evidence

Potential evidence:

certification-body report;
external audit report;
supplier assurance report;
independent evaluation;
technical assessment.

The evidence record should preserve:

issuer;
scope;
date;
criteria;
conclusion;
limitations.

39. Evidence Source Classification

Each evidence record should identify its source:

INTERNAL
EXTERNAL
THIRD_PARTY
REGULATORY_AUTHORITY
CERTIFICATION_BODY
INDEPENDENT_ASSESSOR
SYSTEM_GENERATED
HUMAN_GENERATED

40. Evidence Ownership

Material evidence should have:

evidence owner;
control owner;
system owner where applicable;
reviewer.

Ownership should remain clear even when evidence is shared across frameworks.

41. Evidence Period

Evidence should identify:

creation date;
effective date;
applicable period;
expiration/review date where appropriate.

This prevents old evidence from being reused indefinitely.

42. Evidence Versioning

Where evidence is associated with an AI system, the record should identify relevant versions:

System Version
Model Version
Data Version
Control Version
AIGO Version
Framework Version

This is essential for historical traceability.

43. Evidence Integrity

Integrity controls should address:

unauthorized modification;
deletion;
corruption;
provenance;
timestamping;
access control.

AIGO Document Integrity and Repository Health mechanisms should support these requirements.

44. Evidence Authentication

Where evidence may be contested, AIGO should preserve evidence that establishes:

who created it;
when it was created;
how it was generated;
which system produced it;
whether it was subsequently modified.

45. Evidence Completeness

Completeness should be evaluated relative to the specific criterion. For example:

Risk Assessment
      ↓
Complete for NIST
      ↓
Incomplete for EU AI Act

This is possible and should be representable.

46. Evidence Relevance

Evidence must address the criterion being assessed. A broadly related document is not automatically relevant evidence.

47. Evidence Currency

The currency requirement depends on:

framework requirement;
system lifecycle;
risk;
change;
evidence type.

There should be no universal AIGO evidence expiration period.

48. Evidence Traceability

The minimum relationship is:

Evidence
 ↓
AIGO Control
 ↓
Framework Requirement

The full relationship should support:

Evidence
 ↓
Activity
 ↓
Control
 ↓
Requirement
 ↓
Framework

49. Reverse Evidence Traceability

The system should be able to determine:

Framework Requirement
 ↓
Control
 ↓
Evidence

and:

Evidence
 ↓
Control
 ↓
All Supported Requirements

50. Evidence Reuse Decision

Before reusing evidence across frameworks, check:

Same AI System?
        ↓
Same Version?
        ↓
Same Evidence Period?
        ↓
Compatible Scope?
        ↓
Criterion Addressed?
        ↓
Sufficient Quality?
        ↓
Framework-Specific Extensions?

Only then should the evidence be marked shared.

51. Shared Evidence

A record can be marked: SHARED when the same evidence directly supports several framework relationships without significant extensions. Example:

Approved AI System Profile
      ├── ISO context
      ├── NIST MAP
      └── EU applicability support

The actual sufficiency still requires framework-specific validation.

52. Shared Evidence with Extensions

Most complex evidence will likely be: SHARED_WITH_EXTENSIONS Example:

Common Risk Assessment
      ├── common risk analysis
      ├── EU regulatory fields
      ├── ISO management-system fields
      └── NIST contextual fields

53. Framework-Specific Evidence

Examples:

EU AI Act:
Regulatory registration evidence

ISO:
Management-system internal-audit record

NIST:
Selected AI RMF implementation rationale

These should remain framework-specific.

54. Evidence Sufficiency Matrix

Evidence Type	EU AI Act	ISO/IEC 42001	NIST AI RMF	Typical Reuse
AI System Profile	Supporting	Direct	Direct	High
Risk Assessment	Direct where applicable	Direct	Direct	High with extensions
Control Assessment	Supporting	Direct	Supporting	Medium
Monitoring Record	Direct where applicable	Direct	Direct	High
Incident Record	Direct where applicable	Supporting/direct	Direct	High with extensions
Change Record	Conditional	Direct	Direct	High
Competence Record	Conditional	Direct	Supporting	Medium
Transparency Evidence	Direct where applicable	Supporting	Supporting	Low/medium
Regulatory Submission	Direct	N/A	N/A	Framework-specific
Internal Audit	N/A	Direct	Supporting	Framework-specific
NIST Implementation Rationale	N/A	N/A	Supporting/direct	NIST-specific

55. Evidence and Framework Extensions

A shared record may have extensions:

Evidence
   │
   ├── EU extension
   ├── ISO extension
   └── NIST extension

The extension should not duplicate the core record.

56. Evidence Relationship Identifier

Recommended format:

XFW-EVD-REL-<SEQUENCE>

Example:

XFW-EVD-REL-001

Each relationship should identify:

evidence ID;
AIGO control ID;
framework IDs;
sufficiency;
status.

57. Evidence Registry Relationship

The machine-readable registry should connect:

Evidence
 ↓
AIGO Control
 ↓
Framework IDs

This allows evidence reuse and gap analysis.

58. Evidence Coverage

The cross-framework evidence system should calculate:

Applicable Requirement
        ↓
Expected Evidence
        ↓
Evidence Available
        ↓
Evidence Validated
        ↓
Evidence Sufficient

59. Evidence Gap Categories

Potential gap categories:

NO_EVIDENCE
MISSING_FIELD
INSUFFICIENT
STALE
BROKEN_REFERENCE
WRONG_SYSTEM
WRONG_VERSION
WRONG_SCOPE
FRAMEWORK_EXTENSION_MISSING
INTEGRITY_FAILURE

60. Evidence Integrity Finding

An integrity finding may occur when:

the record cannot be attributed;
the timestamp is missing;
modification history is unclear;
source provenance is unavailable;
evidence has been altered unexpectedly.

61. Evidence Version Finding

A finding should occur when:

Evidence:
Model v2

Assurance:
Model v1

and no justified relationship exists. Potential finding: EVIDENCE_VERSION_MISMATCH

62. Evidence Scope Finding

A finding should occur when evidence is outside the applicable scope. Example:

AIMS Scope:
Business Unit A

Evidence:
Business Unit B

Potential finding: EVIDENCE_SCOPE_MISMATCH

63. Evidence Currency Finding

If evidence has become obsolete because of:

system change;
regulatory change;
control change;
framework version change;

the evidence should be re-evaluated. Potential finding: EVIDENCE_STALE

64. Evidence and Change Management

A material change should trigger evidence review:

Change
 ↓
Affected Evidence
 ↓
Revalidate
 ↓
Replace / Supplement
 ↓
Assurance

65. Evidence and Incident Management

A significant incident should trigger review of:

risk evidence;
control evidence;
monitoring evidence;
assurance evidence.

The incident record should link to affected evidence.

66. Evidence and Improvement

Improvement actions should produce new evidence demonstrating implementation. The lifecycle is:

Finding
 ↓
Improvement
 ↓
Implementation
 ↓
New Evidence
 ↓
Verification

67. Evidence and Management Review

Management Review may consume:

control evidence;
monitoring evidence;
assurance results;
incident evidence;
risk evidence.

The record should preserve source relationships.

68. Evidence and Retirement

When a system is retired:

operational evidence may become historical;
required records must remain retained;
active monitoring evidence should stop only when appropriate;
legal retention obligations must remain respected.

69. Evidence Security and Privacy

Evidence repositories may contain:

personal data;
confidential information;
model details;
security information;
proprietary data.

Access controls should therefore reflect evidence sensitivity.

70. Evidence Classification

AIGO may classify evidence sensitivity as:

PUBLIC
INTERNAL
CONFIDENTIAL
RESTRICTED
HIGHLY_RESTRICTED

This is an AIGO information-governance classification.

71. Evidence Retention

Retention should consider:

applicable law;
contractual requirements;
regulatory obligations;
AIMS requirements;
audit requirements;
incident investigations;
organizational policy.

A universal retention period should not be invented.

72. Evidence Disposal

Evidence disposal should be controlled. Possible states:

ELIGIBLE_FOR_DISPOSAL
DISPOSAL_APPROVED
DISPOSED
LEGAL_HOLD
REGULATORY_HOLD
INVESTIGATION_HOLD

73. Legal Hold

Evidence subject to:

litigation;
regulatory investigation;
audit;
incident investigation;

must not be disposed of until the applicable hold is released.

74. Evidence and Regulatory Deadlines

Where a framework requires specific documentation or notification by a deadline, the evidence record should capture:

requirement;
deadline;
responsible owner;
submission;
acknowledgement;
follow-up.

The deadline itself remains framework-specific.

75. EU AI Act Evidence Boundary

EU AI Act evidence should remain tied to:

applicable legal provision;
role;
system classification;
lifecycle status;
legal timeline;
required documentation.

A common AIGO evidence record can support this, but the legal interpretation remains within the EU AI Act mapping.

76. ISO/IEC 42001 Evidence Boundary

ISO evidence should remain tied to:

AIMS scope;
management-system requirement;
control;
documented information;
internal audit;
management review;
improvement.

77. NIST AI RMF Evidence Boundary

NIST evidence should remain tied to:

selected AI RMF functions;
categories;
outcomes;
organizational rationale;
measurement;
management response.

NIST AI RMF remains voluntary and should not be represented as a statutory evidentiary scheme. (airc.nist.gov)

78. Evidence and Cross-Framework Auditability

The evidence model should permit an auditor or reviewer to reconstruct:

Evidence
 ↓
Control
 ↓
Framework
 ↓
Requirement
 ↓
Applicability
 ↓
Assurance

79. Evidence Dashboard

Potential metrics:

Metric	Purpose
Evidence Records	Inventory
Shared Evidence	Efficiency
Framework-Specific Evidence	Differentiation
Evidence Gaps	Risk
Stale Evidence	Currency
Version Mismatches	Integrity
Unvalidated Evidence	Assurance
Evidence Supporting Multiple Controls	Reuse
Evidence Supporting Multiple Frameworks	Harmonization

80. Evidence Quality Score

AIGO may use an internal evidence quality model:

AUTHENTIC
INTEGRAL
COMPLETE
RELEVANT
CURRENT
TRACEABLE
SUFFICIENT

The result is an AIGO governance indicator. It is not a legal or certification score.

81. Evidence Assurance

The Evidence Coverage and Assurance mechanisms should verify:

Evidence Exists
      ↓
Correct Source
      ↓
Correct System
      ↓
Correct Version
      ↓
Correct Period
      ↓
Correct Scope
      ↓
Criterion Addressed
      ↓
Sufficient Quality

82. Common Evidence Example

A common AI risk assessment might support:

EU AI Act
   → applicable risk-management criterion

ISO/IEC 42001
   → AIMS risk-management requirement

NIST AI RMF
   → MAP / MANAGE outcome

The assessment itself is shared, but each relationship should identify any additional required fields.

83. Common Monitoring Example

A monitoring record may support:

EU AI Act
   → applicable monitoring/post-market relationship

ISO/IEC 42001
   → performance evaluation

NIST AI RMF
   → MEASURE / MANAGE

Again, the record is shared operationally while the criteria remain separate.

84. Common Change Example

A change record may support:

EU AI Act
   → significant-change assessment

ISO/IEC 42001
   → AIMS change planning

NIST AI RMF
   → risk/context reassessment

Each relationship requires independent evaluation.

85. Common Assurance Example

An assurance report may contain:

Section A:
ISO/IEC 42001 criteria

Section B:
NIST AI RMF criteria

Section C:
EU AI Act readiness criteria

The combined report should not imply that the conclusions are legally interchangeable.

86. Evidence Reuse Rule

The preferred sequence is:

Existing Evidence
      ↓
Assess Relevance
      ↓
Assess Sufficiency
      ↓
Add Framework Relationship
      ↓
Reuse

not:

Framework Mapping
      ↓
Assume Existing Evidence Is Sufficient

87. Evidence Creation Rule

Create new evidence only when:

existing evidence is insufficient;
framework-specific information is required;
scope differs;
timing differs;
assurance criteria differ.

This reduces evidence duplication.

88. Evidence Extension Rule

When possible:

Existing Evidence
      +
Framework Extension

should be preferred over creating a duplicate evidence record.

89. Evidence De-duplication

Evidence de-duplication should identify:

duplicate risk assessments;
duplicate monitoring records;
duplicate control tests;
duplicate assurance evidence.

Human review should confirm whether records are actually equivalent before consolidation.

90. Evidence Ownership and Accountability

A shared evidence record should not have multiple ambiguous owners. One accountable evidence owner should be identified, with framework-specific reviewers where needed.

91. Evidence Review Frequency

Review frequency should be determined by:

risk;
system changes;
framework requirements;
evidence type;
operational activity.

92. Evidence Review Triggers

Triggers include:

material AI-system change;
new regulation;
framework revision;
incident;
assurance finding;
control change;
management-review decision.

93. Evidence Historical State

Historical evidence must remain associated with:

system version;
control version;
framework version;
relevant period.

Historical evidence should not be modified to reflect later changes.

94. Evidence Supersession

A newer record should reference the older record where it supersedes it. Example:

EVD-001
  ↓
SUPERSEDED BY
  ↓
EVD-027

Historical auditability must remain intact.

95. Evidence Repository Structure

The actual evidence records should remain in the operational evidence repository rather than being duplicated under every mapping package. Conceptually:

Evidence Repository
        ↓
AIGO Control
        ↓
Framework Relationships

96. Cross-Framework Evidence Registry

The cross-framework registry should support:

Evidence ID
AIGO Control ID
Framework IDs
Sufficiency
Status
Review Date

This is defined structurally in: 00-AIGO-Cross-Framework-Mapping-Registry-v0.1.json

97. Validation Architecture

The evidence layer should be checked by:

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

98. Evidence Validation Rules

The validation system should verify:

Evidence ID Exists
        ↓
Control Exists
        ↓
Framework Relationship Exists
        ↓
Applicable Requirement Exists
        ↓
Scope Matches
        ↓
Version Matches
        ↓
Evidence Status Valid

99. Evidence Findings

Potential findings include:

XFW-EVIDENCE-MISSING
XFW-EVIDENCE-INSUFFICIENT
XFW-EVIDENCE-STALE
XFW-EVIDENCE-SCOPE-MISMATCH
XFW-EVIDENCE-VERSION-MISMATCH
XFW-EVIDENCE-REFERENCE-BROKEN
XFW-EVIDENCE-FRAMEWORK-EXTENSION-MISSING
XFW-EVIDENCE-INTEGRITY-FAILURE
XFW-EVIDENCE-OWNER-MISSING
XFW-EVIDENCE-REVIEW-OVERDUE

100. Critical Evidence Findings

Potential critical findings include:

a material legal requirement has no evidence;
a critical control lacks evidence;
evidence refers to the wrong AI-system version;
evidence used for regulatory purposes cannot be authenticated;
evidence reused across frameworks does not satisfy one of the criteria;
historical evidence has been altered.

101. Coverage Calculation

The evidence coverage calculation should be framework-specific:

Framework Applicable Requirements
          ↓
Requirements With Evidence Need
          ↓
Requirements With Evidence
          ↓
Requirements With Validated Evidence
          ↓
Requirements With Sufficient Evidence

102. No Universal Evidence Percentage

A combined: 90% evidence coverage would be misleading if it aggregates different framework requirements. Instead report:

EU AI Act Evidence Coverage
ISO/IEC 42001 Evidence Coverage
NIST AI RMF Evidence Coverage

and optionally:

Shared Evidence Reuse

as a separate efficiency indicator.

103. Cross-Framework Evidence Maturity

AIGO may use:

Level 1 — Separate Evidence
Level 2 — Reusable Evidence
Level 3 — Shared Evidence
Level 4 — Governed Evidence Relationships
Level 5 — Automated Evidence Traceability

This is an AIGO maturity model.

104. Evidence and Automation

Eventually the AIGO tools should be able to answer:

Which requirements lack evidence?

Which evidence is stale?

Which controls have no evidence?

Which evidence supports multiple frameworks?

Which evidence references obsolete system versions?

105. Evidence and Release Validation

Before the AIGO v1 release gate:

Evidence Schema Valid
      ↓
Evidence References Valid
      ↓
Cross-Framework Relationships Valid
      ↓
Coverage Calculated
      ↓
No Critical Evidence Gaps

Any accepted exceptions must be explicitly recorded.

106. Final Evidence Architecture

The complete evidence relationship is:

Framework
      ↓
Requirement
      ↓
Applicability
      ↓
AIGO Control
      ↓
Activity
      ↓
Evidence
      ↓
Evidence Validation
      ↓
Framework-Specific Assurance
      ↓
Finding
      ↓
Improvement

107. Final Principle

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

Reuse evidence operationally where justified, but evaluate evidence sufficiency separately for each framework relationship.

One governed evidence record can support many requirements, but no evidence record should be assumed to prove legal, normative, or voluntary-framework obligations without explicit traceability and sufficiency validation.

108. Document Control

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

109. Document Status

Document: AIGO — Cross-Framework Evidence Mapping Version: 0.1 Status: Draft Working Name: AIGO Full Name: AI Governance Operating Framework Document Identifier: AIGO-MAP-XFW-003 Document Type: Cross-Framework Evidence Mapping This document establishes the common evidence architecture for the EU AI Act, ISO/IEC 42001, and NIST AI RMF mappings, enabling controlled evidence reuse and bidirectional traceability while preserving framework-specific applicability, sufficiency, legal or normative significance, versioning, and assurance criteria. End of Document

​AIGO — Cross-Framework Evidence Mapping

​1. Document Purpose

​2. Mapping Information

​3. Evidence Architecture Principle

​4. Evidence Non-Equivalence Principle

​5. Evidence Relationship Types

​SHARED

​SHARED_WITH_EXTENSIONS

​FRAMEWORK_SPECIFIC

​SUPPORTING

​PARTIAL

​INSUFFICIENT

​NOT_APPLICABLE

​HISTORICAL

​SUPERSEDED

​6. Evidence Quality Model

​7. Evidence Identity

​8. Evidence Metadata

​9. Evidence Status

​10. Evidence Lifecycle

​11. Evidence Need Identification

​12. Evidence Categories

​13. Governance Evidence

​Framework relationships

​Evidence relationship

​14. Policy Evidence

​Framework relationships

​Evidence model

​15. Context Evidence

​Framework relationships

​Evidence model

​16. Applicability Evidence

​Important distinction

​17. Classification Evidence

​18. Risk Evidence

​Framework relationships

​Evidence model

​19. Risk Assessment Evidence Extensions

​20. Impact Evidence

​Framework relationships

​Evidence model

​21. Data Evidence

​Framework relationships

​22. Control Evidence

​23. Operational Evidence

​24. Testing Evidence

​Framework relationships

​25. Performance Evidence

​26. Monitoring Evidence

​Framework relationships

​27. Incident Evidence

​Critical boundary

​28. Change Evidence

​29. Competence Evidence

​Framework distinction

​30. Human-Oversight Evidence

​31. Transparency Evidence

​Critical distinction

​32. Documentation Evidence

​33. Management Review Evidence

​34. Assurance Evidence

​35. Improvement Evidence

​36. Retirement Evidence

​37. Regulatory Evidence

​38. External Assurance Evidence

​39. Evidence Source Classification

​40. Evidence Ownership

​41. Evidence Period

​42. Evidence Versioning

​43. Evidence Integrity

​44. Evidence Authentication

​45. Evidence Completeness

​46. Evidence Relevance

​47. Evidence Currency

​48. Evidence Traceability

​49. Reverse Evidence Traceability

​50. Evidence Reuse Decision

​51. Shared Evidence

​52. Shared Evidence with Extensions

​53. Framework-Specific Evidence

AIGO — Cross-Framework Evidence Mapping

1. Document Purpose

2. Mapping Information

3. Evidence Architecture Principle

4. Evidence Non-Equivalence Principle

5. Evidence Relationship Types

SHARED

SHARED_WITH_EXTENSIONS

FRAMEWORK_SPECIFIC

SUPPORTING

PARTIAL

INSUFFICIENT

NOT_APPLICABLE

HISTORICAL

SUPERSEDED

6. Evidence Quality Model

7. Evidence Identity

8. Evidence Metadata

9. Evidence Status

10. Evidence Lifecycle

11. Evidence Need Identification

12. Evidence Categories

13. Governance Evidence

Framework relationships

Evidence relationship

14. Policy Evidence

Framework relationships

Evidence model

15. Context Evidence

Framework relationships

Evidence model

16. Applicability Evidence

Important distinction

17. Classification Evidence

18. Risk Evidence

Framework relationships

Evidence model

19. Risk Assessment Evidence Extensions

20. Impact Evidence

Framework relationships

Evidence model

21. Data Evidence

Framework relationships

22. Control Evidence

23. Operational Evidence

24. Testing Evidence

Framework relationships

25. Performance Evidence

26. Monitoring Evidence

Framework relationships

27. Incident Evidence

Critical boundary

28. Change Evidence

29. Competence Evidence

Framework distinction

30. Human-Oversight Evidence

31. Transparency Evidence

Critical distinction

32. Documentation Evidence

33. Management Review Evidence

34. Assurance Evidence

35. Improvement Evidence

36. Retirement Evidence

37. Regulatory Evidence

38. External Assurance Evidence

39. Evidence Source Classification

40. Evidence Ownership

41. Evidence Period

42. Evidence Versioning

43. Evidence Integrity

44. Evidence Authentication

45. Evidence Completeness

46. Evidence Relevance

47. Evidence Currency

48. Evidence Traceability

49. Reverse Evidence Traceability

50. Evidence Reuse Decision

51. Shared Evidence

52. Shared Evidence with Extensions

53. Framework-Specific Evidence