In almost every first meeting the sentence comes up: "We have so much data, but we can't bring it together." What clients mean is rarely a data problem in the narrow sense — storage and pipelines exist. What is missing is a shared vocabulary: which entities exist, how they relate, which rules apply between them.
An ontology is not a schema — it is a contract
Database schemas describe how something is stored. Ontologies describe what it means. A "customer" in the CRM table is a different thing from the "customer" in the billing system; a shared conceptual model forces the organization to say so out loud. It is exactly this discipline that separates an AI system that impresses in demos from one that holds up in an audit.
What is right about the Palantir model
Palantir showed the market something important: when you build on an explicit ontology — Foundry calls it the "object model" — heterogeneous data suddenly becomes operationally usable. Security context, auditability and human-in-the-loop are not late add-ons but follow from the model itself. We consider this architectural decision methodically correct; it is the reason Palantir stayed performant on sensitive use cases.
Where our approach differs
We build smaller, self-contained ontologies for clearly bounded domains — not one universal Foundry-style object model. Each one is useful on its own, can be checked for audits, and can be operated within a manageable timeframe. On the platform side we combine them through clear bridges instead of merging them into a mega-model. That lowers the risk of expensive modeling dead ends and fits the European reality, where every domain brings its own regulation.
The methodology in detail is proprietary. What we share publicly is the approach: small models, formal contracts, cleanly documented bridges. The rest we discuss in the mandate.
What you should take away from the comparison
Anyone working in the mid-market or the European public sector rarely needs a Foundry license package — but almost always the discipline behind it. A small, documented, auditable ontology per core domain is usually the fastest path from "we have data" to "we can explain decisions". That is exactly where we come in: methodically clear, technically sovereign, without vendor lock-in.