AIGO — Assessment Schema Documentation

1. Document Purpose

This document describes the machine-readable AIGO Assessment Schema. The schema provides the structured representation of formal assessments performed within the AIGO AI Governance Operating Framework. It is intended to support assessments including:

AI system classification;
AI risk assessment;
control assessment;
technical assessment;
model assessment;
data assessment;
privacy assessment;
security assessment;
fairness and impact assessment;
human-oversight assessment;
change-impact assessment;
monitoring assessment;
retirement assessment;
compliance assessment; and
other formally governed assessment activities.

The JSON schema defines structural requirements. This documentation explains the intended meaning, governance context, validation expectations, and traceability model for assessment records.

2. Schema Information

Field	Value
Schema	AIGO Assessment Schema
Schema Identifier	`https://aigo.example/schema/assessment/v0.1`
Schema Version	`0.1`
JSON Schema Dialect	JSON Schema Draft 2020-12
Object Type	`ASSESSMENT`
File	`04-AIGO-Assessment-Schema-v0.1.json`
Status	Draft
Framework	AIGO — AI Governance Operating Framework

3. Scope

The Assessment Schema applies to formal evaluations performed to support AIGO governance decisions. An assessment may concern:

an AI system;
a model;
data;
a risk;
a control;
a lifecycle stage;
an intended purpose;
a change;
an incident;
a monitoring result;
an assurance activity;
a retirement decision; or
another governance object.

The assessment should have a clearly defined purpose, scope, criteria, owner, methodology, evidence basis, result, and conclusion where applicable.

4. Object Model

The primary object represented by this schema is:

ASSESSMENT

An Assessment record represents an evaluation performed against defined criteria. The Assessment record should remain distinct from:

the object being assessed;
evidence supporting the assessment;
the approval resulting from the assessment;
controls being assessed;
risks being assessed;
incidents that may trigger the assessment; and
assurance activities that may independently review the assessment.

Related records should normally be connected through stable identifiers.

5. Core Identity

An Assessment record should contain stable identity information. Key fields include:

id;
objectType;
objectVersion;
schemaVersion;
assessment type;
assessment title or purpose;
owner;
scope;
criteria;
status; and
result.

Example:

{
  "id": "ASSESS-001",
  "objectType": "ASSESSMENT",
  "objectVersion": "1.0",
  "schemaVersion": "0.1"
}

The assessment identifier should remain stable while the assessment record is maintained. A materially different assessment should normally receive a distinct identifier.

6. Assessment Purpose

Every formal assessment should have a clearly stated purpose. A purpose may be to:

determine risk;
determine classification;
evaluate control effectiveness;
assess compliance;
determine readiness;
evaluate a proposed change;
validate system performance;
assess impacts;
determine whether approval criteria are satisfied; or
establish whether retirement requirements have been met.

The purpose should explain why the assessment was initiated and how its result will be used.

7. Assessment Types

The schema supports multiple assessment types. Typical assessment types include:

RISK
CLASSIFICATION
CONTROL
TECHNICAL
MODEL
DATA
PRIVACY
SECURITY
FAIRNESS
IMPACT
HUMAN_OVERSIGHT
CHANGE
MONITORING
COMPLIANCE
ASSURANCE_SUPPORT
RETIREMENT
OTHER

The exact enumeration defined in the JSON schema is authoritative. Organizations may use controlled subtypes within the approved assessment taxonomy.

8. Assessment Scope

The assessment scope should identify precisely what is being evaluated. Scope may include:

AI system;
model;
version;
component;
data source;
business process;
lifecycle stage;
jurisdiction;
environment;
organizational unit;
user group;
affected stakeholder group; and
applicable period.

Scope should be sufficiently explicit to prevent ambiguity concerning what the assessment does and does not cover.

9. Assessment Subject

An assessment should identify the object or objects being assessed. This may be represented through references such as:

aiSystemId
riskIds
controlIds
changeId
incidentId
approvalId
monitoringId
retirementId

