Domain Ontologies

The governance layer that gates AI proposals

Ontologies operate above AI generation. The AI has no awareness of them — simulators propose freely, and the completeness gate determines whether that proposal becomes authoritative output.

Architectural Position

The ontology operates above AI generation. The AI has no awareness of it — simulators propose, and the completeness gate vetoes.

An ontology is not a constraint the AI is aware of. It is a completeness gate that intercepts AI proposals after generation.

How the Gate Works

An ontology object is a JSON structure that declares completeness requirements for a specific domain. The AI generates proposals without knowledge of these requirements; the governance layer then evaluates whether that output meets the requirements for authority.

┌─────────────────────────────────────────────────────────────────┐ │ AI GENERATION │ │ ┌──────────────┐ ┌──────────────────────────────────────────┐ │ │ │ Simulator │→ │ Proposal (AI generates freely) │ │ │ └──────────────┘ └──────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────────┘ │ ▼ intercepted by ┌─────────────────────────────────────────────────────────────────┐ │ COMPLETENESS GATE │ │ ┌──────────────┐ ┌──────────────────────────────────────────┐ │ │ │ Ontology │→ │ Check Required State → Verify Authority │ │ │ │ (defines │ │ (evaluates proposal against ontology) │ │ │ │ requirements)│ └──────────────────────────────────────────┘ │ │ └──────────────┘ │ └─────────────────────────────────────────────────────────────────┘ │ ┌────────────┴────────────┐ ▼ ▼ ┌─────────────────┐ ┌─────────────────────────────┐ │ ✓ AUTHORIZED │ │ ⚠ REQUIRES_SPECIFICATION │ │ Output gains │ │ Proposal vetoed │ │ authority │ │ Missing: [parameter_list] │ └─────────────────┘ └─────────────────────────────┘

Ontology Components

The ontology object declares what the gate checks for. The AI has no awareness of these requirements — they exist only within the governance layer.

1 State Axes

Define the dimensions the gate checks—enums, ranges, identifiers, timestamps. These are the controlled axes of reality.

2 Required State

Declare which axes must have values before the gate will approve an AI proposal as authoritative.

3 Authority Requirements

Specify verification methods and multi-factor requirements the gate enforces before granting authority.

Example: Consumer Nutrition Ontology

This example shows how a nutrition domain configures its ontology to prevent AI from making unsupported dietary claims.

{
  "ontology_id": "nutrition_consumer_v1",
  "label": "Consumer Nutrition",
  "domain": "nutrition",
  
  "state_axes": [
    {
      "key": "product_category",
      "type": "enum",
      "allowed_values": ["food", "supplement", "beverage", "infant_formula"]
    },
    {
      "key": "claim_type",
      "type": "enum",
      "allowed_values": ["health_claim", "nutrient_content", "structure_function"]
    },
    {
      "key": "serving_size_g",
      "type": "range",
      "range": { "min": 0, "max": 1000 }
    },
    {
      "key": "lab_certificate_id",
      "type": "identifier",
      "description": "Reference to certified lab analysis"
    }
  ],
  
  "required_state": {
    "always": ["product_category", "serving_size_g"],
    "conditional": [
      {
        "when": { "claim_type": "health_claim" },
        "require": ["lab_certificate_id"]
      }
    ]
  },
  
  "authority": {
    "default_action": "deny",
    "requires_human_approval": true,
    "min_factors": 2,
    "allowed_sources": ["certified_lab", "government_registry", "database"]
  }
}

Note on graduated authority: This example demonstrates graduated authority—single-factor verification by default, escalating to multi-factor only when medications are present. It models consumer nutrition guidance, not clinical dietetics, which would require stricter human-in-the-loop requirements.

Supported Domains

Each domain has unique requirements based on its regulatory environment and operational stakes.

🏥 Healthcare — Clinical decision support, diagnosis assistance High Stakes
💰 Finance — Transaction authorization, risk assessment High Stakes
⚖️ Legal — Contract analysis, compliance validation High Stakes
🛡️ Child Safety — Content moderation, age-appropriate classification High Stakes
🏛️ Government — Eligibility verification, benefit distribution High Stakes
🍎 Nutrition — Dietary guidance, allergen warnings Medium Stakes
🔧 Engineering — Safety calculations, specification validation High Stakes

Key Concepts

Completeness Gate

A validation boundary that blocks authoritative output until all required state is explicitly provided. Refusal is not a failure state; it is the correct outcome when required state is missing.

Multi-Factor Authority

High-stakes decisions may require multiple independent verification sources. The ontology specifies which factor types are acceptable and how many are required.

Conflict Resolution

When oracles disagree, the ontology defines how to detect and handle the conflict—whether to expose it to users, require human review, or apply domain-specific resolution rules.

High-Stakes Escalation

Certain state combinations trigger escalation rules—requiring human approval, additional verification factors, or routing to specialized review processes.

Cross-Domain Comparison

The same structural primitives adapt to each domain's regulatory and operational requirements.

Aspect	Healthcare	Finance	Nutrition
Required State	patient_id, icd_code, physician_approval	account_id, transaction_type, kyc_verified	product_category, serving_size
Min Factors	3	2	1-2 (graduated)
Human Approval	Always required	Above threshold	For health claims
Default Action	Deny	Deny	Deny
Authority Sources	Physician, Lab, Registry	Database, API, Registry	Certified Lab, Registry

Build Your Own Ontology

Use our interactive builder to define state axes, configure required state logic, and set up authority requirements for your domain.

Open Ontology Builder → View Architecture