Do You Need an Ontology? Five Signs Your Data Needs One

You need an ontology when the same business thing, a customer, an order, an approval, means different things in different systems and people or agents keep getting it wrong. An ontology is the model of what those things mean and the rules between them. A knowledge graph is the data loaded into that model. If your data lives in one system of record and the answers are easy to trace, you can skip it.

Most teams reach for an ontology after something breaks: an agent emails the wrong contact, a finance report disagrees with the CRM, nobody can say where a number came from. This post gives you five signs that it is time, an honest section on when it is not, and the parts that are hard once you commit.

What an ontology is, and how it differs from a knowledge graph, a taxonomy and a semantic layer

An ontology defines the kinds of things your business has, what each one means, how they relate, and which relationships are valid. A customer places orders. An order needs an approval above a threshold. An invoice belongs to exactly one vendor. That is the model, written down so people and software share it.

A knowledge graph is the populated version: the actual customers, orders and invoices, connected by those relationships. The ontology is the schema and rules. The graph is the data. That is the whole difference between an ontology and a knowledge graph, and it answers the common question of whether you need an ontology to build a knowledge graph. Technically no, you can load a graph with no formal model. But shared meaning gets harder to maintain as it grows, and you end up writing the model implicitly in queries and in people's heads.

A taxonomy is narrower: a hierarchy of categories, like product type or department. It says what belongs under what, not how things relate or what rules apply. A semantic layer is narrower in a different direction: it standardizes metric definitions, like what counts as monthly revenue, for dashboards. If your problem is two dashboards showing different revenue, a semantic layer may be enough. If your problem is that a customer in Stripe, the CRM and a spreadsheet are not recognized as one customer, you need the model underneath.

On Palantir: it uses "ontology" for the layer that maps a company's data into objects, links and actions its applications work on. The idea is the same one described here. It is a shared model of the business, not a pile of tables.

Sign 1: The same customer or vendor has different names in different systems

If "Acme Corp" in Stripe, "ACME Corporation" in the CRM and "Acme (EU)" in a spreadsheet are all the same customer, and no system knows it, you need an ontology.

This is the most common trigger and the most underrated. Joins on name fail. Joins on ID fail because each system minted its own. So every report starts with someone reconciling by hand. An ontology gives the customer one definition and one place where the matches between sources are recorded.

This is also the strongest business case for data integration. The benefit is not a prettier diagram. A question like "what has this vendor been paid, contracted for and invoiced?" gets one answer instead of three exports. For worked industry examples, see the guides on finance ops, logistics and insurance ontologies.

Sign 2: Agents or automations get entities subtly wrong

If an agent or automation is almost right about customers, orders and approvals, the missing piece is usually a shared definition, not a better model.

Subtly wrong is the dangerous kind. The agent merges two customers with similar names, treats a draft order as approved, or applies a refund rule from the wrong region. Retrieval over text chunks can't fix this, because nothing in the chunks says which entities are the same or which rules bind them.

This is the answer to when an ontology matters for LLM and RAG work. Plain vector retrieval is fine for "find the passage that mentions X". Once the agent has to act on entities and follow relationships, you want the entities and rules explicit. We cover the retrieval side in knowledge graph RAG and the tradeoff in when to use a knowledge graph instead of embeddings.

Sign 3: Nobody can trace an answer back to its source

If someone asks "where did this number come from?" and the honest answer is "we'd have to ask around", you need a model that keeps provenance.

Traceability is a requirement the moment an answer drives money or a decision. A good ontology-backed graph records, for each value, the row in a table or the quote in a document it was taken from. That turns "the AI said so" into "the AI said so, from this invoice row and this contract clause", which a reviewer can check in a minute.

Without it, you can't audit an agent's work, and you can't tell a good answer from a confident one. If your team has started distrusting AI output because nobody can verify it, this is your sign.

Sign 4: Business rules live in people's heads, not in the data

If the rules that decide what is valid, "anything over a threshold needs a second approver", "a contract must exist before an invoice is paid", are known by two people and enforced by habit, write them into the model.

