PAL.NET: Giving .NET Teams a Real Contract With Palantir Foundry

Every Palantir Foundry integration we have seen in .NET begins the same way. Someone needs one endpoint, writes a small HTTP client, and ships it. Six months later that client has thirty methods, three different error conventions, a cache nobody documented, and a set of request models that only approximately match what the platform actually returns.

The part that hurts most is the Ontology. It is the most customer-specific thing in the whole estate, the object and link model that encodes how an organisation thinks about its own data, and it usually ends up in C# as a dictionary of strings. Nothing in the compiler can help you when a property name changes.

What it is

PAL.NET, the Platform Access Layer for .NET, is a licensed SDK targeting .NET 10. It has been running in an operational environment for over a year before we said anything publicly about it, which was deliberate: an access layer is only worth talking about once it has survived real workloads. It gives a .NET application one coherent way to reach Palantir Foundry, Palantir AIP and the customer’s own Ontology, using the conventions a .NET engineer already expects: strongly typed contracts, immutable record payloads, async methods throughout, and cancellation tokens that are honoured rather than accepted and ignored.

Capabilities register modularly. An application that only reads datasets does not pull in orchestration, map rendering or the model surface. When it later needs streams, SQL queries, functions, media sets, AIP agents, the LLM proxy, data health, checkpoints or the sensitive data scanner, those arrive through the same registration pattern and behave the same way.

Two surfaces, one runtime

The platform surface covers the services. The Ontology surface covers the customer model, and it comes in two forms. Where the model is known at build time you get generated strongly typed C# contracts, so a renamed property is a compile error instead of a production incident. Where it is not, dynamic metadata-driven access covers the gap, including specialised Ontology data access. Both run on the same authentication, error and cancellation behaviour, so moving between them is not a rewrite.

Compatibility you can plan around

The piece we care most about is the API Compatibility Manifest. It states what the SDK supports, and release gates are tied to it. That turns an upstream platform change from an investigation into a planned upgrade, which matters a great deal if you operate in an environment where you cannot simply deploy and see what happens.

On performance, the target is under five milliseconds of SDK overhead at the 95th percentile for payloads up to 64 KiB, excluding network time. An access layer should be invisible in a trace, not a line item.

How you get it

PAL.NET is closed source and licensed, distributed through authenticated private NuGet feeds or as licensed offline bundles for disconnected estates. Entitlement is fail-closed, so an unlicensed build does not quietly degrade, it stops. Internally it reuses AIC.Foundry and AIC.Foundation, which keeps it consistent with the rest of our .NET work.

Product information and release detail are at pal.aic.io. We have also written up how connectivity and expansion work in practice as a case study.