Palantir Foundry Integration Architecture

Overview

Start from business decisions and data authority, then map each responsibility to a Foundry primitive. Keep ingestion, transformation, Ontology semantics, application access, deployment, and telemetry independently governable.

Prerequisites

• Identify users, decisions, source systems, data owners, update/writeback semantics, service objectives, compliance boundaries, and recovery needs.
• Inventory current and proposed Foundry projects, datasets, transforms, Ontology entities, applications, products, modules, and external integrations.
• Read references/official-docs.md and resolve target-enrollment feature availability with platform owners.
• Declare trust boundaries and authoritative systems before drawing components.

Current Contract

• Python transforms provide batch/incremental pipelines with multiple compute engines and data expectations.
• The Ontology represents domain objects, links, Actions, and Functions; OSDK applications receive a generated subset of it.
• Platform SDKs expose broader Foundry/AIP REST APIs, while OSDKs provide application-specific Ontology contracts.
• DevOps/Marketplace and Compute Modules cover different release-managed and interactive-container deployment needs.