Skip to content
Agile Defense

Curriculum / Palantir Portfolio for Defense (Orientation)

FOUNDATIONALUnit 1unit-01

The Enterprise Operating System: how AIP, Foundry, and Apollo fit together

not started~120 min
Map the portfolio: Foundry = data operations platform, AIP = generative-AI platform, Apollo = continuous delivery/operations — functioning together as one enterprise operating system.

Introduction

Scenario: You are joining a defense mission team that runs on Palantir's platforms, and a program lead asks you to explain, on one page, how AIP, Foundry, and Apollo fit together so non-technical stakeholders can follow the architecture.

This unit orients you to the Palantir portfolio at the highest level: how the platforms fit together to support a defense mission. This is a literacy course, not a build course — you will not write code or configure anything. Instead you will read the official architecture page, draw a simple platform map, and be able to state in plain language what each platform is responsible for. The goal is fluency in the vocabulary and the shape of the system, so that when later units go deeper you already know where each piece sits.

Three platforms anchor the picture. Foundry is Palantir's data operations platform — the foundational layer where mission data is integrated, modeled, and made usable, and where the Ontology represents enterprise decisions through data, logic, and actions. AIP is the generative-AI platform that connects AI with that data and with operations, built on top of the Ontology. Apollo is the continuous-delivery and day-2 operations platform that manages the infrastructure hosting Foundry and AIP services and keeps them deployed and current. Per Palantir's architecture documentation, these integrated platforms are designed to function together as an Enterprise Operating System, powered by a shared service mesh.

By the end of this unit you will produce a one-page platform-map diagram with a caption that labels Foundry, AIP, and Apollo with their correct one-line roles and notes the shared service mesh, and you will be able to deliver the Enterprise Operating System framing in a single sentence. You will also inspect a course-seeded demo orientation Project read-only, simply to see that the platform resolves a real resource — confirming the environment is wired up before later units rely on it. Gotham and Maven Smart System are part of the broader portfolio but are introduced in later units (Gotham) or named only as out-of-scope (Maven Smart System); this unit stays on the AIP/Foundry/Apollo core.

Capability focus: The integrated-platforms architecture; one-line roles for Foundry/AIP/Apollo; the 'enterprise operating system' framing. · Artifact: A one-page platform-map diagram + caption labeling Foundry/AIP/Apollo with correct roles.

Key concepts

  • Foundry (data operations platform): Palantir's foundational data operations platform. It integrates and manages mission data, hosts logic and actions, and exposes the Ontology, which represents enterprise decisions through data, logic, and actions and provides an AI-accessible computing environment along with analytics and low-code/no-code applications.
  • AIP (generative-AI platform): Palantir's Artificial Intelligence Platform, which connects AI with your data and operations. Its builder tools are built on top of the Ontology and integrate with existing data on a Foundry enrollment, inheriting access controls, encryption, auditing, and governance rather than bolting AI on outside them.
  • Apollo (continuous delivery / day-2 operations): Palantir's continuous-delivery and day-2 operations platform. It manages the infrastructure that hosts Foundry and AIP services, keeping software deployed, updated, and operated across environments — including, as later units cover, disconnected or air-gapped networks.
  • Enterprise Operating System: The framing, from Palantir's integrated-platforms architecture documentation, that AIP, Foundry, and Apollo are designed to function together as a single Enterprise Operating System rather than as separate products — one coordinated system for running mission operations.
  • Shared service mesh: The integration backbone described in Palantir's architecture documentation by which AIP and Foundry operate together as part of a shared service mesh, powered by Apollo. It is what lets the platforms behave as one operating system instead of loosely connected tools.
  • Ontology: Foundry's semantic layer that represents the enterprise through object types, properties, and links over mission data, and on which AIP's tools are built. This unit only names the Ontology as the layer AIP builds on; Unit 2 covers it in depth.

Companion video

Platform map walkthrough (placeholder) · open on YouTube

Hands-on activity

each step validates · the unit completes when all steps pass
  1. 1

    Read the integrated-platforms architecture page

    Read Palantir's integrated-platforms architecture page (palantir.com/docs/foundry/architecture-center/platforms) and the Foundry platform overview, then make sure you can restate, in one line each, what Foundry, AIP, and Apollo are responsible for. Foundry is the data operations platform that integrates and models mission data and exposes the Ontology; AIP is the generative-AI platform that connects AI to that data and operations; Apollo is the continuous-delivery and day-2 operations platform that manages the infrastructure hosting Foundry and AIP. Note the key relationship the page describes: these are integrated platforms designed to function as an Enterprise Operating System, powered by a shared service mesh. This step is self-attested — orientation reading is not observable through any Foundry read API, so you confirm it by being able to restate the three roles in your own words.

    not startedself-attested

    Self-attested: you read the architecture page and can restate how AIP, Foundry, and Apollo fit together.

  2. 2

    Label the platform-map diagram correctly

    Produce a one-page platform-map diagram that labels each platform with its correct one-line role: Foundry = data operations platform, AIP = generative-AI platform, Apollo = continuous delivery / day-2 operations. Show Apollo underneath, managing the infrastructure that hosts Foundry and AIP, and draw the shared service mesh that connects AIP and Foundry. Add a short caption restating each role so the diagram stands on its own for a non-technical reader. This is a self-attested literacy deliverable — a learner-drawn diagram is not a Foundry resource and cannot be machine-verified — so you pass by checking your own labels against the official roles: confirm you did not, for example, swap AIP and Foundry or describe Apollo as a data tool.

    not startedself-attested

    Self-attested: your diagram labels Foundry/AIP/Apollo with correct one-line roles.

  3. 3

    State the 'Enterprise Operating System' framing in one sentence

    State the Enterprise Operating System framing in one sentence. A strong version is: 'AIP, Foundry, and Apollo are integrated platforms — the generative-AI platform, the data operations platform, and the continuous-delivery/operations platform — designed to function together as a single Enterprise Operating System, powered by a shared service mesh.' This is conceptual recall and is not API-confirmable, so you self-attest by delivering the sentence cleanly. The point is that the value comes from the platforms working as one coordinated system, not from any single product in isolation — that framing is the through-line for the rest of this orientation.

    not startedself-attested

    Self-attested: you can explain how integrated AIP + Foundry + Apollo function as one operating system.

  4. 4

    (Enrichment) A course-seeded orientation Project exists

    Enrichment (read-only): confirm that the course environment resolves a platform-seeded demo orientation Project. The platform has seeded a demo Project at '/Defense Portfolio Orientation/orientation-project'; this check simply verifies that a resource of type PROJECT exists at that path, using the read-only resource-lookup API. Be clear on the honest limit: this is an existence check only against a platform-seeded artifact — it does not inspect or grade your diagram, and nothing here is learner-authored. Its purpose is to show that the platform's read surface is wired up against a real demo resource before later units lean on similar checks. You do not build, edit, or own this Project; you only observe that it is there.

    not startedinstance check

    Existence-only: confirms a platform-seeded orientation Project resolves (read-only inspection).