AIGO — NIST AI RMF Mapping Architecture

1. Document Purpose

This document defines the architecture for the AIGO mapping package for the NIST Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI RMF 1.0 was published on 26 January 2023. NIST describes it as a voluntary, rights-preserving, non-sector-specific, use-case-agnostic framework intended to help organizations designing, developing, deploying, or using AI systems manage AI risks and promote trustworthy and responsible AI. The architecture establishes how NIST AI RMF concepts are translated into:

AIGO governance;
AI-system lifecycle management;
risk management;
controls;
assessments;
monitoring;
evidence;
assurance;
incident management;
change management; and
continual improvement.

This document defines the mapping architecture only. It does not reproduce the NIST AI RMF and does not represent NIST endorsement, certification, accreditation, or legal compliance.

2. Mapping Information

Field	Value
Mapping	AIGO NIST AI RMF Mapping Architecture
Version	0.1
Status	Draft
Document Identifier	`AIGO-MAP-NIST-AIRMF-ARCH-001`
Document Type	AI Risk Management Framework Mapping
Mapping Package	`AIGO-MAP-NIST-AIRMF`
Primary Framework	NIST AI RMF 1.0
Primary Publication	NIST AI 100-1
Publication Date	26 January 2023
Mapping Architecture	Current document
Primary Repository	`mappings/nist-ai-rmf/`

NIST identifies AI RMF 1.0 as NIST AI 100-1.

3. NIST AI RMF Architecture

The NIST AI RMF has two major conceptual components:

Part 1
AI Risk Framing
       ↓
Trustworthiness Characteristics
       ↓
Part 2
AI RMF Core

The AI RMF Core consists of four functions:

GOVERN
MAP
MEASURE
MANAGE

NIST describes these four functions as the operational core of the framework.

4. AIGO Translation Principle

The NIST framework should be mapped into AIGO without changing the meaning of the NIST functions. The primary relationship is:

NIST AI RMF
      ↓
Function
      ↓
Category
      ↓
Subcategory / Outcome
      ↓
AIGO Governance Objective
      ↓
AIGO Control
      ↓
Evidence
      ↓
Assurance

The NIST AI RMF remains the authoritative source for the NIST framework. AIGO provides the operational governance implementation layer.

5. Voluntary-Framework Boundary

NIST AI RMF 1.0 is intended for voluntary use. NIST explicitly states that the framework is voluntary and designed to be flexible across organizations, sectors, use cases, and AI lifecycle stages. Therefore:

NIST AI RMF Mapping
        ≠
Legal Compliance

and:

AIGO Implementation
        ≠
NIST Certification

AIGO may use the framework as an organizational risk-management reference without claiming that NIST certifies the resulting governance system.

6. Core Functions

The mapping package shall maintain the four NIST AI RMF Core functions:

GOVERN
MAP
MEASURE
MANAGE

NIST states that these functions may be performed in different orders depending on context and should operate iteratively across the AI lifecycle. AIGO should therefore avoid imposing a rigid sequential implementation model.

7. GOVERN Function

The GOVERN function establishes organizational structures, policies, processes, and practices for managing AI risks. NIST’s Playbook identifies GOVERN outcomes including policies, processes, procedures, and practices that support mapping, measuring, and managing AI risks, including understanding applicable legal and regulatory requirements. AIGO mapping domains include:

Governance;
Policy;
Roles;
Accountability;
Risk;
Competence;
Documentation;
Regulatory mapping;
Third-party governance;
Management Review.

8. MAP Function

The MAP function establishes context and identifies risks associated with an AI system. AIGO mapping domains include:

AI System;
Context;
Intended Purpose;
Stakeholders;
Risk;
Impact Assessment;
Classification;
Lifecycle;
Affected Persons.

The MAP function should feed the MEASURE and MANAGE functions.

9. MEASURE Function

The MEASURE function supports analysis and measurement of AI risks and trustworthiness characteristics. AIGO mapping domains include:

Testing;
Evaluation;
Monitoring;
Metrics;
Performance;
Bias;
Robustness;
Security;
Privacy;
Explainability;
Validity and reliability;
Evidence;
Assurance.

10. MANAGE Function

The MANAGE function uses risk assessments and analytical results to prioritize, respond to, and manage AI risks. NIST describes MANAGE as including prioritization and treatment of AI risks, risk-response planning, incident response, and continual improvement. AIGO mapping domains include:

Risk Treatment;
Controls;
Approval;
Incident;
Change;
Monitoring;
Corrective Action;
Improvement;
Retirement.

11. Iterative Architecture

The four functions should operate as an iterative system:

             ┌───────────────┐
             │    GOVERN     │
             └───────┬───────┘
                     │
                     ▼
             ┌───────────────┐
             │      MAP      │
             └───────┬───────┘
                     │
                     ▼
             ┌───────────────┐
             │    MEASURE    │
             └───────┬───────┘
                     │
                     ▼
             ┌───────────────┐
             │    MANAGE     │
             └───────┬───────┘
                     │
                     └──────────►
                     back to GOVERN / MAP / MEASURE

