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

# 02 AIGO NIST AI RMF Functions Mapping v0.1

# AIGO — NIST AI RMF Functions Mapping

## AIGO — AI Governance Operating Framework

**Version:** 0.1
**Status:** Draft
**Working Name:** AIGO
**Full Name:** AI Governance Operating Framework
**Document Identifier:** `AIGO-MAP-NIST-AIRMF-002`
**Mapping Standard:** NIST AI Risk Management Framework (AI RMF) 1.0
**Mapping Type:** Functions Mapping
**Primary Functions:** GOVERN, MAP, MEASURE, MANAGE

***

## 1. Purpose

This document defines the detailed relationship between the four core functions of the NIST Artificial Intelligence Risk Management Framework (AI RMF) 1.0 and the AIGO AI Governance Operating Framework.

The four NIST AI RMF functions are:

1. GOVERN
2. MAP
3. MEASURE
4. MANAGE

The purpose of this document is to establish function-level traceability between the NIST AI RMF and AIGO governance architecture.

This document should be read together with:

* `01-AIGO-NIST-AI-RMF-Mapping-v0.1.md`
* `03-AIGO-NIST-AI-RMF-Categories-Mapping-v0.1.md`
* `04-AIGO-NIST-AI-RMF-Lifecycle-Mapping-v0.1.md`
* `05-AIGO-NIST-AI-RMF-Risk-Mapping-v0.1.md`
* `06-AIGO-NIST-AI-RMF-Governance-Mapping-v0.1.md`
* `07-AIGO-NIST-AI-RMF-Evidence-Mapping-v0.1.md`
* `08-AIGO-NIST-AI-RMF-Implementation-Mapping-v0.1.md`

***

## 2. Mapping Baseline

This document uses **NIST AI RMF 1.0** as its mapping baseline.

The NIST AI RMF Core is structured around four functions:

* GOVERN
* MAP
* MEASURE
* MANAGE

The functions are intended to provide a flexible structure for organizations to manage AI risks.

They are not intended to be interpreted as a mandatory sequential workflow.

AIGO therefore maps the functions to its own governance lifecycle and operational processes without treating the NIST functions as a rigid sequence.

***

## 3. Function Architecture

The NIST AI RMF function architecture can be represented as:

```text theme={null}
                 NIST AI RMF
                      |
        +-------------+-------------+
        |             |             |
      GOVERN          MAP        MEASURE
        |             |             |
        +-------------+-------------+
                      |
                   MANAGE
```

The functions interact continuously.

GOVERN is cross-cutting and provides organizational governance conditions.

MAP establishes context and identifies risks.

MEASURE provides measurement, assessment, testing and monitoring.

MANAGE prioritizes and responds to identified risks.

***

## 4. AIGO Function Mapping Model

The AIGO function mapping is:

| NIST Function | AIGO Primary Capability                                                               |
| ------------- | ------------------------------------------------------------------------------------- |
| GOVERN        | Governance architecture, accountability, policies, roles, controls and oversight      |
| MAP           | Context establishment, AI system registration, classification and risk identification |
| MEASURE       | Assessment, testing, measurement, monitoring and assurance                            |
| MANAGE        | Risk treatment, approval, acceptance, incident response, change and retirement        |

These relationships are not exclusive.

Each NIST function may interact with multiple AIGO components.

***

# 5. GOVERN

## 5.1 Function Purpose

GOVERN establishes the organizational structures, policies, processes, procedures, accountability mechanisms and organizational culture necessary for managing AI risks.

Within AIGO, GOVERN is represented as the foundational governance capability supporting all AI lifecycle activities.

***

## 5.2 AIGO GOVERN Architecture

```text theme={null}
AIGO Governance Architecture
          |
          v
Governance Principles
          |
          v
Governance Domains
          |
          v
Governance Roles
          |
          v
Governance Controls
          |
          v
Governance Procedures
          |
          v
Decision Rights
          |
          v
Oversight
          |
          v
Monitoring / Assurance
```

GOVERN therefore maps primarily to the AIGO governance architecture rather than to a single lifecycle stage.

***

## 5.3 Primary AIGO References

GOVERN is supported by:

* AIGO Framework Charter
* AIGO Terminology
* AIGO Framework Principles
* AIGO Governance Domains
* AIGO Governance Roles
* AIGO Governance Lifecycle
* AIGO AI Risk Management
* AIGO Governance Controls
* Governance Implementation Guidance
* AI Governance Procedure
* Approval Procedure
* Risk Acceptance Procedure
* Monitoring Procedure
* Assurance Procedure
* Continuous Improvement Procedure

***

## 5.4 GOVERN and Accountability

AIGO establishes accountability through defined roles and decision rights.

The relationship is:

```text theme={null}
Governance Requirement
        ↓
Accountable Role
        ↓
Responsible Role
        ↓
Control Owner
        ↓
Operational Activity
        ↓
Evidence
        ↓
Review
        ↓
Decision
```

