Ontology Ops Kit

Most organizations fail at standardizing language because they put definitions in wikis instead of deployment pipelines.

If “Active Customer” requires interpreting a Visio diagram on Slack, it isn’t a source of truth—it’s folklore.

This kit shifts ontology work into version control. It provides a copy-pasteable schema to treat business definitions exactly like API contracts.

The Semantic Schema

Instead of relying on tribal knowledge, definitions are captured as YAML. When an engineer builds a new service or an AI agent attempts to query a billing dataset, it doesn’t try to guess your domain context; it pulls this semantic asset directly from the registry.

Here is a lightweight OntologyDomain starter schema you can drop right into your repository:

apiVersion: semantics.artemis.owl/v1
kind: OntologyDomain
metadata:
  name: customer-domain
  # We enforce SemVer to cleanly surface breaking changes in meaning
  version: 2.1.0 
  owner: platform-billing-squad
terms:
  - name: ActiveCustomer
    summary: "An identity that has completed a billable transaction in the last 30 days."
    # What something is not is often more important than what it is
    exclusions: ["Trial Users", "Paused Subscriptions", "Internal Test Accounts"]
    aliases: ["Billed User", "Current Subscriber"]
    # Mapping fields ground the concept to the actual infrastructure
    mappings:
      primarySource: "postgres.billingdb.public.subscriptions"
      statusColumn: "billing_status='active'"
      # Only add enough mapping here to direct a developer or agent to the system of record

This isn’t about modeling the universe. It’s about building a tight scope boundary. The mapping fields intentionally anchor the theoretical definition to the physical data layer.

Versioning Meaning (SemVer for Business Terms)

If you let definitions mutate silently, you will cause an incident. We borrow from Semantic Versioning to track changes in meaning.

Any time you change a term in the YAML, bump the version:

• Major (v2.0.0): You changed a definition in a way that breaks existing assumptions. (e.g., You decide “ActiveCustomer” no longer includes people on free trials. Dashboards are going to drop 15%—this is a breaking change.)
• Minor (v1.1.0): You added a new term to the domain or added a new alias to an existing term. It expands capability but breaks nothing.
• Patch (v1.0.1): You fixed a typo or clarified the wording without changing the actual boundaries of the definition.

By treating semantic shifts as breaking API changes, you force the organization to look at the blast radius of their words before they use them.

Grounding AI Agents via MCP

Strict semantics are a prerequisite to keep AI agents from hallucinating.

If you tell an agent to “Delete test accounts,” it must know your specific definition of “test account” before it zeroes out the CEO’s profile.

We use this kit as an “SDK for Meaning”:

1. CI publishes the OntologyDomain YAML.
2. The schema is injected into the Model Context Protocol (MCP) server.
3. Agents read the explicit definitions bound to the runtime rather than guessing based on training weights.

It’s less romantic than AGI, but results in fewer outages.