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

# 03 AIGO Control Schema Documentation v0.1

# AIGO — Control Schema Documentation

## 1. Document Purpose

This document describes the machine-readable AIGO Control Schema.

The schema provides the structured representation of AI governance and risk controls under the AIGO AI Governance Operating Framework.

It is intended to support:

* control identification;
* control definition;
* control objectives;
* control ownership;
* control applicability;
* control implementation;
* preventive, detective, corrective, and compensating controls;
* control operation;
* control evidence;
* control assessment;
* control effectiveness;
* control exceptions;
* control monitoring;
* control remediation;
* control assurance; and
* control lifecycle management.

The JSON schema defines structural requirements.

This documentation explains the intended meaning and governance use of those structures.

***

## 2. Schema Information

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

***

## 3. Scope

The Control Schema applies to controls established to govern AI systems, AI-related risks, governance processes, lifecycle activities, supporting technology, data, people, suppliers, and associated operational environments.

The schema may represent controls addressing:

* governance;
* accountability;
* risk management;
* classification;
* human oversight;
* safety;
* security;
* privacy;
* fairness;
* transparency;
* explainability;
* data quality;
* model performance;
* reliability;
* monitoring;
* incident management;
* change management;
* assurance;
* documentation;
* evidence;
* third-party governance; and
* retirement.

The organization's approved control framework determines which controls are mandatory and how control objectives are defined.

***

## 4. Object Model

The primary object represented by this schema is:

```text id="0pr6m2" theme={null}
CONTROL
```

A Control record represents a defined mechanism intended to prevent, detect, reduce, correct, or otherwise manage a governance or AI risk.

The Control record should remain distinct from:

* the risk it addresses;
* the assessment of the control;
* evidence demonstrating operation;
* an approval decision;
* a monitoring record;
* an incident record;
* a change record; and
* an assurance record.

These relationships should normally be represented through stable identifiers.

***

## 5. Core Identity

A Control record should contain stable identity information.

Key fields include:

* `id`;
* `objectType`;
* `objectVersion`;
* `schemaVersion`;
* control name;
* control objective;
* control owner;
* control status; and
* control type.

Example:

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

The control identifier should remain stable while the control is operationally maintained.

A materially different control should normally receive a new identifier rather than silently changing the meaning of an existing control.

***

## 6. Control Purpose

The control should clearly state what it is intended to achieve.

A control objective may describe the desired governance or risk outcome.

Examples include:

* ensure AI systems are formally registered;
* ensure material risks are assessed before deployment;
* ensure appropriate human oversight is maintained;
* ensure monitoring thresholds are defined;
* ensure material changes receive appropriate review;
* ensure incidents are escalated;
* ensure evidence is retained; or
* ensure retired AI systems are formally removed from operational use.

The objective should be sufficiently specific to support assessment of effectiveness.

***

## 7. Control Statement

The control statement should describe the required action or condition.

A well-defined control should allow a reviewer to determine:

* what must happen;
* who is responsible;
* when or how frequently it must happen;
* under what conditions;
* what evidence should exist; and
* what happens when the control fails.

The control statement should avoid vague requirements that cannot be objectively evaluated.

***

## 8. Control Types

Controls may be classified according to their primary function.

Typical categories include:

```text id="3zgz3u" theme={null}
PREVENTIVE
DETECTIVE
CORRECTIVE
DIRECTIVE
COMPENSATING
RECOVERY
MONITORING
GOVERNANCE
```

The authoritative enumeration is defined in the JSON schema.

A control may also have multiple characteristics where the schema permits.

***

## 9. Control Domain

Controls may be categorized according to the governance area they support.

Examples include:

* governance;
* risk;
* lifecycle;
* security;
* privacy;
* fairness;
* safety;
* reliability;
* transparency;
* human oversight;
* data;
* model;
* monitoring;
* incident;
* change;
* assurance;
* evidence; and
* third-party governance.

A controlled taxonomy should be maintained by the organization's control framework.

***

## 10. Risk Relationship

Controls are generally established because one or more risks require management.

A control may reference one or more risk identifiers.

Example:

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

The referenced Risk records remain authoritative for the risk description, evaluation, treatment, and residual risk.

A control may address:

* one risk;
* several related risks;
* an enterprise-level risk; or
* a governance requirement that indirectly reduces multiple risks.

***

## 11. AI System Relationship

A control may apply to:

* one AI system;
* multiple AI systems;
* an AI-system class;
* an enterprise AI governance process; or
* a shared technical or operational environment.