Rules in heads break when those people are on holiday, leave, or when an agent starts doing their job. In an ontology, a rule is declared once, next to the entities it governs, and anything that violates it can be flagged for review rather than slipping through. That is the practical meaning of an enterprise ontology: customers, policies, invoices, shipments, plus the constraints between them.

Start with the rules that cost you most when broken. You don't need hundreds. Five good ones, each checkable against data you already have, change how much you trust the rest.

Sign 5: Documents and tables disagree and nobody notices

If the contract PDF says net 45 and the billing table says net 30, and nobody finds out until a dispute, your documents and your tables are two unconnected sources of truth.

Most company knowledge lives in both: structured rows in Postgres or Stripe, unstructured text in contracts, specs and notes. A model that only covers tables misses half the facts. One that extracts facts from documents and holds them next to the table values can surface the conflict instead of hiding it, and route it to a person to decide which is right.

The system doesn't pick a winner. Disagreement becomes visible and reviewed instead of silent.

When you do not need an ontology

You don't need one if you have a single system of record, a small amount of data, and nobody is asking an agent to act across tools.

If everything lives in one Postgres database with sensible foreign keys, the schema already is your model. If your data fits in a few spreadsheets one person understands, a shared model is overhead. If your only complaint is inconsistent dashboard metrics, fix the definitions in a semantic layer first. And a schema-less knowledge graph has real pros: you can start in an afternoon with no upfront design. The cost shows up later, when entity types drift, duplicates pile up and nobody agrees what a node means.

A simple test: if you can name the one system that is right about customers and trust it, wait. If you can't, or the answer changes by team, you are in ontology territory.

The hard parts of running one: links, conflicts and schema change

Building the first version is the easy part. Keeping it correct as data and workload change is the real work, and it comes down to three problems.

Links. The value of the graph is in the connections: this invoice belongs to that vendor, this ticket to that customer. Wrong links are worse than missing ones, because they look authoritative. Every link needs a rule for how it is made and evidence for why it holds. We go deeper on matching in entity resolution for knowledge graphs built by an LLM.

Conflicts. Sources will disagree: two systems with different addresses, a document and a table with different terms. You need a policy: which source wins, or hold it for a human. Silent overwrites are how trust erodes.

Schema change. Your business adds a product line, a new approval step, a new tool. The model has to change with it, and the graph has to be reloaded to match without breaking what is already trusted. Teams that treat the ontology as a one-off project find it stale in six months.

These are exactly the parts Helix Foundry is built to take on, described next.

Trying it in Helix Foundry: hosted or on localhost

Helix Foundry connects the tools your company runs on into one ontology and loads it into HelixDB, the graph-vector database it runs on, as one connected graph. The Foundry docs cover each step. Here is the shape of it.

You connect sources. An ontology agent then drafts the types, links and rules, along with the tables and documents each one comes from, based on your data and your stated goal. You review it, edit it and make a version current. Nothing is accepted without you.

When it loads, the graph keeps where every value came from: a table row, or a quote in a document. Values that documents disagree on wait for your review instead of being overwritten. Foundry never writes to your sources.

To run it hosted, go to foundry.helix-db.com and use Set up with your agent. To run it on your own machine:

git clone https://github.com/helixdb/helix-foundry.git
cd helix-foundry
docker compose up -d --wait

Then open http://localhost:3000. The code is Apache 2.0 at github.com/helixdb/helix-foundry. For a full walkthrough, read how to build an ontology from scattered company data. If you are weighing it against Palantir, see the open-source Palantir Foundry alternative.

Count your signs, then try one source pair

If two or more of the five signs describe your week, a shared model will pay for itself. If none do, skip it and revisit when a second system of record shows up. Either way, test it cheaply: pick two sources that disagree about the same customer or vendor, clone Helix Foundry or open foundry.helix-db.com, connect them, and see whether the drafted ontology links them correctly and traces every value to its source.