uagf-ckm

Universal AI Governance Framework (UAGF)

A Canonical Knowledge Infrastructure for Deterministic, Interoperable, and Machine-Readable AI Governance

License: CC BY 4.0 Version: 2.0.0-alpha E2E: 11/11 PASS CI/CD Public Good Machine Native

Executive Summary

Artificial Intelligence governance is rapidly becoming one of the defining infrastructure challenges of the digital era.

Organizations today operate across an increasingly fragmented landscape of regulations, international standards, internal governance policies, industry practices, technical specifications, and AI-specific governance requirements. Although many of these governance sources pursue similar objectives, they were developed independently, using different terminology, structures, assumptions, semantic models, and implementation approaches.

As a result, governance knowledge is frequently duplicated, interpreted and translated manually, maintained across disconnected systems, and gradually diverges over time. This fragmentation makes governance knowledge difficult to compare, validate, reconcile, reuse, and operationalize consistently across organizations, jurisdictions, technologies, and AI contexts.

The Universal AI Governance Framework (UAGF) addresses this problem by introducing a fundamentally different architectural approach: a canonical knowledge infrastructure for structuring, validating, and interoperably representing governance knowledge in a machine-readable form.

UAGF does not replace or supersede the legal, regulatory, normative, or institutional authority of underlying governance sources. Instead, it establishes the Canonical Knowledge Model (CKM) as the canonical, machine-readable knowledge foundation of the UAGF architecture. The CKM provides a structured semantic layer for representing governance concepts, requirements, controls, relationships, constraints, dependencies, and provenance in a consistent and machine-processable form.

The canonical status of the CKM applies to the representation and structural organization of governance knowledge within UAGF, while preserving traceability to the authoritative sources from which that knowledge is derived. This distinction allows UAGF to unify fragmented governance knowledge without creating a competing source of legal, regulatory, or institutional authority.

The CKM enables governance knowledge to be validated against defined structures and constraints and transformed into deterministic, interoperable representations and interfaces. These may include documentation, structured data formats such as JSON-LD and RDF, APIs, knowledge graphs, AI-context representations, governance dashboards, and other machine-readable interfaces.

Through this architecture, UAGF establishes a clear separation between authoritative governance sources, canonical knowledge, and derived representations. Authoritative sources retain their original authority; the CKM provides a canonical semantic and structural foundation for governance knowledge within UAGF; and interoperable representations provide consistent ways for humans and machines to consume and apply that knowledge.

This approach transforms AI governance from a predominantly document-centric discipline into a knowledge-centric infrastructure—where governance knowledge can be represented canonically, validated systematically, transformed deterministically, exchanged interoperably, and operationalized across diverse governance environments while maintaining provenance and accountability.

UAGF therefore provides an open, vendor-neutral foundation for turning fragmented governance knowledge into structured, machine-readable infrastructure capable of supporting interoperable governance across standards, regulations, policies, governance systems, APIs, knowledge graphs, and AI contexts.

Conventional Governance vs UAGF Canonical Knowledge Architecture

UAGF does not seek to replace existing governance sources, standards, regulations, or institutional processes. It introduces a canonical knowledge architecture that enables governance knowledge from heterogeneous authoritative sources to be structured, validated, traced, and transformed into interoperable machine-readable representations.

Aspect Conventional / Fragmented Approach UAGF Canonical Knowledge Architecture
Knowledge Foundation Document-centric Canonical Knowledge Model (CKM) as the canonical knowledge layer
Source Authority Embedded or interpreted through documents Preserved in underlying authoritative sources with explicit provenance
Knowledge Structure Primarily textual and heterogeneous Canonical semantic and structural model
Semantic Identity Often implicit or context-dependent Explicitly defined and machine-resolvable
Serialization Document formats such as Markdown/PDF Machine-readable serialization, including YAML
Synchronization Manual synchronization across artifacts Deterministic transformation and synchronization
Information Loss Often implicit or difficult to detect Explicitly identified and traceable
Validation Human-centric and fragmented review Structured multi-gate validation through the Validation Kernel (K-1..K-8) and the automated E2E suite (G1–G11)
Machine Readability Often secondary or added later First-class architectural requirement
Provenance Can degrade across copies and transformations Machine-traceable provenance
Lineage Difficult to maintain across artifacts Traceable from authoritative source through CKM to derived representations
Determinism Dependent on manual interpretation and process Deterministic transformation subject to defined rules and constraints
Interoperability Point-to-point or format-dependent Canonical semantic interoperability
Evolution Potentially breaking and manually coordinated Versioned, traceable, and controlled evolution
Representations Documents maintained as primary artifacts Deterministically derived interoperable representations
Accountability Dependent on manual documentation and process Supported by structured provenance, validation, and traceability

Why UAGF Exists

Modern AI governance has reached a level of complexity where documentation alone is no longer sufficient to support consistent, traceable, and machine-operable governance across diverse environments.

Organizations increasingly need to demonstrate:

across multiple governance ecosystems simultaneously.

Yet governance knowledge remains distributed across regulations, standards, policies, control frameworks, technical specifications, organizational procedures, and other governance artifacts. These sources are often developed and maintained independently, using different vocabularies, structures, semantic assumptions, and representations.

Every framework introduces its own terminology. Every regulation defines its own concepts and requirements. Every organization develops governance language and mappings suited to its own context.

Over time, these independent representations can diverge:

The resulting problem is not simply one of tooling or document management. It is an architectural problem of fragmented governance knowledge, semantic inconsistency, provenance, and synchronization.

UAGF was created to address this architectural problem by establishing a canonical knowledge infrastructure through which governance knowledge from heterogeneous authoritative sources can be structured, validated, traced, and transformed into interoperable machine-readable representations.

The Problem

Current AI governance suffers from structural fragmentation.

The same or closely related governance requirement may appear across:

…while being expressed differently in each context.

These independent representations can create multiple versions, mappings, interpretations, and implementations of related governance concepts. Over time:

As the number of governance sources and their relationships increase, the cost of maintaining consistent governance knowledge grows accordingly.

The underlying challenge is therefore not simply the volume of governance documentation. It is the absence of a shared canonical knowledge architecture capable of preserving meaning, provenance, structure, and relationships across heterogeneous governance sources.

Current AI Governance Landscape

Organizations commonly operate across multiple governance systems simultaneously. Examples include:

Each of these sources contributes valuable governance knowledge within its intended scope and authority.

UAGF does not seek to replace, consolidate, or supersede these sources. Instead, it recognizes that governance knowledge originating from different authoritative sources needs a common architectural layer through which it can be structured, related, validated, and exchanged.

Existing governance ecosystems were generally not designed to function as a unified, machine-readable knowledge infrastructure across heterogeneous sources.

Organizations therefore frequently construct crosswalks, mappings, catalogs, and integrations between governance artifacts. These relationships require ongoing maintenance and can become outdated as their underlying sources evolve.

The resulting challenge is not a lack of governance knowledge. It is the lack of a canonical infrastructure for maintaining relationships among that knowledge at scale.

Why Existing Governance Does Not Interoperate

The primary interoperability challenge is not that governance frameworks necessarily disagree. Rather, they were developed with different scopes, objectives, vocabularies, structures, identifiers, semantic assumptions, lifecycles, and update processes.

Traditional governance artifacts are often document-oriented, with knowledge expressed primarily through human-readable text and framework-specific structures.

Each source may define:

When these sources are connected without a canonical knowledge layer, organizations must maintain relationships between independently evolving representations.

This can result in:

The larger the governance ecosystem becomes, the more difficult it becomes to maintain these relationships manually.

UAGF addresses this architectural gap by introducing a canonical knowledge layer between authoritative governance sources and their interoperable machine-readable representations.

The UAGF Architectural Principle

UAGF establishes a clear separation between three fundamental layers:

1. Authoritative Governance Sources

Regulations, standards, policies, technical specifications, and other sources retain their original legal, regulatory, normative, or institutional authority.

2. Canonical Knowledge Model (CKM)

The CKM provides the canonical, machine-readable knowledge layer within UAGF. It structurally and semantically represents governance knowledge, including relevant concepts, requirements, controls, relationships, constraints, and provenance.

3. Derived Interoperable Representations

Governance knowledge represented through the CKM can be transformed into interoperable machine-readable and human-consumable representations, including documentation, structured data, APIs, knowledge graphs, AI-context representations, and other interfaces.

Note: The canonical status of the CKM applies to the representation and structural organization of governance knowledge within UAGF. It does not supersede the authority of the underlying governance sources.

Vision

To establish an open, canonical, machine-readable knowledge infrastructure that enables AI governance ecosystems to interoperate without replacing existing standards, regulations, policies, or organizational governance frameworks.

UAGF envisions a future in which governance knowledge can become:

…rather than remaining fragmented across independently maintained representations.

In this vision, governance knowledge becomes infrastructure: structured once at the canonical knowledge layer and made available through consistent, traceable representations across diverse governance contexts.

Mission

The mission of UAGF is to provide an open, vendor-neutral Canonical Knowledge Infrastructure that enables governments, industry, researchers, standards organizations, technology providers, and AI systems to structure, exchange, validate, and use governance knowledge through a shared semantic model.

UAGF does not seek to become another governance standard, regulation, certification scheme, or compliance product.

Instead, UAGF provides the knowledge architecture through which existing and future governance sources can be represented, related, validated, and made interoperable.