Where multiple related objects are assessed, all materially relevant references should be maintained. The assessment record remains authoritative for the actual evaluation.

10. Assessment Owner

The assessment should have a clearly accountable owner. The owner is responsible for ensuring that:

the assessment is appropriately scoped;
qualified assessors are assigned;
criteria are defined;
evidence is collected;
methods are applied;
findings are documented;
conclusions are supported; and
the assessment is completed and controlled.

The person performing the assessment may be different from the accountable assessment owner.

11. Assessor and Independence

Where relevant, the assessment should identify:

assessor;
assessment team;
reviewer;
approving authority;
independence requirements; and
conflicts of interest.

Higher-risk or more consequential assessments may require increased independence. The level of independence should be proportionate to:

system classification;
risk;
affected-person impact;
decision significance;
regulatory requirements; and
organizational governance policy.

12. Assessment Criteria

Assessment criteria define the basis against which the subject is evaluated. Criteria may come from:

AIGO framework requirements;
internal policies;
procedures;
risk methodology;
control requirements;
technical standards;
legal requirements;
regulations;
contracts;
external standards;
model specifications; or
approved assessment methodologies.

Each material assessment should preserve traceability to its criteria.

13. Criteria Traceability

An assessment should identify:

criterion identifier;
criterion description;
source;
reference;
applicability;
mandatory status where applicable; and
interpretation.

Example:

{
  "criterionId": "CRIT-001",
  "source": "AIGO",
  "reference": "AI Governance Lifecycle",
  "description": "Required approval before production deployment."
}

This supports later assurance and audit activities.

14. Assessment Methodology

The assessment should document how the evaluation was performed. Methods may include:

document review;
interview;
observation;
technical testing;
model testing;
statistical analysis;
data analysis;
sampling;
control reperformance;
configuration review;
automated testing;
evidence review;
comparison against benchmarks;
scenario analysis; and
expert judgment.

The method should be appropriate to the assessment objective and documented sufficiently to support repeatability.

15. Assessment Evidence

Assessment conclusions should be supported by sufficient evidence. Evidence may include:

documents;
system records;
logs;
test results;
monitoring records;
configuration data;
approvals;
interviews;
observations;
incident records;
change records;
control evidence; and
external documentation.

Evidence should normally be referenced through stable evidence identifiers.

16. Evidence Quality

The assessment should consider the quality of supporting evidence. Relevant factors may include:

authenticity;
integrity;
completeness;
relevance;
accuracy;
timeliness;
traceability; and
reliability.

Weak evidence may limit the level of confidence in an assessment conclusion.

17. Assessment Sampling

Where the assessment uses sampling, the record should document:

population;
population size;
sample size;
sampling method;
selection criteria;
sampling rationale;
limitations; and
interpretation.

Sampling may be:

random;
systematic;
stratified;
risk-based;
judgmental; or
another approved method.

Sampling limitations should be visible in the assessment record.

18. Assessment Questions

Where useful, an assessment may include explicit questions. Examples include:

Are required governance controls implemented?
Is residual risk within tolerance?
Is the system appropriately classified?
Are required human-oversight controls operational?
Is monitoring functioning as designed?
Are required approvals complete?
Is a proposed change acceptable?
Are retirement criteria satisfied?

Questions should support objective and repeatable assessment.

19. Findings

Assessment findings identify conditions discovered during the assessment. Findings may represent:

compliance;
non-compliance;
control deficiency;
observation;
opportunity;
risk;
gap;
weakness;
strength; or
other material observation.

Each material finding should be traceable to:

assessment criteria;
evidence;
affected object;
severity where applicable; and
resulting action.

20. Finding Severity

The organization may assign findings a severity or priority based on:

potential impact;
risk;
regulatory significance;
affected-person impact;
control criticality;
evidence strength;
likelihood;
urgency; and
recurrence.

The common AIGO severity definitions should be used where applicable. The schema provides structure; the organization’s approved methodology determines how severity is assigned.

21. Assessment Result

The assessment should produce a defined result. Typical conceptual outcomes include:

