Ontology

The ontology mistakes we have all made in Foundry

In Foundry it is very easy to go from the database to the ontology, then to the application, the actions and the automation. That is exactly why the first classic mistake appears, the demo effect: use cases stick too closely to the data. You model the ontology objects by copying a specific system, with its virtues and its defects, because almost every application accumulates workarounds and hacks to make something work in its own front end. Then another department arrives, for which “customer” is a similar concept, and you build one ontology for A and another for B, with a layer on top trying to reconcile them. Sometimes that is a feature; often it is a bug and a pile of patches. And the opposite temptation doesn’t work either: modelling the whole company before building anything is unrealistic and anti-Pareto, because Foundry is expensive and you need to get value out of it as soon as possible.

What worked for us was to look first for the use cases that define the business. In which department is the customer most important, or where is the core of the company? That customer is the first one you model, thinking about that department’s specifics but knowing, with a bit of cunning, that it will change. You stick to the case to move fast, without tying yourself down. As you integrate more data, Foundry encourages fewer, more generic object types, and there are tools for that, such as interfaces, which describe the common shape of several object types, or multi-datasource object types, where a single object is fed by different datasets. You can also group properties of different types into one with struct properties. And you don’t need separate object types for styling whims: a customer in Spain and one in the UK don’t need two object types to get their own flag. That is solved with properties and conditional formatting, even more so if you build applications outside Workshop.

The second mistake is going to the other extreme: giant super-objects that you then have to contort to fit into a Workshop. Sometimes the best option is to duplicate a property from another object instead of chaining three search arounds, because traversing links between object types costs more than filtering on a property of the same object. The balance depends on what hurts. If volume and query cost are what weigh on you, duplicate as little as possible and keep objects separate. If you need operational speed, avoid search arounds and searches over huge objects. If you want to generate value quickly with many applications, large, centralised objects may suit you.

To decide on that balance you need to know how the ontology works underneath, and we do. Queries are resolved by its query engine, Highbury, and we have spent years watching how it responds. What is fast is what the engine can resolve directly in the storage layer, such as a base query filtering on the object’s own properties: the documentation describes it as the fastest execution path. What is slow and expensive is traversing links with search arounds, aggregating, working with derived properties or running advanced searches. And when the set goes above the default of 100,000 objects, the query runs on Spark, with more latency and more compute. The query compute figures, in force since January 2026, reflect this: at least 2 compute-seconds for a base query, 5 for a search around or an aggregation, and 10 for a derived property or an advanced query, and the real cost can be higher depending on complexity. That is why a design that avoids unnecessary hops shows up in the bill as much as in speed. The services behind it are described in the ontology architecture. There are as many answers as there are customers, departments and tools. We have been through all of them, and what we do is an assessment tailored to your operation and to the decisions you need to be able to make.

The ontology mistakes we have all made in Foundry

Further reading (Palantir documentation)