# Ontologies and Semantic Layers, Explained Without the Jargon

> What a semantic layer is, what an ontology is, how they differ, and which one you need when you want AI to follow your business rules rather than just report on your data.

Published 2026-11-03 by Archisus · Topics: ontologies, semantic layers, data governance, AI
Web version: https://archisus.com/insights/ontology-vs-semantic-layer/

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.

```mermaid
%% alt: Procurement ontology: a purchase order must reference one approved supplier, who must hold a valid certificate; a sanctioned supplier can never be approved
graph LR
    PO(["Purchase order"]) -- "must reference exactly one" --> AS(["Approved supplier"])
    AS -- "must hold" --> C(["Valid certificate"])
    C -- "valid only before" --> X(["Expiry date"])
    SS(["Sanctioned supplier"]) -. "can never be" .-> AS
    PO -- "contains" --> PT(["Parts"])
```

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.

```mermaid
%% alt: A semantic layer and an ontology on the same data: the semantic layer feeds dashboards, the ontology governs AI decisions
flowchart TB
    D[("Your data: ERP, finance, maintenance, documents")]
    D --> SL["Semantic layer: shared definitions of terms and metrics"]
    D --> ON["Ontology: things, relationships and rules"]
    SL --> BI["Dashboards and reports"]
    SL -. "shared terms" .-> ON
    ON --> AI["AI decisions, checked against the rules"]
```

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](https://archisus.com/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](https://archisus.com/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.

---

Archisus builds precision AI governed by your business rules. More articles: https://archisus.com/insights/ · Site guide for AI assistants: https://archisus.com/llms.txt