Its purpose is not to determine what governance authority should exist, but to provide infrastructure for making governance knowledge more structured, traceable, machine-readable, and interoperable.

What UAGF Does Not Do

UAGF does not:

Instead, UAGF provides a canonical knowledge architecture through which heterogeneous governance knowledge can be connected while preserving source authority, provenance, and contextual meaning.

Quick Start Guide

This section provides a streamlined entry point for developers, researchers, and governance practitioners to interact with the UAGF repository.

The primary workflow follows a single architectural invariant:

Authoritative Source → CKM → Validation → Rendering → Derived Representation

Contributors and implementers should modify the Canonical Knowledge Model (CKM) rather than editing generated documentation or machine-readable outputs directly. All downstream artifacts are deterministically derived from validated canonical knowledge.

1. Understand the Repository

The repository is organized around the Model-First principle. It separates canonical knowledge, staging material, generated artifacts, and operational evidence:

.
├── ckm/                 # Canonical Knowledge Model (Source of truth within UAGF)
│   ├── requirements/    # Unified Governance Requirements (UGRs)
│   ├── domains/         # Governance Domains (e.g., Risk, Transparency)
│   ├── references/      # Source Locators & Provenance References
│   └── cv/              # Controlled Vocabularies & Terminology Bindings
│
├── ckm-staging/         # Isolated Migration & Preparation Workspace
── generated/           # Read-Only Derived Rendered Artifacts
├── reports/             # Machine-Generated Operational & Verification Reports
├── tests/               # Automated Testing & Pipeline Verification Suite
│
── migrate_ckm.py       # Ingestion & Migration Tooling
├── validate_ckm.py      # Validation Kernel Execution CLI
├── render_ckm.py        # Deterministic Rendering Engine CLI
└── manifest.yaml        # Pipeline, Release & Validation Ruleset Metadata

2. Inspect the Canonical Knowledge Model

Start by examining the structured knowledge layer. Typical CKM objects include:

3. Validate the CKM

Before rendering downstream artifacts, validate the CKM against the UAGF Validation Kernel.

Standard development and transformation workflows exercise the Validation Kernel (K-1..K-8) via the validation CLI:

# Execute the Validation Kernel against a CKM dataset
python validate_ckm.py ckm-2.0.0-alpha

The Validation Kernel implements the kernel-level checks (K-1..K-8). End-to-end pipeline verification is performed separately by the automated E2E suite (tests/run_e2e.py), which implements automated gates G1–G11.

Validation verifies that the CKM conforms to the structural, semantic, provenance, and architectural constraints defined by UAGF. A failed blocking gate prevents downstream processing (Fail-Closed behavior).

4. Render Derived Representations

Once validation succeeds, render the CKM into the required representations:

# Render all active profiles (Markdown, JSON-LD, RDF, AI Context)
python render_ckm.py --profile all --out generated/

Important: Generated artifacts in generated/ should not be manually edited as a substitute for modifying the CKM. If a change is needed, update the CKM, validate, and re-render.

5. Run End-to-End Verification

For a complete pipeline verification (Migration → Validation → Rendering → Fidelity Check):

python tests/run_e2e.py

The repository’s automated end-to-end (E2E) verification suite executes 11 gates (G1–G11):

The Validation Kernel (K-1..K-8) is distinct from these higher-level E2E gates (G1–G11): validate_ckm.py runs the Kernel checks; tests/run_e2e.py orchestrates the pipeline-level gates and the release-integrity/reproducibility checks.

This process verifies the defined behavior of the governance knowledge pipeline, including validation, transformation, rendering, reproducibility, and regression properties.

6. Preparing an Official Release

Development workflows use the Validation Kernel (K-1..K-8) and the automated E2E suite (G1–G11). The current repository implements automated E2E gates G1–G11 only.

The Full Institutional Release concept includes additional institutional release controls beyond the automated E2E gate sequence. These controls are not implemented as G12/G13 automated gate IDs in tests/run_e2e.py. Each control has its own handling mechanism:

An official immutable release therefore requires both automated technical verification (G1–G11) and explicit institutional ratification performed outside of the automated E2E gate sequence.

7. The UAGF Mental Model

If you remember only one thing about the architecture:

                    Authoritative Governance Sources
                              │
                              ▼
                      Migration / Mapping
                       + Provenance
                              │
                              ▼
                    Canonical Knowledge Model (CKM)
                              │
                              ▼
                     ┌────────────────┐
                     │ Validation     │
                     │ Kernel         │
                     │                │
                     │  Validation    │  ← Validation Kernel (K-1..K-8)
                     │    (K-1..K-8)  │
                     ────────────────┘
                              │
                              ▼
                    Deterministic Rendering
                              │
              ┌───────────────┼───────────────┐
              ▼               ▼               ▼
           Markdown         JSON-LD           RDF
              │               │               │
              └───────────────┼───────────────┘
                              ▼
                    Human / Machine
                   Representations


              ┌─────────────────────────────┐
              │   Official Release Path     │
              │                             │
              │  Full Institutional Profile │  ← Immutable Snapshot
              │ (institutional controls —  │
              │  not automated E2E gates)  │
              │                             │
              │  + Release manifest & hashes│
              │  + Institutional ratification│
              │  + License & security checks│
              └─────────────────────────────┘
                              │
                              ▼
                    Immutable Release

Edit the CKM. Validate the CKM. Render the CKM.
Do not treat a rendered artifact as the source of governance knowledge.

For the complete architectural rationale, see Design Philosophy. For validation gate details, see The Validation Gates. For governance and contribution rules, see Governance.

Design Philosophy

UAGF is founded upon a set of architectural principles that define how governance knowledge is represented, validated, transformed, and exchanged within the framework.

These principles establish the relationship between authoritative governance sources, the Canonical Knowledge Model, and derived representations while preserving source authority, provenance, semantic integrity, and architectural determinism.

Model Before Documents

Governance knowledge within UAGF is structured through the Canonical Knowledge Model before it is rendered into documentation or other representations.

Knowledge Before Representation

Governance knowledge exists independently of the format in which it is represented.

Markdown, JSON, JSON-LD, RDF, REST APIs, knowledge graphs, and AI-context representations are representations or interfaces through which canonical knowledge may be consumed. They are not themselves the governance knowledge.

This separation allows UAGF to evolve its representations without changing the underlying semantic and structural model.

Authority Before Canonicalization

Canonicalization within UAGF does not transfer legal, regulatory, normative, or institutional authority from an underlying source to the CKM.

This principle prevents canonical representation from being confused with institutional authority.

Reality Before Convenience

UAGF does not silently modify, reinterpret, or normalize governance knowledge merely to simplify processing.

When source material is ambiguous, incomplete, conflicting, or uncertain, the architecture favors explicit reporting over silent correction. The framework therefore prioritizes fidelity to observable source reality over convenience.

Determinism Before Automation

Automation without determinism can reproduce inconsistency at scale. UAGF therefore requires deterministic transformation processes where deterministic behavior is defined and applicable.

Given identical canonical inputs, transformation rules, rendering profiles, and relevant release metadata, the same rendering process should produce reproducible outputs.

Determinism supports:

Determinism is therefore treated as an architectural property rather than merely an implementation convenience.

Transparency Before Abstraction

Architectural transformations should remain observable and traceable.

UAGF therefore treats transparency as a prerequisite for trustworthy transformation rather than as an optional documentation feature.

Provenance Before Reconciliation

When governance knowledge from different authoritative sources is represented within the CKM, its provenance must remain identifiable.

UAGF does not require heterogeneous sources to be artificially collapsed into a single undifferentiated authority. Instead, relationships, mappings, derivations, and transformations should preserve information about their origins and applicable contexts.

This enables governance knowledge to be related and interoperated while retaining the distinctions between its underlying sources.

Public Benefit

UAGF is developed as an open public-good initiative. Its purpose is to improve the quality, transparency, traceability, and interoperability of AI governance knowledge for the global community.

The framework is intended to support:

UAGF complements existing governance ecosystems. It does not replace them.

Its objective is to provide a common canonical knowledge layer through which heterogeneous governance knowledge can be structured, related, validated, and exchanged while preserving the authority and context of its underlying sources.

Because the CKM is designed to remain vendor-neutral and machine-readable, organizations retain the freedom to adopt whichever governance standards, regulations, policies, and control frameworks are appropriate to their own environments while participating in interoperable governance ecosystems.

High-Level Overview

UAGF introduces a Model-First Architecture in which governance knowledge is structured through the Canonical Knowledge Model before being transformed into downstream representations.

The architecture separates authoritative sources from canonical knowledge representation and derived outputs.

Authoritative Governance Sources
────────────────────────────────────────────
ISO/IEC 42001
EU AI Act
NIST AI RMF
OECD AI Principles
National Regulations
Organizational Policies
Technical Specifications
                    │
                    ▼
       Migration / Mapping / Provenance
                    │
                    ▼
       Canonical Knowledge Model (CKM)
                    │
                    ▼
          Validation & Constraints
                    │
                    ▼
       Deterministic Transformation
                    │
        ┌───────────┼───────────
        ▼           ▼           ▼
    Markdown      JSON-LD       RDF
        │           │           │
        ▼           ▼           ▼
 Documentation    APIs     Knowledge Graphs
                                │
                                ▼
                        AI Context Profiles

This separation enables UAGF to maintain consistency between representations without conflating canonical representation with source authority.

Architectural Innovations

UAGF is not intended to become another AI governance standard. It is a canonical knowledge architecture for AI governance.