Where a control applies to a specific AI system, the Control record should reference the relevant AI System identifier.

***

## 12. Control Owner

Each active control should have an accountable control owner.

The control owner is responsible for ensuring that:

* the control is appropriately designed;
* responsibility is assigned;
* the control is implemented;
* operation is monitored;
* evidence is retained;
* deficiencies are addressed; and
* the control remains appropriate.

Ownership does not necessarily mean the individual personally performs every control activity.

Execution may be delegated while accountability remains assigned.

***

## 13. Control Performer

Where the schema supports separate operational responsibility, the record should distinguish the control owner from the person or function performing the control.

This supports:

* segregation of duties;
* operational clarity;
* independence;
* competence management; and
* effective assurance.

The performer should have sufficient authority and competence to execute the control.

***

## 14. Control Authority

The control should identify its governance basis where appropriate.

This may include:

* AIGO framework requirement;
* internal policy;
* procedure;
* risk treatment;
* legal requirement;
* regulatory requirement;
* contractual requirement;
* assurance recommendation; or
* management decision.

A control should have a clear reason for existing.

***

## 15. Applicability

Not every control applies to every AI system.

Applicability may depend on:

* AI classification;
* risk level;
* system purpose;
* data sensitivity;
* affected persons;
* jurisdiction;
* lifecycle stage;
* deployment environment;
* technology;
* regulatory obligations; or
* organizational policy.

The Control record should identify applicability criteria where material.

***

## 16. Control Implementation

Control implementation should identify whether the control is:

* planned;
* partially implemented;
* implemented;
* temporarily unavailable;
* suspended;
* under remediation; or
* retired.

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

Implementation information should identify the implementation owner and, where appropriate, target completion date.

***

## 17. Control Design

Control design concerns whether the control, if operated as intended, is capable of achieving its stated objective.

Design considerations may include:

* scope;
* frequency;
* responsibility;
* authority;
* trigger conditions;
* dependencies;
* required inputs;
* expected outputs;
* escalation;
* evidence;
* exceptions; and
* compensating controls.

A control can be operationally implemented but poorly designed.

Therefore, design effectiveness should be assessed separately from operating effectiveness where appropriate.

***

## 18. Control Operating Frequency

The control may operate:

* continuously;
* in real time;
* daily;
* weekly;
* monthly;
* quarterly;
* annually;
* at lifecycle gates;
* on material changes;
* on specified triggers; or
* on another defined schedule.

Frequency should be proportionate to the risk being managed.

***

## 19. Automation Level

Controls may be:

* manual;
* automated;
* semi-automated;
* human-reviewed;
* system-enforced; or
* hybrid.

The record should distinguish the mechanism used to operate the control where this is relevant to assurance.

Automation does not inherently make a control more effective.

Automated controls should still be monitored for correct configuration and operation.

***

## 20. Control Dependencies

Controls may depend on:

* data;
* applications;
* infrastructure;
* identity systems;
* monitoring;
* personnel;
* procedures;
* suppliers;
* other controls; or
* governance decisions.

Dependencies should be identified where failure of the dependency could compromise the control.

***

## 21. Control Evidence

Controls should produce or reference evidence sufficient to demonstrate operation.

Examples include:

* system logs;
* approvals;
* assessment results;
* review records;
* configuration records;
* monitoring reports;
* test results;
* training records;
* incident records;
* meeting records; and
* other controlled evidence.

Evidence should be independently represented through the Evidence Schema when appropriate.

***

## 22. Evidence Requirements

For each material control, the organization should determine:

* what evidence is required;
* where it is stored;
* who owns it;
* how long it is retained;
* how integrity is protected;
* how evidence quality is assessed; and
* who may access it.

Evidence requirements should be proportionate to:

* control criticality;
* risk;
* legal requirements;
* assurance needs; and
* record-retention requirements.

***

## 23. Control Assessment

Controls should be assessed periodically and when triggering conditions occur.

Control assessment may evaluate:

* design effectiveness;
* implementation;
* operating effectiveness;
* evidence sufficiency;
* consistency;
* timeliness;
* sustainability;
* exceptions; and
* overall effectiveness.

Assessment results should be maintained in the Assessment Schema where a formal assessment record is required.

***

## 24. Control Effectiveness

The control record may reference the current control rating.

The organization should distinguish, where applicable, between:

### Design Effectiveness

Whether the control is appropriately designed to address its intended objective.

### Implementation Effectiveness

Whether the control has actually been implemented as specified.