This is consistent with NIST’s description of the AI RMF Core as iterative and applicable throughout the AI lifecycle.

12. Trustworthy-AI Characteristics

The mapping architecture should preserve the NIST trustworthiness characteristics rather than collapsing them into a generic “AI risk” field. Relevant characteristics include:

valid and reliable;
safe;
secure and resilient;
accountable and transparent;
explainable and interpretable;
privacy-enhanced;
fair with harmful bias managed.

These characteristics are used throughout the AI RMF to frame AI risk and trustworthiness. AIGO should map each characteristic to appropriate controls and evidence instead of treating all trustworthiness concerns as a single control.

13. Trustworthiness-to-AIGO Architecture

Trustworthiness Characteristic
        ↓
Risk / Objective
        ↓
Control
        ↓
Measurement
        ↓
Evidence
        ↓
Assurance

The resulting relationship should be system-specific and risk-based.

14. AI Lifecycle Architecture

NIST AI RMF applies across AI lifecycle activities. AIGO should represent:

Governance
   ↓
Plan
   ↓
Design
   ↓
Develop / Acquire
   ↓
Test / Evaluate
   ↓
Deploy
   ↓
Operate
   ↓
Monitor
   ↓
Change
   ↓
Retire

The NIST functions can be applied throughout this lifecycle rather than being assigned to isolated lifecycle stages. NIST explicitly states that the functions can be used at any stage of the AI lifecycle.

15. AI Actor Architecture

The mapping should allow identification of relevant AI actors. Potential roles include:

provider;
developer;
deployer;
operator;
evaluator;
data provider;
system owner;
affected person;
assessor;
governance body.

AIGO should use the Governance and AI System schemas to represent organizational responsibilities.

16. Requirement-to-Control Principle

The core mapping relationship is:

NIST Function
      ↓
NIST Category
      ↓
NIST Subcategory / Outcome
      ↓
AIGO Control

A NIST subcategory may map to:

one AIGO control;
multiple AIGO controls;
an integrated AIGO process;
an existing organizational control.

The mapping therefore supports many-to-many relationships.

17. Mapping Relationship Types

The registry should support:

DIRECT
PARTIAL
SUPPORTING
INTEGRATED
CONDITIONAL
CROSS_REFERENCE
DERIVED
NO_DIRECT_EQUIVALENT

DIRECT

AIGO directly implements the mapped NIST outcome.

PARTIAL

AIGO addresses only part of the outcome.

SUPPORTING

AIGO supports the outcome but does not implement it completely.

INTEGRATED

Several AIGO controls collectively implement the outcome.

CONDITIONAL

The relationship depends on organizational or system conditions.

CROSS_REFERENCE

An existing AIGO artifact provides the authoritative implementation.

DERIVED

The mapping is derived from another controlled AIGO relationship.

NO_DIRECT_EQUIVALENT

The NIST outcome requires an organizational activity not represented by a dedicated AIGO artifact.

18. Mapping Status

Mapping records should support:

MAPPED
DEFINED
IMPLEMENTED
EVIDENCED
ASSESSED
MONITORED
ASSURED
SUPERSEDED
RETIRED

A mapping status does not indicate that NIST has formally certified the organization.

19. AIGO Control Architecture

The NIST mapping should use the existing AIGO Control Schema. The relationship is:

NIST Outcome
      ↓
AIGO Control ID
      ↓
Control Objective
      ↓
Procedure
      ↓
Evidence
      ↓
Monitoring
      ↓
Assurance

A new NIST-specific control definition should not be created when an existing AIGO control already provides the required operational capability.

20. AIGO Schema Architecture

The mapping should reuse existing AIGO schemas:

AI System;
Risk;
Control;
Assessment;
Approval;
Monitoring;
Incident;
Change;
Assurance;
Evidence;
Management Review;
Improvement;
Retirement;
Governance.

This allows NIST AI RMF to integrate with the same operational governance data model used by ISO/IEC 42001 and EU AI Act mappings.

21. AIGO Template Architecture

The mapping should use the existing AIGO templates, including:

AI System Registration;
AI System Profile;
AI Classification;
AI Risk Assessment;
AI Approval;
AI Monitoring;
AI Incident;
AI Change Management;
AI Assurance;
AI Management Review;
AI Continuous Improvement;
AI Retirement;
AI Evidence Record.

22. GOVERN — Policy Architecture

The GOVERN mapping should address:

AI governance policies;
risk-management policies;
accountability;
roles;
legal/regulatory awareness;
documentation;
organizational culture;
monitoring;
management oversight.

NIST’s Playbook specifically includes legal and regulatory requirements as a GOVERN 1.1 topic.

23. GOVERN — Accountability

AIGO should identify:

accountable AI governance owner;
system owner;
risk owner;
control owner;
technical owner;
evidence owner;
assurance owner.

Accountability should be linked to actual authority.

24. GOVERN — Policies and Processes

