Why ontology before transforms

A pattern shows up often enough in stalled Foundry implementations to be worth naming. An organization licenses the platform, points it at eight or ten source systems, and starts building pipelines. Ingestion works. Row counts climb. There are dashboards inside a quarter, and the programme reports green.

Then someone asks a question that spans two source systems — how many active cases involve a vessel that also appears in the sanctions list — and it turns out nobody can answer it without a bespoke piece of analysis. The data is all in Foundry. It is faster to query than it was before. But the platform has become an expensive copy of the same fragmentation it was bought to fix.

The common factor in these programmes is not weak engineering. It is that the transforms were written before anyone settled what the objects were.

The ontology is an agreement, not a schema

It is easy to read "ontology" as Palantir's word for a data model, and to treat defining one as a documentation task that can follow the real work. That reading is what causes the problem.

Ask three departments in a border agency what a "vessel" is. Customs means the hull that carries the cargo consignment. The port authority means a berthing entity with a scheduled arrival window. Enforcement means whatever the intelligence report attached the flag to, which might be a hull, a registration, or a name that has changed twice. All three are correct within their own operating context, and all three have systems built on their definition.

No pipeline resolves that. It is not a technical disagreement and no amount of transform logic will settle it — the question of which definition governs is an organizational one. But a transform has to pick. So it picks, silently, in a join condition written by an engineer who had to ship something that week, and the choice becomes load-bearing before anyone with the authority to make it has seen it.

That is the actual function of ontology work: it forces the disagreement into the open early, while it is still a conversation, instead of discovering it at user acceptance testing when it has become a defect.

Why the wrong order feels right

Pipelines produce visible progress. Datasets appear, row counts rise, a health check goes green — all of it legible to a steering committee. Ontology work, in its early weeks, looks like meetings. Under delivery pressure the legible activity wins, every time.

The trap is that transform logic written against an unsettled object model is the most expensive code in the system to change. It is where the joins live. Every assumption about identity, cardinality, and resolution is distributed across dozens of transforms rather than stated once.

The costs are badly asymmetric. Changing an object definition before transforms exist means editing a document and re-running a conversation. Changing it afterwards means touching every downstream transform that joins on it, every Workshop application bound to it, every action type that writes back to it, and every permission rule scoped to it — then re-validating the lot with the users who had just started to trust it.

This is the mechanism behind the six-month rewrite that so many of these programmes go through. It is rarely caused by a bad platform decision or a weak team. It is the compounded cost of a modeling decision deferred past the point where it was cheap.

What doing it first actually looks like

Ontology-first does not mean a quarter of whiteboarding before anyone touches data. Done properly it is weeks, not quarters, and it is done against real data throughout — you validate a definition by profiling the source systems that claim to implement it, which is also how you find out that two of them disagree.

In practice it is four things. Identify the small set of objects the organization actually argues about: usually somewhere between five and fifteen, never the sixty in the source schemas. Write the definitions down with the people who disagree in the room, and record which reading won and why. Define the link types, because in an operational platform the relationships between objects are where nearly all the value sits and they are the thing source schemas capture worst. Only then write transforms whose job is to materialize those agreed objects — not to mirror whatever shape the source system happened to store.

The test for whether you are ready is blunt: can two people from different departments read an object definition and both say, without hedging, that it is what they mean by that word? Until that is true, transforms are premature. Once it is true, they are mostly mechanical.

The honest caveat

None of this argues for a modeling phase with a formal sign-off gate at the end. Ontologies are revised continuously as the work reveals what the source data really contains, and a team that refuses to write a transform until the model is perfect will fail in the other direction — slower, and with less to show for it.

The claim is narrower and, we think, harder to argue with: the objects your organization argues about should be settled before the code that joins them is written. That ordering costs a few weeks at the start of a programme. Getting it backwards costs a rewrite.