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

# AIGO Terminology v0.1

# AIGO — Terminology

## 1. Document Purpose

This document establishes the controlled terminology for the AIGO Framework.

Its purpose is to provide a consistent vocabulary across:

* the AIGO framework;
* governance domains;
* roles;
* lifecycle;
* risk management;
* controls;
* maturity;
* system profiles;
* implementation guidance;
* procedures;
* templates;
* examples;
* schemas;
* mappings;
* validation tools;
* evidence;
* assurance.

Where a term is defined here, that definition should be used consistently throughout the AIGO repository unless a source framework requires a distinct framework-specific meaning.

***

# 2. Document Information

| Field               | Value                   |
| ------------------- | ----------------------- |
| Document            | AIGO Terminology        |
| Version             | 0.1                     |
| Status              | Draft                   |
| Document Identifier | `AIGO-TERM-001`         |
| Document Type       | Controlled Terminology  |
| Repository Area     | `framework/01-charter/` |
| Authority           | AIGO Framework Charter  |
| Owner               |                         |
| Approved By         |                         |
| Effective Date      |                         |
| Next Review Date    |                         |

***

# 3. Terminology Principles

AIGO terminology follows these principles:

1. Terms should have one stable meaning within the AIGO framework.
2. Definitions should be operationally usable.
3. Source-framework terms must retain their original meaning when used in framework mappings.
4. AIGO internal terms must not be presented as legal definitions unless they are directly supported by applicable law.
5. Similar terms must not be treated as identical merely because they overlap conceptually.
6. Framework-specific terminology should be explicitly qualified where ambiguity is possible.
7. Machine-readable identifiers should map to controlled terminology where appropriate.

***

# 4. AIGO

**Definition**

AIGO is the **AI Governance Operating Framework**, a structured framework for establishing, operating, monitoring, assuring, and continually improving governance over artificial intelligence systems, AI-related risks, controls, evidence, and decisions.

**Usage**

Use `AIGO` when referring to the complete framework.

***

# 5. AI Governance

**Definition**

AI governance is the system of leadership, accountability, decision rights, policies, processes, controls, oversight, monitoring, assurance, and improvement through which an organization directs and controls its AI activities.

**Usage**

AI governance describes the organizational governance system rather than a single control or procedure.

***

# 6. AI System

**Definition**

An AI system is an identifiable technological system within the organization's governance scope that performs or supports AI-related functions and is subject to AIGO governance.

**Usage**

The precise legal or regulatory definition of an AI system may differ between source frameworks and jurisdictions. AIGO therefore uses this as an internal governance term.

**Related Terms**

* AI system profile
* AI system lifecycle
* AI system owner
* AI classification

***

# 7. AI Model

**Definition**

An AI model is a computational model used by an AI system to generate outputs, predictions, classifications, recommendations, content, decisions, or other results.

**Usage**

An AI model may be one component of a larger AI system.

***

# 8. AI Service

**Definition**

An AI service is an AI-enabled capability delivered to users, applications, organizations, or other systems.

**Usage**

An AI service may contain one or more AI systems, models, data sources, interfaces, or supporting components.

***

# 9. AI Lifecycle

**Definition**

The AI lifecycle is the sequence of governance-relevant stages through which an AI system is planned, designed, developed or acquired, evaluated, approved, deployed, operated, monitored, changed, improved, and retired.

**AIGO Lifecycle**

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

***

# 10. AI Risk

**Definition**

AI risk is the possibility that an AI-related event, condition, decision, system behavior, or failure may result in undesirable consequences for people, organizations, assets, operations, society, or the environment.

***

# 11. AI Impact

**Definition**

AI impact is an actual or potential consequence of an AI system, AI-related decision, or AI activity affecting people, groups, organizations, society, the environment, or other relevant stakeholders.

**Usage**

Impact may be positive, negative, intended, unintended, direct, indirect, short-term, or long-term.

***

# 12. AI Governance Objective

**Definition**

An AI governance objective is a defined governance outcome that AIGO seeks to establish, maintain, monitor, or improve.

**Example**

```text theme={null}
Objective:
Ensure AI risks are identified and appropriately managed.
```

***

# 13. Control

**Definition**

A control is a defined measure designed to prevent, detect, reduce, manage, or respond to a governance or AI-related risk and to support a specified governance objective.

**Related Terms**

* AIGO control
* common control
* framework-specific extension
* control owner
* control assessment

***

# 14. AIGO Control

**Definition**

An AIGO control is a formally defined governance control within the AIGO control architecture.

