Introduction

Scenario: Your governed supply-chain disruption copilot recommends responses that buyers act on, and leadership now requires that the LLM behind recommendDisruptionResponse be a deliberately chosen, observable model rather than a default — so you register a model under AIP governance, declare its capabilities, select it for the function, and reckon with its rate limits and the defense caveat that registered models do not support Markings.

Until now the disruption copilot has run on whatever model was convenient. This unit moves model choice into governance. In AIP, bring-your-own-model (BYOM), also called registered models, lets your enrollment connect its own LLMs and provider accounts so they flow natively through AIP rather than relying solely on Palantir-provided models. The current GA implementation registers a model once in Control Panel, under AIP settings > Registered models, after which it becomes selectable across the AIP apps you already use: AIP Logic, AIP Chatbot Studio, Workshop, AIP Analyst, AI FDE, and TypeScript functions in Code Repositories. Notably, AIP Assist and Pipeline Builder Generate/Explain do not support registered models, so a registered model cannot back those surfaces.

Registration is not just plumbing; it is a capability declaration. When you register a model you state which capabilities it supports — tool calling, reasoning, and structured outputs — and that declaration governs where the model can legitimately be used. Your recommendDisruptionResponse function depends on grounded tool calls and a defined structured output shape, so the model you choose must declare tool calling and structured outputs or the function cannot behave as designed. Once registered, the model is chosen through the shared model selector that the same selector control surfaces in every AIP app, which is how a single governed registration propagates to your Logic function and your TypeScript classifyDisruptionSeverity function alike. Rate limits and usage observability are then visible in Resource Management, at enrollment, project, and user scope, so you can reason about throughput and cost before the copilot is exercised at scale.

Two hard limits shape what you can prove and what you must simply attest. First, almost nothing about a registered model is exposed by a documented Foundry read API: the registration record, its declared capabilities, its rate limits, and the act of selecting it in the shared model selector are Control Panel and Resource Management admin artifacts, not decision-support data a runner can query. What a runner can confirm is end-to-end behavior — that the published recommendation function still executes and returns its structured keys after you change the backing model — by executing it through the Execute Query API. Second, and critically for a defense deployment: registered (BYOM) models do not support Markings. A model you bring in cannot carry Marking-based access controls the way Palantir-provided models can, so any classification-sensitive constraint must be enforced upstream — through the Ontology objects, Actions, and tool scopes the model is allowed to reach — rather than on the model itself. Record that caveat explicitly; it is the central governance trade-off of this unit.

Capability focus: Bring-your-own-model registration; capability declaration; model selection; rate-limit/usage awareness; the BYOM-Markings caveat. · Artifact: A registered model backing the function, with declared capabilities and rate-limit awareness.

Key concepts

Companion video

1. 1

   Function backed by the selected model still executes

   After you change the model backing recommendDisruptionResponse, the proof that matters to a runner is behavioral: the published function must still execute and return its structured result. The runner calls the published function through the Execute Query API (POST /api/v2/functions/queries/{queryApiName}/execute with preview=true), which runs the latest published version by apiName and returns its output as JSON; here it executes recommendDisruptionResponse on the seeded disruption (disruptionId DISR-CAP-1) and confirms the structured keys action, rationale, and confidence are present and non-empty. Re-publish the function after the model selection change so the latest published version reflects the chosen model, then confirm it still produces a valid recommendation. Understand what this does and does not prove: it confirms the function executes end-to-end with the selected model and yields a well-formed structured output, but it cannot reveal which registered model is bound, because the model-registration configuration is a Control Panel admin artifact, not something a documented Foundry read API exposes (R-BYOM1).

   not startedinstance check

   Run check

   Executes the published function after the model selection change and confirms a valid structured output.

2. 2

   Model registered in Control Panel with declared capabilities

   Register your chosen model in Control Panel under AIP settings > Registered models, and declare its capabilities — tool calling, reasoning, and structured outputs — so it is fit to back a function that relies on grounded tool calls and a defined output shape. This step is self-attested and cannot be machine-confirmed: the registration record and its declared capabilities live in Control Panel as an admin configuration, and no documented Foundry read API surfaces them to the runner (R-BYOM1). Capture evidence the reviewer can inspect directly — a screenshot of the Registered models entry showing the declared capabilities, plus the provider and model identity — and confirm the model is one AIP supports (providers include xAI, OpenAI, Anthropic, Meta, and Google). Treat the capability declaration as load-bearing: if tool calling or structured outputs is not declared, the recommendation function cannot behave as designed regardless of the underlying model's true abilities.

   not startedself-attested

   Mark complete

   Self-attested: a registered model with tool-calling/reasoning/structured-output capabilities appears in Control Panel.

3. 3

   Rate limits and usage observability reviewed

   Review the registered model's rate limits and usage observability in Resource Management at enrollment, project, and user scope, so you can reason about throughput and cost before the copilot is exercised at scale. This is self-attested: no documented read API surfaces AIP rate limits or usage telemetry to the runner, so the reviewer relies on what you record from Resource Management rather than an automated check. Note the limits that would bind your workflow — per-user and per-project ceilings most directly affect an interactive copilot — and observe current usage so you can spot whether evaluation runs or a live demo would approach a limit. Document the figures and where you read them; this awareness is part of operating a governed model responsibly, even though it is not verifiable through a decision-support API.

   not startedself-attested

   Mark complete

   Self-attested: enrollment/project/user rate limits and usage are reviewed in Resource Management.

4. 4

   Model selected via the shared model selector; defense BYOM-markings caveat noted

   Select the registered (or Palantir-provided) model through the shared model selector for recommendDisruptionResponse and, where relevant, for the TypeScript classifyDisruptionSeverity function — the same selector control appears across AIP Logic, AIP Chatbot Studio, Workshop, and TypeScript functions, so one governed registration propagates to each. This selection is self-attested and not API-inspectable; capture it with a screenshot of the selector showing the chosen model. Most important, record the defense caveat in writing: registered (BYOM) models do NOT support data Markings. A bring-your-own model cannot carry Marking-based access controls, so any classification-sensitive constraint must be enforced upstream — on the Ontology objects, Actions, and least-privilege tool scopes the model is permitted to reach — never on the model itself. State this trade-off explicitly in your deliverable, because it is the governing reason a defense deployment might prefer a Palantir-provided model or compensate with tighter Ontology-level controls.

   not startedself-attested

   Mark complete

   Self-attested: the model is chosen in the shared selector; the BYOM-doesn't-support-Markings caveat is recorded.