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

# 05 AIGO Approval Schema Documentation v0.1

# AIGO — Approval Schema Documentation

## 1. Document Purpose

This document describes the machine-readable AIGO Approval Schema.

The schema provides the structured representation of formal governance approvals and authorization decisions under the AIGO AI Governance Operating Framework.

It is intended to support:

* AI system approval;
* deployment approval;
* continued-operation approval;
* risk acceptance;
* material-change approval;
* incident-related governance decisions;
* restricted operation;
* resumption;
* retirement approval;
* control exceptions;
* governance exceptions;
* assurance-related decisions; and
* other formally authorized AI governance decisions.

The JSON schema defines structural requirements.

This documentation explains the intended meaning, governance context, validation expectations, and traceability model for approval records.

***

## 2. Schema Information

| Field               | Value                                       |
| ------------------- | ------------------------------------------- |
| Schema              | AIGO Approval Schema                        |
| Schema Identifier   | `https://aigo.example/schema/approval/v0.1` |
| Schema Version      | `0.1`                                       |
| JSON Schema Dialect | JSON Schema Draft 2020-12                   |
| Object Type         | `APPROVAL`                                  |
| File                | `05-AIGO-Approval-Schema-v0.1.json`         |
| Status              | Draft                                       |
| Framework           | AIGO — AI Governance Operating Framework    |

***

## 3. Scope

The Approval Schema applies to formal authorization decisions made under AIGO governance arrangements.

An approval may authorize:

* an AI system to progress through a lifecycle stage;
* deployment or production operation;
* continued operation;
* a material change;
* risk acceptance;
* an exception;
* restricted operation;
* resumption after suspension;
* corrective action closure;
* retirement; or
* another decision requiring formal governance authority.

The organization's governance framework determines which decisions require formal approval.

***

## 4. Object Model

The primary object represented by this schema is:

```text theme={null}
APPROVAL
```

An Approval record represents a formal governance decision issued by an authorized authority.

The Approval record should remain distinct from:

* the object being approved;
* the assessment supporting the decision;
* the risk being accepted or managed;
* the controls being relied upon;
* supporting evidence;
* monitoring arrangements;
* change records;
* assurance findings; and
* management review records.

Related records should normally be connected through stable identifiers.

***

## 5. Core Identity

An Approval record should contain stable identity information.

Key fields include:

* `id`;
* `objectType`;
* `objectVersion`;
* `schemaVersion`;
* approval type;
* subject;
* approval authority;
* decision;
* decision date;
* status; and
* applicable conditions.

Example:

```json theme={null}
{
  "id": "APPROVAL-001",
  "objectType": "APPROVAL",
  "objectVersion": "1.0",
  "schemaVersion": "0.1"
}
```

The approval identifier should remain stable throughout the approval record's controlled lifecycle.

A materially different decision should normally be represented by a new approval record rather than by silently rewriting a historical decision.

***

## 6. Approval Purpose

The approval record should clearly state why the authorization is required.

Examples include:

* authorize production deployment;
* authorize continued operation;
* approve a material change;
* accept residual risk;
* approve a control exception;
* authorize restricted use;
* authorize resumption;
* approve retirement; or
* authorize another governed action.

The purpose should establish the decision's relationship to the applicable AIGO governance requirement.

***

## 7. Approval Types

The approval type should identify the category of governance decision.

Typical approval categories include:

```text theme={null}
AI_SYSTEM_REGISTRATION
CLASSIFICATION
DEPLOYMENT
OPERATION
CONTINUED_OPERATION
MATERIAL_CHANGE
RISK_ACCEPTANCE
CONTROL_EXCEPTION
GOVERNANCE_EXCEPTION
INCIDENT_RESPONSE
RESTRICTED_OPERATION
RESUMPTION
RETIREMENT
ASSURANCE
OTHER
```

The authoritative enumeration defined in the JSON schema is controlling.

Organizations should use a controlled approval taxonomy to support reporting and traceability.

***

## 8. Approval Subject

An approval should identify exactly what is being authorized.

The subject may be:

* an AI system;
* a risk;
* a control;
* an assessment;
* a change;
* a retirement activity;
* an exception;
* a governance arrangement; or
* another defined AIGO object.

The record should reference the applicable stable identifier.

Examples:

```text theme={null}
AI-SYS-001
RISK-003
CHANGE-004
RETIRE-002
```

***

## 9. Decision Authority

The approval must identify the authority making the decision.

The approval authority should have:

* appropriate organizational authority;
* defined decision rights;
* sufficient competence;
* no prohibited conflict of interest; and
* authority covering the decision scope.

The relevant authority should be traceable to the organization's governance structure and decision-authority model.

An approval record should never be treated as valid merely because a person's name has been entered.

***

## 10. Authority Basis

The record should identify why the approver has authority.

The authority basis may reference:

* governance policy;
* governance committee charter;
* delegated authority;
* decision matrix;
* organizational mandate;
* risk authority;
* regulatory requirement; or
* another controlled source.

Example:

```text theme={null}
AIGO Governance Decision Authority Matrix — AI Deployment Approval
```

This strengthens auditability and prevents ambiguous approval authority.

***

## 11. Segregation of Duties

Where required, the approval process should provide appropriate segregation between:

* requestor;
* assessor;
* reviewer; and
* approver.

The approval record may identify each role.

Segregation requirements should be proportionate to:

* risk;
* decision significance;
* independence requirements;
* organizational policy; and
* applicable external obligations.

Emergency situations may require controlled exceptions to ordinary segregation arrangements, with retrospective review where necessary.

***

## 12. Decision Values

An approval decision should use an explicitly defined decision state.

Typical outcomes include:

```text theme={null}
APPROVED
APPROVED_WITH_CONDITIONS
DEFERRED
REJECTED
CANCELLED
```

The authoritative enumeration defined in the JSON schema is controlling.

A positive decision should not be implied merely by the existence of an approval record.

***

## 13. Approval Status

The approval record should distinguish the decision itself from the administrative lifecycle of the record.

For example:

```text theme={null}
DRAFT
SUBMITTED
UNDER_REVIEW
DECISION_PENDING
APPROVED
APPROVED_WITH_CONDITIONS
DEFERRED
REJECTED
EXPIRED
REVOKED
SUPERSEDED
CLOSED
```

The precise status values defined in the JSON schema are authoritative.

Administrative status and governance decision should not be conflated.

***

## 14. Approval Conditions

An approval may be subject to conditions.

Conditions may require:

* completion of additional controls;
* remediation;
* additional testing;
* enhanced monitoring;
* restricted deployment;
* completion of training;
* additional evidence;
* reassessment;
* independent assurance;
* time-limited operation; or
* management review.

Each material condition should identify:

* description;
* owner;
* due date;
* status;
* verification requirement; and
* evidence where applicable.

***

## 15. Conditional Approval

An approval with conditions is not equivalent to an unrestricted approval.

The organization should define:

* whether the decision is immediately effective;
* which conditions are preconditions;
* which conditions may be completed after approval;
* maximum duration;
* monitoring requirements;
* escalation triggers; and
* consequences of failure to satisfy conditions.

This distinction is important for operational governance.

***

## 16. Effective Date

An approval should identify when the decision becomes effective.

The effective date may differ from:

* request date;
* assessment date;
* approval decision date; or
* implementation date.

Where approval is conditional, the effective date may depend on satisfaction of specified preconditions.

***

## 17. Expiry

Certain approvals may be time-limited.

Examples include:

* temporary risk acceptance;
* emergency approval;
* restricted operation;
* conditional deployment;
* temporary exception; and
* transitional arrangements.

Where an approval has an expiry date, the record should identify:

* expiry date;
* renewal requirements;
* review owner;
* consequences of expiry; and
* whether automatic continuation is prohibited.

Approvals should not silently remain effective after their authorized period.

***

## 18. Preconditions

The approval may specify prerequisites that must be satisfied before implementation.

Examples include:

* assessment complete;
* critical controls operational;
* testing passed;
* evidence captured;
* monitoring active;
* human oversight operational;
* security review complete;
* privacy review complete;
* required training completed; and
* contingency arrangements verified.