An AIGO control has an identifiable objective, scope, ownership, implementation mechanism, evidence expectation, and, where applicable, monitoring and assurance mechanism.

***

# 15. Common Control

**Definition**

A common control is an AIGO control that can operationally support requirements or outcomes from more than one external framework.

**Critical Rule**

A common control does not make the source requirements equivalent.

```text theme={null}
EU Requirement ──┐
ISO Requirement ─┼──→ Common AIGO Control
NIST Outcome ────┘
```

Each source relationship remains independently traceable.

***

# 16. Framework-Specific Extension

**Definition**

A framework-specific extension is an additional requirement, activity, evidence element, procedure, or control characteristic needed to address a source framework's specific criteria where a common AIGO control alone is insufficient.

***

# 17. Control Owner

**Definition**

The control owner is the person or organizational role accountable for ensuring that an assigned AIGO control is defined, implemented, maintained, monitored, and appropriately evidenced.

***

# 18. Evidence

**Definition**

Evidence is information or an artifact that demonstrates the existence, implementation, operation, performance, or outcome of a governance activity, control, decision, or system state.

**Examples**

* records;
* logs;
* assessments;
* approvals;
* reports;
* test results;
* monitoring results;
* policies;
* technical artifacts.

***

# 19. Evidence Record

**Definition**

An evidence record is a governed record describing a specific evidence item and its relevant metadata, provenance, scope, status, ownership, and relationships.

***

# 20. Evidence Owner

**Definition**

The evidence owner is the person or role responsible for ensuring that a governed evidence record is accurate, available, current where required, appropriately protected, and retained according to applicable requirements.

***

# 21. Assessment

**Definition**

An assessment is a structured evaluation of a subject against defined criteria.

Subjects may include:

* AI systems;
* AI risks;
* controls;
* applicability;
* classification;
* impacts;
* evidence;
* changes;
* assurance criteria.

***

# 22. Risk Assessment

**Definition**

A risk assessment is a structured process for identifying, analyzing, evaluating, and documenting AI-related risks.

***

# 23. Control Assessment

**Definition**

A control assessment is an evaluation of whether an AIGO control is appropriately designed, implemented, operating, evidenced, or effective according to its defined criteria.

***

# 24. Applicability

**Definition**

Applicability is the determination of whether a framework, requirement, control, obligation, or governance activity applies to a particular organization, activity, AI system, role, or circumstance.

**Usage**

Applicability should be determined before compliance or coverage conclusions are made.

***

# 25. Framework Requirement

**Definition**

A framework requirement is a requirement, obligation, criterion, clause, article, control expectation, or other authoritative source element originating from an external framework.

**Usage**

The term should be qualified where necessary:

* EU AI Act requirement;
* ISO/IEC 42001 requirement;
* NIST AI RMF outcome.

***

# 26. Framework Outcome

**Definition**

A framework outcome is a defined result or intended governance state identified by an external framework.

**Usage**

This term is particularly useful for frameworks whose structures are outcome- or function-oriented rather than strictly requirement-oriented.

***

# 27. Framework Mapping

**Definition**

A framework mapping is a documented relationship between an external framework source element and one or more AIGO governance objects.

***

# 28. Cross-Framework Mapping

**Definition**

A cross-framework mapping is a documented relationship connecting related requirements, outcomes, controls, evidence, assurance activities, or governance objectives across multiple external frameworks through the AIGO architecture.

***

# 29. Traceability

**Definition**

Traceability is the ability to follow a defined relationship between governance objects across the AIGO lifecycle.

**Core Traceability**

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

**Extended Traceability**

```text theme={null}
AI System
    ↓
Risk
    ↓
Control
    ↓
Assessment
    ↓
Approval
    ↓
Monitoring
    ↓
Evidence
    ↓
Assurance
    ↓
Change / Incident
    ↓
Improvement
    ↓
Retirement
```

***

# 30. Traceability Relationship

**Definition**

A traceability relationship is a governed link between two or more identifiable governance objects.

Each relationship should retain source identifiers and should be independently resolvable.

***

# 31. Governance Role

**Definition**

A governance role is a defined organizational responsibility or authority associated with AI governance activities.

A governance role may be assigned to an individual, organizational unit, committee, or other accountable entity.

***

# 32. AI System Owner

**Definition**

The AI system owner is the person or organizational role accountable for the governance and lifecycle of a specific AI system within the organization's defined scope.

***

# 33. AI Governance Owner

**Definition**

The AI governance owner is the person or role accountable for the organization's overall AI governance architecture, coordination, and governance effectiveness.

***

# 34. Risk Owner

