← 3c Enterprise


TL;DR? Then skip to Demo D3 “Speedrun – Your First Agentic AIP Workflow”, a great example of the direction this part of ZiptieAI is heading.


These demos are not for show. They are for do-it-yourselfers. Those like myself who want minimal text/diagrams and maximum useful info for getting hands-on experience. The main focus is on

  • Organizing the demos into a series that intros Foundry in logical order.
  • Getting the workflows correct and explaining the big picture concepts.
  • (1) Creating ZAI versions of existing PAL demos and (2) creating (from scratch with AI assistance) original ZAI demos (such as “3.1 D9 Haystack needle demo”).
  • Generating the ZAI website docs from docx files (using GPT).

See also (these are outdated… I will update them later)


TOC:

  • 1 External AI models (D1-D3). This is the first set of demos because (1) ZAI focuses primarily on AI and (2) external models are simpler than internal models.
  • 2 Internal AI models (D8a-D8g). Demos that show how to create and host internal models.
  • 2a Data protection and AI security (D3b, D3c) (added 26.0905). Data security = How do we prevent unauthorized access, disclosure, modification, or loss?
  • 2b Sovereignty comparisons (2b.1-2b.8) (added 26.0905). These demos compare external, internally controlled, and hybrid AI architectures to determine what the organization actually controls. The focus is not only data protection, but also model replaceability, application ownership, operational continuity, and control of decisions and outcomes.
  • 3 Core Foundry analytics without LLMs (D9, D5) (finding “needles in the haystack”). Foundry’s core value proposition predates generative AI. It integrates data from different systems, represents entities and relationships through the Ontology, and helps users discover patterns, anomalies, connections, and business processes that are difficult to see in isolated datasets. In these demos, the LLM is an optional analytical assistant; the underlying data integration, Ontology, analysis, applications, and Actions remain useful without it.
  • 4 Other demos. Duplicate or unimportant demos (or demos I could not get to work).


1 External AI models

This sections focuses on getting started (grasping core concepts via hands-on demos) with Foundry demos that use external AI models. This is the first set of demos because (1) ZAI focuses primarily on AI and (2) external models are simpler than internal models.

TOC:

  • 1.1 D1 = “Speedrun – Your First End-to-End Workflow”
  • 1.2 D2 = “Speedrun – Your First AIP Workflow”
  • 1.2b Both D2 and D3 send enterprise data to external LLMs — why does Palantir call D3 the first “agentic” demo?
  • 1.3 D3 = “Speedrun: Your First Agentic AIP Workflow”


1.1 D1 = “Speedrun – Your First End-to-End Workflow” (26.0818)

Your first hands-on with the basics (pipeline, ontology, actions, UI).

  • D1 does not include AI, but its perhaps a required starter for understanding the Foundry basics.
  • A good demo (though a bit too complicated as an initial demo.. I would make something simpler). Plan on spending minimum a full day on this (the demo docs say you will need only 60 minutes).
  • The ZAI splits the demos into 3 phases (this makes the demo much easier to finish and understand).

Demo D1 first end-to-end workflow diagram (no AI) (WIP)
xxx


1.2 D2 (WIP) = “Speedrun – Your First AIP Workflow” (26.0828)

Your first app with AI.

  • Use AI (external models) to clean up extracted chunks of text from PDFs, to extract text keywords (“entities” in the demo) from the chunk, to match a question to chunks via embeddings (machine language representation of the question/chunks meanings (not keywords)), make a RAG call with the question/chunks to answer the question.
  • About half of the demo has nothing to do with AI (the ZAI version splits the demo into 3 phases; phase 3 is the no-AI part; you can skip it).

Demo D2 first AIP workflow (ZAI) diagram (26.0828) (3 different AI models are used)
xxx


1.2b Both D2 and D3 send enterprise data to external LLMs—why does Palantir call D3 the first “agentic” demo? (26.0902)

Follow the above header link for details. See also the complete chat with FDE/GPT.

My own simple explanation (refer to diagram below)

  • Demo D2 made calls to external LLM. That is (in my opinion)
    • an AI agent
    • that shares internal data with an external LLM.
  • However, D3 (the next demo) does several things that D2 did not:
    • (3)(4) Foundry AIP_Logic (a no-code function definition) calls an LLM like D2, but it also modifies the ontology (core objects)
    • (2) Foundry Automation (event-driven automation service) provides a main loop that automatically processes (in D3 this means calling API_logic) any incoming onotology data changes.