PASS
PASS_WITH_CONDITIONS
PARTIALLY_SATISFACTORY
FAIL
NOT_READY
NOT_APPLICABLE
INCONCLUSIVE
PENDING

The authoritative enumeration defined in the JSON schema should be used. The result should be supported by the assessment conclusion and relevant findings.

22. Assessment Conclusion

The conclusion should summarize:

overall result;
key findings;
significant risks;
material limitations;
conditions;
recommendations;
decision implications; and
required follow-up.

A conclusion should not make claims that exceed the evidence or methodology used.

23. Conditions

An assessment may result in conditions. Conditions may require:

corrective action;
additional controls;
enhanced monitoring;
limited deployment;
restricted use;
additional assurance;
reassessment;
management approval; or
completion of specified actions before proceeding.

Conditions should identify:

description;
owner;
target date;
status; and
verification requirements.

24. Assessment Decision Relationship

An assessment is not necessarily an approval. The assessment may provide evidence for a later governance decision. The usual relationship is:

Assessment
    ↓
Conclusion
    ↓
Approval / Decision

For example, an assessment may conclude:

PASS_WITH_CONDITIONS

while the final governance decision is documented separately in an Approval record. This separation preserves independence between evaluation and authorization.

25. Risk Assessment

When the assessment type is RISK, the assessment may establish:

likelihood;
impact;
risk level;
risk criteria;
inherent risk;
treatment requirements;
residual risk; and
acceptance requirements.

The Risk Schema remains the authoritative operational record for the enduring risk. The Assessment record captures the specific evaluation performed at a given point in time.

26. Classification Assessment

A Classification assessment should establish whether the AI system falls into the organization’s relevant classification category. It may evaluate:

intended purpose;
autonomy;
impact;
affected stakeholders;
data sensitivity;
regulatory significance;
safety implications;
security;
privacy;
business context; and
deployment environment.

The result should identify the classification decision and rationale.

27. Control Assessment

A Control assessment should evaluate one or more controls. It may assess:

design;
implementation;
operating effectiveness;
evidence;
exceptions;
deficiencies;
monitoring; and
remediation.

The Control record identifies the control. The Assessment record identifies the evaluation performed against that control.

28. Technical Assessment

Technical assessments may evaluate:

system performance;
architecture;
reliability;
resilience;
robustness;
model behavior;
infrastructure;
integrations;
testing;
security; and
technical dependencies.

Technical assessment results may contribute to:

approval;
risk assessment;
monitoring;
change management;
assurance; and
retirement.

29. Model Assessment

Model assessments may evaluate:

model performance;
robustness;
drift;
bias;
explainability;
calibration;
reliability;
safety;
validation requirements;
model limitations; and
expected versus actual behavior.

The model assessment should identify the model version or relevant model artifact where applicable.

30. Data Assessment

Data assessments may evaluate:

quality;
completeness;
accuracy;
timeliness;
provenance;
relevance;
representativeness;
integrity;
access;
sensitivity; and
drift.

A data assessment may support:

risk management;
control assessment;
model validation;
privacy;
fairness;
monitoring; and
approval.

31. Privacy Assessment

Privacy assessments may evaluate:

data categories;
purpose;
necessity;
proportionality;
data protection measures;
access;
retention;
rights;
transfer;
third-party involvement; and
privacy risks.

The Assessment Schema records the evaluation. Detailed privacy records may be stored in specialized privacy governance systems.

32. Security Assessment

Security assessments may evaluate:

authentication;
authorization;
vulnerabilities;
data protection;
secrets;
infrastructure;
APIs;
model security;
attack resilience;
logging;
incident response; and
supplier security.

Findings should be traceable to relevant controls and risks.

33. Fairness and Impact Assessment

Fairness and impact assessments may evaluate:

affected groups;
potential harms;
differential outcomes;
discrimination risks;
representativeness;
fairness metrics;
mitigation;
affected-person feedback;
contestability; and
residual impact.

The methodology should be defined separately and should reflect applicable context and legal requirements.

34. Human Oversight Assessment

