Three vendors, three decks, three words for the thing that sits between the agent and your data. One sells a semantic layer, one an ontology, one a knowledge graph. The words are not interchangeable, and the difference between them is not the one the decks draw. It is the difference between a metric, a declaration and a record, and between something you configure and something you own.

Three words, three questions

The distinction is settled, and the data catalogue vendors state it well. A semantic layer answers “how do we calculate this metric”: it maps business logic onto 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 the entities and their relations in a formal, machine-readable schema.[1:1] Atlan puts it in one line: a semantic layer tells you what your revenue is, an ontology tells you what a customer is.[1:2] Alation draws the same line from the other side: 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, and it is what makes cross-entity search, lineage and relationship traversal possible.[1:3] One is the declaration. The other is the record.

We agree. The disagreement starts at the question the decks skip: who writes the ontology, and what does it bind?

What the agent needs from the semantic layer

A figure computed the same way every time. Atlan calls this governed, deterministic metric access, and warns that an agent relying on a semantic layer alone produces results that are precise but shallow.[1:4] The semantic layer knows how to add up the column. It does not know what the column is a column of, whether the customer in the CRM is the account in the ledger, or why the seventeen exceptions exist. One cannot observe that for which one possesses no concept.[3] An agent with a formula and no model of the business has arithmetic and no orientation. It will compute the wrong thing correctly.

What the agent needs from the ontology

Entities, relations, actions, rules, and the edge cases that consume most of the work: stated explicitly, in the vocabulary of those who perform the work, and binding upon the machine.[4] Not inferred from the data, which records only what was measured. Not surmised by a model, which will supply the missing structure with fluent invention. Declared, versioned, contested and owned.

Two words carry the argument. 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 sign it. The second is owned. The ontology is the single artefact that the business and the engineers both edit, and it is here, and only here, that they cease to be two populations.[4:1] An ontology the operators cannot edit is a specification about them, written by someone else.

The knowledge graph is where the declaration meets the record. A graph without an ontology is a pile of edges. A graph under a declared ontology is territory: every node is an instance of something the institution has named, every relation is one it has stated, and every figure reaches the row it came from.

Why the ontology has to be yours

Here we part from the vendors, on ownership, not on definitions.

Models converge, and quickly. Compute has a price list. Talent moves. What does not travel is the declared model of your own operations: your entities, your rules, the exceptions that exist because of an incident in 2011 and a regulator’s letter in 2019, the words your people use on the floor.[5] It also compounds: every exception resolved joins the asset, and every rule made explicit constrains every agent thereafter.[5:1]

A vendor who holds that model as configuration inside his product holds your last defensible advantage as a line item in his renewal. When the product goes, the configuration goes, and with it the reason the process exists. Successors preserve a process and lose its reason; that is how an institution becomes ceremonial without noticing.[6] An ontology written down, in your vocabulary, in a form you can take with you, is the one instrument that outlives the people who hold it.

Alation proposes a further layer above the ontology, an enterprise context layer, that tells the agent how to handle the judgement call and improves from the agent’s own interactions.[2:1] We decline the premise. A rule an agent learned from its own behaviour is a rule nobody declared and nobody signed. The judgement call belongs to a named person. The rule that resolved it belongs in the ontology, written by the people who do the work, and binding on the next agent.

What Galahad refuses to do

We do not infer your ontology from your data. We do not let a model guess the structure your systems failed to record. We do not hold the model of your business as our configuration: one deployment, one ontology, one organisation, held as something you own and can inspect rather than as weights inside a rented model.[7] If it cannot leave with you, it was never yours.

The questions to put to the vendor

  1. Show me the ontology. Is it a document I can read, version and export, or a setting inside your product?
  2. Who edits it: my operators, your consultants, or a model?
  3. Is the vocabulary binding on the agent, or advisory?
  4. When the agent meets a case the ontology does not contain, what does it do, and who is told?
  5. If I end the contract, what leaves with me?

Monarch is built on an ontology you own: your entities, your rules, the words your operators use. See it on your data.

  1. 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 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  2. 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 ↩︎ ↩︎

  3. Machines of Consequence, thesis 15. Read it ↩︎

  4. Machines of Consequence, thesis 18. Read it ↩︎ ↩︎

  5. Machines of Consequence, thesis 19. Read it ↩︎ ↩︎

  6. Machines of Consequence, thesis 20. Read it ↩︎

  7. Galahad, the company: one deployment, one ontology, one organisation; the ontology held as something you own and can inspect rather than as weights inside a rented model. Read it ↩︎