Ontology

An ontology gives your data a shared, typed vocabulary: the classes in your domain, the relations between them, and what those relations imply. The platform uses it to admit data, to derive facts that were never stated directly, and to scope queries and security rules by relationship.

PreviewAdvanced integration

The model#

Element	Meaning
Class	A kind of thing: `Customer`, `Order`, `Policy`. Classes can have parents.
Property (relation)	A typed edge between classes, with a domain (the source class) and a range (the target class), plus flags that give it meaning (below).
Property chain	A rule of the form "p then q implies r".
Edge	One relation between two entities. Edges are either asserted (you stated them) or derived (the reasoner inferred them).

Admission: from data to facts#

Data never enters the ontology directly. Each signal is first lowered into a typed assertion: an entity, a scalar attribute, a relation between entities, or a fact-relation between two facts. Admission then checks the assertion against the active vocabulary.

Mode	Use it for	Unknown terms
Open	Discovery: new domains, conversation, documents	Become candidates you can review and promote
Closed	Hard product and system facts, and fixed reference corpora	Rejected, with a diagnostic naming what is missing

A statement such as "I have a son called Aidan" is admitted because it matches the general entity-and-relation shape, not because the word son is special. If a signal cannot be lowered into one of the four assertion kinds, admission fails with a diagnostic saying which shape was missing.

Supported relation semantics#

These are the edge semantics the reasoner supports today, with examples from the platform's own vocabularies and tests.

Semantics	What it means	Example
Class hierarchy	A class inherits its parents' relations; queries on a parent include children.	`CommercialPolicy` is a `Policy` (illustrative)
Domain and range	Types both ends of a relation.	`placedBy`: `Order` → `Customer`
Functional	At most one target per source; checked on write; makes joins to-one.	an order is `placedBy` exactly one customer
Inverse	Asserting one direction materializes the other.	`hasChild` ↔ `hasParent`; `placedBy` ↔ `placed`
Symmetric	A→B implies B→A.	`spouse`, `peerOf`
Transitive	Chains of the same relation close.	`ancestorOf`; `containsBoundary`
Sub-property	An edge also asserts its more general relation.	`brother` is a sub-property of `sibling` and `related_to`
Property chain	Two hops imply a third relation.	`placedBy` then `memberOf` implies `placedInOrg`
Computed composition	Relative relations derived from an anchor.	anchor `son` + candidate `sister` infers `aunt`
Fact-relation	A relation between two facts, not two entities.	one clause `overrides` another (illustrative)
Cardinality and lifecycle	Relation cardinality plus what happens on delete: cascade, orphan removal, unlink, or block while referenced.	`parentTerritory` many-to-one; block delete while referenced

Declared but not enforced today: disjoint classes and same-as are stored but not checked. Equivalent classes and part-of are not supported.

Declaring relations#

version: 1
classes:
  - id: Order
  - id: Customer
  - id: Organization
properties:
  - id: placedBy
    domain: Order
    range: Customer
    functional: true
  - id: memberOf
    domain: Customer
    range: Organization
  - id: ancestorOf
    domain: Organization
    range: Organization
    transitive: true
  - id: placedInOrg          # implied by the chain below
    domain: Order
    range: Organization
chains:
  - chain: [placedBy, memberOf]
    implies: placedInOrg

Derived edges and provenance#

When an edge is written, a forward-chaining reasoner applies inverse, symmetric, transitive, sub-property and chain rules. It materializes each derived edge together with the rule that produced it and the edges that support it. If a supporting edge is removed, derived edges that no longer have a justification are pruned. Edges also carry validity dates, confidence and security labels.

Computed relations can be materialized eagerly (stored), lazily (cached on first read) or on demand.

Using edges#

In queries#

Filter by relationship directly in the query grammar:

status:OPEN && hasEdge(placedInOrg, ORG-ACME)

This returns open orders placed by any customer who is a member of ORG-ACME. Nobody stored that edge; the chain derived it.

In security rules#

Scope what a person can see by their relationships:

hasIncomingEdge(canSeeLocation, ${principalId})

Rule scripts can also use hasEdge, hasIncomingEdge, hasAnyEdge, hasAllEdges and relatedIds. A relation that does not apply to the queried class, or an empty edge set, matches nothing: the rule fails closed.

In joins across sources#

A relation with join-key metadata tells the binding layer how to join two sources that hold its two classes. See Data binding.

Where this runs#

Hosted platform: ontology admission by version, edge materialization, hasEdge queries and rules, and conversational retrieval over admitted facts Preview.
Embedded decision core: packs read typed state, not the ontology graph. Pass the facts a decision needs as input, as shown in Resolving overlapping sources. Resolving ontology facts directly into pack state is Planned.