This structure allows governance responsibilities to be assigned rather than left implicit.

***

## 5.5 GOVERN and Organizational Context

AIGO governance considers:

* organizational objectives;
* AI use cases;
* organizational risk tolerance;
* stakeholder expectations;
* legal obligations;
* regulatory requirements;
* contractual requirements;
* technology dependencies;
* third-party dependencies;
* operational environment.

The organization-level context is established before detailed system-specific risk decisions are made.

***

## 5.6 GOVERN and AI Risk Policy

AIGO provides the policy and framework layer through:

* governance principles;
* risk-management principles;
* control objectives;
* accountability requirements;
* approval requirements;
* escalation requirements;
* monitoring requirements;
* assurance requirements.

This creates the conditions under which AI risk can be managed consistently.

***

## 5.7 GOVERN and Risk Tolerance

Risk tolerance determines how AI risks are treated.

AIGO therefore connects governance decisions to:

```text theme={null}
Organizational Objectives
        ↓
Risk Appetite / Tolerance
        ↓
Risk Criteria
        ↓
Risk Assessment
        ↓
Treatment Decision
        ↓
Risk Acceptance
        ↓
Approval
```

Risk tolerance should be documented and applied consistently where practicable.

***

## 5.8 GOVERN and Roles

Relevant AIGO roles may include:

* governance authority;
* AI governance owner;
* AI system owner;
* risk owner;
* control owner;
* technical owner;
* business owner;
* assurance role;
* reviewer;
* approver;
* incident owner.

The exact allocation of roles depends on organizational context.

***

## 5.9 GOVERN and Competence

AI governance requires appropriate competence.

AIGO should therefore establish mechanisms for:

* role definition;
* competency expectations;
* training;
* awareness;
* specialist review;
* escalation to subject-matter expertise.

Competence requirements should reflect the complexity and risk of the AI system.

***

## 5.10 GOVERN and Organizational Culture

Governance effectiveness depends on organizational behavior.

AIGO therefore supports:

* accountability;
* transparency;
* escalation;
* challenge;
* documentation;
* evidence-based decision-making;
* continuous learning;
* responsible risk acceptance.

A governance framework should not encourage personnel to suppress risk information in order to achieve deployment objectives.

***

## 5.11 GOVERN and Third Parties

AI systems may depend on:

* model providers;
* cloud providers;
* data providers;
* software suppliers;
* system integrators;
* external assessors;
* AI service providers.

AIGO governance should therefore establish requirements for third-party governance.

The relationship is:

```text theme={null}
Third Party
    ↓
Dependency Identification
    ↓
Risk Assessment
    ↓
Control Requirements
    ↓
Contractual / Governance Requirements
    ↓
Monitoring
    ↓
Review
```

***

## 5.12 GOVERN and Documentation

Governance decisions should be documented sufficiently to demonstrate:

* who made the decision;
* what was decided;
* why it was decided;
* what evidence supported it;
* what risks were considered;
* what controls were required;
* what conditions were imposed;
* when the decision should be reviewed.

***

## 5.13 GOVERN Mapping Summary

| Governance Area        | AIGO Mechanism                    | Mapping Strength |
| ---------------------- | --------------------------------- | ---------------- |
| Governance structure   | Governance Domains / Roles        | Direct           |
| Accountability         | Governance Roles                  | Direct           |
| Policy                 | Framework Principles / Governance | Direct           |
| Risk tolerance         | Risk Management                   | Operational      |
| Competence             | Roles / Implementation            | Supporting       |
| Third-party governance | Risk / Controls / Procedures      | Operational      |
| Documentation          | Evidence / Governance Records     | Direct           |
| Oversight              | Assurance / Monitoring            | Direct           |
| Continuous improvement | Improvement Procedure             | Direct           |

***

# 6. MAP

## 6.1 Function Purpose

MAP establishes and documents context, identifies intended uses, considers impacts and identifies AI risks.

Within AIGO, MAP is primarily connected to:

* AI system registration;
* AI system profiles;
* classification;
* lifecycle identification;
* context establishment;
* risk assessment;
* stakeholder identification.

***

## 6.2 AIGO MAP Architecture

```text theme={null}
AI System
   ↓
Registration
   ↓
System Profile
   ↓
Context
   ↓
Intended Use
   ↓
Stakeholders
   ↓
Lifecycle
   ↓
Classification
   ↓
Risk Identification
   ↓
Impact Analysis
```

***

## 6.3 AI System Registration

The AIGO AI System Registration Procedure establishes a controlled record of the AI system.

Registration may identify:

* system name;
* system owner;
* business owner;
* provider;
* purpose;
* intended use;
* deployment environment;
* affected stakeholders;
* data dependencies;
* model dependencies;
* lifecycle status.

***

## 6.4 Context Establishment

MAP requires an understanding of context.

AIGO considers:

* organizational context;
* technical context;
* business context;
* operational context;
* stakeholder context;
* legal context;
* regulatory context;
* societal context;
* human-impact context.

