title: “Evaluation Architecture” description: “Machine-readable governance rule evaluation within the AIGO Framework.”
Evaluation Architecture
The AIGO Evaluation layer defines how machine-readable governance rules are applied to structured governance information and how evaluation results are produced. Evaluation is part of the AIGO machine-readable implementation layer. It provides a mechanism for applying defined governance logic consistently while keeping governance records, rules, evaluation semantics, and orchestration as distinct components.Purpose
Evaluation provides a structured mechanism for determining whether defined governance conditions are satisfied and whether further governance action may be required. It can support: * governance checks * applicability determination * required actions * review triggers * evidence requirements * change-related reassessment * enhanced governance treatment * structured governance findings Evaluation should be understood as a governance-support capability rather than as an automatic determination of legal or regulatory compliance.Evaluation architecture
The core relationship is: governance input → rule → evaluation → result A broader implementation architecture is: governance records → rule selection → condition evaluation → action determination → result → governance action This separation allows governance information to remain independent from the rules and mechanisms used to evaluate it.Evaluation inputs
Evaluation inputs may include structured information about: * AI systems * classifications * risks * controls * assessments * evidence * approvals * changes * incidents * monitoring * assurance * governance status The actual input requirements depend on the rule or evaluation being performed. Evaluation should operate against defined structured inputs rather than relying on undocumented assumptions about the underlying governance record.Rule selection
An evaluation process must determine which rules are relevant to the evaluation context. Rule selection may depend on: * the entity being evaluated * rule applicability * governance scope * classification * lifecycle state * applicable requirements * requested evaluation scope * rule version Not every rule should be applied to every AI system or governance record. The evaluation architecture should preserve the distinction between: rule not applicable and: rule applicable but condition not satisfied These represent different governance states.Condition evaluation
Once applicable rules have been selected, the evaluation mechanism evaluates the defined conditions against the available structured input. A simplified model is: input data + rule conditions → condition result The exact operators, condition semantics, supported data types, and evaluation behavior are defined by the applicable evaluation specification. Evaluation should be deterministic where the relevant inputs and rule definitions are deterministic. Where interpretation or contextual judgment is required, the evaluation result should not be treated as a substitute for appropriate human governance review.Actions and results
Evaluation can determine whether a defined governance action or outcome is associated with the evaluated condition. Possible results include: * pass * fail * not applicable * review required * additional governance action required * evidence required * reassessment required The exact result vocabulary and semantics are defined by the applicable evaluation specifications. A result should be interpreted together with: * the rule identifier * rule version * evaluated entity * evaluation input * evaluation scope * evaluation time * applicable conditions * supporting evidence where relevant This provides traceability for why a particular result was produced.Evaluation result traceability
Evaluation results should be traceable to the rule and governance information that produced them. A useful representation is: entity → input → rule → condition → result → action This allows an organization to reconstruct: * what was evaluated * which rule was applied * which version of the rule was used * what information was evaluated * what result was produced * what governance action followed Traceability is particularly important where evaluation results contribute to approval, monitoring, assurance, change management, or risk decisions.Evaluation components
The repository contains separate specifications and implementation materials for: * rule evaluation * evaluation semantics * semantic validation * evaluation input * evaluation result * evaluation fixtures * governance evaluation orchestration These components are separated so that changes to one part of the evaluation architecture do not unnecessarily change the underlying governance records or rule definitions.Evaluation semantics
Evaluation semantics define how the evaluation mechanism interprets rule conditions and produces results. They establish the meaning of evaluation operations and help ensure that the same rule behaves consistently across supported evaluation contexts. Semantic definitions should therefore be treated as controlled machine-readable implementation specifications.Evaluation fixtures
Evaluation fixtures provide controlled inputs and expected outcomes for testing evaluation behavior. They can be used to verify that: * a rule is interpreted correctly * applicable conditions produce the expected result * non-applicable conditions are handled correctly * expected actions are generated * edge cases behave as defined * changes to evaluation logic do not introduce unintended behavior Fixtures are therefore an important part of the evaluation validation layer.Evaluation orchestration
The AIGO implementation separates evaluation logic from evaluation orchestration. Rules define governance conditions. Evaluation defines how those conditions are applied. Orchestration determines how evaluation activities are assembled, selected, or executed for a particular governance context. The relationship can be represented as: governance records → rules → evaluation → orchestration → results This separation supports controlled integration of multiple rules and evaluation activities.Relationship to governance decisions
Evaluation results can support governance decisions, but they do not automatically make those decisions. For example, an evaluation result may indicate: additional governance action required The organization must then determine the appropriate response according to its governance procedures, decision authority, applicable requirements, and context. Evaluation therefore provides structured information for governance rather than replacing governance authority.Relationship to validation
Evaluation and validation are separate activities. Validation checks whether evaluation components and artifacts satisfy defined structural and semantic validation requirements. Evaluation applies defined governance rules to structured inputs. The relationship can be summarized as: validation → verifies evaluation implementation evaluation → applies governance logic The repository contains dedicated validation for evaluation fixtures, evaluation behavior, and orchestration.Current evaluation validation
The repository includes validation capabilities covering areas such as: * evaluation input structure * evaluation result structure * rule semantics * evaluation fixtures * evaluation behavior * orchestration configuration * orchestration behavior Relevant validation materials are maintained under:validation/10-evaluation-validation/
and:
validation/tests/fixtures/
Validation results provide evidence about the tested implementation within the relevant scope.
They do not establish legal compliance, certification, accreditation, or regulatory conformity.
Evaluation and evidence
Evaluation may use governance evidence as part of its input. For example: control → evidence → evaluation However, the existence of an evidence record does not automatically mean that the evidence is sufficient. Where a governance conclusion depends on evidence quality, relevance, completeness, authenticity, or contextual interpretation, human assessment may still be required. Automated evaluation should therefore complement, rather than automatically replace, evidence review and governance judgment.Evaluation and external requirements
Rules may be derived from AIGO governance requirements, controls, procedures, or mappings to external frameworks and regulations. However, an evaluation result based on an AIGO rule should not automatically be interpreted as a determination of external legal or regulatory compliance. The relationship should remain explicit: external requirement → AIGO mapping / governance interpretation → AIGO rule → evaluation → result The authoritative external source remains controlling for the interpretation of the external requirement.Version boundaries
The canonical AIGO Framework baseline remains v0.1. The current machine-readable rules and evaluation components use v0.2 component versions. This does not mean that the normative AIGO Framework has been changed to v0.2. The version distinction should be preserved between: * AIGO Framework v0.1 * Rules components * Evaluation components * Orchestration components * Validation components These implementation components can evolve independently while the controlled framework baseline remains explicitly identified.Canonical source
The evaluation components are maintained under:rules/evaluation/
The primary rule evaluation engine specification is:
rules/evaluation/AIGO-Rule-Evaluation-Engine-Specification-v0.2.md
Additional evaluation specifications and supporting machine-readable artifacts are maintained within the evaluation architecture and associated repository areas.
The repository is the authoritative source for the current controlled evaluation implementation.