Introduction

Scenario: You are the orientation lead asked to tell one coherent end-to-end story of how a defense mission rides across the whole Palantir portfolio — from raw data to a decision at the tactical edge — so a mixed audience of operators, analysts, and program staff understands who does what and where classification is preserved.

This final unit synthesizes the orientation into a single mission flow. Instead of looking at one platform at a time, you trace one notional mission story end to end and attribute each step to the right platform: data is ingested and shaped in Foundry, given meaning by the Ontology, reasoned over by AIP, surfaced for decision and action in Gotham, and kept reliably deployed everywhere — including disconnected environments — by Apollo. The official integrated-platforms architecture describes AIP, Foundry, and Apollo working together as one Enterprise Operating System, and that is the frame your storyboard makes concrete.

The point of synthesis is correct attribution and continuity, not depth in any one tool. Foundry is the data operations platform that holds the data, logic, and the Ontology that represents enterprise decisions through objects, properties, links, and actions. AIP is the generative-AI platform whose builder tools (such as AIP Logic, AIP Chatbot Studio, and AIP Evals) reason on top of that Ontology. Gotham is positioned as the operating system for defense decision-making, powered by the same Foundry-managed Ontology through type mapping; treat Gotham's specific positioning as partial-confidence and confirm it against current Gotham product docs rather than asserting it as settled fact. Apollo is the continuous-delivery and day-2 operations platform that ships and operates the rest of the stack, and it can be configured on disconnected or air-gapped networks.

Two threads run through every panel. First, classification travels with the data: markings are mandatory controls a user must satisfy in full, CBAC adds conjunctive and disjunctive classification categories, and the architecture's governance guarantee means every operation by humans and agents abides by role-, marking-, and purpose-based controls captured in audit logging. Your storyboard should mark where that preservation holds as data crosses platform boundaries. Second, scope honesty: Maven Smart System (MSS) is a separate, future track that this orientation does not cover, and you should be able to say so plainly so the audience knows where this course ends.

Capability focus: End-to-end portfolio synthesis; per-platform responsibility; classification preservation across the flow; MSS as a future out-of-scope track. · Artifact: A mission-flow storyboard (5-7 panels) + a per-platform responsibility table.

Key concepts

Companion video

1. 1

   Storyboard the end-to-end mission flow

   Draw a 5-7 panel storyboard that moves one notional mission from raw data to action and attributes each step to the right platform in order: (1) raw sources ingested and shaped in Foundry; (2) that data given meaning by the Ontology as object types, properties, and links; (3) AIP reasoning over the governed Ontology to produce a recommendation; (4) Gotham surfacing the decision and enabling action in the battlespace (positioning — keep it high level); and (5) Apollo continuously delivering and operating the whole stack underneath, including to disconnected or air-gapped environments. This is a self-attested narrative deliverable; the value is a coherent, correctly ordered flow, not depth in any one platform. Where you describe Gotham's role, label it as positioning to confirm against current Gotham product docs.

   not startedself-attested

   Mark complete

   Self-attested: your 5-7 panel storyboard moves data → Ontology → AIP → Gotham → Apollo delivery.

2. 2

   Complete the per-platform responsibility table

   Complete a per-platform responsibility table with one row each for Foundry, AIP, Gotham, and Apollo, and three columns: a one-line role, a one-line mission contribution, and a one-line governance note. Foundry: data operations platform; holds and shapes mission data plus the Ontology; markings/CBAC/roles and audit logging originate here. AIP: generative-AI platform; reasons over the Ontology with builder tools like AIP Logic and AIP Chatbot Studio; every human and agent operation abides by role-, marking-, and purpose-based controls. Gotham: positioned as the operating system for defense decision-making, powered by the Foundry-managed Ontology via type mapping (partial-confidence — flag it); turns reasoning into decision and action; inherits mandatory controls. Apollo: continuous-delivery / day-2 operations platform; keeps the stack deployed and current, including air-gapped (IL5/IL6 accreditation claims are partial-confidence — do not assert as fact). This table is self-attested and judged against an instructor key.

   not startedself-attested

   Mark complete

   Self-attested: each of Foundry/AIP/Gotham/Apollo has a correct one-line role and mission contribution.

3. 3

   Show classification preservation across the flow

   Annotate your storyboard to show where classification is preserved as data crosses each platform boundary. Mark that markings are mandatory controls a user must satisfy in full, that CBAC adds conjunctive (must hold all in a category) and disjunctive (must hold any one, e.g., REL TO) classification categories, and that these travel with the data rather than being re-applied per tool. Note the governance guarantee from the architecture: AIP and Foundry operate together on a shared service mesh powered by Apollo, and every operation by humans and agents abides by role-, marking-, and purpose-based controls cataloged in audit logging. The deliverable is conceptual and self-attested — there is no read API that confirms a written annotation — so the standard is that each boundary crossing explicitly states what control keeps the data classified.

   not startedself-attested

   Mark complete

   Self-attested: your storyboard marks where markings/CBAC are preserved as data crosses platforms.

4. 4

   Place Maven Smart System as a future, out-of-scope track

   Add a short scope note stating plainly that Maven Smart System (MSS) is a separate, future track that this orientation does not cover, named here only to mark the edge of the course. This is an awareness checkpoint, intentionally manual and content-excluded per the course scope rules: you are not learning MSS, you are learning to recognize that it sits outside this orientation. Close by restating the honesty boundaries of the unit — Gotham positioning and Apollo accreditation claims are partial-confidence and should be confirmed against current product docs, and this is a literacy synthesis (reading, diagramming, attributing), not a hands-on build.

   not startedself-attested

   Mark complete

   Self-attested: you can state that Maven Smart System is a separate future track NOT covered here.