Preconditions should be explicitly distinguishable from post-approval conditions where the schema supports that distinction.

***

## 19. Supporting Assessments

Approval decisions should generally reference the relevant assessments supporting the decision.

These may include:

* classification;
* risk;
* control;
* technical;
* model;
* data;
* privacy;
* security;
* fairness;
* impact;
* human oversight;
* change impact;
* monitoring; or
* retirement assessment.

The assessment records remain authoritative for their evaluation and conclusions.

***

## 20. Supporting Risk Records

The approval should identify relevant risks.

Example:

```json theme={null}
{
  "id": "APPROVAL-001",
  "riskIds": [
    "RISK-001",
    "RISK-004"
  ]
}
```

This allows reviewers to determine:

* what risks were considered;
* whether residual risk was within tolerance;
* whether risk acceptance was required;
* whether conditions address outstanding exposure; and
* whether the approval aligns with governance requirements.

***

## 21. Supporting Control Records

Where an approval relies on controls, the approval record may reference relevant control identifiers.

Examples include:

* deployment controls;
* human-oversight controls;
* security controls;
* privacy controls;
* monitoring controls;
* incident-response controls; and
* change controls.

Critical controls should be explicitly identified where applicable.

***

## 22. Supporting Evidence

An approval should be supported by evidence sufficient to demonstrate the basis of the decision.

Evidence may include:

* assessment results;
* test reports;
* control evidence;
* monitoring results;
* risk acceptance;
* assurance conclusions;
* stakeholder engagement;
* meeting records;
* approvals from delegated authorities; and
* other controlled records.

The Evidence Schema provides the authoritative structure for evidence records.

***

## 23. Approval Rationale

The approval should provide a rationale for the decision.

The rationale should explain:

* what was considered;
* why the decision was reached;
* relevant risks;
* relevant conditions;
* significant limitations;
* applicable governance requirements; and
* any material assumptions.

A rationale should be sufficiently clear for a later independent reviewer to understand the decision without relying exclusively on undocumented context.

***

## 24. Decision Factors

The approval may record material decision factors.

Examples include:

* risk level;
* residual risk;
* control effectiveness;
* affected-person impact;
* regulatory requirements;
* assurance findings;
* business necessity;
* technical readiness;
* monitoring capability;
* human-oversight readiness; and
* continuity arrangements.

Decision factors should be proportionate to the significance of the decision.

***

## 25. Risk Acceptance Approval

Where residual risk exceeds ordinary acceptance authority or requires formal acceptance, the approval record may represent the risk acceptance decision.

The record should identify:

* risk;
* residual risk;
* risk owner;
* acceptance authority;
* decision;
* validity period;
* conditions;
* rationale; and
* review requirements.

Risk acceptance should not be confused with risk assessment.

The assessment determines the risk.

The approval authorizes acceptance where authorized.

***

## 26. Deployment Approval

Deployment approval may authorize an AI system to move into a specified environment.

The approval should identify, where applicable:

* AI system;
* version;
* environment;
* deployment scope;
* assessment results;
* critical controls;
* testing;
* monitoring;
* human oversight;
* security;
* privacy;
* rollback;
* continuity; and
* approval authority.

Deployment approval should be consistent with the applicable lifecycle gate.

***

## 27. Continued Operation Approval

Some AI systems may require periodic approval for continued operation.

Continued-operation approval may consider:

* monitoring performance;
* incidents;
* changes;
* control effectiveness;
* assurance findings;
* risk acceptance;
* regulatory developments;
* stakeholder concerns; and
* ongoing business justification.

The approval may be time-limited and subject to review conditions.

***

## 28. Material Change Approval

Material changes may require separate approval.

The approval should reference the relevant Change record.

Supporting information may include:

* change assessment;
* risk impact;
* classification impact;
* control impact;
* testing;
* rollback plan;
* monitoring changes;
* human-oversight impact; and
* assurance.

Approval should occur before implementation where required by the change procedure.

***

## 29. Emergency Approval

Emergency governance may require expedited approval.

An emergency approval should document:

* emergency reason;
* immediate risk;
* decision authority;
* action authorized;
* limitations;
* temporary controls;
* effective period;
* retrospective review requirements; and
* evidence.

Emergency approval should not become a mechanism for bypassing ordinary governance without justification.

***

## 30. Restricted Operation

An approval may authorize operation with restrictions.

Restrictions may concern:

* user groups;
* jurisdictions;
* use cases;
* functionality;
* model versions;
* transaction volume;
* environments;
* decision authority; or
* duration.

The restriction should be explicit and supported by monitoring and escalation requirements where appropriate.

***

## 31. Resumption Approval

Following suspension or significant incident handling, an approval may authorize resumption.

The approval should consider:

* incident closure or containment;
* remediation;
* testing;
* residual risk;
* controls;
* monitoring;
* human oversight;
* assurance; and
* conditions for resumption.

Resumption approval should distinguish between:

* full resumption;
* restricted resumption; and
* resumption with conditions.

***

## 32. Retirement Approval

Retirement approval authorizes the controlled withdrawal of an AI system.

Supporting information may include:

* retirement trigger;
* risk assessment;
* replacement readiness;
* business continuity;
* data disposition;
* access removal;
* technical shutdown;
* supplier closure;
* evidence retention;
* regulatory requirements; and
* retirement verification.

The Retirement Schema remains authoritative for the overall retirement process.

***

## 33. Exception Approval

The Approval Schema may support approval of governance exceptions.

An exception approval should identify:

* requirement being excepted;
* reason;
* risk;
* compensating controls;
* owner;
* duration;
* review date; and
* approval authority.

Exceptions should be time-limited where practical.

***

## 34. Approval Review

An approval may require multiple reviews before the final decision.

Review types may include:

* business;
* risk;
* security;
* privacy;
* fairness;
* technical;
* control;
* monitoring;
* legal/compliance;
* AI governance; and
* assurance.

Each review should identify:

* reviewer;
* review date;
* result;
* evidence; and
* conditions or findings.

***

## 35. Approval Workflow

The typical workflow is:

```text theme={null}
Request
  ↓
Scope Confirmation
  ↓
Assessment
  ↓
Evidence Collection
  ↓
Required Reviews
  ↓
Authority Check
  ↓
Decision
  ↓
Conditions
  ↓
Effective Date
  ↓
Implementation
  ↓
Monitoring / Verification
  ↓
Closure / Renewal / Revocation
```

The actual workflow should follow the organization's approved AIGO procedure.

***

## 36. Authority Verification

Before approval becomes effective, the organization should verify:

* authority is current;
* delegation is valid;
* decision scope is covered;
* required reviews are complete;
* conflicts have been addressed; and
* segregation requirements are satisfied.

This is particularly important for high-risk or high-impact decisions.

***

## 37. Approval Revocation

An approval may need to be revoked where:

* conditions are not met;
* material information was incorrect;
* risk becomes unacceptable;
* serious incident occurs;
* control failure occurs;
* intended purpose changes;
* regulatory requirements change;
* approval expires; or
* another defined revocation trigger occurs.

Revocation should be formally documented and traceable.

***

## 38. Supersession

A later approval may supersede an earlier approval.

The approval record should preserve:

* predecessor approval identifier;
* successor approval identifier;
* reason for supersession;
* effective date; and
* historical record.

Historical approval records should not be silently overwritten.

***

## 39. Approval and Monitoring

Approvals may establish monitoring requirements.

For example:

```text theme={null}
APPROVAL
   ↓
Enhanced Monitoring Requirement
   ↓
MONITORING
   ↓
Threshold Breach
   ↓
Review / Escalation
```

The Monitoring Schema remains authoritative for detailed monitoring plans and results.

***

## 40. Approval and Assurance

An approval may rely on assurance evidence.

Assurance may:

* precede approval;
* support a conditional approval;
* verify completion of approval conditions; or
* review the effectiveness of an approval process.

Assurance remains independent from the approval decision where independence is required.

***

## 41. Approval and Management Review

Significant approvals may be reviewed as part of management review.

Management review may examine:

* approval trends;
* approval exceptions;
* overdue conditions;
* rejected requests;
* repeated conditional approvals;
* approval authority;
* governance effectiveness; and
* systemic approval issues.

Management Review records remain authoritative for resulting management decisions.

***

## 42. Approval Conditions and Evidence

Each material condition should be traceable to evidence demonstrating completion.

Recommended relationship:

```text theme={null}
Approval Condition
       ↓
Condition Owner
       ↓
Implementation
       ↓
Evidence
       ↓
Verification
       ↓
Condition Closure
```

Conditions should not be marked complete solely on the basis of an assertion where objective evidence is required.

***

## 43. Approval Reporting

Approval records may be aggregated into governance reporting.

Useful metrics include:

| Metric                      | Purpose                            |
| --------------------------- | ---------------------------------- |
| Approvals issued            | Governance activity                |
| Approvals by type           | Decision distribution              |
| Conditional approvals       | Outstanding governance constraints |
| Rejected approvals          | Risk or readiness issues           |
| Deferred approvals          | Governance backlog                 |
| Expired approvals           | Governance control                 |
| Overdue approval conditions | Follow-up effectiveness            |
| Revoked approvals           | Governance response                |
| Emergency approvals         | Emergency governance usage         |

Metrics should have controlled definitions and owners.

***

## 44. Approval Validation Requirements

A valid Approval record should satisfy:

### Structural Validation

The JSON document must validate against:

`05-AIGO-Approval-Schema-v0.1.json`

### Authority Validation

The authority making the decision must be authorized for the decision scope.

### Subject Validation

The object being approved must be identifiable.

### Assessment Validation

Required assessments must be completed and referenced.

### Evidence Validation

Material decisions should have sufficient supporting evidence.

### Condition Validation

Conditions must have identifiable owners and requirements where applicable.

### Segregation Validation

Required segregation of duties must be satisfied or an authorized exception documented.

### Effective-Date Validation

The approval must not be treated as effective before its authorized effective date.

### Expiry Validation

Time-limited approvals must be monitored for expiry.

### Traceability Validation

The decision must remain traceable to the relevant system, risk, control, assessment, evidence, and implementation records.

***

## 45. Schema Limitations

JSON Schema cannot independently determine:

* whether an approver actually possesses authority;
* whether an assessment is substantively adequate;
* whether the evidence supports the decision;
* whether the decision is reasonable;
* whether conditions are sufficient;
* whether a delegation is valid;
* whether the decision complies with external law; or
* whether the organization has correctly exercised its governance authority.

Those matters require governance procedures, organizational controls, evidence, and assurance.

***

## 46. Relationship to Templates

The Approval Schema corresponds primarily to:

`guidance/03-templates/07-AIGO-AI-Approval-Template-v0.1.md`

It also supports approval decisions generated by:

* governance;
* risk acceptance;
* change management;
* incident management;
* assurance;
* retirement; and
* exception-management processes.

The Markdown template provides the human-readable approval record.

The JSON schema provides the machine-readable structure.

***

## 47. Relationship to Procedures

The schema should be used with:

`guidance/02-procedures/06-AIGO-AI-Approval-Procedure-v0.1.md`

and, where applicable:

* AI governance;
* AI system registration;
* classification;
* risk assessment;
* control assessment;
* change management;
* incident management;
* risk acceptance;
* assurance;
* retirement; and
* continuous improvement procedures.

The procedures define how approval decisions are requested, reviewed, authorized, communicated, implemented, monitored, and closed.

***

## 48. Framework Traceability

| AIGO Component          | Relationship                                        |
| ----------------------- | --------------------------------------------------- |
| Governance Domains      | Defines approval authority and governance decisions |
| Governance Roles        | Defines approval responsibilities and delegation    |
| AI Governance Lifecycle | Defines lifecycle gates requiring authorization     |
| AI Risk Management      | Provides risk basis for approval                    |
| AI Governance Controls  | Provides control readiness information              |
| AI Governance Maturity  | Provides governance capability context              |
| AI System Profiles      | Identifies approval subject                         |
| Implementation Guidance | Defines approval implementation expectations        |
| Operational Procedures  | Defines approval workflow and authority             |
| Templates               | Provides human-readable approval records            |
| External Mappings       | Provides regulatory and standards decision context  |