Human oversight assessments may evaluate:

whether oversight is required;
whether appropriate roles are assigned;
competence;
authority;
ability to intervene;
override functionality;
escalation;
review quality;
automation bias; and
actual versus designed operation.

Results may affect classification, controls, monitoring, risk, approval, or continued operation.

35. Change Assessment

A Change assessment may determine:

whether a proposed change is material;
risk impact;
control impact;
classification impact;
monitoring impact;
stakeholder impact;
security impact;
privacy impact;
fairness impact;
human oversight impact;
testing requirements; and
approval requirements.

The Change Schema remains authoritative for the change itself. The Assessment record captures the formal assessment performed on the change.

36. Monitoring Assessment

Monitoring assessments may evaluate:

indicator suitability;
threshold appropriateness;
data quality;
monitoring coverage;
alerting;
response;
escalation;
false positives;
false negatives;
trend changes; and
monitoring effectiveness.

Monitoring assessments may trigger:

risk reassessment;
incident management;
change management;
assurance; or
improvement.

37. Retirement Assessment

Retirement assessments may establish whether:

retirement is appropriate;
risks have been evaluated;
dependencies are addressed;
replacement systems are ready;
continuity arrangements exist;
data disposition is defined;
access can be removed;
monitoring can be closed;
regulatory requirements are satisfied; and
required evidence has been preserved.

The Retirement Schema remains authoritative for the overall retirement record.

38. Assessment Review

An assessment may undergo review before its conclusion is accepted. Review may include:

technical review;
governance review;
independent review;
peer review;
quality assurance;
management review; or
approval review.

Review information should distinguish the reviewer from the original assessor where independence is required.

39. Assessment Independence

Assessment independence should be proportionate to decision significance. Greater independence may be appropriate when:

the system is high risk;
potential impact is significant;
the assessment determines regulatory compliance;
the assessment supports a critical approval;
conflicts of interest exist;
repeated assessment weaknesses have occurred; or
assurance requires independent evaluation.

Independence should be recorded where material.

40. Assessment Limitations

Assessment limitations should be explicitly documented. Examples include:

incomplete evidence;
unavailable system logs;
restricted test environment;
limited sample size;
inaccessible supplier information;
incomplete stakeholder feedback;
insufficient historical data;
unvalidated assumptions; or
methodological constraints.

A limitation may reduce confidence in the assessment result.

41. Reassessment

Assessments may need to be repeated when material conditions change. Triggers may include:

system changes;
model changes;
data changes;
intended-purpose changes;
incidents;
control failures;
monitoring threshold breaches;
changes in law or regulation;
changes in risk;
new evidence; or
management direction.

The new assessment should preserve traceability to the previous assessment.

42. Assessment Versioning

The assessment record should distinguish:

assessment identifier;
assessment object version;
schema version;
assessment date;
assessment period; and
related system or component version.

A repeated assessment may be a new assessment record when the organization’s governance process requires an independent assessment event.

43. Assessment Evidence Relationship

The recommended evidence relationship is:

Assessment
    ↓
Criteria
    ↓
Procedures / Methods
    ↓
Evidence
    ↓
Findings
    ↓
Conclusion
    ↓
Decision

Evidence should be independently managed where appropriate. The Evidence Schema provides the machine-readable structure for evidence quality and lifecycle.

44. Assessment and Assurance

Assurance may independently examine an assessment. For example:

Assessment
     ↓
Assessment Result
     ↓
Assurance Review
     ↓
Assurance Finding

An assurance activity should not automatically overwrite the original assessment. Instead, disagreement or deficiencies should be captured through the assurance record and applicable governance process.

45. Assessment and Management Review

Significant assessment results may be presented during management review. Management review may consider:

assessment trends;
repeat findings;
unresolved conditions;
assessment quality;
risk implications;
control implications; and
required governance changes.

Management Review records should remain authoritative for management-level decisions.

46. Assessment and Improvement

Assessment findings may generate improvement actions. The relationship may be:

Assessment
    ↓