The framework introduces a set of architectural capabilities that enable governance knowledge from heterogeneous sources to be structured, validated, traced, transformed, and represented in deterministic and machine-readable forms.

These capabilities are not independent features. They are designed to operate together as a coherent architecture.

The Core Differentiator

Traditional governance ecosystems are frequently organized around documents and framework-specific representations.

UAGF introduces a different architectural model:

Authoritative Sources → Canonical Knowledge Model → Derived Representations

The key architectural shift is therefore not from one document format to another. It is from document-centric governance knowledge management to canonical knowledge infrastructure.

Instead of maintaining independent versions of the same governance knowledge across multiple representations, UAGF establishes a canonical knowledge layer from which compatible representations can be derived.

This reduces unnecessary synchronization between independently maintained representations and creates a clearer basis for validation, provenance, reproducibility, and interoperability.

Architectural Innovation Overview

Capability Purpose
Model-First Architecture Structures governance knowledge through the CKM before downstream representations are generated.
Canonical Knowledge Model Provides the canonical semantic and structural knowledge layer within UAGF.
Render-from-Model Derives downstream representations from canonical knowledge rather than treating each representation as an independent source.
Deterministic Transformation Enables reproducible transformation when defined inputs, rules, and profiles are identical.
Loss Manifest Explicitly identifies information intentionally omitted during transformation.
No Silent Correction Prevents migration or transformation processes from silently altering uncertain or conflicting source knowledge.
Migration Provenance Preserves traceable origin and transformation history for migrated knowledge.
Machine-Readable Governance Treats machine readability as a first-class architectural requirement.
Canonical Semantic Interoperability Provides a shared semantic layer through which heterogeneous governance knowledge can be related and exchanged.
Public Knowledge Infrastructure Makes reusable governance knowledge infrastructure available as an open public-good foundation.

Model-First Architecture

Model-First Architecture is the foundational architectural principle of UAGF.

Rather than designing governance knowledge around independently maintained documents, UAGF structures governance knowledge through the Canonical Knowledge Model.

Canonical Knowledge Model
            │
            ▼
     Validation Layer
            │
            ▼
 Deterministic Transformation
            │
     ┌──────┼───────────
     ▼      ▼           ▼
 Markdown JSON-LD       RDF
     │      │           │
     ▼      ▼           ▼
Documents  APIs    Knowledge Graphs
                         │
                         ▼
                  AI Context Profiles

In this architecture:

The CKM is the canonical knowledge layer within UAGF. It does not replace the authority of the governance sources from which the knowledge originates.

Canonical Knowledge Model (CKM)

The Canonical Knowledge Model is the architectural center of UAGF.

It represents governance knowledge as structured, machine-readable knowledge objects rather than relying exclusively on paragraphs of documentation.

Depending on the object type, canonical knowledge may include:

The CKM is intentionally independent from any individual presentation or serialization format. It is neither Markdown nor JSON-LD nor RDF. These are representations of knowledge structured through the canonical model.

This separation allows UAGF to introduce additional representations and interfaces without changing the underlying semantic model unnecessarily.

Render-from-Model

Render-from-Model is one of the defining architectural capabilities of UAGF.

Traditional governance workflows may resemble:

Policy / Governance Source
          │
        Update
          ▼
      Document
          │
     Manual Sync
          ▼
    Structured Data
          │
     Manual Sync
          ▼
   Knowledge Graph
          │
     Manual Sync
          ▼
     AI Context

Every independently maintained synchronization point introduces an opportunity for divergence.

UAGF instead establishes:

Canonical Knowledge Model
            │
            ▼
   Validation / Constraints
            │
            ▼
 Deterministic Transformation
            │
    ┌───────┼───────────────
    ▼       ▼               ▼
Markdown  JSON-LD           RDF
    │       │               │
    ▼       ▼               ▼
Website   APIs       Knowledge Graphs
                            │
                            ▼
                     AI Context

Representations are derived from the CKM rather than maintained as independent sources of governance knowledge.

This does not mean that every output is identical in structure or information content. Different representations may intentionally expose different subsets of the canonical knowledge.

Where information is omitted or transformed, UAGF requires the transformation to remain traceable and, where applicable, explicitly documented through a Loss Manifest.

Deterministic Rendering

UAGF treats deterministic rendering as an architectural property.

Where a rendering process is defined as deterministic, identical:

…should produce reproducible outputs.

This property supports:

Deterministic rendering therefore provides a foundation for verifying that derived representations correspond to the canonical knowledge and transformation rules used to produce them.

Loss Manifest

Not every representation can preserve every property of the Canonical Knowledge Model.

For example:

Traditional transformation pipelines may allow such information loss to remain implicit. UAGF makes intentional information loss explicit.

Where applicable, a renderer produces a corresponding Loss Manifest describing:

This transforms information loss from an implicit side effect into an observable architectural property.

No Silent Correction

UAGF treats migration as a conservative transformation process.

Legacy governance knowledge is not silently rewritten merely because a target representation would be easier to process.

Migration follows three core principles:

  1. Transform mechanically.
  2. Preserve provenance.
  3. Report uncertainty.

The migration process does not silently guess what the source intended. Architectural integrity takes precedence over convenience.

Migration Provenance

Migration is not merely a data conversion operation. Within UAGF, migration is an evidence-preserving transformation process.

Where applicable, migrated knowledge retains information concerning:

This enables users and auditors to reconstruct how governance knowledge moved from an originating source into the canonical knowledge layer and subsequently into derived representations.

The objective is not to prevent transformation. The objective is to ensure that transformation does not erase the history necessary to understand what happened.

Machine-Readable Governance

Many governance systems are designed primarily for human readers, with machine-readable representations introduced afterwards.

UAGF instead treats machine readability as a first-class architectural requirement.

Governance knowledge is structured through the canonical model so that the same underlying knowledge can support both human and machine consumption.

For example:

These are different representations of related canonical knowledge rather than independently authored versions. This reduces unnecessary translation between human-facing and machine-facing governance representations.

Public Knowledge Infrastructure

UAGF treats governance knowledge as reusable public infrastructure rather than isolated proprietary documentation.

Infrastructure is intended to be reused across organizations, jurisdictions, technologies, and governance environments.

The Canonical Knowledge Model can support:

These communities do not need to adopt identical governance frameworks. Instead, governance knowledge from different authoritative sources can be represented, related, and exchanged through a shared canonical knowledge architecture while preserving source authority and contextual distinctions.

Why These Innovations Matter

Taken individually, each capability improves governance engineering. Taken together, they establish a different architectural approach to governance knowledge.

Instead of asking:

“How should we maintain all these documents?”

UAGF asks:

“How should governance knowledge be structured before documents and other representations are created?”

This represents a shift from documentation-centric governance knowledge management toward knowledge-centric governance infrastructure.

The resulting architecture is designed to support governance ecosystems that are:

These properties are intended to emerge from the architecture and its defined constraints rather than from individual implementation choices.

Architectural Layers

UAGF separates governance architecture into distinct layers, each with a defined responsibility.

External Authoritative Governance Sources
────────────────────────────────────────────────────
ISO/IEC 42001
EU AI Act
NIST AI RMF
OECD AI Principles
National Regulations
Organizational Policies
Technical Specifications
Industry / Domain Frameworks

                         │
                         ▼

              Migration / Mapping /
                 Provenance Layer

                         │
                         ▼

             Canonical Knowledge Model
                         (CKM)

                         │
                         ▼

              Validation & Constraints
                    Kernel

                         │
                         ▼

            Deterministic Transformation
                   / Rendering

                         │
         ┌───────────────┼──────────────────
         ▼               ▼                  ▼
     Markdown         JSON-LD             RDF
         │               │                  │
         ▼               ▼                  ▼
   Documentation       APIs          Knowledge Graphs
                                             │
                                             ▼
                                      AI Context Profiles

Each layer exists for a specific architectural purpose:

No layer is intended to replace the authority of another layer, and no derived representation becomes authoritative merely because it is generated or published.

Validation Kernel

Before downstream artifacts may be generated, the Canonical Knowledge Model is evaluated by the UAGF Validation Kernel.

The Validation Kernel enforces defined architectural invariants, structural constraints, semantic constraints, provenance requirements, and pipeline integrity conditions.

Important Distinction: The purpose of the Validation Kernel is not to determine the legal, regulatory, or institutional validity of an underlying governance source. Rather, it verifies whether knowledge represented within the CKM conforms to the rules and constraints required by the UAGF architecture.

The Validation Kernel may evaluate properties including:

Where validation is defined as a blocking condition, downstream transformation or release is prevented when the relevant validation gate fails.

This fail-closed behavior prevents knowledge that violates defined UAGF architectural constraints from being propagated through the downstream representation pipeline.

The Validation Kernel therefore acts as an architectural integrity boundary, not as a replacement for the authority of the underlying governance sources.

Repository Structure & Canonical Knowledge Model

UAGF is organized around a Model-First principle:

Governance knowledge represented within UAGF is structured through the Canonical Knowledge Model before being transformed into downstream representations.

The repository separates canonical knowledge, staging material, generated artifacts, operational evidence, and verification mechanisms.

.
├── ckm/
│   ├── requirements/
│   ├── domains/
│   ├── references/
│   └── cv/
│
├── ckm-staging/
│
├── generated/
│
├── reports/
│
├── tests/
│
├── migrate_ckm.py
├── validate_ckm.py
├── render_ckm.py
├── manifest.yaml
│
└── README.md