***

## 49. Approval Traceability Model

The recommended traceability chain is:

```text theme={null}
Governance Requirement
        ↓
Approval Trigger
        ↓
Subject
        ↓
Assessment
        ↓
Risk / Control Review
        ↓
Evidence
        ↓
Required Reviews
        ↓
Authority Verification
        ↓
Decision
        ↓
Conditions
        ↓
Implementation
        ↓
Verification
        ↓
Monitoring
```

This provides an auditable path from the reason an approval was required through to the resulting operational state.

***

## 50. Example Record

A conceptual Approval record may look like:

```json theme={null}
{
  "id": "APPROVAL-001",
  "objectType": "APPROVAL",
  "objectVersion": "1.0",
  "schemaVersion": "0.1",
  "status": "APPROVED_WITH_CONDITIONS",
  "approvalType": "DEPLOYMENT",
  "aiSystemId": "AI-SYS-001",
  "decision": "APPROVED_WITH_CONDITIONS",
  "decisionDate": "2026-08-14",
  "effectiveDate": "2026-08-20",
  "authority": {
    "role": "AI Governance Committee"
  },
  "assessmentIds": [
    "ASSESS-001",
    "ASSESS-002",
    "ASSESS-003"
  ],
  "riskIds": [
    "RISK-001",
    "RISK-002"
  ],
  "controlIds": [
    "CTRL-001",
    "CTRL-002"
  ],
  "conditions": [
    {
      "description": "Enhanced production monitoring must be active before deployment."
    }
  ],
  "evidenceIds": [
    "EVID-040",
    "EVID-041"
  ]
}
```

The actual record must conform to the authoritative JSON schema.

***

## 51. Schema Registry Relationship

This schema is registered in:

`schemas/00-AIGO-Schema-Registry-v0.1.json`

The registry should maintain:

* schema identifier;
* object type;
* version;
* controlled path;
* status;
* dependencies;
* referenced schemas;
* owner;
* documentation path; and
* traceability metadata.

***

## 52. Change and Version Management

Changes to the Approval Schema should be managed through AIGO change management.

Potential impacts should be assessed against:

* approval workflows;
* delegation rules;
* existing approval records;
* lifecycle gates;
* templates;
* procedures;
* risk acceptance;
* evidence;
* assurance;
* reporting;
* external mappings; and
* validation tooling.

Material schema changes should be documented and approved before release.

Breaking changes should include migration guidance where appropriate.

***

## 53. Future Extensions

Future releases may provide additional support for:

* digital signatures;
* cryptographic approval evidence;
* multi-stage approval workflows;
* quorum requirements;
* voting models;
* conditional approval automation;
* approval expiry automation;
* delegated-authority validation;
* policy-as-code decision rules;
* approval provenance; and
* machine-readable decision matrices.

Such extensions should preserve the distinction between structural representation and actual organizational authority.

***

## 54. Document Control

| Field               | Value                               |
| ------------------- | ----------------------------------- |
| Document            | AIGO Approval Schema Documentation  |
| Version             | 0.1                                 |
| Status              | Draft                               |
| Document Identifier | `AIGO-SCHEMA-DOC-005`               |
| Document Type       | Schema Documentation                |
| Schema              | `05-AIGO-Approval-Schema-v0.1.json` |
| Owner               |                                     |
| Technical Reviewer  |                                     |
| Governance Reviewer |                                     |
| Approved By         |                                     |
| Effective Date      |                                     |
| Next Review Date    |                                     |

***

## 55. Document Status

**Document:** AIGO — Approval Schema Documentation

**Version:** 0.1

**Status:** Draft

**Working Name:** AIGO

**Full Name:** AI Governance Operating Framework

**Document Identifier:** `AIGO-SCHEMA-DOC-005`

**Document Type:** Schema Documentation

This document provides the human-readable interpretation, governance context, validation expectations, and traceability guidance for the AIGO Approval Schema.

End of Document