### Operating Effectiveness

Whether the control operates consistently and achieves its intended result.

### Overall Effectiveness

The organization-level conclusion regarding control effectiveness.

A control should not be considered effective solely because it exists in a control catalogue.

***

## 25. Control Deficiency

A control deficiency may arise when:

* the control does not exist when required;
* the control is poorly designed;
* the control is not implemented;
* the control is not operating;
* evidence is inadequate;
* the control is bypassed;
* the control is outdated;
* dependencies have failed; or
* the control does not adequately reduce the relevant risk.

Deficiencies should be recorded and tracked through the applicable assessment and improvement processes.

***

## 26. Control Exceptions

An exception represents an approved or requested departure from a control requirement.

Exceptions should identify:

* affected control;
* reason;
* risk;
* compensating controls;
* owner;
* approval authority;
* duration;
* review date; and
* status.

Exceptions should be time-bounded where practical.

A permanent exception should generally trigger reassessment of whether the underlying control requirement remains appropriate.

***

## 27. Compensating Controls

A compensating control may be used where the primary control cannot be implemented or is temporarily unavailable.

A compensating control should:

* address the same or relevant risk;
* be explicitly documented;
* have an accountable owner;
* be assessed for effectiveness;
* have an approved duration; and
* be monitored.

Compensating controls should not be used to avoid implementing necessary controls without governance justification.

***

## 28. Control Monitoring

Controls may be monitored through:

* control performance indicators;
* compliance checks;
* automated telemetry;
* review results;
* exceptions;
* incidents;
* assurance findings;
* sampling;
* testing; and
* management review.

Monitoring should identify deviations that may require:

* corrective action;
* increased monitoring;
* control reassessment;
* risk reassessment;
* incident escalation; or
* change management.

***

## 29. Control Thresholds

Where a control has measurable thresholds, the control record may identify:

* normal operating range;
* warning threshold;
* escalation threshold;
* critical threshold; and
* associated response.

Thresholds should have clear definitions and owners.

Thresholds should be reviewed when:

* risk changes;
* control effectiveness changes;
* system behavior changes;
* incidents occur;
* material changes are implemented; or
* external requirements change.

***

## 30. Control Failure and Incident Relationship

A control failure may contribute to an incident.

The Control record should support relationships to relevant incident records where required.

Example:

```json id="mtu3ua" theme={null}
{
  "id": "CTRL-002",
  "incidentIds": [
    "INC-005"
  ]
}
```

Incident records remain authoritative for incident investigation and remediation.

Control records should capture the resulting control implications.

***

## 31. Control and Change Management

Controls may be affected by changes to:

* AI models;
* data;
* system architecture;
* business processes;
* governance procedures;
* suppliers;
* regulatory requirements;
* monitoring;
* human oversight; or
* intended purpose.

Material control changes should be assessed through the AIGO Change process.

Changes may require:

* control reassessment;
* testing;
* approval;
* evidence updates;
* monitoring changes; and
* assurance.

***

## 32. Control and Assurance

Assurance activities may examine:

* control design;
* control implementation;
* control operation;
* evidence;
* exceptions;
* control dependencies;
* management response; and
* effectiveness.

The Assurance Schema provides the formal assurance structure.

A control may reference assurance records supporting its effectiveness conclusion.

***

## 33. Control and Risk Treatment

Controls should remain traceable to the risk treatment that justified them.

The traceability chain may be:

```text id="oecwac" theme={null}
Risk
  ↓
Risk Treatment
  ↓
Control
  ↓
Control Operation
  ↓
Evidence
  ↓
Control Assessment
  ↓
Residual Risk
```

This provides visibility into whether a control is actually contributing to the organization's intended risk outcome.

***

## 34. Human Oversight Controls

Some controls may specifically govern human oversight.

Examples include:

* mandatory human approval;
* human review before action;
* override capability;
* escalation;
* periodic review;
* competence verification;
* decision challenge;
* output review; and
* prohibition of uncontrolled automation.

Such controls should clearly define the required human responsibility and authority.

***

## 35. Data Controls

AI governance may require controls over:

* data quality;
* data provenance;
* data access;
* data preparation;
* data transformation;
* data validation;
* data drift;
* data retention;
* sensitive data handling; and
* data deletion.

The Control record should identify the control objective and applicable data scope.

Detailed data records may be held in technical or data governance systems.

***

## 36. Model Controls

Model-related controls may address:

* model validation;
* model performance;
* model drift;
* model versioning;
* model approval;
* retraining;
* model change;
* model inventory;
* rollback;
* robustness; and
* model monitoring.

Controls should be proportionate to system classification and risk.

***

## 37. Security Controls

Security controls may address:

* access management;
* authentication;
* authorization;
* secrets management;
* vulnerability management;
* secure deployment;
* logging;
* monitoring;
* attack detection;
* incident response;
* supplier security; and
* resilience.

Where an external security framework is used, traceability should be maintained through the appropriate mapping repository.

***

## 38. Privacy Controls

Privacy controls may address:

* lawful data use;
* data minimization;
* access restrictions;
* retention;
* deletion;
* privacy assessment;
* sensitive data handling;
* purpose limitation;
* transparency;
* rights handling; and
* privacy incident response.

The control record should not substitute for the organization's detailed privacy compliance records.

***

## 39. Fairness and Non-Discrimination Controls

Where applicable, controls may address:

* fairness assessment;
* bias testing;
* affected-group analysis;
* mitigation;
* monitoring;
* human review;
* contestability;
* escalation; and
* corrective action.

Controls should reflect the organization's applicable fairness methodology and regulatory obligations.

***

## 40. Safety and Reliability Controls

Controls may address:

* fail-safe operation;
* system reliability;
* resilience;
* performance thresholds;
* fallback processes;
* incident response;
* human intervention;
* safe shutdown;
* recovery; and
* post-incident validation.

Safety-critical controls should normally receive enhanced governance attention.

***

## 41. Third-Party Controls

Third-party AI may require controls addressing:

* due diligence;
* supplier risk;
* contractual requirements;
* data handling;
* security;
* privacy;
* assurance;
* incident notification;
* material change notification;
* service continuity; and
* termination.

Third-party control ownership should remain explicit even where the underlying activity is performed by a supplier.

***

## 42. Control Lifecycle

The control lifecycle may be represented as:

```text id="8i7xup" theme={null}
Control Need
    ↓
Design
    ↓
Approval
    ↓
Implementation
    ↓
Operation
    ↓
Monitoring
    ↓
Assessment
    ↓
Remediation / Improvement
    ↓
Reassessment
    ↓
Modification / Retirement
```

The lifecycle state itself does not authorize implementation or retirement.

The relevant procedures and authorities remain controlling.

***

## 43. Control Retirement

A control may be retired when:

* the underlying risk no longer exists;
* the AI system is retired;
* the control is replaced;
* the control is incorporated into another control;
* the control is no longer necessary; or
* an approved governance decision authorizes retirement.

Retirement should include consideration of:

* residual risk;
* replacement controls;
* evidence retention;
* monitoring updates;
* documentation updates; and
* related assurance.

A control should not be silently deleted from the historical record.

***

## 44. Control Reporting

Control records may be aggregated into governance reports.

Useful reporting may include:

* active controls;
* controls by domain;
* controls by risk;
* critical controls;
* implementation status;
* effectiveness ratings;
* open deficiencies;
* overdue remediation;
* exceptions;
* compensating controls;
* failed controls;
* repeated failures; and
* assurance findings.

Reports should distinguish source control records from reporting views.

***

## 45. Control Metrics

Organizations may establish metrics such as:

| Metric                         | Purpose                |
| ------------------------------ | ---------------------- |
| Control implementation rate    | Implementation status  |
| Control effectiveness rate     | Effectiveness overview |
| Critical control failure count | Critical exposure      |
| Overdue control remediation    | Deficiency management  |
| Open control exceptions        | Exception exposure     |
| Compensating control count     | Control resilience     |
| Evidence completeness          | Audit readiness        |
| Assessment completion          | Control governance     |
| Repeat deficiency rate         | Continual improvement  |

Metrics should have defined owners and calculation methods.

***

## 46. Validation Requirements

A valid Control record should satisfy:

### Structural Validation

The JSON document must validate against:

`03-AIGO-Control-Schema-v0.1.json`

### Reference Validation

Referenced risks, AI systems, assessments, evidence, monitoring, incidents, changes, assurance, and approvals should resolve where required.

### Ownership Validation

Active controls should have accountable ownership.

### Applicability Validation

The control should have a defined applicability basis where applicability is conditional.

### Evidence Validation

Material controls should have appropriate evidence requirements.

### Assessment Validation

Controls requiring assessment should have valid assessment records.

### Exception Validation

Exceptions should have appropriate authority, duration, and monitoring.

### Traceability Validation

Controls should remain traceable to their objectives, risks, requirements, assessments, and evidence.