[3] Demo D3 Foundry agent
xxx


1.3 D3 (WIP) = “Speedrun: Your First Agentic AIP Workflow” (26.0902)

This demo builds the first autonomous operational agent in this sequence.

  • (1) A new Patient is added through the UI and written to the Ontology.
  • (2) Automate detects that the Patient entered the monitored object set.
  • (3)(4a) AIP Logic evaluates the Patient against the selected Clinical Trial.
  • (3)(4b) The governed Action automatically writes the initial eligibility decision and reasoning.
  • (5) Staff review the result and may manually adjust the eligibility decision through the UI. This last step is important: Automation makes the initial operational decision, but staff retain oversight and can override it through a governed Action.

Diagram of the workflows for the ZAI version of demo D3 “Speedrun: Your First Agentic AIP Workflow”
xxx


2 Internal AI models

Demos that show how to create and host internal models.


I worked out the structure of this section with FDE/GPT on 26.0905… I will continue working on it from 10 Oct 2026.


TOC

  • 2.1 D8a — Model integration concepts
  • 2.2 D8b — Use an existing internal model
  • 2.3 D8c — Train and evaluate a custom model
  • 2.4 D8d — Batch and live inference
  • 2.5 D8e — Internal LLM and governed RAG
  • 2.6 D8f — Fine-tuning, if needed
  • 2.7 D8g — Model governance and operations


2.1 D8(a) (WIP) — Deep Dive: Model integration (26.0905)

Demo D8 explores how a traditional machine-learning model can be trained, deployed, and used for inference inside Palantir Foundry. The demo first examines Foundry’s Model Studio and model-management workflow, then creates a project and trains models using two approaches: Model Studio and a Jupyter notebook. Finally, the trained model is deployed and connected to an interactive application for inference. The demo therefore follows much of the model lifecycle: data → training → model → deployment → inference → application.

FDE VERSION: 2.1 D8a — Understanding models in Foundry

Identify the model resources, deployment options, input/output contracts, and differences among external APIs, imported models, internally hosted models, and custom-trained models.

Topics:

  • model versus model endpoint;
  • external versus internally deployed;
  • pre-trained versus custom-trained;
  • batch versus live inference;
  • model versions and dependencies.

Training of the internal model
xxx


2.2 D8b (TODO) — Deploy and call an existing internal model

Import or select an existing model, deploy it within the controlled environment, test its inference interface, and call it from a simple Foundry workflow.

This should be the smallest end-to-end internal-model demo:

  • Input → internal model → prediction


2.3 D8c (TODO) — Train a custom model

Prepare training data, select features and labels, train candidate models, compare evaluation metrics, and register the selected model version.

Start with a conventional classification or regression model rather than an LLM. It provides a much clearer introduction to:

  • training and validation data;
  • feature engineering;
  • overfitting;
  • metrics;
  • model selection.


2.4 D8d (TODO) — Operationalize model inference

Use a published model for batch inference in a pipeline and live inference from a Function or application. Compare the latency, scale, output, and deployment requirements of both approaches.

This connects modeling back to your standard workflow:

  • Pipeline → batch predictions → dataset/Ontology
  • UI or Function → live prediction → response/Action


2.5 D8e (TODO) — Build RAG with an internal LLM

Index governed internal content, retrieve only authorized context, send that context to an internally deployed LLM, and return a grounded response with source traceability.

Topics:

  • document extraction;
  • chunking;
  • embeddings;
  • semantic retrieval;
  • permission-aware retrieval;
  • context minimization;
  • prompt injection;
  • grounded answers and citations.

Fine-tuning should be a separate optional demo because it is not the same as RAG.


2.6 D8f (TODO) — Adapt a model to a specialized task

Where supported and justified, fine-tune or otherwise adapt a model using governed training data. Compare the adapted model with prompting and RAG before deciding whether the additional complexity is worthwhile.

This should be optional. Many use cases need prompting or RAG, not LLM fine-tuning.


2.7 D8g (TODO) — Govern and monitor internal models

Manage model versions, approvals, deployment promotion, access controls, evaluation thresholds, drift, monitoring, rollback, and retirement.

This is the internal-model equivalent of your Function versioning discussion.


2a Data protection and AI security (added 26.0905)

Data security = How do we prevent unauthorized access, disclosure, modification, or loss?

