Governance Ontology
The governance ontology is AIGP’s shared map of AI records and how they relate, including assets, tests, decisions, jobs, replays, and activity history.
Overview
The ontology is the authoritative business model of AIGP; all storage models, APIs, graph projections, UI views, and AI reasoning are derived representations. It is intentionally independent of a graph database, relational schema, API transport, or UI. Storage engines project the ontology; they do not define it.
Think of an ontology as a well-labelled map of an AI system. A model, dataset, policy, experiment, decision, and execution are places on the map. The lines between them explain how those places are connected: for example, which policy governed a decision or which model and dataset were used in an experiment. It helps people answer not just what happened?, but also why did it happen?.
The Ontology Explorer is the starting point for understanding how governed AI assets, evidence, decisions, and operational activity fit together. It presents the same canonical ontology used by APIs and graph storage; it does not create a separate copy of governance data.
Start in Explore by typing a familiar name, such as a model, dataset, policy, prompt, decision, or experiment. Suggestions are grouped by entity type and remain tenant-scoped. Searching only finds a starting point; the graph is loaded after you choose an entity.
After choosing an entity, Explore shows its immediate neighbourhood: the useful nearby facts and relationships rather than every record in the graph. Select a node to focus it, inspect it for more detail, or expand one hop at a time when you need a wider view.
Selecting a node highlights its directly connected nodes and relationship labels. This is a visual aid only: exploring, highlighting, and opening details never changes the underlying ontology.
Open the contextual inspector only when you need it, so the graph keeps its full width while you explore. In Explore it prioritises plain-language properties, governance context, relationships, decisions, evidence, and executions.
Explore and Technical Views
The Explorer has two views over the same ontology. They use the same entity IDs, relationships, permissions, tenant/project boundaries, and APIs. Switching views changes how much technical detail is shown; it does not change, copy, or reinterpret the data.
Explore: start with a question
Explore is the default view. It is designed for people who know the business question but do not need to know graph terminology. Search for something familiar, choose it, and follow the labelled connections. For example: find a Fraud Detection Model, see which experiments used it, then inspect the policies and decisions connected to those experiments.
Use Filters only when you need to narrow the view. You can choose how many hops to show, whether to look upstream, downstream, or both, and which kinds of nodes or relationships matter. Sensible defaults keep the first view small and understandable.
Technical: inspect the wiring
Technical is for engineers, support teams, and graph investigators. It exposes the exact entity type and ID, traversal depth and direction, raw relationship names, node and edge properties, and schema metadata. Use it when diagnosing an integration, comparing a response with an API payload, or tracing a precise graph path.
If you select an entity in Explore and switch to Technical, you stay on that exact underlying entity and preserve the current graph context.
A simple way to explore
- Search for the model, dataset, policy, decision, prompt, or experiment you recognise.
- Choose the matching result and read the labelled connections around it.
- Select a node and open Inspect when you need evidence, decisions, or properties.
- Expand one hop or use Filters only when the first view does not answer your question.
- Switch to Technical when you need exact IDs, raw types, or traversal controls.
Entity Taxonomy
Every first-class entity has stable identity, ownership, lifecycle state, and versioning rules.
Actor
External identity provider, human operator, service account, or MCP agent. Lifecycle: active, disabled, unknown.
Prompt & PromptVersion
A Prompt is a logical family; changes to content create a new PromptVersion. Lifecycle: DRAFT, ACTIVE, DEPRECATED, ARCHIVED.
Model & ModelVersion
Model metadata changes that affect reproducibility create a new ModelVersion. Lifecycle: DRAFT, ACTIVE, DEPRECATED, ARCHIVED.
Dataset
Versioned dataset metadata for governed evaluation use. Lifecycle: DRAFT, ACTIVE, DEPRECATED, ARCHIVED.
Experiment & ExperimentCandidate
An Experiment defines a comparison space. An ExperimentCandidate is an immutable AI configuration binding prompt, model, dataset, evaluation provider, and runtime parameters.
EvaluationResult & EvaluationRun
EvaluationResult is metric evidence for a single execution. EvaluationRun links an experiment candidate to a governed evaluation attempt.
GovernanceDecision
Captures the decision type, status, ontology-aligned target, evidence references, policy references, provenance, confidence, and supersession metadata.
GovernancePolicy
A versioned, deterministic policy definition for producing governance-oriented outcomes from structured evidence. Evaluated by GovernancePolicyEvaluator.
Relationships
Relationships are directed and named from source to target. They describe durable semantics; events describe temporal facts.
SUBMITS → EvaluationResult DEPENDS_ON → PromptVersion, ModelVersion, Dataset CONTAINS → ExperimentCandidate EVALUATED_BY → EvaluationProvider PRODUCES → GovernanceDecision GOVERNED_BY → GovernancePolicy SUPERSEDES → GovernanceDecision (older) EVIDENCE_FOR → GovernanceDecision
Actions and Events
Actions are imperative (e.g., CreateExperiment, EvaluateDecision). Events are past-tense (e.g., ExperimentCreated, EvaluationCompleted).
ExperimentCreated → Experiment EvaluationCompleted → EvaluationResult DecisionFinalized → GovernanceDecision DriftDetected → DriftAnalysis JobQueued → Job MCPAuditStarted → MCPAuditRecord
Deterministic Projection
The graph is a projection of relational state, not a second source of truth. Given the same relational records, projection always produces the same nodes and relationships. This determinism is what makes the graph safe to rebuild and verify.
Neo4j Deployment Schema
Neo4j is a queryable projection of the ontology, not a second system of record. On a normal Compose startup, the one-shot schema service runs after Neo4j becomes healthy and before the Platform API starts. It creates the required constraints and indexes idempotently.
This includes the ontology_entity_searchfull-text index used by Ontology Explorer's type-ahead entity discovery. Neo4j populates the index from existing entity properties, and the Platform waits for it to become ONLINE before starting. A fresh Neo4j volume is therefore ready for entity search automatically.
docker compose up -d --build # Optional verification in Neo4j Browser SHOW INDEXES YIELD name, type, state WHERE name = 'ontology_entity_search' RETURN name, type, state;
Starting only the Platform container bypasses this deployment dependency. Use the Compose startup path when provisioning or recreating the graph.
Hashing & Reconciliation
Each projected entity carries a projection hash computed from its canonical fields. Alongside the node hash, AIGP hashes the full set of a node's relationships. A change in either hash marks the node for reconciliation, allowing incremental repair instead of full re-projection.
Ontology Versioning
The ontology version follows SemVer. Patch changes clarify wording or add non-normative examples. Minor changes add optional entities, relationships, attributes, actions, or events without changing existing semantics. Major changes rename or remove entities, relationships, required fields, or lifecycle meanings.
Existing entity and relationship names remain valid for the full major version. Deprecated concepts must remain documented with replacement guidance for at least one major version.