Finding / Gap
    ↓
Improvement
    ↓
Action
    ↓
Verification

The Improvement Schema remains authoritative for improvement planning and implementation.

47. Assessment Reporting

Assessment records may be aggregated into governance reports. Useful metrics include:

Metric	Purpose
Assessments completed	Assessment coverage
Assessments overdue	Governance timeliness
Failed assessments	Risk and compliance exposure
Conditional assessments	Outstanding requirements
Repeat findings	Control and governance weakness
Assessments by type	Portfolio visibility
Assessments by risk level	Risk prioritization
Open conditions	Decision constraints
Assessment turnaround time	Process performance

Metrics should use controlled definitions.

48. Assessment Validation Requirements

A valid Assessment record should satisfy:

Structural Validation

The JSON document must validate against: 04-AIGO-Assessment-Schema-v0.1.json

Scope Validation

The assessed object and boundaries should be clearly defined.

Criteria Validation

Assessment criteria should be identifiable and traceable.

Method Validation

The assessment method should be appropriate to the purpose.

Evidence Validation

Material conclusions should have sufficient evidence.

Ownership Validation

The assessment should have accountable ownership.

Result Validation

The result should be supported by findings and conclusion.

Reference Validation

Referenced AI systems, risks, controls, evidence, approvals, incidents, changes, and other objects should resolve where required.

Governance Validation

The assessment should be performed according to the applicable AIGO procedure and authority.

49. Schema Limitations

JSON Schema cannot independently determine:

whether an assessment methodology is appropriate;
whether evidence is sufficient;
whether a finding is accurate;
whether an assessor is competent;
whether an assessor is independent;
whether the conclusion is objectively justified;
whether risk has actually been reduced; or
whether the final governance decision is correct.

Those matters require qualified human judgment, procedures, evidence, and assurance.

50. Relationship to Templates

The Assessment Schema supports multiple assessment templates, including: guidance/03-templates/04-AIGO-AI-Classification-Template-v0.1.md guidance/03-templates/05-AIGO-AI-Risk-Assessment-Template-v0.1.md guidance/03-templates/06-AIGO-AI-Control-Assessment-Template-v0.1.md It may additionally support formal assessment records generated through:

security assessment processes;
privacy assessment processes;
fairness assessment processes;
change assessment;
monitoring assessment;
assurance;
retirement; and
other governed assessment activities.

51. Relationship to Procedures

The schema should be used with the relevant procedures, including: guidance/02-procedures/03-AIGO-AI-Risk-Assessment-Procedure-v0.1.md guidance/02-procedures/04-AIGO-AI-Classification-Procedure-v0.1.md guidance/02-procedures/05-AIGO-AI-Control-Assessment-Procedure-v0.1.md and, where applicable:

approval;
monitoring;
incident management;
change management;
assurance;
risk acceptance;
retirement; and
continuous improvement procedures.

Procedures define how assessments are performed and governed.

52. Framework Traceability

AIGO Component	Relationship
Governance Domains	Defines assessment governance context
Governance Roles	Defines assessor, owner, reviewer and authority
AI Governance Lifecycle	Identifies lifecycle stage being assessed
AI Risk Management	Provides risk assessment requirements
AI Governance Controls	Provides control assessment requirements
AI Governance Maturity	Supports assessment of governance maturity
AI System Profiles	Provides assessment subject context
Implementation Guidance	Defines operational assessment expectations
Operational Procedures	Defines assessment methods and workflow
Templates	Provides human-readable assessment records
External Mappings	Provides requirement and criteria traceability

53. Assessment Traceability Model

The recommended traceability chain is:

Object / System
      ↓
Assessment Purpose
      ↓
Scope
      ↓
Criteria
      ↓
Method
      ↓
Evidence
      ↓
Findings
      ↓
Conclusion
      ↓
Decision / Approval
      ↓
Monitoring / Assurance
      ↓
Reassessment / Improvement

This enables the organization to demonstrate not only that an assessment occurred, but also why it was performed, what it evaluated, what evidence it used, and what decision resulted.