Topics include:

  • permissions and markings;
  • sensitive-data scans;
  • encryption;
  • download controls;
  • justification prompts;
  • audit logs;
  • prompt-data leakage;
  • Action restrictions.

The distinction can be demonstrated clearly:

  • Secure but not sovereign:
    • A well-protected vendor system that the vendor ultimately controls.
  • Sovereign but insecure:
    • A completely self-hosted system with weak permissions and poor security.
  • Secure and sovereign:
    • A company-controlled system with strong protection and governance.

TOC:

  • 2a.1 (1.4) (TODO) D3b — Protecting agents that use external AI models
  • 2a.2 (2.8) (was 2.2) D3c (TODO) — Rebuild the protected D3 agent with an internal AI model


2a.1 (1.4) (TODO) D3b — Protecting agents that use external AI models

Extend D3 with controls for both sides of the agent boundary: the enterprise data sent to an external LLM and the Ontology changes produced from its response. Proposed topics include sensitive-data detection, minimization and redaction, approved model access, prompt-injection defenses, output validation, constrained Actions, human approval, automation-loop safety, evaluation, monitoring, and rollback.

The objective is to determine which risks Foundry controls actually mitigate and which risks remain with the external model provider.

D3b is specifically about adding safety controls to the external-model D3 agent:

  • controlling data sent to the model;
  • detecting or minimizing sensitive content;
  • validating model responses;
  • constraining Actions;
  • adding approval, monitoring, and rollback.

It should be referenced from the external-model section, but its primary home is now 2a Data Protection and AI Security.

drones


2a.2 (2.8) (was 2.2) D3c (TODO) — Rebuild the protected D3 agent with an internal AI model

Replace D3b’s external LLM with an approved model deployed within the organization’s controlled environment. Optionally add RAG over governed internal sources, then compare external and internal implementations for confidentiality, accuracy, latency, cost, access control, deployment, and operational maintenance.

An internal model can reduce third-party data egress, but it does not eliminate prompt injection, excessive data access, unreliable outputs, or unsafe agent Actions. The D3b controls therefore remain relevant.

D3c sits at the intersection of:

  • internal models;
  • agent security;
  • data egress;
  • governed Actions.

Because it is explicitly a protected D3 agent, placing it after D3b in the security section creates a useful comparison:


2b Sovereignty comparisons (added 26.0905)

Sovereignty = Who ultimately controls the data, models, application, workflows, decisions, and operational future?

Comparative demos that hold the business task constant while changing who controls the model, data, RAG system, application, and operational decisions. These experiments examine data egress, model replaceability, provider dependency, continuity, and whether the organization retains control of its proprietary knowledge, Ontology, workflows, Actions, and outcomes.

Topics include:

  • internal versus external models;
  • data and model location;
  • ownership of the application and Ontology;
  • provider dependency;
  • model replaceability;
  • RAG and memory placement;
  • operational continuity;
  • control of outcomes and customer relationships.

Click on heading link above for current chats about the Palantir post below.

Those chats will be converted start in mid-October to demos based on previous demos (sections 1 and 2). The list of demos will be something like this (FDE list):

  • 2b.1 Define and measure sovereignty
  • 2b.2 External model with provider-controlled application
  • 2b.3 Foundry-controlled application with external model
  • 2b.4 Replace the external model with an internal model
  • 2b.5 Compare external, internal and provider-hosted RAG
  • 2b.6 Model-provider outage and model replacement
  • 2b.7 Agent Action, approval and decision sovereignty
  • 2b.8 Final sovereignty scorecard

Alex Karp sounding the alarm sovereignty in the enterprise.
xxx


3 Core Foundry analytics without LLMs

Foundry’s core value proposition predates generative AI. It integrates data from different systems, represents entities and relationships through the Ontology, and helps users discover patterns, anomalies, connections, and business processes that are difficult to see in isolated datasets. In these demos, the LLM is an optional analytical assistant; the underlying data integration, Ontology, analysis, applications, and Actions remain useful without it.

Palantir emerged in the post-9/11 period with the broader objective of helping organizations connect signals across fragmented data and identify unusual patterns relevant to security and intelligence. The same architecture is now applied to commercial and operational problems.


3.1 D9 (TO-UPDATE, DIY) = Haystack needle demo

What has interested me the most about Palantir for over a year now are “haystack needle” (HN) algorithms. This was the original reason for the founding of PAL. PAL’s job was to sift through vast amounts of data to flag potential threats (for the first decade or so without the help of AI). To find the needle in the haystack. Thats what this demo does. The demo is DIY (do it yourself), which means it was created from scratch with only FDE/GPT assistance.

