Ontology Engineering for Enterprise Data

Ontology engineering is the practice of building a shared, governed model of what an organization deals with: the entities that matter, how they relate, and the operations that may be performed on them. It sits above data modeling and below application development. A data model describes how records are stored. An ontology describes what the business means by a customer, an asset, or a claim, and encodes that meaning once so every application, report, and agent uses the same definition. The engineering work is deciding those definitions, resolving identity across systems, keeping lineage intact, and governing change over years.

Where the discipline came from

The word arrived from philosophy through knowledge representation research in the 1990s, and for two decades ontology engineering mostly meant building formal models in OWL and RDF with description logic underneath, in domains like biomedical research and library science. Those efforts produced durable artifacts, including the Gene Ontology and SNOMED CT, both still in daily use.

What changed is the reason enterprises care. The academic tradition optimized for logical rigor and automated reasoning. The current wave optimizes for operations, meaning it gives applications and AI agents a dependable model of the business to act through. The formal apparatus is lighter, the governance demands are heavier, and the measure of success is whether decisions get made differently rather than whether the model is logically complete.

What you are actually building

You are building four artifacts, listed here in order of how much trouble they cause.

Entity definitions. The set of types the organization operates on, each with agreed properties and a stated scope. This looks like the easy part and is where projects stall, because the question of what counts as a customer turns out to have three answers inside the company and each one is load bearing for somebody's reporting.

Relationships. Declared connections between types, with cardinality. Getting these right is what lets someone traverse from a late shipment to the affected orders without writing a join. Getting them wrong produces confident answers built on the wrong path.

Identity resolution. The rules that decide when two records from two systems are the same real-world thing. This is the least glamorous work and the most consequential. An ontology built on unresolved identity produces duplicate entities, duplicate entities produce wrong counts, and wrong counts destroy operator trust faster than any other failure.

Operations. The defined actions that may be taken against entities, with their validation rules and their effects on systems of record. Models without this layer describe the business. Models with it can run part of it.

How to model one

Start from a decision rather than from the data estate. Pick one operational decision that costs the organization money and currently spans systems: which order to expedite, which asset to service, which claim to escalate. Model only what that decision needs. You will produce a small, plain, useful model in six to eight weeks instead of a beautiful enterprise model in eighteen months that nobody has validated against real work.

Work with the operators, in their words. If an entity type is named after a source table, you have modeled the system rather than the business, and the people who make the decision will not recognize it. The test is whether an experienced operator can read the entity list and say yes, that is what we deal with.

Fix identity before adding breadth. Each new source system brings its own version of the same entities, and the matching rules compound. Resolve identity for the entities in scope, write the rules down, and instrument how often they fire and how often they are wrong.

Version everything from the first week. Entity definitions, relationships, and operations are schema for the operational layer of the business, and they will change. If you cannot answer what the definition of a customer was six months ago, you cannot explain why a metric moved.

Then add the second workflow. The compounding return in this discipline is real, and it comes from reuse, because the second use case borrows most of its entities from the first. That return only shows up if the first model was built narrow and clean rather than broad and provisional.

Common failure modes

Five patterns account for most of the failures we get called into:

• Modeling the enterprise before modeling a workflow, which produces an artifact with no user and no way to tell whether it is correct.
• No named owner per entity type, so definitional disagreements get resolved by adding optional fields until the model describes the disagreement instead of settling it.
• Skipping identity resolution, then discovering the duplicates in front of the executive sponsor.
• Mirroring source system structure, which locks the business model to whatever your ERP happened to do in 2011.
• Read-only scope, where the model informs decisions but never writes back, so operators keep the spreadsheet and the platform becomes a second place to look.

Lineage and governance are the same problem

Ontology work is often sold on the modeling and judged on the governance. The connective tissue is lineage: for every property on every entity, which pipeline produced it, from which source, under which transformation, and when. Without that, three things break. Nobody can debug a wrong number. Nobody can assess the impact of an upstream schema change. And nobody can answer an auditor asking how a decision was reached, which is now a regulatory question wherever AI touches a consequential decision.

The governance layer that sits on lineage has four parts worth naming: an owner per entity type with authority to settle definitions, a change process for definitions and operations with the same discipline as a production migration, access control expressed at entity and property level rather than by table, and audit records tied to operations rather than to queries. Organizations that already run a data catalog and a stewardship program have most of this. Organizations that do not will find that the ontology forces the question, which is one of its underrated benefits.

Lineage also determines whether the model survives contact with reality. Source systems change constantly. An ontology with lineage tracked at property level lets you see, before you ship the change, which entities and which applications an upstream schema change will break. An ontology without it discovers the answer in production.

Who does this work

The skill mix is unusual, which is why the discipline is hard to staff. You need someone who can hold a modeling conversation with a plant manager and a schema conversation with a data engineer, and those are rarely the same person by training. The teams that work tend to pair a domain-literate modeler with an engineer who owns pipelines and identity resolution, plus a named business owner who can make decisions rather than relay them.

Titles are inconsistent across the market: ontologist, knowledge engineer, semantic architect, data architect, forward deployed engineer. What they have in common is the ability to convert an argument about definitions into a durable artifact.

Platforms, and where they help

Tooling ranges from RDF and OWL stacks with a triple store, through property graph databases, through data catalogs and semantic layers, to operational platforms that ship the whole model as a first-class construct. Palantir Foundry is the most developed example of the last category, because its ontology carries objects, links, permissioned actions, and lineage in one governed layer, which is why the term entered enterprise vocabulary through Palantir rather than through the research tradition. The platform-specific mechanics are in the Palantir ontology explained, and the concept on its own is in what is an ontology.

The tooling choice is the smaller decision. A well-governed ontology in a graph database will outperform a sloppy one in the best platform available, because the failure modes above are organizational. Choose the tool that matches how much of the operation you intend to run through the model, then spend your attention on definitions, identity, and ownership.

Where BD Emerson fits

We run ontology engineering as part of data platform work, and we do it in the order above: one decision, a narrow model, identity resolved, lineage instrumented, ownership named, then breadth. Our data engineering practice builds the pipelines and lineage underneath, and our Foundry implementation team does the work where the model runs on Palantir. The engineering is portable. The governance is where engagements succeed or fail.