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:

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:

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

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:

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

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

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:

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:

Governance Requirement
        ↓
Risk / Objective
        ↓
Control
        ↓
Control Owner
        ↓
Implementation
        ↓
Evidence
        ↓
Assessment
        ↓
Effectiveness
        ↓
Monitoring / Assurance
        ↓
Remediation / Improvement

Additional relationships may connect the control to:

Incident
Change
Approval
Risk Acceptance
Management Review
Retirement

52. Example Record

A conceptual Control record may look like:

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

​AIGO — Control Schema Documentation

​1. Document Purpose

​2. Schema Information

​3. Scope

​4. Object Model

​5. Core Identity

​6. Control Purpose

​7. Control Statement

​8. Control Types

​9. Control Domain

​10. Risk Relationship

​11. AI System Relationship

​12. Control Owner

​13. Control Performer

​14. Control Authority

​15. Applicability

​16. Control Implementation

​17. Control Design

​18. Control Operating Frequency

​19. Automation Level

​20. Control Dependencies

​21. Control Evidence

​22. Evidence Requirements

​23. Control Assessment

​24. Control Effectiveness

​Design Effectiveness

​Implementation Effectiveness

​Operating Effectiveness

​Overall Effectiveness

​25. Control Deficiency

​26. Control Exceptions

​27. Compensating Controls

​28. Control Monitoring

​29. Control Thresholds

​30. Control Failure and Incident Relationship

​31. Control and Change Management

​32. Control and Assurance

​33. Control and Risk Treatment

​34. Human Oversight Controls

​35. Data Controls

​36. Model Controls

​37. Security Controls

​38. Privacy Controls

​39. Fairness and Non-Discrimination Controls

​40. Safety and Reliability Controls

​41. Third-Party Controls

​42. Control Lifecycle

​43. Control Retirement

​44. Control Reporting

​45. Control Metrics

​46. Validation Requirements

​Structural Validation

​Reference Validation

​Ownership Validation

​Applicability Validation

​Evidence Validation

​Assessment Validation

​Exception Validation

​Traceability Validation

​47. Schema Limitations

​48. Relationship to Templates

​49. Relationship to Procedures

​50. Framework Traceability

​51. Control Traceability Model

​52. Example Record

​53. Schema Registry Relationship

​54. Change and Version Management

​55. Future Extensions

​56. Document Control

​57. Document Status