Skip to content
Agile Defense

Curriculum / Palantir Portfolio for Defense (Orientation)

FOUNDATIONALUnit 2unit-02

Foundry and the Ontology: the operational layer of the mission

not started~120 min
Understand Foundry as the data operations platform and the Ontology as its semantic layer — object types, properties, and links over mission data.

Introduction

Scenario: Your mission team has integrated data spread across sensors, assets, and intel feeds, and leadership wants a shared, plain-language picture of what that data actually represents. In this unit you build the literacy to explain how Foundry and its Ontology turn raw mission data into a coherent operating picture.

Unit 1 placed Foundry, AIP, and Apollo on a single map; this unit zooms into Foundry — Palantir's data operations platform — and the Ontology that sits on top of it. Foundry is where mission data is integrated, managed, and made trustworthy, and where the logic and applications that act on that data are authored. The Ontology is the semantic layer over that data: it names the real-world things the mission cares about (object types like an asset, a sensor, a track, a mission), describes them with properties, and connects them through link types so that the platform represents how those things actually relate. The goal of this unit is awareness, not building: you should leave able to explain, in plain terms, what Foundry does and what the Ontology is — not to author one.

The Ontology is best understood as having two complementary sides. The semantic side describes what exists: object types, their properties, and the link types that relate them, forming a shared vocabulary that mission analysts, operators, and AI all reason over instead of arguing about column names in disconnected tables. The kinetic side describes what can be done: action types and functions let the platform (and governed AI through AIP) change the state of objects — for example, re-tasking an asset or updating a track. Read together, the semantic and kinetic sides let the Ontology behave less like a static schema and more like a working model of the mission. This unit treats that distinction as the core literacy outcome.

By the end you will have produced three short self-attested deliverables — a read-through of the Ontology overview that names semantic versus kinetic elements, a simple object-link sketch of three or four notional mission object types, and a one-paragraph explainer of Foundry's role as the data operations platform — and then performed one read-only inspection of a platform-seeded demo Ontology to see real object types alongside your notional sketch. Because this is a literacy course, the first three deliverables are self-attested: there is no learner-built artifact for the platform to machine-verify. Only the final inspection touches a real platform artifact, and even then it merely confirms that a pre-seeded demo exists for you to look at — it does not certify that you authored anything.

Capability focus: Foundry as the data operations platform; the Ontology (object/link types, properties); semantic vs kinetic elements. · Artifact: A short explainer + an object-link sketch of 3-4 notional mission object types.

Key concepts

  • Foundry (data operations platform): Palantir's foundational data operations platform. It integrates and manages data, supports logic and workflow authoring, hosts analytics and low-code/no-code applications (Workshop), and provides the AI-accessible computing environment the rest of the portfolio builds on. In this orientation it is the layer underneath the Ontology.
  • Ontology (semantic layer): The Ontology represents enterprise and mission decisions through data, logic, and actions. It is the semantic layer over integrated Foundry data — the shared model that turns disconnected tables into a coherent picture of the things the mission cares about.
  • Object types and properties (semantic elements): Object types are the kinds of real-world things the mission tracks (for example, an asset, a sensor, a track, a mission). Each object type is described by properties (its attributes) and is typically anchored by a primary key. These are the 'nouns' of the Ontology.
  • Link types (semantic elements): Link types define how object types relate to one another — for example, a sensor detecting a track, or a mission tasking an asset. Links are what make the Ontology a connected model rather than a list of separate tables.
  • Action types and functions (kinetic elements): Action types and functions are the kinetic side of the Ontology — the governed operations that change object state (re-tasking, updating, creating). They let humans and, through AIP, governed AI act on the model, not just read it.
  • Semantic vs. kinetic distinction: 'Semantic' describes what exists (object types, properties, links); 'kinetic' describes what can be done (action types, functions). Holding both in mind is the central literacy outcome of this unit. ASSUMPTION (framing): 'semantic vs. kinetic' is this course's teaching framing layered over the official elements (object/link types, action types, functions); the docs describe the elements, not this exact pair of labels.

Companion video

Deep Dive: Creating Your First Ontology · open on YouTube

Hands-on activity

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

    Read the Ontology overview and identify semantic vs kinetic elements

    Read the Ontology overview and the object-types overview, then practice naming the two sides of the Ontology in your own words. The semantic elements describe what exists — object types (the kinds of things the mission tracks), their properties (attributes), and link types (how those things relate). The kinetic elements describe what can be done — action types and functions that change the state of objects. Self-attest that you can, without notes, give one example of each: an object type, a property, a link type, and an action type drawn from a mission context. (Honest limit: this is a reading/recall deliverable; there is no read API that can confirm you read a docs page, so this step is self-attested.)

    not startedself-attested

    Self-attested: you can name semantic elements (object types, properties, link types) vs kinetic/operational ones.

  2. 2

    Sketch 3-4 notional mission object types and their links

    Sketch three or four notional mission object types and the links between them — for example Asset, Sensor, Track, and Mission — drawing labeled links such as 'Sensor detects Track', 'Mission tasks Asset', and 'Asset reports Track'. Name one or two action types that would change object state, such as 'Re-task Asset' or 'Update Track'. Keep it simple and notional: this is a hand-drawn or whiteboard sketch meant to show you can model the mission's nouns, their relationships, and a couple of governed operations. (Honest limit: a notional sketch is not a built Ontology, so the platform cannot machine-verify it; you self-attest that your sketch names coherent object types, links, and at least one action type.)

    not startedself-attested

    Self-attested: your sketch names mission object types and links them coherently.

  3. 3

    Explain Foundry's role as the 'data operations platform'

    Write a one-paragraph explainer of Foundry's role as the data operations platform. State that Foundry is where mission data is integrated and managed, where logic and workflows are authored, where analytics and low-code/no-code applications (such as Workshop) live, and where the Ontology is developed and hosted — making it the foundation the rest of the portfolio (AIP, and the wider operating picture) builds on. Avoid outdated or invented terms: say Foundry, the Ontology, object/link types, action types, and functions. (Honest limit: this is a recall/explainer deliverable with no learner-built artifact to verify, so it is self-attested.)

    not startedself-attested

    Self-attested: you can state Foundry provides data management, logic authoring, and the Ontology.

  4. 4

    (Enrichment) Read-only inspect a seeded demo Ontology

    Enrichment (read-only, existence/schema): if your enrollment has a platform-seeded demo Ontology provisioned, inspect it read-only and confirm that the expected notional object types resolve — demo.Asset, demo.Sensor, demo.Track, and demo.Mission — each exposing a primary key and properties. Compare what you see against the sketch you made in step 2 to reinforce how object types and links look as real platform elements. (Honest limit: this only confirms that a pre-seeded demo Ontology exists for you to look at; it does NOT confirm that you authored anything, and the step is skipped if no demo Ontology is provisioned on the enrollment.)

    not startedinstance check

    Existence+schema: confirms a platform-seeded demo Ontology exposes notional object types with primary keys.