Context may change over time.

***

## 6.5 Intended Use

AIGO distinguishes between:

* intended use;
* reasonably foreseeable use;
* prohibited use;
* out-of-scope use;
* changed use.

The intended-use definition is important because AI risks cannot be evaluated independently of how a system is used.

***

## 6.6 Stakeholder Mapping

AIGO identifies relevant stakeholders.

```text theme={null}
AI System
   ↓
Stakeholder Identification
   ↓
Stakeholder Needs / Expectations
   ↓
Potential Impacts
   ↓
Risk Identification
   ↓
Governance Requirements
```

Stakeholders may include:

* users;
* affected persons;
* customers;
* employees;
* management;
* regulators;
* suppliers;
* communities;
* technical operators;
* assurance functions.

***

## 6.7 AI System Classification

Classification determines the governance intensity appropriate to the system.

AIGO classification may consider:

* impact;
* criticality;
* autonomy;
* deployment scale;
* affected populations;
* data sensitivity;
* operational dependency;
* legal requirements;
* risk level.

Classification may determine:

* assessment depth;
* approval level;
* monitoring intensity;
* assurance requirements;
* evidence requirements;
* review frequency.

***

## 6.8 Risk Identification

MAP provides the foundation for risk identification.

AIGO considers:

* technical risks;
* operational risks;
* safety risks;
* security risks;
* privacy risks;
* fairness risks;
* bias risks;
* transparency risks;
* explainability risks;
* misuse risks;
* third-party risks;
* governance risks;
* societal impacts.

***

## 6.9 Impact Analysis

AIGO distinguishes risk from impact while recognizing their relationship.

```text theme={null}
AI System Context
        ↓
Potential Impact
        ↓
Risk Scenario
        ↓
Likelihood
        ↓
Severity
        ↓
Risk Level
```

Impact analysis should consider affected stakeholders and the nature of potential harm.

***

## 6.10 MAP Mapping Summary

| MAP Area              | AIGO Mechanism           | Mapping Strength |
| --------------------- | ------------------------ | ---------------- |
| System identification | Registration             | Direct           |
| Context               | System Profile           | Direct           |
| Intended use          | Registration / Profile   | Direct           |
| Stakeholders          | Governance / Risk        | Operational      |
| Classification        | Classification Procedure | Direct           |
| Risk identification   | Risk Assessment          | Direct           |
| Impact assessment     | Risk Management          | Direct           |
| Lifecycle context     | Governance Lifecycle     | Direct           |
| Third-party context   | Risk Management          | Supporting       |

***

# 7. MEASURE

## 7.1 Function Purpose

MEASURE establishes mechanisms for assessing, testing, evaluating and monitoring AI risks and relevant trustworthiness characteristics.

Within AIGO, MEASURE is primarily represented through:

* risk assessment;
* control assessment;
* monitoring;
* assurance;
* measurement;
* testing;
* evidence;
* management review.

***

## 7.2 AIGO MEASURE Architecture

```text theme={null}
Risk / Requirement
        ↓
Measurement Objective
        ↓
Metric / Test / Assessment
        ↓
Result
        ↓
Interpretation
        ↓
Risk Evaluation
        ↓
Decision
        ↓
Monitoring
```

***

## 7.3 Measurement Objectives

Measurement should be connected to an explicit objective.

Examples include:

* determining control effectiveness;
* evaluating model performance;
* detecting unexpected behavior;
* identifying bias;
* evaluating security;
* evaluating robustness;
* assessing reliability;
* measuring incident frequency;
* monitoring operational performance.

***

## 7.4 Measurement Methods

AIGO may use:

* quantitative measurement;
* qualitative assessment;
* testing;
* inspection;
* review;
* benchmarking;
* sampling;
* observation;
* expert assessment;
* automated monitoring;
* independent assessment.

The method should be appropriate to the risk and decision being supported.

***

## 7.5 Measurement Quality

Measurement results should consider:

* validity;
* reliability;
* completeness;
* reproducibility;
* relevance;
* limitations;
* uncertainty;
* data quality;
* measurement bias.

A measurement without sufficient context may lead to an incorrect governance conclusion.

***

## 7.6 Testing and Evaluation

Testing may occur:

* before deployment;
* during deployment;
* after material change;
* following incidents;
* periodically;
* when risk conditions change.

Testing depth should be proportional to risk.

***

## 7.7 Monitoring

AIGO Monitoring provides continuous or periodic observation.

Monitoring may include:

* system performance;
* risk indicators;
* control indicators;
* incidents;
* user feedback;
* drift;
* changes in context;
* unexpected behavior;
* third-party changes;
* regulatory developments.

***

## 7.8 Measurement and Evidence

Measurement should generate traceable evidence.

```text theme={null}
Measurement Objective
        ↓
Method
        ↓
Measurement
        ↓
Result
        ↓
Interpretation
        ↓
Evidence
        ↓
Decision
```