Each directory has a defined architectural responsibility.

The repository structure is designed to prevent different representations from silently becoming competing sources of canonical knowledge.

Generated artifacts do not acquire authority merely because they are published, and operational reports do not become canonical knowledge merely because they are used as evidence.

Canonical Knowledge Model (ckm/)

The ckm/ directory contains the canonical knowledge representation maintained within UAGF.

The CKM represents governance knowledge as structured, machine-readable objects rather than relying exclusively on manually maintained documentation.

The CKM does not replace the authoritative governance sources from which its knowledge is derived. Instead, it provides the canonical semantic and structural layer through which that knowledge is represented within UAGF, while maintaining references and provenance to its originating sources.

The CKM currently contains four primary categories:

1. Requirements (ckm/requirements/)

Contains Unified Governance Requirements (UGRs). Each requirement represents an atomic governance statement that can be:

Requirements are intentionally represented independently from any single regulation, standard, or implementation environment while retaining their source relationships and provenance.

2. Domains (ckm/domains/)

Defines the governance domains used by the framework. Domains provide semantic organization for canonical knowledge while remaining independent from presentation formats.

3. References (ckm/references/)

Contains normalized references to external governance sources (e.g., ISO/IEC 42001, NIST AI RMF, EU AI Act, OECD AI Principles, National regulations).

4. Controlled Vocabulary (ckm/cv/)

Contains controlled vocabularies used throughout the Canonical Knowledge Model to support semantic consistency across:

Controlled vocabularies are evaluated as part of CKM validation to ensure that canonical objects use permitted and consistent terminology.

CKM Staging (ckm-staging/)

The staging area is an isolated workspace used during migration and preparation of canonical knowledge.

Legacy governance material may be transformed into candidate CKM objects within this directory before those objects are introduced into the canonical knowledge layer.

The staging workspace provides an architectural boundary between: source material → transformation → candidate canonical knowledge and the already established CKM.

This separation helps ensure that migration processes do not silently modify existing canonical knowledge. Candidate objects may enter the canonical model only after satisfying the applicable validation, review, and governance requirements defined by UAGF.

Note on Ratification: Where Founder or institutional ratification is required, such ratification remains a governance decision and is not replaced by automated validation.

Generated Artifacts (generated/)

The generated/ directory contains artifacts produced by UAGF transformation and rendering processes.

Typical outputs may include:

These files are derived artifacts. They are not independently maintained sources of canonical knowledge.

Generated artifacts should therefore not be manually edited as a substitute for modifying the canonical knowledge layer. When the applicable source inputs and transformation rules remain available, a generated artifact should be reproducible through the corresponding rendering process.

If a generated artifact is deleted, its recreation depends on the continued availability of the relevant canonical knowledge, rendering profile, transformation rules, and release inputs. This distinction is important: reproducibility is an architectural objective, not a claim that every artifact is permanently recoverable regardless of repository state.

Reports (reports/)

The reports/ directory stores machine-generated operational and verification reports.

Typical reports may include:

Reports provide operational and verification evidence. They do not become canonical knowledge merely because they record the results of processing canonical knowledge.

Their purpose is to make the behavior and results of the UAGF pipeline observable, reviewable, and auditable.

Tests (tests/)

The tests/ directory contains automated verification of the major architectural properties of the UAGF pipeline.

Examples include:

Testing is designed to verify that defined UAGF transformations and constraints behave consistently across the governance pipeline.

Where determinism is an explicit requirement, tests verify that identical inputs and defined transformation conditions produce reproducible results.

Note: Testing therefore provides evidence that the architecture behaves according to its defined constraints; it does not by itself establish the legal or institutional authority of the underlying governance sources.

Repository Design Principles

The UAGF repository architecture intentionally separates four distinct concepts to prevent accidental authority drift between authoritative governance sources, canonical knowledge, generated representations, and operational evidence.

Layer Role within UAGF Directly Editable
Canonical Knowledge Model (CKM) Canonical knowledge representation within UAGF ✅ Yes
Generated Artifacts Derived representations rendered from canonical knowledge ❌ No
Operational Reports Machine-generated evidence of validation, migration, rendering, and testing activities ❌ No
Documentation Views Human-readable representations derived from canonical knowledge ❌ No

⚖️ Authority Boundary: The CKM is canonical within the UAGF architecture, but it does not supersede the legal, regulatory, normative, or institutional authority of the underlying governance sources. (SATHIRA Constitution Rule 003 & Rule 005)

Canonical Knowledge Source within UAGF

One of the core architectural invariants of UAGF is:

The Canonical Knowledge Model is the single canonical knowledge source within UAGF.

This means that the CKM is the maintained source from which UAGF generates its downstream representations.

It does not mean that the CKM becomes the legal, regulatory, normative, or institutional authority of the governance knowledge it represents. Authoritative governance sources retain their original authority.

The CKM provides the canonical semantic and structural representation of governance knowledge within UAGF while maintaining references and provenance to those authoritative sources.

Accordingly:

All downstream representations are derived from the CKM through defined transformation and rendering processes.

Why This Matters

Traditional governance repositories may duplicate related governance knowledge across multiple files and representations. Over time, these independently maintained copies can diverge:

UAGF addresses this architectural failure mode by maintaining a canonical knowledge layer within the repository and deriving downstream representations from it.

The objective is not to eliminate the existence of multiple representations.
The objective is to eliminate independent authority and independent maintenance of those representations.

Knowledge represented within UAGF is maintained at the canonical knowledge layer. Documentation, structured exports, APIs, knowledge graphs, and AI-context representations are derived views of that knowledge.

This architecture supports:

Tooling

UAGF is implemented as a deterministic knowledge engineering pipeline.

Each tool has a defined responsibility within the governance knowledge lifecycle and must operate within the authority boundaries established by the UAGF architecture. Tools must not silently modify canonical governance knowledge or bypass defined validation and governance controls.

Transformations performed by UAGF tooling should be:

The tooling layer therefore exists to enforce and operationalize the UAGF architecture rather than to become an independent source of governance authority.

Core Toolchain

UAGF is implemented as a deterministic knowledge engineering toolchain. Each tool performs a defined function within the canonical knowledge pipeline and operates subject to the architectural constraints established by UAGF.

Tool Purpose
validate_ckm.py Validates the Canonical Knowledge Model against defined UAGF architectural invariants and validation constraints.
migrate_ckm.py Transforms legacy governance material into candidate CKM objects while preserving applicable provenance and migration information.
render_ckm.py Generates defined downstream representations and public artifacts from the validated CKM.
tests/run_e2e.py Executes end-to-end verification of the defined migration, validation, rendering, fidelity, and reproducibility pipeline.
manifest.yaml Defines applicable migration, release, provenance, and pipeline metadata and processing rules.

Together, these components form the UAGF Canonical Knowledge Infrastructure Pipeline.

The toolchain separates the major responsibilities of the architecture:

Authoritative Governance Sources
              │
              ▼
      Migration / Mapping
              │
              ▼
       CKM Staging Area
              │
              ▼
     Validation Kernel
              │
       ┌────────────┐
       │             │
     FAIL          PASS
       │             │
       ▼             ▼
     HOLD      Transformation
                     │
                     ▼
              Deterministic
                 Rendering
                     │
                     ▼
          Derived Representations

Architectural Boundary: The toolchain does not replace the authority of the underlying governance sources. Its purpose is to preserve, structure, validate, transform, and represent governance knowledge within the defined UAGF architecture.

Validation Pipeline

The Validation Pipeline is a primary execution stage of the UAGF knowledge infrastructure pipeline.

Its purpose is to determine whether canonical knowledge and pipeline outputs conform to the architectural invariants, structural constraints, semantic constraints, provenance requirements, and other validation conditions defined by UAGF.

Important Distinction: Validation does not determine whether an underlying governance source is legally, regulatorily, normatively, or institutionally authoritative. Instead, validation establishes whether the representation of governance knowledge within UAGF satisfies the conditions required for the applicable stage of the pipeline.

Validation Boundary

The validation boundary separates candidate knowledge from knowledge that is eligible to proceed through defined downstream processing.

Candidate CKM Objects
        │
        ▼
┌───────────────────────────┐
│     Validation Kernel     │
│                           │
│ Schema                    │
│ Semantics                 │
│ Relationships             │
│ Vocabulary                │
│ Provenance                │
│ Fidelity                  │
│ Release Constraints       │
└─────────────┬─────────────┘
              │
       ┌──────┴──────┐
       ▼             ▼
     FAIL           PASS
       │             │
       ▼             ▼
     HOLD      Eligible for
               downstream
               processing
                     │
                     ▼
                Rendering

Where a validation condition is defined as blocking, failure prevents the affected knowledge or artifact from progressing to the next stage. This fail-closed behavior ensures that objects or transformations that violate applicable UAGF architectural constraints do not silently propagate through the downstream pipeline.

Validation Before Rendering

Validation precedes rendering for pipeline stages in which the CKM is the source of the resulting representation.

A rendered artifact is therefore eligible for downstream release or use only when the applicable CKM and rendering conditions have successfully satisfied the required validation gates.

This establishes a controlled relationship between: canonical knowledge → validation → transformation → derived representation

…rather than allowing rendering to become an independent path around the Validation Kernel.

What Validation Establishes

Successful validation may establish that:

Successful validation does not establish that:

Constitutional Alignment: These distinctions preserve the absolute boundary between UAGF architectural validity and external governance authority, strictly adhering to Institutional Rule 003 (Human Accountability) and Rule 005 (Public Neutrality).

Validation Kernel

The UAGF Validation Kernel (K-1..K-8) enforces defined architectural invariants, structural constraints, semantic constraints, provenance requirements, and pipeline integrity conditions via validate_ckm.py. The automated E2E suite (tests/run_e2e.py) implements pipeline-level gates G1–G11. Official publication and immutable institutional releases additionally involve institutional release controls beyond the automated E2E gate sequence: IC-1 (release manifest & SHA-256 hashes) handled through the release-cutting workflow (cut_release.py); IC-2 (institutional ratification) handled through the Founder/institutional ratification process and the UFD ledger; and IC-3 (license & security checks) handled as an institutional responsibility outside the automated E2E gate sequence. Before downstream artifacts may be generated or released, the Canonical Knowledge Model (CKM) is evaluated by this kernel to enforce defined UAGF architectural invariants, structural constraints, semantic constraints, provenance requirements, and pipeline integrity conditions.

Important Distinction: The purpose of the Validation Kernel is not to determine the legal,regulatory,normative,or institutional validity of an underlying governance source. Instead, it verifies whether governance knowledge represented within the CKM conforms to the structures, constraints,relationships, metadata requirements,and transformation conditions defined by the UAGF architecture.

The Validation Kernel may evaluate properties including:

Where a validation condition is defined as blocking, failure of that condition prevents the affected downstream transformation or release from proceeding.

This fail-closed behavior prevents knowledge that violates defined UAGF architectural constraints from propagating through the downstream representation or release pipeline.

The Validation Kernel therefore acts as an architectural integrity boundary.It does not replace the authority of the underlying governance sources, and successful validation must not be interpreted as legal, regulatory, normative,or institutional approval of those sources or of the knowledge represented within them.

The Validation Gates

The UAGF verification architecture separates three layers:

Each gate evaluates a specific class of architectural conditions. Conditions designated as blocking must pass before the affected transformation or release may proceed.

Validation Gate Architecture

graph TD
    subgraph Phase1 ["Phase 1: Structural & Semantic Foundation (G1–G4)"]
        G1["<b>G1</b><br/>CKM Structural Integrity"] --> G2["<b>G2</b><br/>Controlled Vocabulary"]
        G2 --> G3["<b>G3</b><br/>Relationship Consistency"]
        G3 --> G4["<b>G4</b><br/>Kernel Invariants"]
    end

    subgraph Phase2 ["Phase 2: Traceability & Transformation (G5–G7)"]
        G4 --> G5["<b>G5</b><br/>Migration Provenance"]
        G5 --> G6["<b>G6</b><br/>Loss Manifest Validation"]
        G6 --> G7["<b>G7</b><br/>Deterministic Rendering"]
    end

    subgraph Phase3 ["Phase 3: Integrity & End-to-End (G8–G10)"]
        G7 --> G8["<b>G8</b><br/>Round-Trip Integrity"]
        G8 --> G9["<b>G9</b><br/>Canonical Fidelity"]
        G9 --> G10["<b>G10</b><br/>End-to-End Consistency"]
    end

    subgraph Phase4 ["Phase 4: Institutional & Release Boundary (IC-1–IC-3, outside automated E2E sequence)"]
        G10 --> IC1["<b>IC-1</b><br/>Cryptographic Integrity<br/>(release manifest, SHA-256)"]
        IC1 --> IC2["<b>IC-2</b><br/>Institutional Ratification<br/>(Founder / UFD ledger)"]
        IC2 --> IC3["<b>IC-3</b><br/>License & Security Compliance"]
    end

    IC3 -->|INSTITUTIONAL RELEASE CRITERIA SATISFIED| RELEASE["<b>✓ Validated Immutable Release</b>"]

    G1 -.->|FAIL| HOLD
    G6 -.->|FAIL| HOLD
    G10 -.->|FAIL| HOLD
    IC2 -.->|NOT SATISFIED| HOLD

    HOLD["<b>✗ HOLD / Quarantine State</b>"]

    style Phase1 fill:#0A1833,stroke:#C7CBD3,stroke-width:2px,color:#F5F3EE
    style Phase2 fill:#0A1833,stroke:#C7CBD3,stroke-width:2px,color:#F5F3EE
    style Phase3 fill:#0A1833,stroke:#C7CBD3,stroke-width:2px,color:#F5F3EE
    style Phase4 fill:#071026,stroke:#C9A45A,stroke-width:3px,color:#F5F3EE
    style RELEASE fill:#0A1833,stroke:#2e7d32,stroke-width:3px,color:#F5F3EE
    style HOLD fill:#1A1D21,stroke:#c62828,stroke-width:3px,color:#F5F3EE
    style G1 fill:#F5F3EE,stroke:#0A1833,color:#0A1833
    style G2 fill:#F5F3EE,stroke:#0A1833,color:#0A1833
    style G3 fill:#F5F3EE,stroke:#0A1833,color:#0A1833
    style G4 fill:#F5F3EE,stroke:#0A1833,color:#0A1833
    style G5 fill:#F5F3EE,stroke:#0A1833,color:#0A1833
    style G6 fill:#F5F3EE,stroke:#0A1833,color:#0A1833
    style G7 fill:#F5F3EE,stroke:#0A1833,color:#0A1833
    style G8 fill:#F5F3EE,stroke:#0A1833,color:#0A1833
    style G9 fill:#F5F3EE,stroke:#0A1833,color:#0A1833
    style G10 fill:#F5F3EE,stroke:#0A1833,color:#0A1833
    style IC1 fill:#F5F3EE,stroke:#C9A45A,color:#0A1833
    style IC2 fill:#F5F3EE,stroke:#C9A45A,color:#0A1833
    style IC3 fill:#F5F3EE,stroke:#C9A45A,color:#0A1833

Execution Profile Summary

Layer Checks Use Case Enforcement
Validation Kernel K-1..K-8 Kernel-level structural/semantic/provenance validation Automated (validate_ckm.py)
Automated E2E Gates G1–G11 CI/CD pipeline verification, incl. release integrity (G10) and reproducibility (G11) Automated (tests/run_e2e.py)
Institutional Release Controls IC-1..IC-3 Official publication, immutable release snapshots Manual Founder/institutional ratification + cut_release.py

Gate Definitions

Gate Name Purpose
G1 CKM Structural Integrity Schema correctness, mandatory fields, namespace validity
G2 Controlled Vocabulary Validation Permitted terminology bindings, classification consistency
G3 Relationship Consistency Cross-object references, dependency integrity, orphan detection
G4 Kernel Invariant Validation Namespace integrity, canonical identity preservation, core determinism
G5 Migration Provenance Validation Source references, transformation history, migration metadata
G6 Loss Manifest Validation Explicit declaration of omitted fields during lossy transformations
G7 Deterministic Rendering Validation Reproducibility under identical inputs, profiles, and metadata
G8 Round-Trip Integrity Reconstruction integrity for lossless profiles
G9 Canonical Fidelity No undeclared semantic drift in derived artifacts
G10 End-to-End Consistency Complete pipeline integrity from source to output
IC-1 Cryptographic Integrity & Artifact Manifest SHA-256 manifest verification for release outputs (generated by cut_release.py)
IC-2 Institutional Ledger & Ratification Founder/Institutional sign-offs and decision records (UFD ledger)
IC-3 License & Security Compliance CC BY 4.0 boundaries, software licenses, security disclosures

Architectural Note: The institutional release controls IC-1..IC-3 (highlighted in Institutional Gold) represent the Full Institutional Release boundary. They embody human accountability, cryptographic integrity, and legal compliance—ensuring that no automated system can bypass institutional ratification. Each control has its own handling mechanism: IC-1 through the release-cutting workflow (cut_release.py) and release-manifest generation/verification; IC-2 through the Founder/institutional ratification process and the UFD ledger; and IC-3 as an institutional licensing and security responsibility. None of IC-1..IC-3 is implemented as an automated gate ID in tests/run_e2e.py (which implements G1–G11). The executable semantics of the automated E2E gates are those implemented in tests/run_e2e.py and summarized in the Quick Start.

Fail-Closed Validation Policy

UAGF applies a fail-closed policy to validation conditions explicitly designated as blocking.

A release or transformation is valid only when all applicable blocking conditions have passed. For release purposes, the intended condition is:

A detected conflict may exist within source material or during migration without implying that the source itself is invalid. However, an unresolved conflict that is designated as blocking must prevent the affected knowledge from being released as validated canonical knowledge until the applicable governance or verification process resolves or explicitly disposes of it.

Where uncertainty, ambiguity, conflict, or missing information is detected, the system records and reports the condition according to the applicable migration, validation, and governance rules.

Reality Before Convenience

One of the constitutional principles of UAGF is: Reality First.

UAGF is designed to represent governance knowledge faithfully rather than silently making that knowledge appear more consistent than its underlying sources actually are. If governance knowledge contains inconsistencies, ambiguity, missing information, conflicting interpretations, or unresolved provenance, the system reports the condition rather than silently inventing a resolution.

Automated validation therefore does not replace human or institutional governance judgment. Instead, it provides structured evidence that enables such decisions to remain explicit, reviewable, traceable, and accountable.

Fundamental Distinction: UAGF validates representation against UAGF constraints. It does not confer external authority upon the represented governance knowledge.