Policies should be supported by operational processes.

Policy
 ↓
Process
 ↓
Control
 ↓
Evidence
 ↓
Monitoring

A policy without an operating mechanism should not be treated as complete governance implementation.

25. GOVERN — Organizational Culture

AIGO should provide governance mechanisms supporting:

risk awareness;
responsible AI culture;
escalation;
transparency;
learning;
challenge;
continual improvement.

NIST describes GOVERN as establishing organizational processes and practices that support the other AI RMF functions.

26. GOVERN — Competence

AIGO should map NIST governance expectations related to:

personnel;
roles;
training;
awareness;
technical capability;
risk-management capability.

AI literacy should be mapped separately when a regulatory framework such as the EU AI Act imposes a specific requirement.

27. GOVERN — Resource Management

Governance evidence should support:

people;
technology;
evaluation resources;
monitoring;
assurance;
incident response.

Resource limitations should be considered as AI governance risks.

28. GOVERN — Legal and Regulatory Requirements

AIGO should maintain links to relevant:

laws;
regulations;
standards;
contractual requirements;
policies;
guidance.

The cross-framework mapping layer should connect NIST AI RMF to:

EU AI Act
ISO/IEC 42001
Other Regulations
Internal Governance

NIST identifies understanding and documenting applicable legal and regulatory requirements as part of GOVERN 1.1.

29. MAP — Context

The MAP function should establish the context necessary to understand AI risks. AIGO should represent:

intended purpose;
use context;
users;
affected persons;
stakeholders;
deployment environment;
organizational objectives;
legal context;
technical characteristics.

30. MAP — AI System Profile

The AIGO AI System Profile should provide the primary operational record for:

system identity;
intended purpose;
lifecycle state;
owner;
deployment context;
dependencies;
interfaces;
users;
affected persons.

31. MAP — Stakeholder Analysis

AIGO should capture:

stakeholder group;
interests;
possible impacts;
expectations;
concerns;
communication;
participation.

The analysis should support multidisciplinary and affected-person perspectives. NIST emphasizes diverse and multidisciplinary perspectives in applying the AI RMF Core.

32. MAP — Risk Identification

AIGO should identify risks across:

technical;
operational;
safety;
security;
privacy;
fairness;
social;
human;
legal;
reputational;
environmental dimensions where relevant.

The exact risk taxonomy should remain configurable.

33. MAP — Impact Assessment

Impact assessments should identify:

affected people;
affected communities;
severity;
likelihood;
distribution of impacts;
intended and unintended consequences;
mitigations.

AIGO Assessment and Risk schemas should support this.

34. MAP — AI Lifecycle Context

Risk context should be assessed at different lifecycle stages:

Design Risk
Development Risk
Testing Risk
Deployment Risk
Operational Risk
Change Risk
Retirement Risk

Risks may change as the system progresses through the lifecycle.

35. MEASURE — Measurement Architecture

The MEASURE function should connect:

Risk / Trustworthiness Claim
      ↓
Measurement Objective
      ↓
Metric
      ↓
Method
      ↓
Result
      ↓
Evaluation

36. MEASURE — Technical Testing

Potential measurement domains include:

validity;
reliability;
performance;
safety;
robustness;
security;
privacy;
fairness;
explainability;
transparency.

The applicable measures depend on system context and risk.

37. MEASURE — Data Quality

Measurement may evaluate:

data quality;
representativeness;
completeness;
bias;
lineage;
labeling;
drift.

AIGO Data Governance controls may support these activities.

38. MEASURE — Bias and Fairness

AIGO should support:

bias identification;
metric selection;
fairness analysis;
subgroup analysis where lawful;
mitigation;
remeasurement.

NIST’s AI RMF treats fairness with harmful bias managed as a trustworthiness consideration.

39. MEASURE — Privacy

Where applicable, measurement should assess:

privacy risks;
data exposure;
privacy controls;
inference risks;
retention;
access.

Privacy requirements should also be mapped to applicable legal frameworks such as GDPR where relevant.

40. MEASURE — Security

Potential measurement areas:

vulnerability;
adversarial robustness;
attack resistance;
access control;
model integrity;
supply-chain risks;
incident response.

41. MEASURE — Explainability and Interpretability

Where applicable, evidence may include:

explanation methods;
human review;
interpretability tests;
explanation consistency;
user testing.

The appropriate method depends on system and use context.

42. MEASURE — Transparency

AIGO should evaluate whether required information is:

available;
accurate;
understandable;
timely;
accessible to relevant stakeholders.

Where a legal transparency requirement exists, the corresponding regulatory mapping remains authoritative.

43. MEASURE — Evaluation Evidence

Every significant measurement should preserve:

objective;
method;
data;
assumptions;
result;
interpretation;
limitations;
reviewer.

44. MANAGE — Risk Prioritization

NIST’s MANAGE function uses outputs from MAP and MEASURE to prioritize risk treatment. NIST identifies impact, likelihood, available resources, and risk-response planning as relevant management considerations. AIGO should map this to:

Risk;
Assessment;
Approval;
Control;
Improvement.

45. MANAGE — Risk Treatment

Risk treatment may include:

mitigation;
avoidance;
transfer;
monitoring;
acceptance;
redesign;
restriction;
retirement.

Treatment decisions should be recorded.

46. MANAGE — Deployment Decision

AIGO should support a governance gate determining whether an AI system:

achieves intended purposes;
meets defined objectives;
has unacceptable unresolved risks;
should proceed;
requires modification;
should be restricted.

NIST includes a MANAGE 1.1 outcome concerning whether the system achieves intended purposes and whether development or deployment should proceed.

47. MANAGE — Risk Response

High-priority risks should have:

response;
owner;
deadline;
control;
evidence;
monitoring;
escalation.

48. MANAGE — Residual Risk

AIGO should maintain:

Initial Risk
 ↓
Treatment
 ↓
Residual Risk
 ↓
Decision
 ↓
Monitoring

Residual-risk decisions should identify accountable authority.

49. MANAGE — Incident Response

NIST’s MANAGE function includes responding to and recovering from incidents or events. AIGO Incident Management should therefore support:

detection;
classification;
containment;
investigation;
communication;
recovery;
corrective action;
lessons learned.

50. MANAGE — Continuous Monitoring

Risk management should continue after deployment. NIST explicitly states that MANAGE should continue to be applied to deployed AI systems as methods, contexts, risks, and expectations evolve. AIGO Monitoring should therefore remain active during the operational lifecycle.

51. Trustworthy-AI Architecture

The NIST trustworthiness characteristics should be mapped to AIGO domains:

NIST Trustworthiness Characteristic	AIGO Domains
Valid and Reliable	Performance / Monitoring / Assurance
Safe	Risk / Control / Incident
Secure and Resilient	Security / Risk / Monitoring
Accountable and Transparent	Governance / Evidence / Transparency
Explainable and Interpretable	Assessment / Human Oversight
Privacy-Enhanced	Privacy / Data Governance
Fair with Harmful Bias Managed	Rights / Risk / Measurement

The mapping is contextual rather than one-to-one.

52. AI Risk Taxonomy

AIGO should support risk domains including:

SAFETY
SECURITY
PRIVACY
FAIRNESS
BIAS
RELIABILITY
ROBUSTNESS
TRANSPARENCY
EXPLAINABILITY
ACCOUNTABILITY
HUMAN_OVERSIGHT
SOCIAL_IMPACT
LEGAL
OPERATIONAL
REPUTATIONAL
ENVIRONMENTAL

Organizations may extend the taxonomy.

53. Risk Aggregation

AI-system risks should roll up where useful:

AI System Risk
      ↓
Portfolio Risk
      ↓
Enterprise AI Risk
      ↓
Management Review

The aggregation should preserve the source system.

54. Evidence Architecture

Evidence should connect:

NIST Function
      ↓
Category
      ↓
Subcategory
      ↓
AIGO Control
      ↓
Evidence
      ↓
Assurance

The Evidence Schema remains the authoritative structure.

55. Assurance Architecture

AIGO assurance should evaluate:

governance;
context;
risk;
measurement;
risk treatment;
evidence;
lifecycle implementation.

AIGO assurance is distinct from NIST endorsement or certification.

56. NIST Playbook Boundary

The NIST AI RMF Playbook provides suggested actions for achieving AI RMF outcomes and is voluntary. NIST explicitly states that the Playbook is not a checklist or ordered implementation sequence and can be tailored by organizations. AIGO should therefore map Playbook material as: IMPLEMENTATION GUIDANCE rather than as normative requirements.

57. Playbook Mapping

The mapping architecture may identify:

AI RMF Outcome
      ↓
Playbook Suggested Action
      ↓
AIGO Implementation Option
      ↓
AIGO Control

Not every Playbook suggestion needs a dedicated AIGO control.

58. NIST AI RMF 1.0 Update Status

NIST’s current AI RMF resource page states that AI RMF 1.0 is being updated. The current Playbook also states that it will be updated after the AI RMF is revised. Therefore this mapping must explicitly preserve:

Framework Version:
AI RMF 1.0

Update Status:
NIST AI RMF being updated

The mapping should not silently treat a future revision as already normative.

59. Generative AI Profile

NIST published the AI Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1, on 26 July 2024 as a companion profile to AI RMF 1.0. AIGO should treat this as a profile extending the application of AI RMF 1.0 to generative AI. It is not a replacement for AI RMF 1.0.

60. Generative-AI Mapping Relationship

The architecture should support:

NIST AI RMF 1.0
      ↓
Generative AI Profile
      ↓
Applicable Risk
      ↓
AIGO Controls
      ↓
Evidence
      ↓
Assurance

The detailed NIST package may later include a dedicated generative-AI profile mapping if operational requirements justify it.

61. Critical Infrastructure Profile