Evidence should remain linked to the applicable AI system and lifecycle context.

***

## 7.9 Control Assessment

AIGO Control Assessment evaluates whether controls:

1. exist;
2. are implemented;
3. operate as intended;
4. are effective;
5. produce sufficient evidence.

This distinction prevents documentation presence from being confused with effective governance.

***

## 7.10 Assurance

Assurance provides additional confidence that governance and risk-management activities are functioning as intended.

Assurance may evaluate:

* measurement methods;
* control effectiveness;
* evidence quality;
* risk assessments;
* monitoring;
* corrective actions.

***

## 7.11 MEASURE Mapping Summary

| MEASURE Area           | AIGO Mechanism           | Mapping Strength |
| ---------------------- | ------------------------ | ---------------- |
| Risk measurement       | Risk Assessment          | Direct           |
| Control measurement    | Control Assessment       | Direct           |
| Monitoring             | Monitoring Procedure     | Direct           |
| Testing                | Assessment / Assurance   | Operational      |
| Evidence               | Evidence Management      | Direct           |
| Assurance              | Assurance Procedure      | Direct           |
| Management review      | Governance / Assurance   | Supporting       |
| Continuous measurement | Monitoring / Improvement | Direct           |

***

# 8. MANAGE

## 8.1 Function Purpose

MANAGE prioritizes and responds to AI risks identified through governance, mapping and measurement activities.

Within AIGO, MANAGE is represented by:

* risk treatment;
* control implementation;
* approval;
* risk acceptance;
* incident management;
* change management;
* corrective action;
* retirement;
* continuous improvement.

***

## 8.2 AIGO MANAGE Architecture

```text theme={null}
Risk Identified
      ↓
Risk Evaluation
      ↓
Risk Prioritization
      ↓
Treatment Options
      ↓
Treatment Decision
      ↓
Implementation
      ↓
Approval / Acceptance
      ↓
Monitoring
      ↓
Reassessment
```

***

## 8.3 Risk Prioritization

AIGO prioritizes risks according to defined criteria.

Potential factors include:

* severity;
* likelihood;
* affected population;
* regulatory significance;
* business criticality;
* safety impact;
* reversibility;
* exposure;
* uncertainty;
* control effectiveness.

***

## 8.4 Risk Treatment

AIGO risk treatment may include:

* mitigation;
* avoidance;
* transfer;
* acceptance;
* restriction;
* additional controls;
* monitoring;
* redesign;
* delayed deployment;
* suspension;
* retirement.

Treatment should be proportionate to risk.

***

## 8.5 Risk Acceptance

Residual risk may require explicit acceptance.

```text theme={null}
Initial Risk
     ↓
Controls / Treatment
     ↓
Residual Risk
     ↓
Risk Evaluation
     ↓
Acceptance Decision
     ↓
Accountable Authority
```

Risk acceptance should identify:

* accepted risk;
* rationale;
* evidence;
* conditions;
* acceptance authority;
* review date;
* expiry or reassessment trigger where applicable.

***

## 8.6 Approval

AIGO Approval provides a governance decision point before significant deployment or continued operation where required.

Approval may depend on:

* classification;
* risk level;
* control effectiveness;
* residual risk;
* evidence quality;
* legal requirements;
* assurance results.

***

## 8.7 Incident Management

Incidents may trigger MANAGE activities.

```text theme={null}
Incident
   ↓
Containment
   ↓
Investigation
   ↓
Risk Reassessment
   ↓
Corrective Action
   ↓
Decision
   ↓
Monitoring
```

Incident information should feed back into MAP and MEASURE.

***

## 8.8 Change Management

Material change may require:

* reclassification;
* risk reassessment;
* control reassessment;
* approval;
* monitoring changes;
* evidence updates.

Change therefore creates a feedback loop between MANAGE and the other functions.

***

## 8.9 Retirement

MANAGE includes decisions to discontinue systems when:

* risk becomes unacceptable;
* intended use ends;
* system becomes obsolete;
* controls are insufficient;
* regulatory conditions change;
* replacement occurs;
* business need ends.

Retirement should include appropriate closure, evidence retention and risk disposition.

***

## 8.10 Continuous Improvement

MANAGE feeds continuous improvement.

```text theme={null}
Manage
  ↓
Monitor
  ↓
Review
  ↓
Learn
  ↓
Improve
  ↓
Update Controls
  ↓
Update Procedures
  ↓
Reassess
```

***

## 8.11 MANAGE Mapping Summary

| MANAGE Area            | AIGO Mechanism            | Mapping Strength |
| ---------------------- | ------------------------- | ---------------- |
| Risk prioritization    | Risk Management           | Direct           |
| Risk treatment         | Risk Management           | Direct           |
| Risk acceptance        | Risk Acceptance Procedure | Direct           |
| Approval               | Approval Procedure        | Direct           |
| Incident response      | Incident Management       | Direct           |
| Change                 | Change Management         | Direct           |
| Corrective action      | Assurance / Improvement   | Direct           |
| Retirement             | Retirement Procedure      | Direct           |
| Continuous improvement | Improvement Procedure     | Direct           |

