If you've sat through a data or AI presentation recently, you've probably heard both terms: semantic layer and ontology. They are often used as if they mean the same thing. They don't, and the difference matters if you want AI that follows your business rules rather than just reporting on your data.
The problem both are trying to solve
Ask three departments what a "customer" is and you may get three answers. Sales counts anyone with an open opportunity. Finance counts anyone who has paid an invoice. Support counts anyone with a contract. Each system stores "customer" differently, and the same word means different things in different places.
Both semantic layers and ontologies exist to fix this: to give data a shared, agreed meaning. ("Semantic" just means "to do with meaning".) They do it at different depths.
A semantic layer: one dictionary for your numbers
A semantic layer sits between your data and the people (or tools) asking questions of it. It translates technical database fields into business terms everyone agrees on:
- "Revenue" means this calculation, from these tables, excluding these items.
- "Active customer" means someone who bought something in the last 12 months.
- "Region" is defined by this mapping of countries.
Once defined, every dashboard, report and analyst uses the same definitions, so the sales report and the finance report finally agree.
Semantic layers are mainly about consistent measurement. They answer "how do we calculate this?" They are a big improvement for reporting and analytics, and many organisations already have one inside their business-intelligence tools.
What a semantic layer usually doesn't do: it doesn't describe how your business works: which things are connected, what's allowed, what's forbidden. It defines the numbers; it doesn't know the rules.
An ontology: a model of how your business works
An ontology goes further. It is a formal description of the things in your world, how they relate, and the rules that govern them, written precisely enough for a computer to reason with.
For a procurement process, an ontology might say:
- There are suppliers, parts, purchase orders and certificates.
- A purchase order must reference exactly one approved supplier.
- An approved supplier must hold a valid quality certificate.
- A certificate is valid only before its expiry date.
- A supplier under sanctions cannot be an approved supplier.
That last part is the key difference. An ontology doesn't just name things; it defines rules and relationships, and software can use them to:
- check whether a decision follows the rules ("this order breaks rule 47.3: the certificate has expired"),
- infer new facts from existing ones ("this supplier is sanctioned, so it's not approved, so these three open orders are now non-compliant"),
- spot contradictions in the rules themselves ("these two approval conditions can never both be true").
Side by side
| Semantic layer | Ontology | |
|---|---|---|
| Main job | Consistent definitions for reporting and analytics | A model of how the business works, including its rules |
| Answers | "How do we calculate this metric?" | "What is this, how is it connected, and is this decision allowed?" |
| Contains | Business terms mapped to data fields and formulas | Things, relationships, constraints and rules |
| Can a computer reason with it? | Limited: it computes metrics | Yes: it can check, infer and detect contradictions |
| Typical users | Analysts, BI dashboards | AI systems, compliance and decision automation |
| Typical standards | Defined in BI or data tools | OWL for the model, SHACL for rules and validation |
Why this matters for AI
When you put an AI assistant on top of a semantic layer, it can answer questions like "What was revenue in the Gulf region last quarter?" accurately and consistently. That's valuable.
But when you want AI to make or support decisions (approve an order, flag a compliance breach, recommend a maintenance action), consistent numbers aren't enough. The AI needs to know the rules and be checked against them. That's what an ontology provides:
- The AI proposes an answer.
- The answer is checked against the ontology's rules before it's released.
- If it breaks a rule, it's blocked and passed to a person, with the rule named.
- Every decision leaves a record of which rule applied and what data was checked.
Do you need both?
Often, yes, and they work well together. The semantic layer keeps your reporting consistent; the ontology governs decisions.
Many organisations start with the ontology in one high-stakes process and connect it to the definitions they already have, rather than replacing anything.
Choosing where to start
A good first ontology covers a single process where mistakes are costly and the rules are reasonably clear: procurement compliance, regulatory reporting, maintenance approvals. Writing those rules down formally is also the fastest way to find out where they contradict each other.
That's the purpose of the Archisus Business DNA Audit: in two weeks, it maps the rules of one domain, reports the gaps and contradictions, and delivers a draft ontology you can build on. To see how the ontology, the reasoning engine and your existing data fit together, see the platform.
Key takeaways
- Semantic layers give everyone the same definitions for data and metrics.
- Ontologies model how the business works, including its rules, so software can reason with them.
- For reporting, a semantic layer is often enough. For AI that makes or supports decisions, you need an ontology.
- The two are complementary, and you can start an ontology with one process.