**Definition**

The risk owner is the person or organizational role accountable for ensuring that an identified AI risk is evaluated, treated, monitored, accepted, transferred, avoided, or otherwise managed appropriately.

***

# 35. Assurance

**Definition**

Assurance is a structured activity providing confidence, based on defined criteria and evidence, regarding the design, implementation, operation, effectiveness, or governance of an AI-related control or process.

***

# 36. Assurance Activity

**Definition**

An assurance activity is a planned and executed evaluation performed against defined criteria using appropriate evidence and methods.

***

# 37. Assurance Conclusion

**Definition**

An assurance conclusion is the documented result of an assurance activity against its defined criteria, scope, evidence, and methodology.

**Possible AIGO Conclusions**

* Effective
* Effective with observations
* Partially effective
* Ineffective
* Insufficient evidence
* Not assessed
* Not applicable

These are AIGO assurance states and are not automatically external certification or legal conclusions.

***

# 38. Human Oversight

**Definition**

Human oversight is the organizational and operational capability through which appropriately authorized and competent people supervise, review, intervene in, override, or otherwise govern AI-system operation where required or appropriate.

***

# 39. Human Intervention

**Definition**

Human intervention is a deliberate action by an authorized person to influence, modify, pause, override, reject, or otherwise respond to an AI-system process or output.

***

# 40. AI Literacy

**Definition**

AI literacy is the knowledge, skills, understanding, and awareness required for people to perform their AI-related responsibilities appropriately and understand relevant AI capabilities, limitations, risks, and governance requirements.

**Usage**

The exact legal meaning and applicability of AI literacy may vary by source framework.

***

# 41. Transparency

**Definition**

Transparency is the provision of appropriate information about an AI system, its purpose, operation, limitations, relevant risks, or consequences to the people or organizations who require that information.

**Usage**

Framework-specific transparency obligations remain authoritative within their source mappings.

***

# 42. Explainability

**Definition**

Explainability is the degree to which relevant aspects of an AI system's behavior or output can be appropriately explained to an intended audience.

***

# 43. Interpretability

**Definition**

Interpretability is the extent to which the behavior, relationships, or outputs of an AI model or AI system can be understood in a meaningful way.

***

# 44. Accountability

**Definition**

Accountability is the assignment and acceptance of responsibility for decisions, actions, outcomes, and governance obligations.

***

# 45. Responsibility

**Definition**

Responsibility is the duty or obligation assigned to a person, role, or organizational unit to perform or oversee a defined activity.

**Distinction**

Responsibility describes the assigned duty.

Accountability describes answerability for the resulting outcome.

***

# 46. AI Classification

**Definition**

AI classification is the structured determination of an AI system's category, status, or governance treatment according to defined criteria.

**Critical Rule**

An AIGO internal classification must not automatically be represented as a statutory or regulatory classification.

***

# 47. Legal Classification

**Definition**

A legal classification is a classification established by applicable law or regulation.

**Example**

An EU AI Act legal classification is distinct from an organization's internal risk rating.

***

# 48. Internal Risk Classification

**Definition**

An internal risk classification is an organizational classification used to determine the level of governance, control, monitoring, or assurance appropriate for an AI system.

***

# 49. Residual Risk

**Definition**

Residual risk is the remaining AI-related risk after implemented risk treatments and controls have been considered.

***

# 50. Risk Treatment

**Definition**

Risk treatment is an action or combination of actions intended to modify, reduce, avoid, transfer, accept, or otherwise manage AI-related risk.

***

# 51. Risk Acceptance

**Definition**

Risk acceptance is a formally authorized decision to retain a defined level of residual risk under specified conditions.

***

# 52. Risk Register

**Definition**

A risk register is a controlled record containing identified risks, their attributes, evaluation, treatment, owners, status, and related information.

***

# 53. Control Effectiveness

**Definition**

Control effectiveness is the degree to which a control achieves its intended governance objective according to defined assessment criteria.

Control effectiveness may be evaluated separately for:

* design;
* implementation;
* operation;
* evidence;
* monitoring;
* overall effectiveness.

***

# 54. Monitoring

**Definition**

Monitoring is the systematic collection, observation, measurement, analysis, and review of AI-system, control, risk, or governance information over time.

***

# 55. Measurement

**Definition**

Measurement is the process of obtaining quantitative or qualitative information about an AI system, control, risk, process, or governance outcome according to defined methods.

***

# 56. Indicator

**Definition**

An indicator is a defined measure used to monitor performance, risk, control activity, governance activity, or another relevant condition.

***