NIST released a concept note on 7 April 2026 for an AI RMF Profile on Trustworthy AI in Critical Infrastructure. NIST’s current AI RMF page identifies this as a concept note intended to guide critical-infrastructure operators. AIGO should track this as an external development. It should not be represented as an existing NIST AI RMF 1.0 requirement.

62. Version-Control Principle

The mapping must distinguish:

NIST AI RMF 1.0

from:

NIST AI RMF future revision

and from:

NIST AI RMF Profile

This prevents version contamination.

63. Cross-Framework Integration

The NIST mapping should integrate with:

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

Shared AIGO controls should be reused where appropriate.

64. Cross-Framework Control Example

AIGO Risk Control
      ├── NIST AI RMF
      ├── ISO/IEC 42001
      └── EU AI Act

Each framework relationship remains independently traceable.

65. Cross-Framework Boundary

NIST AI RMF is voluntary. ISO/IEC 42001 is a management-system standard. EU AI Act is binding EU law. AIGO must preserve these differences.

NIST AI RMF
→ Voluntary Framework

ISO/IEC 42001
→ Management-System Standard

EU AI Act
→ Binding Regulation

This distinction should be reflected in machine-readable metadata and user-facing documentation.

66. Common-Control Model

AIGO controls should operate at the common operational layer:

NIST / ISO / Regulation
        ↓
Requirement
        ↓
AIGO Control
        ↓
Evidence
        ↓
Assurance

This minimizes duplicate governance processes.

67. Conflict Management

When frameworks impose different requirements:

preserve each source;
identify the difference;
assess applicability;
define the shared control;
document additional requirements;
obtain legal/standards review when needed.

NIST guidance should not be treated as overriding law or a normative ISO requirement.

68. Scope Architecture

NIST AI RMF mapping should support:

Organization Scope
      ↓
AI Portfolio
      ↓
System Scope
      ↓
Risk Context
      ↓
Applicable Functions

Because NIST is flexible, not every organization needs to implement every suggested practice in the same way.

69. Implementation Principle

AIGO implementation should prioritize risk and context. NIST describes the AI RMF as flexible and adaptable to organizations of different sizes, sectors, and capabilities. Therefore the AIGO mapping should not force:

one universal process;
one risk methodology;
one measurement set;
one implementation order.

70. Measurement Architecture

Measurement should be:

risk-based;
context-specific;
reproducible where possible;
documented;
linked to decisions.

AIGO should preserve metric lineage:

Metric
 ↓
Data Source
 ↓
Method
 ↓
Result
 ↓
Interpretation
 ↓
Decision

71. Risk-Management Architecture

The complete risk cycle is:

Identify
 ↓
Analyze
 ↓
Evaluate
 ↓
Prioritize
 ↓
Treat
 ↓
Monitor
 ↓
Reassess

This aligns the NIST MANAGE function with the existing AIGO Risk and Monitoring schemas.

72. Decision Governance

Where risk assessment affects deployment or continuation, AIGO Approval should capture:

decision;
rationale;
risk state;
conditions;
owner;
evidence;
review date.

73. Human Oversight

NIST AI RMF governance should connect to AIGO human oversight controls where relevant. Potential evidence:

responsible person;
authority;
intervention;
escalation;
review;
training.

74. Incident Governance

Incident records should connect:

Incident
 ↓
Risk
 ↓
Control
 ↓
Evidence
 ↓
Corrective Action
 ↓
Monitoring

This supports the iterative nature of MANAGE.

75. Change Governance

Changes should trigger re-evaluation of:

context;
risk;
measurements;
controls;
evidence;
deployment decision.

76. Retirement Governance

Retirement should consider:

unresolved risks;
incidents;
evidence retention;
stakeholder obligations;
residual impacts;
lessons learned.

77. Governance-to-Management-Review

NIST governance results should feed AIGO Management Review. Potential inputs:

risk trends;
measurement results;
incidents;
stakeholder concerns;
control failures;
emerging risks;
regulatory changes.

78. Assurance Model

The assurance chain should be:

NIST Outcome
 ↓
AIGO Control
 ↓
Evidence
 ↓
Test
 ↓
Conclusion
 ↓
Finding
 ↓
Improvement

79. Assurance Boundaries

AIGO assurance does not:

certify NIST AI RMF;
create NIST accreditation;
establish legal compliance;
substitute for ISO certification;
substitute for statutory conformity.

80. NIST AI RMF Coverage

A future coverage calculation may show:

Applicable NIST Outcomes
       ↓
Mapped
       ↓
Controlled
       ↓
Implemented
       ↓
Evidenced
       ↓
Measured
       ↓
Managed

This is a governance maturity indicator, not a NIST certification score.

81. Evidence Coverage

Evidence coverage should identify:

missing governance evidence;
missing mapping evidence;
missing measurements;
missing risk treatments;
missing monitoring;
missing assurance.

82. Control Coverage

Control coverage should identify:

NIST outcomes without controls;
shared controls;
partial controls;
control gaps;
controls without owners.

83. Traceability

The minimum traceability chain is:

NIST Function
 ↓
Category
 ↓
