How to Build an Ontology From Scattered Company Data

To build an ontology, start from the decisions it must support, list the entities and links those decisions need, pick a source of truth for each field, match the same customer, order or vendor across systems, and write the rules and evidence trail that keep every value checkable. That is the whole method, and you can do it in a spreadsheet. The hard part isn't the first draft. It's keeping the links right as the data changes.

This guide gives the tool-agnostic steps first, then shows the same flow in Helix Foundry, an open-source app that drafts the ontology for you and traces each value to its source. It also says plainly when you don't need an ontology at all.

What an ontology is for, in one paragraph (and the answer up front)

An ontology is a written, machine-readable model of what your business means by its things (customer, order, vendor, invoice), how they link, and what rules hold between them. Its job is to make data from Stripe, a CRM, Postgres, spreadsheets and documents behave as one model. A person or an AI agent asking "which customers have an overdue invoice and an open support ticket?" then gets one answer instead of three partial ones.

The word has a philosophy meaning and a database meaning. Here it's the practical one: types, links and rules, plus the evidence behind each value. If a question needs data from more than one system, or an answer has to be traced to where it came from, you're in ontology territory. If not, keep reading anyway, because the last section covers when to stop.

Step 1: Start from the decisions, not the tables

Write down five to ten questions or decisions the model must support before you open a schema. "Which accounts are at risk of churn?" "Does this vendor invoice match a signed contract?" "What did we ship to this customer last quarter, and what did they pay?" Each one tells you which entities you need and which systems have to agree.

Teams skip this step, and it's why so many ontologies end up as a copy of the source tables with nicer names. Scope the first version to one domain, such as customers or suppliers, and expand only after it answers real questions correctly.

An ontology built from tables describes your systems. An ontology built from decisions describes your business. Only the second one is worth maintaining.

Step 2: List entities and links, and pick a source of truth per field

Now name the entities in business language and define each one in a sentence. A Customer is a legal entity that has paid us at least once; a Contact is a person at that customer. Give each entity a stable key and its useful attributes.

Then define the links as directional verbs: Customer places Order, Order contains LineItem, Vendor issues Invoice. Note cardinality where it matters. Don't infer a link like parent company and subsidiary from a loose record match alone.

The step that saves you later is choosing a source of truth per field, not per system. Billing status comes from Stripe. Account owner comes from the CRM. Shipping address comes from Postgres. Write down what wins when two systems disagree and what happens when a field is blank. A practical deliverable is one table with these columns: entity, definition, key, attributes, source fields, relationships, authoritative source, owner.

Step 3: Match the same customer, order or vendor across systems

The same customer is "Acme Ltd" in the CRM, "ACME LIMITED" in a spreadsheet and a Stripe customer ID attached to a billing email. Matching these records decides whether your answers are right.

Standardise first: case, punctuation, legal suffixes, domains, phone formats. Then compare candidates using reliable identifiers (tax ID, domain, billing email) before fuzzy attributes like names. Link or merge by documented rules, and keep each match decision inspectable. When the evidence is uncertain, don't declare two records identical. Send the pair to a person.

Keep the source records attached to the resolved entity rather than overwriting them, so you can undo a bad merge. If your records come from an LLM extraction, the same problem applies at higher volume. Our guide on entity resolution for knowledge graphs built by an LLM covers it in detail.

Step 4: Write the rules and keep evidence for every value

Rules turn a pile of linked records into something you can trust. Write them as plain statements first: every Invoice must link to exactly one Vendor; an Order can't ship before it's paid unless the customer is flagged as net-30; a Contract end date must be after its start date. Decide which rules block a write and which only flag it for review.

Then keep evidence for every value: the system, table and row it came from, or the document and quote it was read from. When an answer is challenged, "it came from this Stripe record and this line of the signed PDF" ends the argument. Without that, every AI-generated answer over your data is a claim you can't check.

Assign an owner for definitions, matching rules and changes, and version the ontology. An ontology nobody owns drifts within a quarter.

Build it in Helix Foundry: clone, docker compose, or Helix Cloud

Helix Foundry connects your databases, tools and documents, has an ontology agent draft one ontology over them, and loads it into HelixDB as one connected graph. HelixDB is the database; Foundry is the app on top. Foundry is open source under Apache-2.0.

To run it on your computer you need Docker with Compose v2, ports 3000 and 8333 free, and room for a few GB of images on first start:

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

Then open http://localhost:3000. The local install is for one person on their own computer, so don't expose it. If you'd rather not run anything, use Helix Cloud at foundry.helix-db.com and choose Set up with your agent.

The flow maps onto the steps above. Connect a source, test it and sync its tables. Then run a generation: Foundry's agent drafts a new version of the ontology with its types, links, mappings from your tables, routes for your documents, rules and the questions it should answer. You review the draft, edit it, and make it current. Versions never change once drafted, so each edit is a new version you can compare. Making a version current and loading it writes it into the ontology's database. The create an ontology docs cover the panel and setup.

Two properties matter for the evidence step. Foundry never writes to your sources, and each value in the graph traces back to the row or document quote it came from. Once loaded, you can explore the graph and ask questions about your data in plain language, or connect an agent through the Helix MCP.

The hard parts of running one: self-healing, links and schema change

A first draft is a weekend. Running an ontology for a year is the real job, and three things break it.

Links go wrong quietly. A renamed customer, a re-imported spreadsheet or a new Stripe account creates a near-duplicate, and every downstream answer is now slightly off. Schema change is the second: a new field in Postgres, a new document type, a CRM migration. If the ontology is a frozen diagram, it falls out of sync with the data it describes. Third, a wrong value needs to be traceable, not just fixable.

Foundry's approach is to treat the ontology as something regenerated and versioned rather than hand-maintained. When your tables or documents change, you sync and draft a new version against the new shape, review what changed, and make it current. Earlier versions are kept. Because every value carries its source, you can see where a bad link came from instead of guessing. Foundry's design goal is that the tool, not a person re-wiring mappings, handles the hard parts of running an ontology: correct links, self-healing, and schema and graph updates as the workload changes. Read the Foundry docs for the exact generation and review flow before you depend on it for a production workflow.

If you also need to remove data for a user or customer from a graph, see how to delete an AI agent's memory of a user.

When you do not need an ontology, and Foundry's trade-offs

You don't need an ontology if one system holds the truth for your question. If every answer lives in Postgres, write a view. If your data is a pile of documents and you only need search, a vector index may be enough; see when to use a knowledge graph instead of embeddings. A single team with two tools and a monthly reconciliation can also live without one.

You do need one when the same entity appears in three or more systems, when answers must be traced to a source, or when an AI agent will act on the data and a subtly wrong match is expensive.

Foundry's trade-offs are real. A generation sends your synced data to Foundry's agent, so check that's acceptable for your data. The local install is single-owner and restricted to localhost, but it authenticates the owner with a site token; no OAuth sign-in is required. A drafted ontology is a draft: someone who knows the business has to review the types, links and rules before making it current. Foundry reads your sources and never writes to them. That's safe, but it also means fixing source data is still your job.

If you're comparing builders, Palantir's Foundry is the large enterprise option; Foundry here is open source and runs on your machine in a few commands. For an overview of that comparison, see our open-source Palantir Foundry alternative page.

FAQ

The questions below are the ones people search most about building an ontology.

Start with one domain and one question

An ontology earns its keep when it answers a real cross-system question correctly and shows where the answer came from. Pick one domain, write the five questions it must answer, and let the model grow from there. To try it on your own data, clone helix-foundry, run docker compose up -d --wait, open localhost:3000, connect a source, and generate a first draft you can review.