# 57. Threshold

**Definition**

A threshold is a defined condition or value used to determine whether a measured indicator requires attention, escalation, investigation, or action.

***

# 58. Incident

**Definition**

An incident is an event or condition involving an AI system or AI governance process that results in, or may result in, harm, material disruption, control failure, security or safety consequences, nonconformity, or other defined adverse impact.

***

# 59. Incident Management

**Definition**

Incident management is the structured process for identifying, classifying, responding to, investigating, documenting, escalating, resolving, and learning from AI-related incidents.

***

# 60. Change

**Definition**

A change is a planned or unplanned modification to an AI system, model, data, configuration, process, control, governance arrangement, or other relevant component that may affect risk, applicability, performance, or compliance.

***

# 61. Change Management

**Definition**

Change management is the controlled process for evaluating, approving, implementing, documenting, monitoring, and reviewing changes.

***

# 62. Material Change

**Definition**

A material change is a change that may significantly affect:

* AI-system behavior;
* intended purpose;
* risk;
* impact;
* regulatory status;
* control effectiveness;
* security;
* safety;
* fairness;
* privacy;
* governance obligations.

Materiality should be determined using defined criteria.

***

# 63. Improvement

**Definition**

Improvement is a deliberate action intended to increase the effectiveness, suitability, adequacy, resilience, or maturity of AIGO governance.

***

# 64. Continual Improvement

**Definition**

Continual improvement is the ongoing cycle of identifying opportunities, implementing changes, evaluating results, and improving AI governance over time.

***

# 65. Corrective Action

**Definition**

Corrective action is an action taken to eliminate the cause of an identified problem, finding, nonconformity, incident, or control deficiency and to prevent recurrence.

***

# 66. Finding

**Definition**

A finding is a documented result identifying a condition that requires attention, correction, clarification, monitoring, acceptance, or improvement.

***

# 67. Gap

**Definition**

A gap is a documented difference between a defined requirement, expected governance state, control state, evidence state, assurance state, or other target condition and the current state.

***

# 68. Control Gap

**Definition**

A control gap exists when an applicable requirement or governance objective does not have an adequate control or framework-specific control extension.

***

# 69. Evidence Gap

**Definition**

An evidence gap exists when required or expected evidence is missing, insufficient, stale, inaccessible, improperly scoped, or otherwise inadequate to support the relevant criterion.

***

# 70. Assurance Gap

**Definition**

An assurance gap exists when an applicable control or requirement lacks appropriate assurance coverage where such coverage is required or established by the AIGO assurance model.

***

# 71. Traceability Gap

**Definition**

A traceability gap exists when a required relationship between governance objects cannot be established or resolved.

***

# 72. Version Gap

**Definition**

A version gap exists when a source framework, mapping, control, evidence, assurance activity, or related governance artifact references an incompatible, obsolete, or unidentified version.

***

# 73. Harmonization Gap

**Definition**

A harmonization gap exists when materially similar operational requirements are implemented separately without an identified reason or when an opportunity for defensible common implementation has not been addressed.

***

# 74. False Equivalence

**Definition**

False equivalence is the incorrect assumption that two requirements, standards, laws, controls, outcomes, or assurance conclusions are equivalent merely because they address related subject matter.

**AIGO Rule**

```text theme={null}
Shared Control
    ≠
Equivalent Requirement
```

***

# 75. Framework Status

**Definition**

Framework status describes the legal, normative, or voluntary nature of an external framework.

AIGO currently distinguishes:

```text theme={null}
Binding legislation
International standard
Voluntary framework
```

***

# 76. Source Framework

**Definition**

A source framework is an external law, regulation, standard, framework, guidance document, or other authoritative source against which AIGO establishes a mapping.

***

# 77. Framework Version

**Definition**

A framework version is the specific published or otherwise controlled version of a source framework used by an AIGO mapping.

***

# 78. AIGO Version

**Definition**

An AIGO version is a controlled release or revision of the AIGO Framework.

***

# 79. Applicability Assessment

**Definition**

An applicability assessment is a structured assessment used to determine which requirements, controls, or governance activities apply to a defined organization, activity, AI system, role, or situation.

***

# 80. AI System Profile

**Definition**

An AI system profile is the controlled record describing an AI system's identity, purpose, ownership, lifecycle state, architecture, dependencies, classification, and relevant governance characteristics.

***

# 81. Approval

**Definition**

Approval is a formally recorded authorization granted by an appropriately authorized person or governance body to proceed with a defined activity, state, deployment, change, or decision.

***

# 82. Governance Decision

