September 2026 · 8 min read · Part 3 · Stop Picking a Winner
The seam is a role
Part 2 said the risk lives in the seam between the two platforms and told you to name the person who owns it. It never said who. The entity contract, the boundary, and the forward-deployed seat already have names in the org model. Leave them unstaffed and the vendor fills all three.
Part 2 ended on the seam. The risk is not in either platform, it is in the boundary between them, and the closing instruction was to set that boundary and give it an owner. Name the person. It did not say who that person is, or how you shape an org around a two-platform world.
The same disclosure one more time. I do not have a side, because neither platform has a durable edge and both can run up a bill fast. That is exactly why the boundary matters. Run both without one and you get sprawl: the same entity defined twice, the same compute paid for twice, a token bill that grows because no one drew the line between what each tool is for. Containing it takes engineering rigor and one rule, that each tool does the job it is built for. That is work, and work has an owner. Leave it unowned and the vendor whose revenue grows by expanding inside your account owns it for you.
Part 1 set the premise: you picked Snowflake, modeled the entities in dbt, got finance to tie out, and then Palantir showed up. So Snowflake is your transformation plane and your definitions already live there. The rule is not Snowflake over Foundry. It is one definitional plane, not two.
The seam is a role, not a diagram
Every risk Part 2 named is a decision someone makes or fails to make. The entity that gets redefined in a second place. The transformation layer that grows inside Foundry because waiting on the backlog was slower. The committed fee that either earns out or funds a third read-only app. None of those are architecture problems. They are ownership problems that look like architecture. A boundary with no owner is not a boundary. It is a suggestion.
I have already described the people who should own it, in The New Org Model. Three roles, three contracts, one system. Map them onto the two platforms and the seam stops being abstract.
The definition is the DPE’s
The entity contract from Part 2, one definition of customer, order, SKU, where it lives and who approves a change, is not a new artifact you invent for Palantir. It is the Data Product Engineer’s core output, and it already exists in dbt if you did the Snowflake work. The rule that Foundry consumes governed marts and not raw tables is the DPE’s contract to everyone downstream: the mart is the interface. Build objects and actions on top of it, do not recompute the definition underneath.
The second transformation layer is what happens when someone treats that contract as optional. So the DPE owns the definition on both platforms, authored once in Snowflake, consumed by the ontology, never re-derived. The DPE’s failure mode was building correct datasets nobody consumes. In a two-platform world the mirror is worse: correct datasets quietly re-created inside Foundry because the shortcut worked. Same failure, shorter fuse.
The handoff to Foundry is not the DPE’s whole job. Most use cases never need an ontology, and the DPE builds data agents directly on Snowflake for those, the fast questions and the ad hoc analysis. That is also the quickest way the team learns what an agent can and cannot do.
The boundary and the meter are the PM’s
Whether a use case belongs in Foundry at all is a build-vs-configure decision, and that is the Domain Product Manager’s job by definition. Part 2’s test, that a question with an answer stays in Snowflake while Foundry earns its cost where a human takes an action against an object, is a build-vs-configure rule with a platform axis. The PM owns the integration map, which is only the drawn version of the boundary: what crosses into the ontology, what stays a governed mart, what never gets copied at all.
The meter is the same person. Part 2 said to instrument both platforms on the same meter and budget the expansion curve. Platform utilization is already the PM’s success metric, and a two-platform world sharpens it. The committed fee is spent whether you use it or not, so the call of whether it goes to the use cases that justify a platform, the writes and actions, or to a third app that Snowflake would have served for the price of a query, sits with the PM in partnership with the data platform team that owns the contract and the budget.
The PM’s failure mode is becoming a governance bottleneck, and the fix is the same as in the org model. The PM decides what should exist and where it should live, not how it gets built. The boundary is a where.
The forward-deployed seat is the FDE’s
Part 2 told you to staff the forward-deployed model on purpose, pair your engineers to Palantir’s on day one, and make the pairing a condition rather than a courtesy. That engineer has a name too. The Forward Deployed Engineer, yours and not Palantir’s, is the person embedded with the business, building the Workshop app or the agent on top of the ontology, on the entities the DPE already governs rather than a fresh set.
Palantir will supply forward-deployed engineers, and they are good. But their FDE and your FDE are not the same seat. Theirs builds fast against whatever definitions are within reach. Yours builds against the DPE’s contract and carries the context home when the engagement ends. Fill your side of the pairing and it works. Leave it empty and Palantir’s FDE is paired to no one. They are just authoring your business logic, and the lock-in Part 2 warned about, the layer you would most want to keep, now belongs entirely to people who leave.
One qualifier on the seat. A strong FDE can go the whole way when they have to. The best of them came up through the data product engineer path and can author the entity contract as readily as they build on top of it, so in a smaller org that is the point: one owner for the definition and the forward build both, because they have done each job and know where the two meet. The three roles are three responsibilities, not necessarily three people, and one person can hold more than one. What you cannot do is leave any of them unheld.
Staff it, or the vendor staffs it for you
Few enterprises have all three of these roles clearly defined. Drop a second platform into one that does not, and the vendor’s forward-deployed team fills all three by default. They define the entities, because someone has to and you did not. They draw the boundary, because they are the ones building and the boundary lands wherever the build is easiest. They own the meter by default, because no one on your side is reading it.
Every seam Part 2 told you to own is now owned by the one party in the room whose incentive, like any platform vendor’s, is to expand the account. That is not a knock on Palantir. It is what happens to any seam you leave unstaffed. The definitions get invented against a deadline, the second layer grows because it is faster, and the run rate climbs because no one whose job it is to say no is at the table.
The entity work is the asset. Part 2 said so. An asset no one owns is one the vendor gets to define for you, against a deadline and in time for renewal.
Put a name to each responsibility
Before the next pipeline, do the org version of the ninety-day list.
- Name the DPE who owns the entity contract, defined in Snowflake and consumed everywhere. One definition, one owner, one place a change gets approved.
- Name the PM who owns the boundary, and who calls the meter with the data platform team. What crosses into Foundry, what stays a mart, and whether the committed fee is earning out on the use cases that justify it.
- Name the FDE who fills your side of the forward-deployed pairing, builds against the contract, and keeps the context in the building when the vendor’s team rotates off.
The people who fill these seats are scarce, and most of the object-layer fluency starts on the vendor’s side. The real work is making it less scarce inside your own walls: put someone who owns the tech and the business context next to the vendor’s FDE, not to watch but to absorb the object layer, so the skill is yours before their team rotates off. Then put a name against each of the three responsibilities, written down before anyone builds, because after the next pipeline the seam stops being a decision and becomes a negotiation. Both platforms are staying. The only question Part 2 left open was who holds the line between them. It was never going to be a tool. It is the three names on that list, or it is the vendor.