Migration Pipeline

The Migration Pipeline transforms legacy governance material and other supported source representations into candidate CKM objects.

Migration is intentionally conservative. Its objective is preservation, traceability, and explicit transformation—not silent reinterpretation.

Authoritative Governance Source
        │
        ▼
Source Analysis / Mapping
        │
        ▼
Migration Transformation
        │
        ▼
CKM Staging
        │
        ▼
Validation & Governance Review
        │
        ▼
Canonical Knowledge Model

Every migrated object retains applicable information required to establish:

No migrated knowledge should enter the canonical knowledge layer without satisfying the applicable UAGF validation and governance requirements.

Migration Dispositions

Migration dispositions provide explicit machine-readable status for migrated knowledge.

Disposition Meaning
ACCEPTED Migrated into the applicable workflow without currently identified blocking issues.
TO_VERIFY Requires human or designated institutional verification before applicable release or canonicalization.
CONFLICT Competing interpretations, source conflicts, or unresolved semantic conditions have been detected.
REJECTED Explicitly excluded from the applicable canonicalization workflow.

These dispositions are not themselves statements of legal or regulatory authority. They describe the status of the migration and governance process within UAGF. A disposition may therefore change as verification, review, or governance decisions occur.

Provenance Preservation

Migration preserves historical and transformation context to the extent required by the applicable UAGF provenance rules.

For applicable migrated knowledge, provenance should allow the system to answer questions such as:

This provenance establishes traceable lineage between source material, canonical knowledge, and derived representations.

The objective is not merely to preserve document history. The objective is to preserve sufficient lineage for governance knowledge to remain:

Rendering Engine

The UAGF Rendering Engine transforms validated Canonical Knowledge Model (CKM) content into defined downstream representations.

Rendering is a transformation process. The Rendering Engine does not establish governance authority and does not independently create canonical governance knowledge.

Instead, it projects canonical knowledge represented within UAGF into representation-specific views according to defined rendering profiles and transformation rules.

The CKM remains the canonical knowledge representation maintained within UAGF. Derived artifacts do not acquire canonical status merely because they are published, distributed, or consumed by downstream systems.

Rendering profiles may therefore evolve, and additional representations may be introduced, without changing the underlying governance knowledge represented by the CKM.

Supported Rendering Profiles

UAGF may provide multiple rendering profiles for different consumption requirements.

Profile Format Characteristics
Registry Documentation Markdown Human-readable representation; may be declared-lossy.
Registry JSON JSON Structured machine-readable representation; losslessness subject to the applicable profile.
Registry JSON-LD JSON-LD Linked-data representation; preservation properties defined by the applicable mapping.
Registry RDF RDF/Turtle Semantic-web representation; preservation properties defined by the applicable mapping.
AI Context Plain Text Declared-lossy representation optimized for machine or LLM consumption.
Additional Profiles Profile-defined Governed by their respective transformation and fidelity rules.

A rendering profile is not itself a source of governance authority. Its preservation, transformation, and information-loss characteristics are defined by the applicable UAGF rendering specification.

Additional rendering profiles may be introduced without modifying canonical governance knowledge, provided that their transformation rules and validation requirements are explicitly defined.

Rendering Profiles and Preservation Semantics

Different representations may preserve different subsets or structures of the CKM. UAGF therefore distinguishes between:

Losslessness is therefore a property of a defined transformation profile, not an inherent property of a serialization format alone.

For example, JSON, JSON-LD, and RDF may support lossless representations under appropriately defined mappings, but their actual preservation guarantees depend on the corresponding UAGF rendering profile and transformation rules.

Declared Information Loss

Some rendering targets cannot preserve every property of the CKM. Examples may include:

When a rendering profile intentionally omits information:

  1. The omission must be defined by the applicable rendering profile.
  2. The omitted information must be recorded in the corresponding Loss Manifest where required.
  3. The reason or transformation condition must be identifiable.
  4. Reconstruction limitations must be declared where applicable.
  5. The resulting artifact must not be represented as preserving information that it intentionally discards.

A declared loss is therefore an explicit property of a transformation.

Core Principle: Declared loss is acceptable. Undeclared loss is not.

The purpose of the Loss Manifest is to make information loss observable and machine-processable rather than allowing it to remain implicit.

Rendering Fidelity

The Rendering Engine must preserve the applicable properties of canonical knowledge according to the requirements of each rendering profile.

These properties may include:

A rendering process must not introduce undeclared semantic modification. Where a transformation intentionally changes representation, structure, or information content, the applicable rendering profile must define that transformation and declare any resulting information loss or limitation.

Rendering Guarantees

Subject to the applicable rendering profile and transformation conditions, the Rendering Engine provides the following architectural guarantees:

Generated documentation and machine-readable artifacts are therefore derived representations of canonical knowledge maintained within UAGF, rather than independent sources of canonical knowledge.

Deterministic Rendering

Where deterministic rendering is required, identical:

…must produce reproducible outputs.

Deterministic rendering enables:

Determinism is therefore treated as an architectural property of applicable UAGF rendering processes rather than merely an implementation convenience.

Release Validation

A UAGF release represents a specific validated state of the Canonical Knowledge Model.

A release is eligible for publication only when the applicable technical and institutional release requirements have been satisfied:

If the implementation defines a different gate set or profile in the future, the authoritative validation specification and implementation take precedence over this documentation.

Only after the applicable release criteria have been satisfied may the resulting rendered artifacts be distributed as official derived outputs of the UAGF Canonical Knowledge Model.

Representation Authority Boundary

The Rendering Engine maintains a strict separation between canonical knowledge and its representations.

Canonical Knowledge Model
          │
          ▼
   Validation Kernel
          │
          ▼
 Rendering Profile
          │
          ▼
 Rendering Engine
          │
    ┌─────┼─────┬──────────┐
    ▼     ▼     ▼          ▼
 Markdown JSON-LD RDF   AI Context
    │     │     │          │
    └──────────┴──────────┘
              │
              ▼
       Derived Artifacts

The authority relationship is therefore:

This boundary prevents a generated document, API response, knowledge graph, or AI-context artifact from becoming an unintended competing source of canonical knowledge.

Governance

The Universal AI Governance Framework is governed using the same architectural principles it promotes.

UAGF treats governance knowledge as structured, traceable, and verifiable knowledge rather than as a collection of independently maintained documents.

Governance within UAGF therefore separates:

This separation prevents governance authority from being confused with the representation, processing, or publication of governance knowledge.

Governance Model

UAGF adopts a Model-First Governance Architecture.

The Canonical Knowledge Model (CKM) is the canonical governance knowledge representation maintained within UAGF.

The CKM provides the canonical semantic and structural layer through which governance knowledge is represented, related, validated, and transformed within the UAGF architecture.

The CKM does not replace or supersede the legal, regulatory, normative, or institutional authority of the governance sources from which its knowledge is derived.

Core Principle: Source authority remains with the authoritative source. Canonicality applies to the representation of governance knowledge within UAGF.

Governance activities therefore operate across multiple controlled stages rather than treating a document or rendered artifact as an independent source of authority.

These activities may include:

Each activity has a defined architectural or governance responsibility.

Core Governance Principles

Governance Lifecycle

UAGF separates candidate knowledge from established canonical knowledge.

A simplified governance lifecycle is:

Proposal / Source Material
          │
          ▼
   Staging / Candidate Object
          │
          ▼
   Provenance & Transformation
          │
          ▼
    Validation Kernel
       (G1–G10)
          │
     ┌────┴────┐
   FAIL       PASS
     │          │
     ▼          ▼
  Reject /    Review /
  Resolve    Ratification
                │
                ▼
       Canonical Knowledge
          Model (CKM)
                │
                ▼
       Release Validation
                │
                ▼
     Deterministic Rendering
                │
                ▼
           Publication
                │
                ▼
       Immutable Release

A failed validation gate prevents the relevant candidate or release from progressing through a blocking stage.

Automated validation does not replace human or institutional governance decisions where such decisions are required.

Ratification Note: Where Founder or institutional ratification is required, ratification remains an explicit governance decision and must be recorded through the applicable governance mechanism.

Contribution

UAGF accepts community contributions to the framework.

Contributors should modify the canonical knowledge layer or other explicitly designated source-controlled governance artifacts rather than manually modifying generated representations.

The repository distinguishes between source material that may be intentionally edited and representations that are derived by the rendering pipeline.

Category Examples Contribution Status
Canonical Knowledge Requirements, Governance Domains, Controlled Vocabulary, Reference Objects, Relationship Definitions, Canonical Metadata Acceptable
Governance / Decision Records Working Papers, ADRs, Ratification Records, Release Metadata Acceptable where applicable
Generated Artifacts Generated Markdown, JSON, JSON-LD, RDF, AI Context Packages Derived — not manually edited
Operational Reports Validation Reports, Migration Reports, Regression Reports, Rendering Diagnostics Generated Evidence — not canonical knowledge

Generated artifacts are not independent sources of governance knowledge.

Where generated artifacts are committed to the repository, they remain derived representations and must remain reproducible from their applicable source inputs and transformation rules.

Repository Integrity: Pull Requests that modify generated artifacts directly, without the corresponding source-level change or approved regeneration process, should be treated as repository integrity violations.

Validation and Governance Enforcement

The Validation Kernel functions as an architectural integrity gate within the UAGF processing pipeline.

It verifies whether candidate or release knowledge conforms to the structural, semantic, provenance, and pipeline constraints defined by UAGF.

