Ontology: how concepts connect and what depends on what

What it is

An ontology is a formal description of the concepts in your domain and how they relate. It answers: What entities exist (Order, Customer, Payment, Shipment)? What are the relationships between them (Order placed_by Customer, Order has_one Payment, Order has_many Shipments)? What dependencies and rules hold (a Refund must reference a Payment; an Order in status “shipped” must have at least one Shipment)? The ontology makes the structure of your domain explicit so that pipelines, analytics, and AI can reason over relationships instead of guessing — and so that “tell me everything about this order” knows to pull in customer, payment, shipment, and support ticket.

How it’s made

An ontology for a governed data product (or a domain) is built and stored as follows:

• Entity list and relationship graph. You define the entities (nodes) and the typed relationships (edges). Each relationship has a name and cardinality (e.g. Order → placed_by → Customer, one-to-one). This can be represented as a graph model (e.g. in a catalog or a dedicated ontology store) or as a set of tables and foreign keys with business labels.
• Keys and join paths. For each relationship you specify how to join: e.g. Order.customer_id → Customer.id. That’s how the process graph and queries know how to traverse from “this order” to “this customer” and “this customer’s support tickets.”
• Business rules (optional). You can attach rules such as “Refund.approved implies Refund.payment_id is not null” or “Order.status = delivered implies at least one Shipment with status delivered.” These can be used for validation or for AI to reason about consistency.

Example ontology fragment for an ecommerce domain:

{
  "entities": ["Order", "Customer", "Payment", "Shipment", "SupportTicket", "Refund"],
  "relationships": [
    { "from": "Order", "to": "Customer", "role": "placed_by", "cardinality": "n:1", "join": "Order.customer_id = Customer.id" },
    { "from": "Order", "to": "Payment", "role": "paid_by", "cardinality": "1:1", "join": "Order.id = Payment.order_id" },
    { "from": "Order", "to": "Shipment", "role": "fulfilled_by", "cardinality": "1:n", "join": "Order.id = Shipment.order_id" },
    { "from": "Customer", "to": "SupportTicket", "role": "opened", "cardinality": "1:n", "join": "Customer.id = SupportTicket.customer_id" },
    { "from": "SupportTicket", "to": "Order", "role": "about", "cardinality": "n:1" },
    { "from": "Refund", "to": "Payment", "role": "refunds", "cardinality": "n:1", "join": "Refund.payment_id = Payment.id" }
  ]
}

The ontology is stored as part of the governed data product’s metadata or in a domain-level ontology service. When you build the process graph or run a “full context” query, the system uses this graph to know which entities to traverse and how to join them.

Why it matters for governed data products and AI

Without an ontology, “everything about this order” is undefined — you’re left to hand-wire every join. With an ontology, the governed data product (and Loxtep’s process graph) knows exactly which entities to pull in and how they connect. AI can use the same structure to reason (“this refund relates to this payment, which relates to this order”) and to explain its answers. In Loxtep, the ontology underpins how we build and serve the process graph so the context we deliver is structurally correct and complete.