***

# 9. Cross-Function Relationships

## 9.1 Function Interaction

The four functions operate as an integrated system.

```text theme={null}
                  GOVERN
                     |
        +------------+------------+
        |            |            |
       MAP        MEASURE       MANAGE
        |            |            |
        +------------+------------+
                     |
                 Feedback
                     |
                  GOVERN
```

GOVERN establishes the conditions.

MAP establishes context.

MEASURE evaluates.

MANAGE responds.

The results feed back into governance and future mapping.

***

## 9.2 MAP → MEASURE

MAP establishes what should be measured.

```text theme={null}
Context
  ↓
Risk
  ↓
Trustworthiness Characteristic
  ↓
Measurement Objective
  ↓
Metric / Test
```

Without appropriate context, measurement may not address the actual risk.

***

## 9.3 MEASURE → MANAGE

Measurement results support management decisions.

```text theme={null}
Measurement
    ↓
Result
    ↓
Risk Interpretation
    ↓
Prioritization
    ↓
Treatment
```

***

## 9.4 MANAGE → MAP

Management decisions may change the system context.

Examples:

* new deployment environment;
* changed intended use;
* new user population;
* changed data source;
* new model version;
* changed operational dependency.

These changes require MAP activities to be revisited.

***

## 9.5 MANAGE → MEASURE

Risk treatment may introduce new controls that require measurement.

```text theme={null}
Risk
 ↓
Treatment
 ↓
New Control
 ↓
Measurement
 ↓
Effectiveness
```

***

## 9.6 GOVERN → MAP

Governance determines the rules under which mapping occurs.

Examples:

* classification criteria;
* risk criteria;
* stakeholder requirements;
* documentation requirements;
* approval requirements.

***

## 9.7 GOVERN → MEASURE

Governance establishes:

* measurement responsibilities;
* acceptable evidence;
* assessment frequency;
* reporting requirements;
* escalation thresholds.

***

## 9.8 GOVERN → MANAGE

Governance determines:

* who can accept risk;
* who can approve deployment;
* who can authorize exceptions;
* who can suspend systems;
* who can approve retirement.

***

# 10. Function-to-Lifecycle Mapping

| AIGO Lifecycle | GOVERN | MAP | MEASURE | MANAGE |
| -------------- | :----: | :-: | :-----: | :----: |
| Identify       |    ✓   |  ✓  |         |        |
| Classify       |    ✓   |  ✓  |         |    ✓   |
| Assess         |    ✓   |  ✓  |    ✓    |        |
| Treat          |    ✓   |     |    ✓    |    ✓   |
| Approve        |    ✓   |     |    ✓    |    ✓   |
| Deploy         |    ✓   |  ✓  |    ✓    |    ✓   |
| Operate        |    ✓   |     |    ✓    |    ✓   |
| Monitor        |    ✓   |     |    ✓    |    ✓   |
| Assure         |    ✓   |     |    ✓    |    ✓   |
| Improve        |    ✓   |     |    ✓    |    ✓   |
| Change         |    ✓   |  ✓  |    ✓    |    ✓   |
| Retire         |    ✓   |  ✓  |    ✓    |    ✓   |

***

# 11. Function-to-AIGO-Control Mapping

| NIST Function | Primary AIGO Control Areas                                              |
| ------------- | ----------------------------------------------------------------------- |
| GOVERN        | Governance, accountability, policy, roles, oversight                    |
| MAP           | Registration, classification, context, stakeholder, risk identification |
| MEASURE       | Assessment, measurement, testing, monitoring, assurance                 |
| MANAGE        | Risk treatment, approval, acceptance, incident, change, retirement      |

Detailed control mapping is maintained separately.

***

# 12. Function-to-Procedure Mapping

| NIST Function | AIGO Procedures                                                                                       |
| ------------- | ----------------------------------------------------------------------------------------------------- |
| GOVERN        | Governance, Approval, Risk Acceptance, Monitoring, Assurance, Continuous Improvement                  |
| MAP           | Registration, Classification, Risk Assessment                                                         |
| MEASURE       | Risk Assessment, Control Assessment, Monitoring, Assurance                                            |
| MANAGE        | Approval, Risk Acceptance, Change Management, Incident Management, Retirement, Continuous Improvement |

A procedure may support multiple NIST functions.

***

# 13. Function-to-Evidence Mapping

| Function | Typical Evidence                                                            |
| -------- | --------------------------------------------------------------------------- |
| GOVERN   | Policies, roles, governance records, approvals, reviews                     |
| MAP      | System profiles, registration records, classifications, context assessments |
| MEASURE  | Test results, metrics, assessment reports, monitoring records               |
| MANAGE   | Treatment plans, acceptance records, approvals, incidents, change records   |