The Validation Kernel does not determine:

Its role is to determine whether represented knowledge satisfies the applicable UAGF architectural constraints.

Where a validation gate is defined as blocking, failure terminates the relevant processing stage.

This fail-closed behavior prevents knowledge that violates defined UAGF constraints from propagating into downstream representations or releases.

Release Governance

A UAGF release represents a specific validated state of the Canonical Knowledge Model.

A release is eligible for publication only when the applicable release validation requirements have been satisfied.

These requirements may include:

The release process therefore establishes a controlled boundary between an evolving canonical knowledge repository and a published governance reference.

Immutable Releases

UAGF distinguishes between an evolving canonical knowledge repository and a published release.

The CKM may evolve through subsequent governed changes and versioned releases.

Once a release is published, the release snapshot is immutable.

An immutable release fixes:

Scope Clarification: The immutability of a release applies to that specific published state rather than to the continuously evolving CKM repository.

This enables governance knowledge to evolve while preserving historical release states as reproducible governance references.

Reproducible Governance References

A published UAGF release is intended to provide a reproducible reference point for governance knowledge represented within UAGF.

Given the same:

…the rendering process is expected to produce reproducible artifacts according to the determinism requirements defined by UAGF.

This enables:

Reproducibility Scope: Reproducibility applies to the defined processing conditions of a release and does not imply that governance knowledge itself is permanently immutable.

Working Papers

Architectural and governance evolution may be explored through Working Papers (WP).

Working Papers provide a controlled mechanism for exploring ideas without immediately modifying the canonical knowledge model.

Typical Working Paper topics may include:

Working Papers are informative and exploratory. They do not acquire normative status merely through publication.

A Working Paper becomes part of the canonical UAGF governance model only through the applicable review, validation, and governance process.

Architecture Decision Records

Major architectural decisions are recorded explicitly through Architecture Decision Records (ADRs) or equivalent governance artifacts.

ADRs may be required for changes affecting areas such as:

An architectural decision should record, as applicable:

This ensures that architectural evolution remains transparent, reviewable, reproducible, and historically traceable.

Governance Records and Evidence

Governance decisions and processing outcomes should remain distinguishable from canonical knowledge.

Governance records may include:

These records provide evidence of how UAGF knowledge and architecture evolved.

They do not automatically become canonical knowledge merely because they document a governance decision or processing result.

Where a governance decision changes canonical knowledge, the resulting canonical state must be represented through the CKM and subjected to the applicable validation and release process.

Governance Integrity Principles

UAGF governance is based on the following integrity principles:

Authority Before Representation

External legal, regulatory, normative, and institutional authority remains with its originating source. UAGF does not create authority merely by representing a source within the CKM.

Canonical Knowledge Before Representation

The CKM provides the canonical knowledge representation maintained within UAGF. Generated documents, APIs, knowledge graphs, and AI Context representations are derived views.

Evidence Before Assumption

Governance decisions and transformations should be supported by traceable evidence rather than undocumented assumptions.

Reality Before Convenience

Inconsistencies, ambiguity, missing information, and conflicts are reported rather than silently corrected.

Determinism Before Automation

Automation must operate according to defined deterministic rules and constraints.

Transparency Before Abstraction

Governance transformations, decisions, provenance, and declared information loss should remain observable and traceable.

Immutable Release State

Published releases preserve a specific validated state of the UAGF knowledge infrastructure even while subsequent versions continue to evolve.

Governance Boundary

UAGF governance can therefore be understood as a controlled relationship between four elements:

Authoritative Governance Sources
            │
            │ provenance / references
            ▼
   Canonical Knowledge Model
            │
            │ validation / governance
            ▼
    Validated Release State
            │
            │ deterministic rendering
            ▼
    Derived Representations

The architectural boundary is intentional:

This separation allows UAGF to provide a canonical knowledge infrastructure without becoming a competing source of legal, regulatory, or institutional authority.

Versioning

UAGF versioning describes the evolution of the Canonical Knowledge Model (CKM), its applicable schemas, validation constraints, controlled vocabularies, and governed release state.

Version changes may reflect:

A UAGF release identifies a specific validated state of the knowledge infrastructure at a defined point in its evolution.

Generated documentation and other derived representations inherit the relevant version and release metadata of the CKM state from which they were rendered.

Derived artifacts do not establish an independent canonical version of governance knowledge.

Their version and release metadata exist primarily to preserve:

Accordingly, a generated representation may carry its own artifact or format metadata while remaining non-canonical with respect to the underlying governance knowledge representation.

Version Evolution

UAGF distinguishes between changes to the representation of governance knowledge and changes to the governance knowledge itself.

Examples include:

Change Type Potential Version Impact
Schema evolution May require a new compatible or breaking version
New governance knowledge May result in a new knowledge release
Controlled vocabulary update May affect semantic compatibility
Identifier change May constitute a compatibility-impacting change
Validation rule change May affect release validity
Rendering profile change May affect derived artifact compatibility
Semantic change Requires explicit governance review and traceability
Breaking structural change Requires migration guidance

Version changes must remain explicit, reviewable, and traceable.

UAGF does not rely on undocumented changes between releases.

Compatibility

Compatibility is treated as a controlled architectural property rather than an unconditional guarantee.

Where compatibility is maintained, UAGF aims to preserve:

Compatibility may differ across:

A change that cannot preserve compatibility must be explicitly classified and governed.

Breaking changes require:

Most importantly:

UAGF does not introduce silent semantic shifts.

If the meaning of a canonical governance object changes, the change must be explicit, documented, reviewable, and traceable.

Where a change affects the relationship between a canonical object and its authoritative source, the relevant provenance and governance records must remain identifiable.

Reality First therefore applies not only to governance knowledge, but also to the evolution of the knowledge infrastructure itself.

Version Integrity

A versioned UAGF release should provide sufficient information to determine:

This allows organizations and researchers to distinguish between:

  1. What changed in the knowledge
  2. What changed in the architecture
  3. What changed only in its representation

Such distinctions are essential for long-term interoperability and governance traceability.

Public Ecosystem

The Universal AI Governance Framework is designed as a public knowledge infrastructure rather than a proprietary governance product.

Its purpose is to provide a shared, deterministic architectural foundation through which governments, standards organizations, researchers, enterprises, developers, technology providers, and civil society can structure and exchange AI governance knowledge.

UAGF does not require participants to adopt identical governance frameworks.

Instead, participants may preserve their own governance authorities, institutional processes, and implementation environments while using UAGF-compatible canonical representations and interoperability mechanisms where appropriate.

Because downstream artifacts are derived from the Canonical Knowledge Model, different participants can consume the same canonical release state through representations appropriate to their technical or operational environments.

These representations remain subject to their defined profiles, serialization characteristics, and declared information-loss constraints.

UAGF therefore promotes interoperability without requiring uniform implementation.

Public Good

UAGF is developed as an open public-good initiative.

Its objective is to make governance knowledge more accessible, structured, machine-readable, traceable, and reusable across jurisdictions, sectors, and technical environments.

The public-good model is based on several principles:

UAGF is intended to strengthen the broader AI governance ecosystem by providing infrastructure for connecting governance knowledge rather than establishing another competing source of legal, regulatory, or normative authority.

The framework therefore complements existing governance ecosystems rather than attempting to replace them.

Research

Academic and independent researchers require governance knowledge that is reproducible, citable, structurally analyzable, and computationally accessible.

The Canonical Knowledge Model can support research through:

Researchers can analyze canonical governance objects and their relationships without relying exclusively on manual extraction from heterogeneous document collections.

Where JSON, JSON-LD, RDF, or other representations are generated from the same CKM release state, researchers can work with consistent representations of the same canonical knowledge while preserving traceability to the source release.

This can support research areas including:

The CKM can therefore serve as a shared research substrate for computational and interdisciplinary study of AI governance.

Research Note: Generated representations remain subject to their respective profiles and declared information-loss characteristics. Researchers should therefore use the canonical release and provenance information when semantic or historical fidelity is material to their analysis.

Standards and Governance Community

UAGF is intended to support collaboration among communities that produce, interpret, implement, and study governance knowledge.

Potential participants include:

UAGF does not require these communities to relinquish their existing governance authorities.

Instead, the framework provides an architectural mechanism through which relationships between heterogeneous governance sources can be represented, validated, traced, and exchanged.

This allows interoperability to occur at the knowledge layer while preserving institutional independence.

Vendor Neutrality

UAGF is designed to remain vendor-neutral.

The Canonical Knowledge Model is not dependent on:

Implementations may use different technologies while preserving compatibility with the applicable UAGF knowledge and interoperability requirements.

This separation allows organizations to adopt UAGF without creating architectural dependence on a particular technology provider.

Interoperability Without Uniformity

UAGF does not define interoperability as requiring every organization to implement governance in the same way.

Instead:

Institution A Governance
          │
          ▼
   Canonical Representation
          │
          ├──────────────┐
          ▼              ▼
   Machine Interface   Human View


Institution B Governance
          │
          ▼
   Canonical Representation
          │
          ├──────────────┐
          ▼              ▼
   Knowledge Graph     AI Context

The purpose of the canonical layer is to establish shared semantic and structural interoperability while allowing institutions to retain their own governance processes, authorities, controls, and implementation environments.

This distinction is fundamental to the public ecosystem model of UAGF.

Public Ecosystem Principle

The public ecosystem can therefore be summarized as:

Shared canonical knowledge does not require shared institutional authority or identical implementation.

UAGF provides the infrastructure for interoperability while preserving:

The result is an ecosystem in which governance knowledge can be shared and computationally reused without requiring the underlying governance institutions to become identical.

Government

Governments increasingly operate across multiple legal frameworks, regulatory bodies, national policies, and international standards.

UAGF provides a canonical knowledge infrastructure through which governance knowledge originating from these heterogeneous sources can be structured, related, validated, and exchanged while preserving the original authority of each source.

Potential applications include:

Boundary Note: UAGF does not replace legislation, regulation, or institutional authority. It provides an architectural layer for representing relationships among governance knowledge while preserving source authority and provenance.

Public-sector systems may use UAGF-derived representations to reduce duplicated manual interpretation, improve traceability, and support more consistent governance processes across organizational boundaries.

The resulting interoperability is intended to improve governance coordination without requiring government institutions to surrender their existing legal mandates, regulatory responsibilities, or institutional decision-making authority.

Enterprise

Enterprises frequently operate under overlapping governance obligations.

A single organization may simultaneously be subject to:

The Canonical Knowledge Model provides a structured semantic layer through which these heterogeneous governance sources can be represented and related within UAGF.

Enterprise systems may therefore use UAGF-compatible infrastructure to:

UAGF does not determine whether an enterprise is legally or normatively compliant.

Instead, it provides infrastructure that can help organizations structure, trace, validate, and operationalize governance knowledge derived from the authorities applicable to their environment.

Deterministic transformation and explicit provenance can reduce operational ambiguity while supporting scalable governance automation.

Developers

Developers and engineering systems can interact with structured representations of the Canonical Knowledge Model rather than relying exclusively on manually interpreted documentation.

Because canonical knowledge is represented as structured objects, compatible software systems can integrate governance knowledge directly into engineering and operational workflows.

Potential integration scenarios include:

Potential machine-readable representations include:

These representations are derived from the CKM and remain subject to their applicable rendering profiles and declared information-loss characteristics.

Where a representation is lossless for its defined purpose, it may preserve the relevant canonical structures required for machine processing. Where a representation is intentionally lossy, its associated Loss Manifest identifies the relevant omissions and constraints.

This allows developers to consume governance knowledge through machine-readable interfaces while maintaining traceability to the canonical release from which the representation was derived.

Community

Community participation is essential to the long-term evolution of UAGF.

UAGF encourages contributions from individuals and organizations while preserving the deterministic governance and validation principles of the framework.

Community contributors may propose:

Community participation does not itself grant normative or institutional authority.

Contributions become part of the canonical knowledge infrastructure only through the applicable UAGF governance, review, validation, and approval processes.

Every contribution is therefore subject to the same architectural constraints regardless of contributor.

Reality First remains a governing principle:

Accepted contributions should preserve:

Future Expansion

The architecture of UAGF is intentionally designed for long-term evolution.

Because governance knowledge is separated from its representations, new capabilities can be introduced without requiring the Canonical Knowledge Model to become dependent on a particular presentation technology.

Potential future capabilities may include:

Each capability should consume the applicable Canonical Knowledge Model and release state rather than establishing an independent competing source of governance knowledge.

New capabilities may introduce new representations, interfaces, or processing mechanisms, but they must remain subject to the applicable UAGF architectural constraints.

The architecture therefore allows UAGF to evolve alongside advances in:

The long-term objective is to provide a stable knowledge infrastructure through which governance ecosystems can evolve without repeatedly recreating the same underlying knowledge in incompatible forms.

Release Checklist

A UAGF release is considered eligible for publication only when the applicable technical, governance, and documentation requirements have been satisfied.

Technical Gates

Technical release gates should be enforced automatically wherever the relevant checks are implemented in CI/CD.

Governance Gates

Governance gates require explicit human or institutional action where authority cannot be delegated to automated validation.

Documentation Gates

Note: A release checklist records release readiness. It does not itself confer legal, regulatory, or institutional authority.

Known Pending Items

The following items represent known outstanding conditions associated with the current release state.

Ledger Counter-Signature

The decisions_register: LEDGER-SIGN item remains pending Founder manual sign-off.

This is an institutional governance action rather than a technical validation failure.

Until the required sign-off is completed, the corresponding governance state should remain explicitly identified as pending.

D-06 Source Verification

The D-06 source-verification pass has not yet been completed.

External-law locators associated with the current release carry pending-verification status.

Accordingly, references to specific legal articles, clauses, or locators must not be represented as independently verified until the required source-verification process has been completed.

Batch B Remainder

Of the 15 requirements approved under D-02, 12 have not yet been activated.

The current release therefore contains:

This produces a current release population of 33 requirements.

The remaining approved-but-not-activated requirements should remain distinguishable from active canonical knowledge until their applicable activation process is completed.

Security Contact

SECURITY.md currently contains a placeholder security contact pending Founder designation.

Until a permanent contact is designated, the placeholder should remain explicitly identifiable rather than being presented as an active institutional security contact.

Release-State Transparency

Known pending items are part of the observable governance state of a release.

UAGF does not treat incomplete governance actions as failures to be hidden or automatically repaired.

Instead, pending conditions should remain:

This reflects the Reality First principle:

An incomplete governance state must be represented as incomplete rather than being presented as complete for convenience.

The purpose of release-state transparency is to ensure that users, implementers, auditors, researchers, and other ecosystem participants can distinguish between:

This distinction allows UAGF releases to remain auditable without implying that technical validation alone constitutes legal, regulatory, or institutional approval.

Appendix

Roadmap

The long-term evolution of UAGF focuses on strengthening the Canonical Knowledge Model (CKM) as a universal governance knowledge infrastructure rather than expanding documentation as an independent source of authority.

Future development priorities include:

The roadmap is intentionally incremental.

New capabilities are introduced by extending the Canonical Knowledge Model and its defined transformation, validation, and rendering mechanisms rather than by creating parallel sources of governance knowledge.

UAGF therefore aims to evolve its capabilities while preserving the separation between: Authoritative Governance Sources → Canonical Knowledge Representation → Derived Representations

Citation

Researchers, standards organizations, governments, enterprises, and other users are encouraged to cite UAGF when referencing its architecture, governance model, or Canonical Knowledge Model.

Plain Text Citation

SATHIRA Institution. Universal AI Governance Framework (UAGF): A Canonical Knowledge Infrastructure for Interoperable AI Governance. Version 2.0.0-alpha. Available at: https://github.com/SATHIRA-Institute/uagf-ckm

BibTeX

@software{uagf2026,
  title        = {Universal AI Governance Framework},
  subtitle     = {A Canonical Knowledge Infrastructure for Interoperable AI Governance},
  author       = ,
  version      = {2.0.0-alpha},
  year         = {2026},
  url          = {https://github.com/SATHIRA-Institute/uagf-ckm},
  note         = {Model-First AI Governance Knowledge Infrastructure}
}

License

The UAGF project includes both governance knowledge and software tooling. These components are treated according to their respective licensing terms to maintain explicit boundaries.

The documentation and Canonical Knowledge Model (CKM) are released under the Creative Commons Attribution 4.0 International License (CC BY 4.0), unless otherwise specified by the repository’s applicable license files.

Under CC BY 4.0, users are free to:

Under the following condition:

Software tooling, including validation, migration, rendering, and reference implementation code, is governed by the specific software license declared for those components.

Licensing Note: The repository maintains explicit licensing boundaries between governance knowledge, documentation, and software code to avoid ambiguity regarding reuse and derivative works.

See the full CC BY 4.0 license text at: https://creativecommons.org/licenses/by/4.0/

Acknowledgement

UAGF is inspired by decades of work across the international governance, standards, semantic web, systems engineering, knowledge representation, and open-source communities.

The framework does not attempt to replace existing standards, regulations, or institutional governance processes. Instead, UAGF provides a canonical knowledge layer through which governance knowledge originating from heterogeneous authoritative sources can be represented, related, validated, and transformed into interoperable representations.

Credits

UAGF has been designed around several foundational architectural principles:

These principles collectively shape the architecture of the Universal AI Governance Framework.

Contact

Channel Link
Official Website https://sathira.institute
GitHub Repository github.com/SATHIRA-Institute/uagf-ckm
Issue Tracker github.com/SATHIRA-Institute/uagf-ckm/issues
Maintainer Apichai Chuensuang (Rootz), SATHIRA Institution
Community Discussions github.com/SATHIRA-Institute/uagf-ckm/discussions

Final Closing

“Artificial intelligence will increasingly participate in decisions that affect individuals, organizations, and societies.

As governance becomes more complex, documentation alone is no longer sufficient.

Governance knowledge must be deterministic. It must be machine-readable. It must be verifiable. It must remain internally consistent across diverse governance sources, representations, and systems.

The Universal AI Governance Framework is built on that principle.

Its purpose is not merely to publish documentation, but to establish a Canonical Knowledge Infrastructure through which governance knowledge can be structured, validated against defined architectural constraints, traced to authoritative sources, and rendered into interoperable representations across the global AI governance ecosystem.

Documentation may evolve. Rendering formats may change. Technologies will continue to advance.

Within UAGF, the Canonical Knowledge Model remains the single canonical source for the structured representation of governance knowledge.

Everything else is a derived representation.

Reality First.”

Developed by SATHIRA Institution as a public-good initiative.
Technology must remain accountable to humanity.

This site is open source. Improve this page.