Subcategory
 ↓
AIGO Control
 ↓
Evidence
 ↓
Assurance

84. Repository Validation

The mapping package should be validated through:

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

85. NIST-Specific Validation

The mapping should additionally verify:

Function Coverage

GOVERN, MAP, MEASURE, MANAGE are represented.

Category Coverage

NIST categories are mapped appropriately.

Version Coverage

AI RMF 1.0 is the explicit baseline.

Profile Separation

GAI and other profiles are not confused with the core framework.

Voluntary Status

NIST AI RMF is not represented as binding law.

86. Regulatory and Standards Source Currency

The NIST mapping should monitor:

AI RMF revisions;
Playbook updates;
Generative AI Profile;
emerging NIST profiles;
NIST crosswalks;
relevant NIST technical publications.

NIST’s current resources page identifies AI RMF 1.0, the Playbook, the Generative AI Profile, and other AI RMF resources.

87. Source Hierarchy

The NIST mapping should use:

NIST AI RMF Publication
        ↓
NIST Official Core / Resource
        ↓
NIST Profile
        ↓
NIST Playbook
        ↓
AIGO Mapping
        ↓
AIGO Implementation

NIST Playbook suggestions should remain identified as voluntary implementation guidance.

88. Profile Hierarchy

A profile should be represented as:

Core Framework
      ↓
Profile
      ↓
Context-Specific Guidance

The Generative AI Profile is a companion profile to AI RMF 1.0.

89. Future NIST Revision

If NIST publishes a new AI RMF version:

New NIST Version
      ↓
Source Verification
      ↓
Mapping Impact
      ↓
Control Impact
      ↓
Evidence Impact
      ↓
Assurance Impact
      ↓
Registry Update

Historical AI RMF 1.0 mappings should remain identifiable.

90. NIST Mapping Version

The AIGO package should explicitly state:

NIST Baseline:
AI RMF 1.0

AIGO Mapping:
v0.1

This prevents future NIST revisions from silently altering the mapping.

91. Mapping Package Architecture

The current NIST package is:

— Master Mapping
— Functions Mapping
— Categories Mapping
— Lifecycle Mapping
— Risk Mapping
— Governance Mapping
— Evidence Mapping
— Implementation Mapping

The package will be completed with:

— Architecture
— Registry
— Assurance Mapping
— AIGO Control Mapping
README

92. File Responsibilities

`01-AIGO-NIST-AI-RMF-Mapping-v0.1.md`

High-level NIST AI RMF → AIGO mapping.

`02-AIGO-NIST-AI-RMF-Functions-Mapping-v0.1.md`

Detailed mapping of:

GOVERN;
MAP;
MEASURE;
MANAGE.

`03-AIGO-NIST-AI-RMF-Categories-Mapping-v0.1.md`

Detailed categories and subcategory mapping.

`04-AIGO-NIST-AI-RMF-Lifecycle-Mapping-v0.1.md`

Lifecycle integration.

`05-AIGO-NIST-AI-RMF-Risk-Mapping-v0.1.md`

Risk identification, analysis, prioritization, treatment, monitoring, and residual risk.

`06-AIGO-NIST-AI-RMF-Governance-Mapping-v0.1.md`

Governance, policies, accountability, roles, culture, and legal/regulatory awareness.

`07-AIGO-NIST-AI-RMF-Evidence-Mapping-v0.1.md`

Evidence and traceability.

`08-AIGO-NIST-AI-RMF-Implementation-Mapping-v0.1.md`

Operational implementation guidance.

`09-AIGO-NIST-AI-RMF-Assurance-Mapping-v0.1.md`

Assurance, testing, evaluation, findings, and follow-up.

`10-AIGO-NIST-AI-RMF-AIGO-Control-Mapping-v0.1.md`

Detailed NIST outcome → AIGO control crosswalk.

`00-AIGO-NIST-AI-RMF-Mapping-Registry-v0.1.json`

Machine-readable mapping registry.

`README.md`

Human-facing directory entry point.

93. Recommended Reading Order

00 Architecture
        ↓
00 Registry
        ↓
01 Master Mapping
        ↓
02 Functions
        ↓
03 Categories
        ↓
04 Lifecycle
        ↓
05 Risk
        ↓
06 Governance
        ↓
07 Evidence
        ↓
08 Implementation
        ↓
09 Assurance
        ↓
10 AIGO Control Mapping

94. Recommended Implementation Order

Although NIST does not require a fixed sequence, AIGO may use this operational sequence:

GOVERN
   ↓
MAP
   ↓
MEASURE
   ↓
MANAGE
   ↺

with continuous feedback between the functions. This is an AIGO implementation convenience, not a NIST-required sequence. NIST expressly states that functions may be performed in different orders depending on context.

95. AIGO Governance Integration

NIST governance controls should connect to:

Governance Schema;
Management Review;
Policy;
Risk;
Control;
Evidence;
Assurance.

96. AIGO Risk Integration

NIST risk management should use the AIGO Risk Schema. The risk record should preserve:

source;
system;
context;
likelihood;
impact;
priority;
treatment;
residual risk;
owner.

97. AIGO Measurement Integration

Measurement records should use:

Monitoring;
Assessment;
Evidence;
Assurance.

A metric without a decision or monitoring context should not automatically be treated as a governance measure.

98. AIGO Manage Integration

Risk treatment should use:

Control;
Approval;
Incident;
Change;
Improvement;
Retirement.

99. Evidence Architecture

The NIST evidence chain is:

NIST Outcome
      ↓
AIGO Control
      ↓
Activity
      ↓
Evidence
      ↓
Validation
      ↓
Assurance

The Evidence Schema remains authoritative.

100. Assurance Architecture

The assurance chain is:

NIST Outcome
      ↓
Control
      ↓
Evidence
      ↓
Measurement / Test
      ↓
Assurance
      ↓
Finding
      ↓
Improvement

101. Control Reuse

AIGO should prefer existing controls. Example:

AIGO Risk Control
       ├── NIST AI RMF
       ├── ISO/IEC 42001
       └── EU AI Act

This reinforces the common-control architecture.

102. Shared Evidence

Evidence may be reused across mapping packages when:

applicable;
current;
sufficient;
traceable.

For example, one risk assessment may support:

NIST MAP;
ISO/IEC 42001 planning;
EU AI Act risk requirements.

Each relationship must be explicit.

103. Shared Assurance

One assurance activity may evaluate several framework relationships where:

criteria are clearly separated;
reviewer competence is adequate;
scope is sufficient.

104. Cross-Framework Maturity

AIGO may eventually provide a unified maturity view:

NIST Coverage
      +
ISO Coverage
      +
EU AI Act Coverage
      ↓
AIGO Governance Maturity

This should not be represented as a score issued by NIST, ISO, or the EU.

105. Findings

Potential NIST mapping findings:

NIST_FUNCTION_UNMAPPED
NIST_CATEGORY_UNMAPPED
NIST_SUBCATEGORY_UNMAPPED
AIGO_CONTROL_MISSING
NIST_EVIDENCE_GAP
NIST_MEASUREMENT_GAP
NIST_RISK_TREATMENT_GAP
NIST_ASSURANCE_GAP
NIST_VERSION_GAP
NIST_PROFILE_CONFUSION
NIST_SOURCE_CURRENCY_GAP

106. Critical Findings

Potential critical findings include:

high-impact AI risk lacks a mapped control;
high-priority risk lacks treatment;
critical measurement has no reliable evidence;
deployed AI risk is not monitored;
incident-response evidence is unavailable;
governance accountability is missing;
NIST profile material is misrepresented as a mandatory requirement.

107. Repository Health

Repository health should verify:

all expected mapping files;
registry synchronization;
valid references;
function coverage;
category coverage;
control coverage;
evidence coverage;
assurance coverage;
version metadata.

108. Document Integrity

The Document Integrity Checker should verify:

file existence;
readability;
version;
required metadata;
references;
structure.

109. Framework Consistency

The Framework Consistency Checker should identify:

conflicting control mappings;
duplicate identifiers;
inconsistent NIST terminology;
inconsistent framework version;
profile/core confusion;
conflicting AIGO control references.

110. Validation Tools

The mapping package should be consumed by:

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

111. Machine-Readable Architecture

The registry should eventually support:

mappingId
documentId
nistFunction
nistCategory
nistSubcategory
aigoControlId
aigoSchema
aigoTemplate
relationship
applicability
status
evidence
assurance
sourceVersion
reviewDate

112. Registry Principle

The mapping registry should describe relationships and metadata. It should not reproduce the entire narrative contents of the mapping documents.

113. NIST Profile Metadata

The registry should support profile metadata such as:

profileId
profileName
profileVersion
publicationDate
parentFramework
status

This allows the Generative AI Profile and future profiles to remain separate from the AI RMF Core.

114. Source Metadata

Every mapping should identify:

NIST document;
publication number;
version;
publication date;
source location;
review date.

115. Source Currency

The organization should review the mapping when:

AI RMF is revised;
Playbook changes materially;
new profiles are published;
NIST changes implementation resources;
crosswalks are updated;
relevant federal guidance changes.

NIST states that the current Playbook will be updated after AI RMF 1.0 is revised.

116. Current NIST Baseline

The baseline for this mapping is:

NIST AI RMF 1.0
NIST AI 100-1
Published:
26 January 2023

117. Current Supplementary Baseline

The current supplementary profile baseline includes:

NIST AI 600-1
Generative AI Profile
Published:
26 July 2024

NIST describes this as a cross-sectoral companion profile for generative AI.

118. Current Development Watch

NIST’s current AI RMF page identifies the framework as being updated and identifies a 2026 concept note for an AI RMF profile focused on trustworthy AI in critical infrastructure. The AIGO mapping should monitor these developments without treating them as part of AI RMF 1.0 until formally published.

119. Implementation Boundary

