Analytics Glossary
In business data, an ontology is a formal, machine-readable model of the entities your organisation cares about — customers, products, machines, orders — and the relationships between them. It gives every system and every AI agent one shared definition of what your data means, and it is the backbone of knowledge graphs and semantic layers.
An ontology defines three things: which kinds of entities exist, how they relate, and which rules constrain them. Filled with your actual data, it becomes a knowledge graph.
The ontology declares entity types (Customer, Machine, Order), the relationships between them (a Customer places an Order; a Machine produces a Batch) and constraints (every Order belongs to exactly one Customer). Stanford's classic guide "Ontology Development 101" describes this modelling discipline.
The ontology is the schema; the knowledge graph is that schema instantiated with real records and their links. Queries can then traverse relationships — "which customers are affected by this machine's downtime?" — instead of joining tables by hand.
Ontologies come from decades of AI and semantic-web research, but Palantir popularised the term for operational enterprise data, making the ontology the interaction layer between source systems and decision-making applications. The concept itself is vendor-neutral.
Illustrative business entities, documents and external signals joined by typed, labelled relationships.
Note the shape: a mesh with cross-links and cycles — Customer, Order and Invoice loop back on each other, and returns trace through quality lots to suppliers. That is what distinguishes an ontology-backed knowledge graph from a star schema, which forces everything through one central table. Dashed edges are relationships Adaptrix discovered automatically, with no foreign key declared anywhere.
Most analytics failures are semantic, not technical: two teams compute "active customer" three different ways, and AI agents inherit the confusion. An ontology fixes the meaning once, so every downstream question starts from the same reality.
Adaptrix builds a semantic model of your connected sources automatically — entities, relationships and metric definitions inferred from schemas and usage, then refined by your team — so its AI agents query one consistent picture of the business. You get the practical benefits of an ontology without a multi-year modelling programme or a Palantir-scale engagement.
Keep building your analytics vocabulary.
A semantic layer defines metrics and dimensions for BI — revenue, active users, margin — so every dashboard computes them the same way. An ontology is broader: it models the entities themselves and their relationships, covering operational questions beyond metrics. In practice a semantic layer is often the BI-facing slice of an ontology.
The ontology is the schema — the types, relationships and rules. The knowledge graph is that schema populated with real instances: your actual customers, machines and orders, connected. One ontology can back many graphs.
No. Ontologies have decades of history in AI and the semantic web — from formal definitions in 1990s knowledge engineering to W3C standards such as OWL. Palantir's contribution was popularising the term for operational enterprise data and making the ontology the centre of its Foundry platform.
An ontology that is largely built and maintained by software: entity types, relationships and definitions are inferred from source schemas, data profiles and usage patterns, with humans reviewing and refining instead of modelling from scratch. It dramatically shortens what was historically a long manual modelling effort.
Bring a real question from your business and watch a live answer — reasoning, sources and math included — or model what it saves you first.