**Definition**

A governance decision is a formally recorded decision made through an authorized AI governance process.

***

# 83. Governance Review

**Definition**

A governance review is a structured evaluation performed by an authorized governance body or role to determine whether AI governance remains appropriate, effective, and aligned with organizational requirements.

***

# 84. Management Review

**Definition**

Management review is a formal evaluation by organizational management of the suitability, adequacy, effectiveness, performance, risks, findings, and improvement needs of the applicable AI governance or management system.

***

# 85. Retirement

**Definition**

Retirement is the controlled termination of an AI system, service, model, process, control, or other governed object, including management of remaining obligations, records, risks, and dependencies.

***

# 86. Lifecycle State

**Definition**

A lifecycle state is a defined status representing the current stage of an AI system or governance object within its governed lifecycle.

***

# 87. Governance Domain

**Definition**

A governance domain is a defined area of responsibility or activity within the AIGO governance architecture.

Examples include:

* governance;
* risk;
* controls;
* lifecycle;
* monitoring;
* assurance;
* evidence.

***

# 88. Governance Control

**Definition**

A governance control is a control primarily concerned with organizational governance, accountability, policy, decision-making, oversight, or governance processes.

***

# 89. Risk Control

**Definition**

A risk control is a control primarily intended to prevent, reduce, manage, or respond to an identified AI-related risk.

***

# 90. Preventive Control

**Definition**

A preventive control is designed to prevent an undesired event, condition, or outcome before it occurs.

***

# 91. Detective Control

**Definition**

A detective control is designed to identify an undesired event, condition, or outcome after or while it occurs.

***

# 92. Corrective Control

**Definition**

A corrective control is designed to respond to and remediate an identified problem, failure, incident, or deviation.

***

# 93. Compensating Control

**Definition**

A compensating control is an alternative control implemented to reduce a risk when the preferred control is unavailable, ineffective, or temporarily impractical.

***

# 94. Exception

**Definition**

An exception is an authorized, documented departure from a defined requirement, control, procedure, or governance expectation.

***

# 95. Accepted Exception

**Definition**

An accepted exception is an approved exception whose risk, rationale, owner, compensating measures, and validity period have been documented.

***

# 96. Escalation

**Definition**

Escalation is the controlled transfer of an issue, decision, risk, incident, finding, or other matter to a role or governance body with appropriate authority or competence.

***

# 97. Stakeholder

**Definition**

A stakeholder is a person, group, organization, authority, or other entity that can affect, be affected by, or perceive itself to be affected by an AI system or AI governance activity.

***

# 98. Affected Person

**Definition**

An affected person is an individual who may be affected by the operation, output, decision, use, or consequences of an AI system.

***

# 99. Intended Purpose

**Definition**

Intended purpose is the documented purpose for which an AI system is designed, deployed, or governed.

***

# 100. Deployment

**Definition**

Deployment is the controlled introduction of an AI system, model, service, or material change into an operational environment.

***

# 101. Operation

**Definition**

Operation is the period during which an AI system or governed service performs its intended functions in an operational environment.

***

# 102. Post-Deployment Monitoring

**Definition**

Post-deployment monitoring is the systematic observation and evaluation of an AI system after deployment to identify changes in performance, risk, impact, incidents, or other relevant conditions.

***

# 103. Technical Documentation

**Definition**

Technical documentation is controlled documentation describing the design, development, architecture, operation, characteristics, performance, testing, or other technical aspects of an AI system.

**Usage**

Specific legal or regulatory definitions of technical documentation remain source-framework specific.

***

# 104. Documented Information

**Definition**

Documented information is controlled information that an organization is required or chooses to maintain and manage as evidence, instruction, governance content, or a formal record.

***

# 105. Record

**Definition**

A record is retained information providing evidence that an activity, event, decision, assessment, control, or outcome occurred.

***

# 106. Repository

**Definition**

The AIGO repository is the controlled collection of AIGO framework documents, schemas, guidance, mappings, tools, validation resources, examples, and related governance artifacts.

***

# 107. Registry

**Definition**

A registry is a machine-readable or controlled record containing structured metadata and relationships for a defined class of AIGO artifacts.

Examples include:

* schema registry;
* framework mapping registry;
* cross-framework mapping registry.

***

# 108. Machine-Readable Artifact

**Definition**

A machine-readable artifact is a repository artifact structured for automated processing, validation, integration, or analysis.

Examples include:

* JSON schemas;
* JSON registries;
* validation reports.

***

# 109. Validation

**Definition**