xxx


3.2 D5 (TO-UPDATE): Speedrun: Mining Your First Business Process (26.0718)

FDE: The demo starts with claims, customers, and claim-history logs. After ingesting these datasets into Foundry, the data is modeled as Ontology objects such as Customers and Claims. Machinery then uses the process logs to reconstruct how claims move through the business process over time. Once the process map is built, you can inspect where claims get stuck, identify why some remain unresolved, and embed the process view into an interactive application.

xxx


4 Other demos

Duplicate or unimportant demos (or demos I could not get to work).


26.0906 (v1 26.0725)





NOTES


Yes—the structure and core conceptual progression are sound.

It moves logically through:

Sovereignty motivation
→ understand model integration
→ deploy an existing model
→ train a custom model
→ operationalize inference
→ add governed RAG
→ consider fine-tuning
→ govern and monitor models
→ use an internal model in the protected D3 agent

Specific structural strengths:

  • 2.0 explains why internal models matter.
  • D8a–D8g decompose an otherwise oversized model-integration topic.
  • RAG and fine-tuning are correctly treated as separate concepts.
  • Governance follows deployment and adaptation.
  • D3c works well as the capstone, integrating the model work with the earlier agent and security work.
  • The existing D8 deep dive can initially serve as the umbrella/starting demo; overlaps can be separated later.

The only broad concept to revisit later is the exact meaning of internal, local, and sovereign—they are related but not automatically equivalent. Likewise, the interpretation of Karp’s claims should eventually be distinguished from what can be independently demonstrated. Neither issue requires changing the current structure.


(1) the ZiptieAI webpage for D8 (my original ) is below.

i have been working on this demo past few days… the source for the demo is not a speedrun, but the PAL website.. so there a lot of jumping around, differrent options, very difficult to follow….

so what you have given me is basically a straight path through the whole topic? and after i get back from xxx we can work together to match up the website docs with your path?

1. D8 structure

Yes. The D8a–D8g sequence I suggested is a coherent, straight learning path through the larger subject. It is a proposed curriculum, not a claim that Palantir’s current Model Studio pages already present the material that way.

Your existing D8 work maps into that path reasonably well:

Current D8 material Proposed path
D8.1 Goal Overall orientation
D8.2 Model Studio D8a: model-integration concepts
D8.3 Project Setup shared by later demos
D8.4 Train in Model Studio D8c: custom-model training
D8.5 Train in Jupyter D8c: alternative training approach
D8.6 Inference app D8d: deployment and live inference
D8.7 Summary Transition to operational inference

Your present demo already covers a substantial vertical slice:

Understand infrastructure
→ create project
→ train model
→ deploy model
→ call model from application

The later proposed demos add topics that the current D8 does not fully cover:

  • starting from an existing model;
  • batch and streaming inference;
  • internal LLMs;
  • governed RAG;
  • model adaptation/fine-tuning;
  • model governance and monitoring;
  • integration into the protected D3 agent.

After you return, we can map the Palantir pages and your existing screenshots onto that sequence, identify overlaps and gaps, and decide whether to split the current D8 document into D8a, D8b, D8c, and so forth. There is no need to restructure it before your trip.


2. Account lifespan

The information you found is reassuring, but I would distinguish the two claims:

  • Developer Tier lifespan: the claim that it is available indefinitely appears to mean there is no ordinary fixed 30- or 60-day trial expiration.
  • User inactivity: after approximately 30 days without login, the user may be marked inactive and security tokens disabled. If the official policy applies to your tenant, an interactive login should reactivate the user rather than requiring the account to be recreated.

Therefore, after xxx away, the likely sequence is:

No login for more than 30 days
→ user marked inactive
→ existing account/resources remain
→ next successful login reactivates user

The Reddit source is not authoritative, and program terms can change, so it is not an absolute guarantee. However, your account already remaining available for approximately two months is consistent with it being a Developer/Learning tier rather than a short fixed-duration trial.

Before leaving:

  • retain your DOCX files, Markdown, and screenshots locally;
  • make sure you have working MFA and recovery access;
  • record the Foundry organization and login method;
  • pause any Automations you do not want running during your absence;
  • do not attempt to access the account over a connection you consider unsafe.

On the evidence available, five weeks of inactivity is more likely to cause a reversible inactive status than deletion of your account and projects.