The detailed evidence model is maintained in the dedicated Evidence Mapping document.

***

# 14. Function-to-Role Mapping

| NIST Function | Typical AIGO Accountable Roles                              |
| ------------- | ----------------------------------------------------------- |
| GOVERN        | Governance authority / AI governance owner                  |
| MAP           | AI system owner / risk owner                                |
| MEASURE       | Risk owner / control owner / technical assessor / assurance |
| MANAGE        | Risk owner / approval authority / governance authority      |

Actual role assignments depend on organizational context.

***

# 15. Function-to-Decision Mapping

```text theme={null}
GOVERN
  ↓
Establish Decision Authority
  ↓
MAP
  ↓
Establish Context and Risk
  ↓
MEASURE
  ↓
Provide Evidence
  ↓
MANAGE
  ↓
Make Risk Decision
  ↓
Monitor
  ↓
Reassess
```

***

# 16. Function Traceability Model

A complete function-level trace should connect:

```text theme={null}
NIST Function
      ↓
NIST Category
      ↓
NIST Subcategory
      ↓
AIGO Governance Domain
      ↓
AIGO Requirement
      ↓
AIGO Control
      ↓
AIGO Procedure
      ↓
Lifecycle Stage
      ↓
Risk
      ↓
Evidence
      ↓
Decision
      ↓
Role
      ↓
Monitoring
      ↓
Assurance
```

***

# 17. Function Mapping Strength

## 17.1 GOVERN

**Primary status:** Direct / Operational

AIGO contains an explicit governance architecture corresponding to the organizational governance intent of GOVERN.

## 17.2 MAP

**Primary status:** Direct

AIGO provides explicit system registration, classification and risk assessment mechanisms.

## 17.3 MEASURE

**Primary status:** Direct / Operational

AIGO provides assessment, measurement, monitoring and assurance mechanisms.

## 17.4 MANAGE

**Primary status:** Direct

AIGO provides risk treatment, acceptance, approval, incident, change and retirement mechanisms.

***

# 18. Function Gaps

The existence of a function mapping does not mean that every NIST category or subcategory is automatically implemented.

Potential detailed gaps may arise in areas such as:

* specialized measurement methodologies;
* AI-specific technical testing;
* statistical validation;
* model performance benchmarking;
* advanced fairness assessment;
* explainability testing;
* security testing;
* privacy-enhancing measurement;
* third-party evidence;
* domain-specific impact assessment.

Such gaps shall be identified in the detailed category and implementation mappings.

***

# 19. Function Implementation Principle

The implementation principle is:

```text theme={null}
NIST Function
      ↓
AIGO Governance Requirement
      ↓
AIGO Control
      ↓
AIGO Procedure
      ↓
Operational Implementation
      ↓
Evidence
      ↓
Assessment
      ↓
Assurance
```

A function mapping therefore represents an architectural relationship rather than proof of implementation.

***

# 20. Function Effectiveness Model

AIGO should distinguish between:

```text theme={null}
Mapped
   ↓
Defined
   ↓
Implemented
   ↓
Operating
   ↓
Measured
   ↓
Effective
   ↓
Assured
   ↓
Improved
```

This maturity progression should be applied when evaluating the actual implementation of NIST-aligned capabilities.

***

# 21. Function Review Triggers

The function mapping shall be reviewed when:

* NIST AI RMF changes;
* AIGO governance changes;
* AIGO lifecycle changes;
* AIGO risk methodology changes;
* new AIGO controls are introduced;
* procedures materially change;
* new AI risk categories are introduced;
* significant implementation gaps are identified;
* regulatory or organizational context changes.

***

# 22. Function Mapping Governance

The owner of this mapping shall ensure:

* consistent terminology;
* consistent NIST references;
* traceability to AIGO controls;
* consistency with subordinate mappings;
* documented mapping gaps;
* controlled changes;
* periodic review.

***

# 23. Relationship to Categories Mapping

This document establishes function-level relationships.

The next level is the NIST category and subcategory mapping.

The category mapping shall therefore answer:

> Which specific NIST AI RMF Categories and Subcategories are addressed by which AIGO governance requirements, controls, procedures, lifecycle activities and evidence?

The category mapping shall reference this document rather than duplicate the entire function architecture.

***

# 24. Relationship to Lifecycle Mapping

The lifecycle mapping shall answer:

> At which AIGO lifecycle stages are the NIST AI RMF functions and their detailed outcomes operationalized?

The lifecycle mapping shall use the four functions defined in this document as its top-level reference.

***

# 25. Relationship to Risk Mapping

The risk mapping shall answer:

> How do the NIST AI RMF functions relate to AIGO's AI risk-management methodology?

The principal relationship is:

```text theme={null}
GOVERN
   ↓
Risk Governance
   ↓
MAP
   ↓
Risk Identification
   ↓
MEASURE
   ↓
Risk Analysis / Evaluation
   ↓
MANAGE
   ↓
Risk Treatment
```

***

