Three vendors, three decks, three terms for what sits between the agent and your data. One sells a semantic layer, one an ontology, one a knowledge graph. The terms are not interchangeable. The first defines metrics, the second defines the business, the third stores the facts. And the real question is who owns the definitions.
Three terms, three questions
The definitions are well established, and data catalogue vendors state them clearly. A semantic layer answers “how do we calculate this metric?”: it maps business logic onto the data so that revenue is computed the same way in every tool.[1] An ontology answers “what are the things in our business, and how do they relate?”: it defines entities and their relations in a formal, machine-readable schema.[1:1] Atlan sums it up: a semantic layer tells you what your revenue is, an ontology tells you what a customer is.[1:2] Alation puts it the other way round: the semantic layer answers “what is the number?”, the ontology defines what should happen next when an event occurs.[2]
A knowledge graph is a third thing. The ontology defines the schema; the graph stores the instances, which makes search across entities, lineage and relationship traversal possible.[1:3] One is the definition, the other is the data.
We agree with these definitions. Where we differ is on a question the decks skip: who writes the ontology, and is the agent bound by it?
What the agent needs from the semantic layer
A figure calculated the same way every time. Atlan calls this governed, deterministic access to metrics, and notes that an agent relying on a semantic layer alone produces results that are precise but shallow.[1:4] The semantic layer knows how to sum a column. It does not know what the column represents, whether the customer in the CRM is the account in the ledger, or why certain exceptions exist.[3] An agent with formulas but no model of the business will calculate the wrong thing correctly.
What the agent needs from the ontology
Entities, relations, actions, rules, and the edge cases that account for most of the work, all stated explicitly, in the vocabulary of the people who do the work, and binding on the machine.[4] Not inferred from the data, which only records what was measured. Not guessed by a model, which will fill the gaps with plausible invention. Defined, versioned, debated and owned.
Two words matter here. The first is binding. A vocabulary the agent may consult is a dictionary. A vocabulary the agent cannot step outside is a constraint, and only a constraint makes an action predictable enough for a named person to approve it. The second is owned. The ontology is the one artefact that business teams and engineers both edit, and where they finally work from the same definitions.[4:1] An ontology the business teams cannot edit is a specification written about them by someone else.
The knowledge graph is where the definitions meet the data. A graph without an ontology is a pile of links. A graph under an explicit ontology is a map: every node is an instance of something the organisation has named, every relation one it has defined, and every figure traces back to its source row.
Why the ontology has to be yours
This is where we differ from the vendors: on ownership, not on definitions.
Models converge quickly. Compute is priced like a commodity. Talent moves. What does not move is the explicit model of your own operations: your entities, your rules, the exceptions added after a past incident or a regulator’s letter, the words your teams use.[5] Its value also grows over time: every exception resolved is added to it, and every rule made explicit applies to every agent from then on.[5:1]
A vendor who holds that model as configuration inside its product holds your most lasting advantage as a line in its renewal contract. When the product goes, the configuration goes with it, and so does the reasoning behind your processes. Organisations that keep a process but lose its reason end up following rules nobody understands.[6] An ontology written in your vocabulary, in a form you can take with you, outlasts the people who wrote it.
Alation proposes an additional layer above the ontology, an “enterprise context layer”, which tells the agent how to handle judgement calls and learns from the agent’s own interactions.[2:1] We disagree. A rule an agent learned from its own behaviour is a rule nobody defined and nobody approved. Judgement calls belong to a named person. The rule that settles them belongs in the ontology, written by the people who do the work, and binding on every agent after that.
Our position
Galahad does not infer your ontology from your data, and does not let a model guess the structure your systems never recorded. We do not hold the model of your business as our configuration. Each deployment serves one organisation, with its own ontology, which you own and can inspect.[7] If it cannot leave with you, it was never yours.
Questions to ask a vendor
- Show me the ontology. Is it a document I can read, version and export, or a setting inside your product?
- Who edits it: my teams, your consultants, or a model?
- Is the vocabulary binding on the agent, or only advisory?
- When the agent meets a case the ontology does not cover, what does it do, and who is informed?
- If I end the contract, what do I keep?
Monarch is built on an ontology you own: your entities, your rules, the words your teams use. See it on your data.
Atlan, Ontology vs semantic layer: ontologies define domain concepts and relationships in a formal, machine-readable schema; semantic layers map business logic onto data for consistent metrics; a knowledge graph stores the instances the ontology defines; semantic layers give governed, deterministic metric access and, alone, results that are precise but shallow. Source ↩︎ ↩︎ ↩︎ ↩︎ ↩︎
Alation, Semantic layer vs ontology vs enterprise context layer: the semantic layer answers “what is the number”, the ontology defines what should happen next when an event occurs, and the enterprise context layer delivers judgement context to autonomous agents and improves from their interactions. Source ↩︎ ↩︎
Galahad, the company: each deployment serves one organisation, with its own ontology, which you own and can inspect. Read it ↩︎