54. Example Record

A conceptual Assessment record may look like:

{
  "id": "ASSESS-001",
  "objectType": "ASSESSMENT",
  "objectVersion": "1.0",
  "schemaVersion": "0.1",
  "status": "COMPLETE",
  "assessmentType": "RISK",
  "title": "Initial AI Risk Assessment",
  "aiSystemId": "AI-SYS-001",
  "purpose": "Determine the AI system's risk level before production approval.",
  "scope": {
    "description": "AI decision-support system and associated operational process."
  },
  "criteria": [
    {
      "criterionId": "CRIT-001",
      "source": "AIGO",
      "description": "Applicable AI risk assessment criteria."
    }
  ],
  "result": "PASS_WITH_CONDITIONS",
  "evidenceIds": [
    "EVID-030",
    "EVID-031"
  ],
  "findingsIds": [
    "FIND-001"
  ]
}

The actual record must conform to the authoritative JSON schema.

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

56. Change and Version Management

Changes to the Assessment Schema should be governed through AIGO change management. Potential impacts should be assessed against:

existing assessment records;
assessment templates;
assessment procedures;
risk management;
classification;
control assessment;
approval;
assurance;
evidence;
reporting;
external mappings; and
validation tooling.

Breaking changes should include migration guidance where appropriate.

57. Future Extensions

Future versions may support:

reusable assessment profiles;
formal assessment scoring models;
confidence scoring;
assessment workflow states;
automated evidence collection;
statistical assessment metadata;
machine-readable criteria libraries;
cross-framework assessment criteria;
decision-quality scoring;
assessment independence profiles; and
automated assessment conformance checks.

Extensions should preserve stable assessment identity and traceability.

58. Document Control

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

59. Document Status

Document: AIGO — Assessment Schema Documentation Version: 0.1 Status: Draft Working Name: AIGO Full Name: AI Governance Operating Framework Document Identifier: AIGO-SCHEMA-DOC-004 Document Type: Schema Documentation This document provides the human-readable interpretation, governance context, validation expectations, and traceability guidance for the AIGO Assessment Schema. End of Document

​AIGO — Assessment Schema Documentation

​1. Document Purpose

​2. Schema Information

​3. Scope

​4. Object Model

​5. Core Identity

​6. Assessment Purpose

​7. Assessment Types

​8. Assessment Scope

​9. Assessment Subject

​10. Assessment Owner

​11. Assessor and Independence

​12. Assessment Criteria

​13. Criteria Traceability

​14. Assessment Methodology

​15. Assessment Evidence

​16. Evidence Quality

​17. Assessment Sampling

​18. Assessment Questions

​19. Findings

​20. Finding Severity

​21. Assessment Result

​22. Assessment Conclusion

​23. Conditions

​24. Assessment Decision Relationship

​25. Risk Assessment

​26. Classification Assessment

​27. Control Assessment

​28. Technical Assessment

​29. Model Assessment

​30. Data Assessment

​31. Privacy Assessment

​32. Security Assessment

​33. Fairness and Impact Assessment

​34. Human Oversight Assessment

​35. Change Assessment

​36. Monitoring Assessment

​37. Retirement Assessment

​38. Assessment Review

​39. Assessment Independence

​40. Assessment Limitations

​41. Reassessment

​42. Assessment Versioning

​43. Assessment Evidence Relationship

​44. Assessment and Assurance

​45. Assessment and Management Review

​46. Assessment and Improvement

​47. Assessment Reporting

​48. Assessment Validation Requirements

​Structural Validation

​Scope Validation

​Criteria Validation

​Method Validation

​Evidence Validation

​Ownership Validation

​Result Validation

​Reference Validation

​Governance Validation

​49. Schema Limitations

​50. Relationship to Templates

​51. Relationship to Procedures

​52. Framework Traceability

​53. Assessment Traceability Model

​54. Example Record

​55. Schema Registry Relationship

​56. Change and Version Management

​57. Future Extensions

​58. Document Control

​59. Document Status