# 26. Relationship to Governance Mapping

The governance mapping shall provide additional detail concerning:

* accountability;
* roles;
* policies;
* organizational governance;
* risk culture;
* oversight;
* third parties;
* documentation;
* decision rights.

GOVERN will therefore receive the greatest governance-level detail.

***

# 27. Relationship to Evidence Mapping

The evidence mapping shall establish which evidence demonstrates execution of activities associated with:

* GOVERN;
* MAP;
* MEASURE;
* MANAGE.

Evidence shall be linked to the relevant controls and procedures where practicable.

***

# 28. Relationship to Implementation Mapping

The implementation mapping shall translate this function-level architecture into implementation steps.

The implementation sequence may include:

```text theme={null}
Establish Governance
       ↓
Identify AI Systems
       ↓
Establish Context
       ↓
Map Risks
       ↓
Measure
       ↓
Treat
       ↓
Approve
       ↓
Operate
       ↓
Monitor
       ↓
Assure
       ↓
Improve
```

This is an AIGO operationalization sequence and shall not be interpreted as a mandatory NIST sequence.

***

# 29. Cross-Framework Integration

The NIST function model can also be related to other AIGO external mappings.

For example:

```text theme={null}
                 AIGO
                   |
       +-----------+-----------+
       |           |           |
 ISO/IEC 42001  NIST AI RMF  EU AI ACT
       |           |           |
       +-----------+-----------+
                   |
          Common AIGO Model
                   |
      +------------+------------+
      |            |            |
   Governance     Risk       Lifecycle
      |            |            |
      +------------+------------+
                   |
                Controls
                   |
              Procedures
                   |
                Evidence
```

The external frameworks remain independently mapped.

***

# 30. Function-Level Master Matrix

| Capability             | GOVERN | MAP | MEASURE | MANAGE |
| ---------------------- | :----: | :-: | :-----: | :----: |
| Governance             |    ●   |  ○  |    ○    |    ○   |
| Accountability         |    ●   |  ○  |    ○    |    ○   |
| Context                |    ●   |  ●  |    ○    |    ○   |
| System registration    |    ○   |  ●  |         |        |
| Classification         |    ●   |  ●  |    ○    |    ●   |
| Risk identification    |    ●   |  ●  |    ○    |        |
| Risk analysis          |    ○   |  ●  |    ●    |        |
| Risk measurement       |    ○   |     |    ●    |        |
| Control assessment     |    ●   |     |    ●    |        |
| Monitoring             |    ●   |  ○  |    ●    |    ●   |
| Risk treatment         |    ●   |     |    ●    |    ●   |
| Risk acceptance        |    ●   |     |    ●    |    ●   |
| Approval               |    ●   |  ○  |    ●    |    ●   |
| Incident management    |    ●   |  ○  |    ●    |    ●   |
| Change management      |    ●   |  ●  |    ●    |    ●   |
| Retirement             |    ●   |  ●  |    ●    |    ●   |
| Assurance              |    ●   |     |    ●    |    ●   |
| Continuous improvement |    ●   |  ○  |    ●    |    ●   |

**Legend:**

* `●` Primary relationship
* `○` Supporting relationship

***

# 31. Function Interaction Matrix

| From / To | GOVERN | MAP | MEASURE | MANAGE |
| --------- | -----: | --: | ------: | -----: |
| GOVERN    |      ✓ |   ✓ |       ✓ |      ✓ |
| MAP       |      ✓ |   ✓ |       ✓ |      ✓ |
| MEASURE   |      ✓ |   ✓ |       ✓ |      ✓ |
| MANAGE    |      ✓ |   ✓ |       ✓ |      ✓ |

The complete matrix is intentionally interconnected because AI risk management is iterative.

***

# 32. Operational Feedback Loop

The complete AIGO-NIST function loop is:

```text theme={null}
                 GOVERN
                    ↓
                  MAP
                    ↓
                MEASURE
                    ↓
                 MANAGE
                    ↓
                MONITOR
                    ↓
                 REVIEW
                    ↓
                IMPROVE
                    ↓
                 CHANGE
                    ↓
                  MAP
```

This represents operational feedback rather than a fixed linear sequence.

***

# 33. Function-Level Evidence Chain

A complete evidence chain may be represented as:

```text theme={null}
GOVERNANCE DECISION
        ↓
SYSTEM CONTEXT
        ↓
RISK IDENTIFICATION
        ↓
MEASUREMENT
        ↓
RISK EVALUATION
        ↓
TREATMENT
        ↓
APPROVAL
        ↓
OPERATION
        ↓
MONITORING
        ↓
ASSURANCE
        ↓
MANAGEMENT REVIEW
        ↓
IMPROVEMENT
```

This chain should be reconstructable for material AI governance decisions.

***

# 34. Function-Level Accountability Chain

```text theme={null}
Governance Authority
        ↓
AI Governance Owner
        ↓
AI System Owner
        ↓
Risk Owner
        ↓
Control Owner
        ↓
Operational Owner
        ↓
Assurance
        ↓
Management Review
```

