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:

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:

{
  "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:

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:

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:

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:

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:

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:

{
  "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:

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:

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:

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:

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:

{
  "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

​AIGO — Approval Schema Documentation

​1. Document Purpose

​2. Schema Information

​3. Scope

​4. Object Model

​5. Core Identity

​6. Approval Purpose

​7. Approval Types

​8. Approval Subject

​9. Decision Authority

​10. Authority Basis

​11. Segregation of Duties

​12. Decision Values

​13. Approval Status

​14. Approval Conditions

​15. Conditional Approval

​16. Effective Date

​17. Expiry

​18. Preconditions

​19. Supporting Assessments

​20. Supporting Risk Records

​21. Supporting Control Records

​22. Supporting Evidence

​23. Approval Rationale

​24. Decision Factors

​25. Risk Acceptance Approval

​26. Deployment Approval

​27. Continued Operation Approval

​28. Material Change Approval

​29. Emergency Approval

​30. Restricted Operation

​31. Resumption Approval

​32. Retirement Approval

​33. Exception Approval

​34. Approval Review

​35. Approval Workflow

​36. Authority Verification

​37. Approval Revocation

​38. Supersession

​39. Approval and Monitoring

​40. Approval and Assurance

​41. Approval and Management Review

​42. Approval Conditions and Evidence

​43. Approval Reporting

​44. Approval Validation Requirements

​Structural Validation

​Authority Validation

​Subject Validation

​Assessment Validation

​Evidence Validation

​Condition Validation

​Segregation Validation

​Effective-Date Validation

​Expiry Validation

​Traceability Validation

​45. Schema Limitations

​46. Relationship to Templates

​47. Relationship to Procedures

​48. Framework Traceability

​49. Approval Traceability Model

​50. Example Record

​51. Schema Registry Relationship

​52. Change and Version Management

​53. Future Extensions

​54. Document Control

​55. Document Status