Validation is a structured process for determining whether an AIGO repository artifact, relationship, schema, document, or repository state satisfies defined structural or consistency criteria.

**Critical Boundary**

AIGO validation does not by itself establish legal compliance, certification, accreditation, or conformity.

***

# 110. Validation Finding

**Definition**

A validation finding is an automatically or manually generated result identifying a structural, reference, traceability, consistency, coverage, documentation, or repository-health condition requiring attention.

***

# 111. Repository Health

**Definition**

Repository health is the overall condition of the AIGO repository with respect to structural integrity, references, traceability, coverage, consistency, documentation, versioning, and validation status.

***

# 112. Release Gate

**Definition**

A release gate is a defined set of validation criteria that must be satisfied before an AIGO version may be designated ready for release.

***

# 113. AIGO v1

**Definition**

AIGO v1 is the first controlled release of the AIGO Framework that satisfies the approved v1 scope and release-gate criteria.

A v1 release should be distinguished from draft and v0.x development states.

***

# 114. Readiness

**Definition**

Readiness is the state in which defined preparation, implementation, evidence, assurance, and validation criteria have been satisfied for a particular objective.

Examples:

* regulatory readiness;
* certification readiness;
* framework readiness;
* release readiness.

Readiness does not automatically mean compliance or certification.

***

# 115. Regulatory Readiness

**Definition**

Regulatory readiness is the documented state in which an organization has prepared the governance processes, controls, records, evidence, and assurance needed to address specified regulatory requirements within scope.

***

# 116. Certification Readiness

**Definition**

Certification readiness is the documented state in which an organization has prepared for an external certification assessment against a specified certification standard and scope.

Certification readiness does not constitute certification.

***

# 117. Compliance

**Definition**

Compliance is conformity with an applicable legal, regulatory, contractual, organizational, or other defined requirement.

**AIGO Boundary**

AIGO repository validation should not describe a system or organization as legally compliant unless the relevant assessment has actually been performed against applicable criteria.

***

# 118. Conformity Assessment

**Definition**

A conformity assessment is a formal evaluation against defined conformity criteria performed by an appropriately authorized or competent party under the applicable framework.

***

# 119. Certification

**Definition**

Certification is a formal attestation issued by an appropriately authorized certification body or other recognized authority according to applicable certification rules.

***

# 120. Audit

**Definition**

An audit is a systematic and documented evaluation performed against defined criteria to obtain evidence and determine the extent to which the criteria are fulfilled.

***

# 121. Internal Audit

**Definition**

An internal audit is an audit performed within or on behalf of an organization for internal governance, management-system, control, or assurance purposes.

***

# 122. External Assessment

**Definition**

An external assessment is an evaluation performed by a party external to the organization according to an established scope, methodology, and criteria.

***

# 123. Framework Equivalence

**Definition**

Framework equivalence is a formally justified determination that two framework elements are sufficiently equivalent for a specifically defined purpose.

**AIGO Rule**

AIGO does not assume equivalence merely from overlapping subject matter.

***

# 124. Operational Harmonization

**Definition**

Operational harmonization is the deliberate use of common governance processes, controls, evidence, or assurance mechanisms to satisfy related requirements across multiple frameworks.

***

# 125. Reusable Evidence

**Definition**

Reusable evidence is evidence that can legitimately support more than one governance or framework relationship while remaining traceable and sufficient for each applicable criterion.

***

# 126. Shared Evidence

**Definition**

Shared evidence is a single governed evidence record associated with multiple framework or control relationships.

Shared evidence must be evaluated independently for sufficiency.

***

# 127. Shared Assurance

**Definition**

Shared assurance is an assurance activity that evaluates multiple related framework criteria through common testing or evidence where the scope and methodology are sufficient.

***

# 128. Framework-Specific Assurance

**Definition**

Framework-specific assurance is assurance performed against criteria that arise from a specific framework and cannot be safely generalized to other frameworks without additional evaluation.

***

# 129. Source Authority

**Definition**

Source authority is the original or controlling law, regulation, standard, framework, official publication, or other authoritative source from which a requirement or criterion originates.

***

# 130. Authoritative Source

**Definition**

An authoritative source is a source recognized as controlling or authoritative for the interpretation of the specific requirement or framework relationship being evaluated.

***

# 131. Normative Requirement

**Definition**

A normative requirement is a requirement that specifies what must, should, or is otherwise expected to be done within the authority and context of its source.

***

# 132. AIGO Internal Requirement

**Definition**

An AIGO internal requirement is a requirement established by the AIGO framework itself for implementation, governance, validation, documentation, or repository operation.

***