Actual organizational structures may differ.

***

# 35. Function-Level Control Principle

Controls should be designed to support specific governance objectives.

The relationship is:

```text theme={null}
NIST Function
      ↓
Risk / Governance Objective
      ↓
AIGO Control Objective
      ↓
Control
      ↓
Procedure
      ↓
Evidence
      ↓
Assessment
```

This prevents controls from becoming disconnected documentation artifacts.

***

# 36. Function-Level Monitoring Principle

Monitoring shall evaluate whether the function remains effective over time.

Examples:

### GOVERN Monitoring

* role assignment;
* policy status;
* governance decisions;
* overdue reviews;
* unresolved governance gaps.

### MAP Monitoring

* new AI systems;
* changed intended uses;
* classification changes;
* new stakeholders;
* new risk scenarios.

### MEASURE Monitoring

* measurement results;
* failed tests;
* control effectiveness;
* metric trends;
* monitoring alerts.

### MANAGE Monitoring

* overdue treatment actions;
* residual risks;
* accepted risks;
* incidents;
* corrective actions;
* change requests;
* retirement decisions.

***

# 37. Function-Level Assurance

Assurance should evaluate whether:

1. the function is defined;
2. responsibilities are assigned;
3. required activities occur;
4. evidence exists;
5. outputs are reliable;
6. decisions are traceable;
7. controls are effective;
8. identified deficiencies are corrected.

***

# 38. Function-Level Continual Improvement

Improvement inputs may include:

* monitoring results;
* incidents;
* assessments;
* audits;
* assurance findings;
* stakeholder feedback;
* regulatory changes;
* technology changes;
* changes in risk tolerance;
* lessons learned.

The improvement process is:

```text theme={null}
Input
  ↓
Analysis
  ↓
Improvement Opportunity
  ↓
Prioritization
  ↓
Change
  ↓
Implementation
  ↓
Verification
  ↓
Updated Governance
```

***

# 39. Function Mapping Quality Criteria

A high-quality mapping should be:

* traceable;
* specific;
* evidence-based;
* current;
* understandable;
* internally consistent;
* externally referenced;
* reviewable;
* maintainable.

A mapping should avoid unsupported claims such as:

> "AIGO is NIST compliant."

Instead, the appropriate statement is:

> "AIGO provides mapped governance and operational mechanisms aligned with applicable NIST AI RMF functions."

***

# 40. Function Mapping Limitations

This document does not:

* reproduce NIST AI RMF;
* establish NIST requirements;
* create certification;
* create legal compliance;
* guarantee system trustworthiness;
* replace technical assessment;
* replace organizational risk management;
* replace applicable law;
* constitute NIST endorsement.

***

# 41. Function Mapping Maintenance

This document shall be reviewed:

* at least annually;
* when the NIST AI RMF baseline changes;
* when AIGO changes materially;
* when subordinate mappings reveal inconsistencies;
* when significant implementation gaps are identified.

Changes shall be controlled through AIGO change management.

***

# 42. Function Mapping Change Record

| Version | Date | Change           | Author | Reviewer | Approval |
| ------- | ---- | ---------------- | ------ | -------- | -------- |
| 0.1     |      | Initial document |        |          |          |

***

# 43. Document Control

## 43.1 Controlled Information

| Field               | Value                                  |
| ------------------- | -------------------------------------- |
| Document Title      | AIGO — NIST AI RMF Functions Mapping   |
| Document ID         | `AIGO-MAP-NIST-AIRMF-002`              |
| Version             | 0.1                                    |
| Status              | Draft                                  |
| Framework           | AIGO AI Governance Operating Framework |
| Mapping Standard    | NIST AI RMF 1.0                        |
| Mapping Domain      | Functions                              |
| Primary Owner       |                                        |
| Technical Reviewer  |                                        |
| Governance Reviewer |                                        |
| Approver            |                                        |
| Effective Date      |                                        |
| Next Review Date    |                                        |

***

## 44. Final Control Statement

This document is controlled within the AIGO Framework documentation structure.

It establishes the function-level relationship between NIST AI RMF 1.0 and the AIGO AI Governance Operating Framework.

The four NIST functions are treated as interconnected and iterative capabilities:

```text theme={null}
GOVERN
   ↓
MAP
   ↓
MEASURE
   ↓
MANAGE
   ↓
Feedback
   ↓
GOVERN
```

The detailed mapping of NIST categories and subcategories shall be maintained in the subsequent NIST AI RMF mapping document.

***

# 45. End of Mapping Document

**AIGO — NIST AI RMF Functions Mapping**

**Document ID:** `AIGO-MAP-NIST-AIRMF-002`

**Version:** 0.1

**Status:** Draft

**Mapping Standard:** NIST AI RMF 1.0

**Primary Functions:** GOVERN, MAP, MEASURE, MANAGE

**End of Document**