Domain Models and Customer Workflows

Imagine a software company whose product must serve a counter-narcotics team on one day and an aerospace manufacturer on the next. The two customers do different work, use different vocabulary, and track different kinds of things. A natural first guess is that the company would need two separate products. The source describes how Palantir approached this problem differently, and the key idea is an architectural layer called the ontology.

The source's early engagements showed that each customer needed its own domain model. A counter-narcotics operation and an aerospace manufacturer do not describe their work in the same terms, so a model built for one does not simply transfer to the other. The important fact is not just that the two models differ in content, but that each model is specific to a domain or industry. Different customers need different domain models.

The obvious response to customers needing different domain models would be to build each one from scratch, one customer at a time. The source rejects that path. Building a bespoke system for every customer is the alternative against which the ontology investment is measured, and the source presents that alternative as far more expensive. The team's question therefore became how to make domain models cheap to define without making them identical.

The figure contrasts the two approaches. On the left, each customer has a separate system, so the software that must be built and maintained grows with every new customer. On the right, most of the work sits in one shared layer, and each customer's differences live inside its own domain model defined in the ontology format. The source describes the first approach as multiplying the software that must be built and maintained, and the second as concentrating most of the work in one shared layer.

The ontology is a layer that allows domain models to be defined in a consistent format. The key word is consistency. Because definitions share one format, the software that reads those definitions does not need to be rewritten for each new customer. The format is the thing that stays constant while the content of each domain model varies.

It helps to see the ontology as sitting between the shared software and the individual customer models. The shared engine, UI, and workflow logic sit on top of the ontology's consistent format, and each customer's domain model is defined within that format. The source's team built the layer so that FDEs could define domain models through it.

Tracing one customer through this stack: a user working in the counter-narcotics workflow interacts with the shared UI, which is driven by the shared workflow logic and engine. Those pieces are built on the ontology's format, and the entities and relationships they operate on come from the counter-narcotics domain model defined within that format. A user working in the aerospace manufacturing workflow follows the same stack, but the domain model underneath is the aerospace one. The software is shared; the content beneath it differs. This is how the same engine, UI, and workflow logic can power different customer workflows simultaneously.

The two terms are easy to blur, so it is worth separating them. The ontology is the format, or the rules, that every domain model follows. A domain model is a concrete instance of that format: the specific entities and relationships defined for one domain or industry.

The source makes a claim about the company itself, not just the software. It says that the investment in the ontology, which it describes as significant in absolute terms but small compared with the alternative of building bespoke systems for each customer, is what made Palantir a software business rather than a consulting business.

The reasoning is that a shared layer lets the same product serve many customers. Custom construction for each customer would keep the work tied to individual engagements, which is the pattern of a consulting business. The ontology investment is therefore judged against that alternative: the cost of one shared layer compared with the cost of building each customer's system separately.