# 133. Mandatory

**Definition**

Mandatory describes an obligation that must be satisfied under the authority applicable to the specific context.

The source of mandatory status must be identified.

***

# 134. Recommended

**Definition**

Recommended describes an AIGO or source-framework practice that is advised but is not itself represented as a binding legal requirement unless the authoritative source states otherwise.

***

# 135. Not Applicable

**Definition**

Not applicable is a formally determined state indicating that a requirement, control, evidence expectation, or assurance criterion does not apply within a defined scope.

***

# 136. Superseded

**Definition**

Superseded describes an artifact, version, record, requirement, or control that has been replaced by a later approved artifact while remaining relevant for historical traceability.

***

# 137. Historical

**Definition**

Historical describes information retained to preserve the state of a system, governance process, framework, evidence set, or decision at an earlier point in time.

***

# 138. Current

**Definition**

Current describes the approved version of an artifact or framework relationship applicable to the present governance state.

***

# 139. Control Baseline

**Definition**

A control baseline is the defined set of AIGO controls applicable to a specific organizational, system, framework, risk, or governance scope.

***

# 140. Evidence Baseline

**Definition**

An evidence baseline is the defined set of evidence expected or required to demonstrate implementation, operation, performance, or assurance of a specified control or requirement.

***

# 141. Assurance Baseline

**Definition**

An assurance baseline is the defined set of assurance criteria, scope, methods, and coverage expected for a specified governance scope.

***

# 142. Governance Baseline

**Definition**

A governance baseline is the approved set of governance requirements, controls, roles, processes, evidence, and assurance expectations applicable to a defined organizational scope.

***

# 143. Terminology Conflict

**Definition**

A terminology conflict exists when the repository uses the same term with materially different meanings in different AIGO artifacts without explicitly identifying the distinction.

***

# 144. Controlled Term

**Definition**

A controlled term is a term whose meaning is defined in this document and whose use should remain consistent throughout the AIGO repository.

***

# 145. Preferred Usage Rule

Where multiple expressions could describe the same concept, AIGO should use the terminology defined in this document unless:

* a source framework requires its own terminology;
* a legal definition must be quoted or preserved;
* a technical term has a distinct established meaning.

When a source-specific term differs from an AIGO term, the source-specific term should be identified explicitly.

***

# 146. Source-Specific Terminology Rule

The following pattern should be used:

```text theme={null}
AIGO Internal Term
        +
[Source Framework] Specific Meaning
```

Example:

```text theme={null}
AIGO internal classification
        ≠
EU AI Act legal classification
```

***

# 147. Capitalization

The following names should retain their defined capitalization where referring to the formal framework or artifact:

* AIGO;
* AI Governance;
* AI System;
* EU AI Act;
* ISO/IEC 42001;
* NIST AI RMF.

Generic usage may be lowercase where grammatically appropriate.

***

# 148. Identifier Rule

Where a controlled object has a machine-readable identifier, documentation should use the identifier consistently.

Examples:

```text theme={null}
AIGO Control ID
AIGO Evidence ID
AIGO Assurance ID
Framework Requirement ID
Mapping Relationship ID
```

***

# 149. Definition Hierarchy

Where definitions conflict, apply the following order:

```text theme={null}
Applicable Law
      ↓
Authoritative Source Framework
      ↓
AIGO Framework
      ↓
AIGO Guidance
      ↓
Operational Procedure
      ↓
Local Implementation
```

A lower-level document must not silently override a higher-level definition.

***

# 150. Framework Mapping Rule

When a source framework uses a term that differs from AIGO terminology:

1. retain the source term where necessary;
2. identify the source framework;
3. preserve the source meaning;
4. map the source concept to the appropriate AIGO concept;
5. do not imply equivalence unless justified.

***

# 151. Terminology and Schemas

Schema property names should use controlled terminology where practical.

For example:

```text theme={null}
system_id
control_id
evidence_id
assurance_id
risk_id
assessment_id
approval_id
incident_id
change_id
```

The machine-readable property name should remain stable even if explanatory text evolves.

***

# 152. Terminology and Mappings

Mapping documents should distinguish:

```text theme={null}
Source Requirement
AIGO Control
Framework Extension
Evidence
Assurance
```

These terms should not be collapsed into a generic `compliance item`.

***

# 153. Terminology and Validation

Validation findings should use controlled categories such as:

```text theme={null}
REFERENCE_GAP
TRACEABILITY_GAP
CONTROL_GAP
EVIDENCE_GAP
ASSURANCE_GAP
VERSION_GAP
DOCUMENT_INTEGRITY_GAP
FRAMEWORK_CONSISTENCY_GAP
```

