title: “Control Schema” description: “Machine-readable representation of AIGO governance controls and their relationships.”
Control Schema
The Control Schema defines the machine-readable representation of governance controls within the AIGO Framework. Controls translate governance expectations and risk-treatment decisions into defined requirements, activities, safeguards, or mechanisms that can be implemented, assessed, evidenced, monitored, and assured. The schema should be used together with the AIGO control framework, risk-management model, assessment model, evidence model, and implementation procedures.Purpose
The Control Schema supports structured representation of: * control identity * control purpose * control description * ownership * applicability * implementation * status * relationships to risks * relationships to requirements * assessment * evidence * monitoring * assurance * remediation * improvement * governance traceability The schema provides the structure for control records. It does not itself establish that a control is effective or that an organization has satisfied a particular external requirement.Controls within the AIGO governance model
AIGO controls should be understood as part of a connected governance system rather than as isolated records. A representative relationship is: Governance Expectation → Risk → Control → Evidence → Assessment → Assurance A control may address: * one or more risks * one or more governance expectations * one or more applicable requirements * one or more system characteristics Likewise, a risk may require multiple controls. For example:What a control record represents
A control record represents a defined governance control that an organization expects to implement or operate. Depending on the canonical schema and implementation, information may include concepts such as: * control identifier * control name * control objective * control description * control owner * applicability * implementation status * related risks * related requirements * evidence requirements * assessment information * monitoring information * assurance information * remediation information * lifecycle status The canonical JSON Schema is the authoritative source for the actual fields, types, required properties, and constraints.Control objectives
A control should have a clear governance purpose. A control objective describes the outcome the control is intended to support. For example, a control may be intended to: * establish accountability * protect sensitive information * reduce a defined risk * ensure appropriate human oversight * maintain required documentation * detect governance failures * support transparency * maintain monitoring * ensure appropriate approval Control objectives help organizations determine whether the control is relevant and whether the implemented mechanism addresses its intended purpose.Control applicability
Not every control necessarily applies to every AI system. Applicability can depend on: * AI system classification * intended use * risk profile * deployment context * organizational policy * applicable legal or regulatory requirements * contractual obligations * system characteristics * governance decisions An organization should document the basis for significant applicability decisions. An applicable control should normally have a clear implementation or remediation status. A control determined to be not applicable should have sufficient justification where the governance model requires it.Control implementation
Control implementation converts a defined control into an operational mechanism. Implementation may involve: * policies * procedures * technical safeguards * system configurations * approval workflows * monitoring mechanisms * training * documentation * operational practices * contractual mechanisms The implementation should be appropriate to the control objective and the risk it addresses.Control ownership
Controls should have appropriate ownership and accountability. Ownership may distinguish between: * control owner * implementation owner * operational owner * evidence owner * assessment responsibility * assurance responsibility The precise allocation depends on the organization’s governance operating model. Clear ownership helps ensure that control deficiencies result in an identifiable governance action rather than remaining unresolved.Relationship to risks
Controls should be connected to the risks they are intended to address. A representative relationship is: Risk → Control This enables an organization to determine: * which controls address a risk * whether all significant risks have treatment * whether controls are implemented * whether controls are effective * whether residual risk remains The relationship also supports control coverage and traceability analysis. See Risk Schema and Risk Assessment.Relationship to governance requirements
Controls may also be related to governance expectations or applicable external requirements. A simplified model is: Requirement → Control → Evidence This allows an organization to identify which controls support a particular requirement and what evidence demonstrates implementation. External mappings should remain distinguishable from the canonical AIGO control definition. A mapping to an external requirement does not automatically establish legal or regulatory conformity. See the Mappings section for framework-specific relationships.Control assessment
Control assessment determines whether a control has been appropriately implemented and is operating as intended. Assessment may consider: * applicability * implementation status * design adequacy * operating effectiveness * evidence quality * deficiencies * remediation * assessment scope * assessment conclusions A simplified relationship is: Control → Evidence → Assessment See Control Assessment.Evidence
Controls should be supported by appropriate evidence where evidence is required. Evidence can include: * policies * procedures * system configurations * test results * logs * monitoring records * approvals * training records * assessment results * assurance reports * incident records Evidence should demonstrate the relevant implementation or operation of the control rather than merely assert that the control exists. See Evidence Schema.Control effectiveness
Implementation and effectiveness are related but distinct. A control can be: * defined but not implemented * implemented but not operating effectively * operating effectively * partially effective * ineffective * not applicable * awaiting sufficient evidence The actual status vocabulary should follow the applicable AIGO control and assessment definitions. Control effectiveness should be determined through the appropriate assessment process and supporting evidence.Control lifecycle
Controls can be managed through a lifecycle:Control monitoring
Monitoring can provide ongoing information about control performance. Monitoring may identify: * control failures * control degradation * recurring exceptions * evidence gaps * changes in risk * changes in system behavior * changes in applicable requirements * emerging governance weaknesses Monitoring results may trigger reassessment, remediation, escalation, or assurance. See AI Monitoring.Control remediation
A control deficiency should result in an appropriate governance response. A remediation record may identify: * identified deficiency * affected control * related risk * severity or significance * remediation owner * corrective action * target date * status * evidence of completion * verification Remediation should preserve traceability from the original deficiency through to its resolution.Relationship to assurance
Assurance provides an additional mechanism for evaluating whether controls and the wider governance arrangements are appropriate and effective. A representative relationship is: Control → Evidence → Assessment → Assurance Assurance findings can result in: * remediation * risk reassessment * control modification * additional evidence requirements * monitoring changes * governance improvement See AI Governance Assurance.Relationship to change management
Changes to an AI system can affect control applicability or effectiveness. Potential triggers include: * changes to intended use * model changes * system architecture changes * deployment changes * changes to data * changes in stakeholders * changes in applicable requirements * material risk changes A material change may therefore require control reassessment. A simplified relationship is: Change → Risk Reassessment → Control Review → Assessment → Approval See AI Change Management.Relationship to incidents
An incident may indicate that an existing control failed, was insufficient, or was not operating as intended. Incident findings may therefore trigger: * control reassessment * new controls * control modification * remediation * risk reassessment * monitoring changes * assurance A representative relationship is: Incident → Investigation → Control Finding → Remediation → Verification See AI Incident Management.Machine-readable evaluation
Controls can participate in the AIGO machine-readable evaluation architecture. The evaluation layer separates governance records from evaluation logic: Governance Record → Rule → Evaluation → Result For example:Example control record
An implementation might represent a control conceptually as:Implementation sequence
A practical implementation can connect the control schema to the governance workflow:Control coverage
Control coverage provides a way to determine whether relevant risks and governance expectations have associated controls. A simplified coverage model is: Requirement / Risk → Control → Evidence → Assessment Coverage analysis can help identify: * risks without controls * controls without identified purpose * requirements without supporting controls * controls without evidence * controls without assessment * recurring control deficiencies The repository’s control coverage validation can provide a machine-readable repository-level view of relevant relationships. Coverage should not be interpreted as proof that controls are effective.Validation
Control records and relationships can be validated as part of the AIGO machine-readable governance layer. Validation may include: * schema validation * reference validation * relationship validation * control coverage validation * evidence coverage validation * framework consistency validation * repository integrity validation A passing validation result indicates that the tested content satisfies the implemented validation checks. It does not establish: * legal compliance * regulatory conformity * certification * accreditation * control effectiveness * adequacy of organizational governance Those conclusions require the appropriate substantive governance and assurance processes.Canonical source
Machine-readable schema:schemas/03-control/03-AIGO-Control-Schema-v0.1.json
Schema documentation:
schemas/03-control/03-AIGO-Control-Schema-Documentation-v0.1.md
Canonical control framework:
framework/07-controls/AIGO-AI-Governance-Controls-v0.1.md
Operational control assessment guidance:
docs/control-assessment.mdx
Canonical control assessment procedure:
guidance/02-procedures/05-AIGO-AI-Control-Assessment-Procedure-v0.1.md