title: “Rules Architecture” description: “Machine-readable governance rules within the AIGO Framework.”
Rules Architecture
The AIGO Rules layer provides machine-readable governance logic that can be evaluated against structured governance information. Rules extend the AIGO governance model from descriptive framework content into defined, testable governance conditions. They are part of the machine-readable implementation layer and should be understood separately from the normative AIGO Framework baseline.Purpose
Rules translate defined governance conditions, requirements, and governance expectations into structured machine-readable logic. They can support: * governance decisions * applicability determination * required actions * review triggers * evidence requirements * change detection * enhanced governance requirements * governance evaluation * automated or semi-automated checks Rules allow governance expectations to be represented in a form that can be validated and evaluated consistently.Rules and governance records
Rules do not replace governance records. Instead, rules operate against structured governance information. A simplified relationship is: governance record → rule → evaluation → result For example: AI system → classification rule → evaluation → classification-related result or: AI system change → material-change rule → evaluation → reassessment requirement This separation allows governance records to represent the state of an AI system while rules define conditions that should be checked against that state.Rule architecture
AIGO rules are organized around concepts such as: * rule definitions * rule identifiers * rule versions * conditions * actions * applicability * references * evaluation semantics * validation The exact machine-readable structure is defined by the canonical rule architecture and registry.Rule identifiers and versions
Each rule should have a stable identity that allows it to be referenced by evaluation fixtures, orchestration configuration, documentation, and governance tooling. Rule versions allow governance logic to evolve while preserving traceability to the version that produced a particular evaluation result. A change to a rule should therefore be treated as a controlled change to the machine-readable governance layer.Conditions
Rules define conditions under which a governance requirement, action, review, or other result applies. Conditions may depend on information such as: * AI system characteristics * classification * intended use * risk information * governance status * evidence * control status * lifecycle state * changes * other structured governance information The permitted condition structure is defined by the rule architecture.Actions and outcomes
A rule may identify an expected governance action or result when its conditions are satisfied. Possible governance outcomes can include: * required action * additional assessment * evidence requirement * review requirement * escalation * enhanced governance treatment * reassessment trigger * governance finding The meaning of an individual rule outcome is determined by the rule definition and its associated governance context. A rule result should not automatically be interpreted as a legal determination unless the rule is specifically designed and authorized for that purpose.Applicability
Rules may contain or depend upon applicability conditions. Applicability determines whether a rule should be considered for a particular governance entity or situation. This is important because not every rule applies to every AI system. Applicability may depend on factors such as: * system classification * intended use * deployment context * organizational policy * risk * lifecycle state * governance scope * applicable external requirements The evaluation architecture should distinguish between: rule does not apply and: rule applies but its condition is not satisfied These represent different governance states.Current rule layer
The current repository contains rules addressing areas including: * AI system registration * AI system classification * enhanced governance requirements * evidence validity * material AI system change The rule set may expand as the machine-readable governance layer develops. New rules should preserve clear relationships to the relevant AIGO governance concepts, controls, schemas, procedures, or external mappings where applicable.Rules and schemas
Rules operate on structured governance information represented by AIGO schemas. A simplified architecture is: AIGO schema → governed data → rule → evaluation For example, an AI System Schema can provide the structured entity being evaluated while a rule defines what governance condition should be checked. This separation prevents governance logic from being embedded directly into individual record schemas.Rules and evaluation
Rules define governance logic. The evaluation layer applies that logic to structured inputs and produces evaluation results. The conceptual separation is: rules → evaluation engine → evaluation result This allows the same governance rule to be evaluated consistently against defined inputs without changing the underlying governance record. Evaluation fixtures can provide controlled examples of expected rule behavior. Evaluation validation can then verify that the defined rule and fixture behavior are consistent with the intended semantics.Rules and orchestration
The AIGO implementation also includes an orchestration layer. Orchestration determines how defined evaluation activities are assembled or executed for a particular evaluation context. The conceptual architecture is: governance records → rules → evaluation → orchestration → results Rules therefore remain separate from the mechanism used to select, execute, validate, or combine evaluation activities. This separation supports maintainability and controlled evolution of the machine-readable governance layer.Rule validation
Rules are subject to validation within the AIGO repository. Validation can examine aspects such as: * rule structure * rule identifiers * rule references * rule semantics * required fields * supported operators or conditions * relationship to the rule registry * evaluation compatibility A passing rule-validation result means that the tested rule artifacts satisfy the implemented validation checks. It does not establish that the underlying governance policy is correct, legally sufficient, or appropriate for every organization.Rule evaluation is not compliance determination
Machine-readable rules can support governance evaluation, but they should not automatically be interpreted as legal or regulatory compliance determinations. For example: rule satisfied → defined governance condition satisfied does not necessarily mean: rule satisfied → organization is legally compliant External legal and regulatory obligations may require interpretation, contextual analysis, professional judgment, additional evidence, or formal assessment. The AIGO evaluation layer should therefore be treated as a governance-support capability.Traceability
Rules should maintain traceability to the governance concepts from which they are derived. Depending on the rule, relationships may include: * framework requirements * governance controls * procedures * schemas * external mappings * evidence expectations * evaluation fixtures * validation tests This provides a traceability chain such as: governance requirement → rule → evaluation → result → governance action Traceability helps organizations understand why a rule exists and how its result should be interpreted.Rule lifecycle
Rules should be managed as controlled machine-readable governance artifacts. A practical lifecycle is: 1. define the governance condition 2. identify the applicable governance source 3. define the rule 4. assign the rule identity and version 5. validate the rule 6. create evaluation fixtures where appropriate 7. validate expected evaluation behavior 8. integrate the rule into orchestration where applicable 9. deploy the rule 10. monitor rule behavior 11. review changes in the underlying governance requirement 12. revise or retire the rule when necessary Changes to rules should preserve appropriate version and traceability information.Version boundaries
The canonical AIGO Framework baseline remains v0.1. The Rules layer currently uses v0.2 component versions. This is an independent component version and does not mean that the normative AIGO Framework itself is v0.2. The distinction is important: AIGO Framework v0.1 → normative framework baseline Rules v0.2 → machine-readable governance implementation component Evaluation / orchestration components → supporting implementation capabilities These components can evolve while the controlled framework baseline remains explicitly identified as v0.1.Canonical source
The rule architecture is maintained in:rules/00-AIGO-Rule-and-Evaluation-Architecture-v0.2.md
The rule registry is maintained in:
rules/00-AIGO-Rule-Registry-v0.2.json
Individual rules are maintained under:
rules/
Evaluation and orchestration materials are maintained in their respective repository areas.
The repository is the authoritative source for the controlled machine-readable rule artifacts.