***

# 154. Terminology and Evidence

Evidence should describe what is demonstrated, not merely what document exists.

For example:

```text theme={null}
Risk Assessment Record
```

is an artifact.

```text theme={null}
Evidence of documented risk assessment
```

describes the governance evidentiary purpose.

***

# 155. Terminology and Assurance

Assurance should not be described simply as:

```text theme={null}
COMPLIANT
```

unless that conclusion is specifically within the authorized scope and criteria of the assessment.

Preferred terminology includes:

* effective;
* partially effective;
* insufficient evidence;
* finding identified;
* readiness demonstrated.

***

# 156. Terminology and Compliance Claims

AIGO documents should avoid unsupported statements such as:

```text theme={null}
"ISO compliant"
"EU AI Act compliant"
"NIST certified"
```

unless the statement is explicitly scoped, evidenced, and authorized.

***

# 157. Terminology and Legal Claims

AIGO internal terms should not be presented as legal definitions unless the legal source explicitly establishes the definition.

Where legal terminology is important, the mapping should identify the source provision.

***

# 158. Terminology Review

This terminology document should be reviewed whenever:

* a new major AIGO concept is introduced;
* a schema introduces a new controlled object;
* a framework mapping introduces material terminology conflict;
* a validation category changes;
* a v1 or later release changes core architecture.

***

# 159. Terminology Change Control

Changes to controlled terminology should be:

* documented;
* versioned;
* reviewed;
* evaluated for downstream impact.

Material terminology changes should trigger review of:

* schemas;
* guidance;
* procedures;
* mappings;
* templates;
* examples;
* validators.

***

# 160. Backward Compatibility

Where terminology changes, the repository should preserve historical identifiers and references where practical.

A terminology change should not silently invalidate existing machine-readable relationships.

***

# 161. Terminology Deprecation

A term may be marked:

```text theme={null}
CURRENT
DEPRECATED
SUPERSEDED
HISTORICAL
```

A deprecated term should identify its preferred replacement.

***

# 162. Terminology Registry Principle

The controlled terminology document is the human-readable terminology authority.

Future machine-readable terminology registries may be introduced, but should remain synchronized with this document.

***

# 163. Minimum Controlled Vocabulary

The following are designated core AIGO terms:

```text theme={null}
AIGO
AI Governance
AI System
AI Model
AI Lifecycle
AI Risk
AI Impact
AI Governance Objective
Control
AIGO Control
Common Control
Framework-Specific Extension
Evidence
Assessment
Applicability
Framework Requirement
Framework Outcome
Framework Mapping
Traceability
Governance Role
AI System Owner
AI Governance Owner
Assurance
Monitoring
Incident
Change
Improvement
Retirement
AI Classification
Residual Risk
Risk Treatment
Risk Acceptance
Human Oversight
AI Literacy
Transparency
Accountability
```

***

# 164. Final Terminology Principle

AIGO uses the following governing principle:

> **Use one controlled AIGO vocabulary for the framework, while preserving source-specific meanings wherever law, standards, or external frameworks define concepts differently.**

This prevents terminology drift, reduces ambiguity, supports machine-readable traceability, and allows the framework to integrate multiple external sources without collapsing their distinct meanings.

***

# 165. Document Control

| Field               | Value                                           |
| ------------------- | ----------------------------------------------- |
| Document            | AIGO Terminology                                |
| Version             | 0.1                                             |
| Status              | Draft                                           |
| Document Identifier | `AIGO-TERM-001`                                 |
| Document Type       | Controlled Terminology                          |
| Repository Path     | `framework/01-charter/AIGO-Terminology-v0.1.md` |
| Authority           | AIGO Framework Charter                          |
| Owner               |                                                 |
| Terminology Owner   |                                                 |
| Governance Reviewer |                                                 |
| Framework Reviewer  |                                                 |
| Schema Reviewer     |                                                 |
| Approved By         |                                                 |
| Effective Date      |                                                 |
| Next Review Date    |                                                 |

***

# 166. Document Status

**Document:** AIGO — Terminology

**Version:** 0.1

**Status:** Draft

**Working Name:** AIGO

**Full Name:** AI Governance Operating Framework

**Document Identifier:** `AIGO-TERM-001`

**Document Type:** Controlled Terminology

This document establishes the controlled vocabulary for the AIGO Framework and provides the terminology foundation for framework documents, guidance, procedures, templates, schemas, mappings, evidence, assurance, validation, and repository governance.

End of Document