***

## 47. Schema Limitations

JSON Schema cannot independently determine whether:

* a control is appropriately designed;
* a control actually operates;
* evidence is genuine;
* evidence is sufficient;
* an owner has adequate authority;
* a control reduces risk;
* a compensating control is equivalent;
* a deficiency is material; or
* assurance conclusions are justified.

These matters require governance judgment, operating evidence, testing, and assurance.

***

## 48. Relationship to Templates

The Control Schema corresponds primarily to:

`guidance/03-templates/06-AIGO-AI-Control-Assessment-Template-v0.1.md`

It may also support control-related records generated through:

* governance templates;
* monitoring templates;
* incident templates;
* change-management templates;
* assurance templates; and
* evidence templates.

The Markdown templates support human operation.

The JSON schema provides the machine-readable structure.

***

## 49. Relationship to Procedures

The schema should be used together with:

`guidance/02-procedures/05-AIGO-AI-Control-Assessment-Procedure-v0.1.md`

and, where applicable:

* governance;
* risk assessment;
* classification;
* approval;
* monitoring;
* incident management;
* change management;
* assurance;
* risk acceptance;
* continuous improvement; and
* retirement procedures.

Procedures define how controls are designed, implemented, assessed, remediated, monitored, and retired.

***

## 50. Framework Traceability

| AIGO Component          | Relationship                                             |
| ----------------------- | -------------------------------------------------------- |
| Governance Domains      | Defines control areas and accountability                 |
| Governance Roles        | Defines control ownership and authority                  |
| AI Governance Lifecycle | Determines where controls apply                          |
| AI Risk Management      | Provides risk-treatment relationships                    |
| AI Governance Controls  | Primary conceptual source for the schema                 |
| AI Governance Maturity  | Supports control capability and effectiveness assessment |
| AI System Profiles      | Provides AI-system applicability context                 |
| Implementation Guidance | Defines implementation expectations                      |
| Operational Procedures  | Defines control assessment and operation                 |
| Templates               | Provides human-readable control records                  |
| External Mappings       | Provides standards and regulatory traceability           |

***

## 51. Control Traceability Model

The recommended traceability model is:

```text id="3y8i14" theme={null}
Governance Requirement
        ↓
Risk / Objective
        ↓
Control
        ↓
Control Owner
        ↓
Implementation
        ↓
Evidence
        ↓
Assessment
        ↓
Effectiveness
        ↓
Monitoring / Assurance
        ↓
Remediation / Improvement
```

Additional relationships may connect the control to:

```text id="1wc5kl" theme={null}
Incident
Change
Approval
Risk Acceptance
Management Review
Retirement
```

***

## 52. Example Record

A conceptual Control record may look like:

```json id="9z76w3" theme={null}
{
  "id": "CTRL-001",
  "objectType": "CONTROL",
  "objectVersion": "1.0",
  "schemaVersion": "0.1",
  "status": "ACTIVE",
  "name": "AI System Pre-Deployment Approval",
  "controlType": "PREVENTIVE",
  "objective": "Prevent deployment of an AI system before required governance approval is completed.",
  "riskIds": [
    "RISK-001",
    "RISK-003"
  ],
  "owner": {
    "role": "AI Governance Owner"
  },
  "frequency": "PER_DEPLOYMENT",
  "evidenceIds": [
    "EVID-020"
  ],
  "assessmentIds": [
    "ASSESS-010"
  ]
}
```

The actual record must conform to the authoritative JSON schema.

***

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

***

## 54. Change and Version Management

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

Potential impacts should be assessed against:

* existing controls;
* risk treatment;
* control assessments;
* evidence;
* monitoring;
* assurance;
* templates;
* procedures;
* external mappings; and
* validation tooling.

Breaking structural or semantic changes should include migration guidance where appropriate.

***

## 55. Future Extensions

Future versions may expand support for:

* machine-enforced policy controls;
* continuous controls monitoring;
* automated control testing;
* control maturity;
* control dependency graphs;
* control effectiveness scoring;
* automated evidence collection;
* policy-as-code;
* control inheritance;
* cross-system control libraries; and
* automated regulatory control mapping.

Extensions should preserve stable control identity and traceability.

***

## 56. Document Control

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

***

## 57. Document Status

**Document:** AIGO — Control Schema Documentation

**Version:** 0.1

**Status:** Draft

**Working Name:** AIGO

**Full Name:** AI Governance Operating Framework

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

**Document Type:** Schema Documentation

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

End of Document