> ## Documentation Index
> Fetch the complete documentation index at: https://docs.aigoframework.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 04 AIGO Assessment Schema Documentation v0.1

# 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:

```text id="3is4c8" theme={null}
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:

```json id="o6svwj" theme={null}
{
  "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:

```text id="7y2j9h" theme={null}
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:

```text id="vgkx9j" theme={null}
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:

```json id="3fg9wc" theme={null}
{
  "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:

```text id="64c7b4" theme={null}
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:

```text id="n0d4qg" theme={null}
Assessment
    ↓
Conclusion
    ↓
Approval / Decision
```

For example, an assessment may conclude:

```text id="vlbo1o" theme={null}
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:

```text id="2z2r6t" theme={null}
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:

```text id="32d4q3" theme={null}
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:

```text id="q15bvv" theme={null}
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:

```text id="ux5a8x" theme={null}
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:

```json id="rxt3qj" theme={null}
{
  "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