08-AIGO-NIST-AI-RMF-Implementation-Mapping-v0.1.md should remain responsible for implementation guidance. This architecture file defines the structure only.

120. Evidence Boundary

07-AIGO-NIST-AI-RMF-Evidence-Mapping-v0.1.md should remain responsible for detailed evidence relationships.

121. Assurance Boundary

09-AIGO-NIST-AI-RMF-Assurance-Mapping-v0.1.md will remain responsible for detailed assurance relationships.

122. Control Boundary

10-AIGO-NIST-AI-RMF-AIGO-Control-Mapping-v0.1.md will remain responsible for detailed NIST-to-AIGO-control relationships.

123. Registry Boundary

00-AIGO-NIST-AI-RMF-Mapping-Registry-v0.1.json will be the machine-readable index for the package.

124. README Boundary

README.md will be the human-facing entry point. It should contain:

purpose;
file inventory;
reading order;
source hierarchy;
framework status;
validation;
ownership.

125. Final Architecture Rule

The NIST AI RMF mapping package follows:

NIST AI RMF
      ↓
GOVERN
MAP
MEASURE
MANAGE
      ↓
NIST Category
      ↓
NIST Subcategory / Outcome
      ↓
AIGO Governance Objective
      ↓
AIGO Control
      ↓
Evidence
      ↓
Monitoring
      ↓
Assurance
      ↓
Risk Treatment
      ↓
Improvement

The functions remain iterative rather than a mandatory linear sequence.

126. Final Principle

The AIGO NIST AI RMF mapping is designed to operationalize the NIST AI Risk Management Framework within a reusable AI governance architecture. NIST AI RMF 1.0 remains the authoritative NIST framework baseline. AIGO provides the operational layer connecting NIST’s GOVERN, MAP, MEASURE, and MANAGE functions to:

AI systems;
risks;
controls;
assessments;
evidence;
monitoring;
incidents;
changes;
assurance;
management review; and
continual improvement.

The architecture also establishes the foundation for integrating NIST AI RMF with ISO/IEC 42001, the EU AI Act, and other AIGO mapping packages without conflating their different legal or normative statuses. End of Document

​AIGO — NIST AI RMF Mapping Architecture

​1. Document Purpose

​2. Mapping Information

​3. NIST AI RMF Architecture

​4. AIGO Translation Principle

​5. Voluntary-Framework Boundary

​6. Core Functions

​7. GOVERN Function

​8. MAP Function

​9. MEASURE Function

​10. MANAGE Function

​11. Iterative Architecture

​12. Trustworthy-AI Characteristics

​13. Trustworthiness-to-AIGO Architecture

​14. AI Lifecycle Architecture

​15. AI Actor Architecture

​16. Requirement-to-Control Principle

​17. Mapping Relationship Types

​DIRECT

​PARTIAL

​SUPPORTING

​INTEGRATED

​CONDITIONAL

​CROSS_REFERENCE

​DERIVED

​NO_DIRECT_EQUIVALENT

​18. Mapping Status

​19. AIGO Control Architecture

​20. AIGO Schema Architecture

​21. AIGO Template Architecture

​22. GOVERN — Policy Architecture

​23. GOVERN — Accountability

​24. GOVERN — Policies and Processes

​25. GOVERN — Organizational Culture

​26. GOVERN — Competence

​27. GOVERN — Resource Management

​28. GOVERN — Legal and Regulatory Requirements

​29. MAP — Context

​30. MAP — AI System Profile

​31. MAP — Stakeholder Analysis

​32. MAP — Risk Identification

​33. MAP — Impact Assessment

​34. MAP — AI Lifecycle Context

​35. MEASURE — Measurement Architecture

​36. MEASURE — Technical Testing

​37. MEASURE — Data Quality

​38. MEASURE — Bias and Fairness

​39. MEASURE — Privacy

​40. MEASURE — Security

​41. MEASURE — Explainability and Interpretability

​42. MEASURE — Transparency

​43. MEASURE — Evaluation Evidence

​44. MANAGE — Risk Prioritization

​45. MANAGE — Risk Treatment

​46. MANAGE — Deployment Decision

​47. MANAGE — Risk Response

​48. MANAGE — Residual Risk

​49. MANAGE — Incident Response

​50. MANAGE — Continuous Monitoring

​51. Trustworthy-AI Architecture

​52. AI Risk Taxonomy

​53. Risk Aggregation

​54. Evidence Architecture

​55. Assurance Architecture

​56. NIST Playbook Boundary

​57. Playbook Mapping

​58. NIST AI RMF 1.0 Update Status

​59. Generative AI Profile

​60. Generative-AI Mapping Relationship

​61. Critical Infrastructure Profile

​62. Version-Control Principle

​63. Cross-Framework Integration

​64. Cross-Framework Control Example

​65. Cross-Framework Boundary

​66. Common-Control Model

​67. Conflict Management

​68. Scope Architecture

​69. Implementation Principle

​70. Measurement Architecture

​71. Risk-Management Architecture