​

Approval Schema

The AIGO Approval Schema provides the machine-readable structure for recording governance approval and decision records. An approval represents a formal governance decision made by an authorized decision-maker or decision body. Approval records provide a durable representation of what was decided, who made the decision, what information supported it, and what conditions or limitations apply.

​

Purpose

The Approval Schema supports consistent recording of:

• the decision subject
• the decision scope
• the decision authority
• the decision status
• the decision date
• supporting assessments and evidence
• conditions or limitations
• required actions
• review or renewal requirements
• relationships to other governance records

This allows governance decisions to remain traceable throughout the AI system lifecycle.

​

Role in the AIGO architecture

Approval is a governance decision layer that sits downstream of relevant assessments, evidence, risks, controls, and other governance information. A representative decision chain is: AI system → classification → risk → controls → assessment → evidence → approval Approval should therefore not be treated as an isolated record. The approval record can reference the governance information that supported the decision and establish the decision as an authoritative governance outcome.

​

What an approval represents

An approval may authorize:

• deployment of an AI system
• continued operation
• a significant lifecycle activity
• a material change
• acceptance of defined conditions
• an exception
• a risk treatment decision
• another governed activity requiring formal authorization

The precise scope of approval depends on the organization’s governance model and the applicable AIGO process.

​

Decision authority

An approval should identify the person, role, committee, or other authorized decision authority responsible for the decision. The decision authority should be appropriate to:

• the AI system classification
• risk significance
• decision type
• organizational governance requirements
• applicable policies
• applicable legal or regulatory requirements

Approval authority should not be inferred solely from technical ownership of an AI system. Technical ownership and governance decision authority may be different roles.

​

Decision status

An approval record should preserve the status of the governance decision. Depending on the applicable AIGO definitions, statuses may include concepts such as:

• approved
• conditionally approved
• rejected
• pending
• suspended
• expired
• withdrawn

The canonical Approval Schema defines the permitted machine-readable structure and values. Status should always be interpreted together with the decision scope and any applicable conditions.

​

Approval scope

An approval should clearly establish what is being authorized. For example, an approval may apply to:

• a specific AI system
• a specific version or deployment
• a defined use case
• a defined operating environment
• a material change
• a defined time period
• a specific governance exception

A broad approval should not automatically be interpreted as authorization for activities outside its defined scope.

​

Supporting governance context

Approval decisions should be connected to the information used to reach the decision. Depending on the context, this may include:

• AI system registration
• classification
• risk assessments
• risk treatment
• control assessments
• evidence
• monitoring results
• assurance findings
• incident records
• change records
• remediation actions
• exceptions
• applicable requirements

This creates a traceable relationship between the decision and its supporting governance basis.

​

Conditional approval

A system or activity may be approved subject to defined conditions. Examples include:

• required remediation
• additional monitoring
• restricted deployment
• defined usage limitations
• compensating controls
• additional evidence
• management review
• time-limited authorization
• reassessment requirements

Conditions should be specific enough to determine whether they have been satisfied. Where possible, conditions should have:

• an identified owner
• a required action
• a due date or review point
• supporting evidence requirements
• a verification mechanism

A conditional approval should therefore remain connected to subsequent monitoring, assessment, evidence, and assurance activities.

​

Approval and risk

Approval does not eliminate or automatically transfer risk. A governance decision may authorize operation while residual risks remain within defined organizational tolerances or are subject to specified conditions. The relationship can therefore be represented as: risk → treatment → controls → assessment → residual risk → approval Where residual risk exceeds the organization’s defined authority or tolerance, an appropriate risk acceptance or escalation process may also be required.

​

Approval and controls

Control implementation and assessment may provide important inputs to an approval decision. For example: risk → control → control assessment → evidence → approval An approval record should not replace the underlying control assessment. Instead, it should preserve the decision that was made after considering the relevant control state and evidence.

​

Approval and assurance

Assurance activities may subsequently examine whether:

• the approval was made by an authorized decision-maker
• the decision scope was clear
• supporting information was appropriate
• approval conditions were satisfied
• required actions were completed
• the approval remained valid
• subsequent changes were properly governed

This creates an important distinction between making a governance decision and providing assurance over that decision.

​

Approval lifecycle

Approval should be treated as a lifecycle record rather than a one-time event. A practical lifecycle is: request → review → decision → conditions → implementation → monitoring → review → renewal, change, suspension, or withdrawal The appropriate lifecycle depends on the decision type. For example, a deployment approval may require periodic review, while an approval associated with a specific change may only apply to that change.

​

Review and renewal

Approvals may require review or renewal when:

• the approval period expires
• the AI system materially changes
• intended use changes
• classification changes
• risk changes
• controls change
• significant incidents occur
• applicable requirements change
• approval conditions are not satisfied
• monitoring identifies significant concerns
• assurance identifies deficiencies

A renewed approval should preserve traceability to the previous decision where appropriate.

​

Relationship to change management

Material changes may invalidate or alter the basis of an existing approval. Change management should therefore determine whether a change requires:

• no approval action
• approval confirmation
• additional conditions
• reassessment
• re-approval
• suspension
• withdrawal

The relationship can be represented as: change → impact assessment → reassessment → approval decision This prevents an approval from being treated as permanently valid regardless of subsequent changes.

​

Relationship to machine-readable evaluation

AIGO separates governance records from machine-readable evaluation rules. The Approval Schema represents the governance decision. Evaluation rules define conditions that can be checked against governed records. The conceptual architecture is: governance records → rules → evaluation → result Approval information can therefore become an input to evaluation without embedding evaluation logic directly into the Approval Schema. For example, an evaluation rule could determine whether:

• a required approval exists
• the approval is in an acceptable status
• the approval applies to the relevant AI system
• required conditions have been recorded
• a required approval has expired

Automated evaluation supports governance operations but does not automatically replace authorized human decision-making.

​

Machine-readable implementation

An organization implementing AIGO may use the Approval Schema as the structural contract for storing or exchanging approval records. A governance system could use the schema to:

1. create an approval request
2. identify the governed subject
3. identify the required decision authority
4. associate supporting assessments and evidence
5. record the decision
6. record conditions or limitations
7. assign required follow-up actions
8. establish review or renewal requirements
9. make the decision available to monitoring and evaluation
10. preserve the approval as lifecycle evidence

The schema defines the structure of the governance record. It does not prescribe a particular workflow engine, database, application, or organizational approval model.

​

Validation

Approval artifacts participate in the broader AIGO validation model. Relevant validation may include:

• schema validation
• reference validation
• traceability validation
• evidence relationships
• framework consistency
• document integrity
• repository health
• rule validation
• evaluation fixture validation
• evaluation orchestration validation

A passing validation result indicates that the tested artifact or repository content satisfies the implemented validation checks within the applicable scope. It does not establish legal compliance, certification, accreditation, or regulatory conformity.

​

Canonical source

Machine-readable schema: schemas/05-approval/05-AIGO-Approval-Schema-v0.1.json Schema documentation: schemas/05-approval/05-AIGO-Approval-Schema-Documentation-v0.1.md Operational procedure: guidance/02-procedures/06-AIGO-AI-Approval-Procedure-v0.1.md Implementation template: guidance/03-templates/07-AIGO-AI-Approval-Template-v0.1.md