Palantir Foundry CI and Review Gates

Overview

Build the quality gate around Foundry Code Repository branches, automatic checks, unit tests, and pull-request review. External Git hosting may mirror evidence, but it must not replace the checks that Foundry runs against repository inputs, outputs, dependencies, and platform builds.

Prerequisites

• Identify the Foundry enrollment, Code Repository, target branch, owned datasets, and release owner.
• Confirm whether the repository uses Python transforms, TypeScript, or another supported project type.
• Read references/official-docs.md and inspect the repository's effective CI and branch settings before proposing changes.
• Use a sandbox branch and non-production data until the checks and rollback path are proven.

Current Contract

• A commit to a Code Repository branch runs automatic checks; the Checks tab is the primary result surface.
• Python unit tests can participate in repository CI when configured according to the repository's supported build layout.
• Transform input and output declarations are evaluated by CI and cannot be chosen dynamically at build time.
• A pull request can require approving review before merge, and reviewers can inspect dataset impact for transform changes.

Instructions

1. Inventory current branch protection, checks, unit-test wiring, build ownership, and required reviewers.

1. Create or update tests so each test isolates one unit of transform logic and avoids live external dependencies.

1. Run the Foundry branch checks and preserve the exact failing check, build report, and dependency evidence.

1. Open a Foundry pull request, review code plus dataset impact, and obtain the required independent approval.

1. Merge only the exact reviewed commit, then verify the main-branch checks and downstream build behavior.

Tool Discipline

• Use Glob to locate candidate repositories, manifests, configurations, and evidence without widening scope.
• Use Grep to find relevant identifiers, declarations, permissions, errors, and stale claims.
• Use Read to inspect the smallest required files and authoritative evidence.
• Use Write only for a new approved local draft, test, manifest, or evidence artifact.
• Use Edit only for a bounded approved change whose rollback is known.
• Do not use file tools as a substitute for authenticated Foundry operations or owner approval.

Approval Boundaries

Require the Code Repository owner to approve branch-policy changes and the data owner to approve changes to dataset inputs, outputs, or production builds. Do not bypass a failed Foundry check or approving-review requ…

Palantir Foundry Error Triage

Overview

Triage the failing surface before changing credentials, permissions, code, or compute. Preserve the server request identifier and Foundry build evidence so similar-looking failures are not collapsed into the same cause.

Prerequisites

• Capture the exact status code or Foundry error name, request identifier, timestamp, endpoint or build, and affected principal.
• Identify whether the call uses a temporary user token, authorization-code token, or client-credentials service user.
• Read references/official-docs.md; use the API reference and in-platform build report as the current contract.
• Reproduce with a read-only request or sandbox branch whenever possible.

Current Contract

• A 401 points to missing, malformed, expired, or otherwise unusable authentication; it does not justify broader scope.
• A 403 can result from the intersection of token scope, application restrictions, user/service-user permissions, project roles, and mandatory controls.
• Foundry documents global rate and concurrency limits, while individual endpoints may impose stricter limits and return 429 or 503.
• Transform preview and full build can differ because preview may use a subset of data; repository checks also evaluate dependencies and declared resources.

Authentication

All Foundry REST API calls use OAuth 2.0 bearer tokens. Never print or persist a token in the triage report. Record the grant type, requested scopes, Developer Console restrictions, and effective user or service-user permissions without recording credential values.

Instructions

1. Classify the failure as authentication, authorization, limit/concurrency, resource identity, dependency, transform logic, or platform availability.

1. Preserve the smallest complete evidence set: request ID, build ID, branch, commit, principal type, scope names, and affected RIDs or API names.

1. For auth failures, evaluate token validity, scope, application restrictions, project role, and mandatory markings in that order.

1. For 429 or 503, honor server guidance and apply bounded exponential backoff with jitter; reduce concurrency before retrying.

1. For build failures, inspect the detailed report, compare preview and full inputs, and test the minimal failing transform on a sandbox branch.

Tool Discipline

• Use Glob to locate candidate repositories, manifests, configurations, and evidence without widening scope.
• Use Grep to find relevant identifiers, declarations, permissions, errors, and stale claims.
• Use Read to inspect the smallest required files and authoritative evidence.
…

Palantir Python Transform Pipeline

Overview

Create a pipeline whose inputs, outputs, engine, write behavior, and quality checks are explicit before the first production build. Prefer the simplest supported compute engine that satisfies data scale and feature requirements, then prove the choice with Foundry metrics.

Prerequisites

• Identify the owning project, Code Repository, input and output datasets, schema contract, data classification, and build schedule.
• Confirm whether the workload requires Spark or can use a single-node engine such as Polars, pandas, or DuckDB.
• Read references/official-docs.md and inspect current input transaction history before selecting incremental semantics.
• Develop on a sandbox branch with representative but appropriately protected data.

Current Contract

• Python transforms support batch and incremental pipelines, reusable libraries, expectations, and single-node or distributed engines.
• Input and output datasets must differ; using the same dataset creates a cyclic dependency.
• Incremental input modes and output write modes have precise transaction semantics; modify and replace are not interchangeable.
• A snapshot build may be needed when incremental transaction history becomes progressively slow or invalid.

Instructions

1. Write the pipeline contract: owner, inputs, output, primary key or deduplication rule, schema, data-quality expectations, and recovery objective.

1. Choose the engine from required features and observed scale; document why single-node or Spark is appropriate.

1. Implement the transform with explicit input and output declarations and keep pure business logic separately testable.

1. If incremental processing is justified, define input read modes, output write mode, late-arrival behavior, and snapshot recovery.

1. Preview representative cases, run repository checks, build on the branch, inspect metrics and output transactions, then request review.

Tool Discipline

• Use Glob to locate candidate repositories, manifests, configurations, and evidence without widening scope.
• Use Grep to find relevant identifiers, declarations, permissions, errors, and stale claims.
• Use Read to inspect the smallest required files and authoritative evidence.
• Use Write only for a new approved local draft, test, manifest, or evidence artifact.
• Use Edit only for a bounded approved change whose rollback is known.
• Do not use file tools as a substitute for authenticated Foundry operations or owner approval.

Approval Boundaries

The data owner must approve new outputs, schema changes, marking changes, ret…

Palantir Ontology Application Workflow

Overview

Use the generated Ontology SDK as the typed contract for a Developer Console application. Keep reads, Functions, and Actions distinct, and validate writeback before execution when the generated SDK and action support it.

Prerequisites

• Identify the Developer Console application, Foundry environment, selected Ontology entities, grant type, application restrictions, and data owner.
• Generate or select the OSDK language and version required by the application; do not guess object, property, link, Action, or Function API names.
• Read references/official-docs.md and the application-specific generated documentation in Developer Console.
• Prepare test objects and a non-production Action path.

Current Contract

• An OSDK is generated for a selected subset of an Ontology and supports TypeScript, Python, Java, and other-language generation paths.
• Application access is the intersection of the acting user or service user, OAuth scopes, and Developer Console restrictions.
• In TypeScript OSDK 2.x, generated definitions are passed to the client for object operations, Actions, and Functions.
• Action validation and returned edits are explicit options; validation-only and returned-edits modes cannot be assumed interchangeable.

Authentication

Use the Developer Console grant chosen for the application: authorization code for user-delegated applications or client credentials for a backend service. Never embed a client secret or bearer token. Record scopes and resource restrictions separately from the Foundry permissions of the user or service user.

Instructions

1. Define the user job and list the minimum object types, interfaces, links, Actions, and Functions the application requires.

1. Configure the Developer Console application and generate the OSDK with only those Ontology resources.

1. Implement a bounded object query with explicit filters, selected properties, deterministic ordering, and pagination.

1. Add link traversal, aggregation, or Function execution only where the generated contract requires it.

1. For writeback, validate the Action against non-production objects, review edits and validation errors, then execute only after owner approval.

Tool Discipline

• Use Glob to locate candidate repositories, manifests, configurations, and evidence without widening scope.
• Use Grep to find relevant identifiers, declarations, permissions, errors, and stale claims.
• Use Read to inspect the smallest required files and authoritative evidence.
• Use Write only for a new approved local draft, test, manifest, or evidence artifact.
• Use Ed…

Palantir Compute and Usage Optimization

Overview

Optimize from measured Foundry usage and telemetry, not invented data-volume bands. Separate transform-build consumption from interactive Compute Module replica consumption because they have different controls and failure modes.

Prerequisites

• Identify the pipeline, build jobs, Compute Modules, schedules, owners, service objectives, and current usage window.
• Capture build duration, requested and observed CPU/memory, queue time, input change rate, output volume, and module replica activity.
• Read references/official-docs.md and confirm contract-specific pricing or usage questions with the account owner or Palantir representative.
• Define correctness and latency constraints that cannot be traded away.

Current Contract

• Python transforms can use single-node engines or Spark; required feature support constrains the choice.
• Foundry build metrics expose requested and observed CPU and memory, enabling evidence-based resource changes.
• Incremental transforms can reduce repeated work only when their transaction semantics remain correct.
• Compute Module usage is measured while replicas are starting or active, including predictive autoscaling behavior.

Instructions

1. Build a baseline that separates transform jobs, schedules, previews, retries, snapshots, and Compute Module replicas.

1. Rank usage drivers by measured consumption and business criticality.

1. Test one change at a time: engine, resource request, incremental mode, schedule, batch shape, property selection, or replica policy.

1. Compare output parity, latency, failure rate, queue time, and consumption against the baseline.

1. Promote the smallest validated change and monitor one full representative operating window.

Tool Discipline

• Use Glob to locate candidate repositories, manifests, configurations, and evidence without widening scope.
• Use Grep to find relevant identifiers, declarations, permissions, errors, and stale claims.
• Use Read to inspect the smallest required files and authoritative evidence.
• Use Write only for a new approved local draft, test, manifest, or evidence artifact.
• Use Edit only for a bounded approved change whose rollback is known.
• Do not use file tools as a substitute for authenticated Foundry operations or owner approval.

Approval Boundaries

The pipeline owner approves transform and schedule changes; the application owner approves module scaling changes; the commercial owner approves interpretations of contract pricing. Never shut down production compute or relax correctness controls solely to reduce usage.

Ou…

Palantir Data Governance and Handling

Overview

Map the full data path before editing a permission or transform. Foundry discretionary roles, mandatory controls, Ontology row/property policies, and downstream exports protect different boundaries and must be reviewed separately.

Prerequisites

• Identify data owner, purpose, classifications, source datasets, derived resources, Ontology objects and properties, logs, exports, and retention obligations.
• Record the projects, organizations, markings, CBAC policies, groups, and roles governing each stage.
• Read references/official-docs.md and involve the information-security or privacy owner for regulated data.
• Use synthetic data for policy tests unless a protected test environment is approved.

Current Contract

• Projects and roles provide discretionary access, while organizations, markings, and CBAC remain mandatory and propagate according to their own rules.
• Ontology object and property policies can implement row- and column-level read controls; granular controls do not automatically protect downstream exports.
• Mandatory controls within security policies continue to protect derived data where the documented propagation rules apply.
• Logs and audit exports may contain sensitive or personal data and require explicit access, marking, retention, and audience decisions.

Instructions

1. Draw the data-flow and authority map from ingestion through transforms, Ontology, applications, logs, and exports.

1. Classify each resource and define the minimum project roles, groups, mandatory controls, and application restrictions.

1. Configure Ontology object/property policies for read-time needs and pair them with mandatory controls when downstream propagation is required.

1. Define retention, deletion, export, and audit evidence procedures with accountable owners.

1. Test authorized, unauthorized, downstream-derived, log-viewing, and export cases before production.

Tool Discipline

• Use Glob to locate candidate repositories, manifests, configurations, and evidence without widening scope.
• Use Grep to find relevant identifiers, declarations, permissions, errors, and stale claims.
• Use Read to inspect the smallest required files and authoritative evidence.
• Use Write only for a new approved local draft, test, manifest, or evidence artifact.
• Use Edit only for a bounded approved change whose rollback is known.
• Do not use file tools as a substitute for authenticated Foundry operations or owner approval.

Approval Boundaries

The data owner approves purpose and access; the security owner approves markings or CBAC; the privacy…

Palantir Redacted Diagnostic Bundle

Overview

Collect identifiers and platform evidence that allow another operator to reproduce the failure while excluding bearer tokens, secrets, object values, dataset rows, and unnecessary logs. The bundle is an inventory and evidence manifest, not an indiscriminate archive.

Prerequisites

• Identify the failure surface, time window, owner, support case, audience, and maximum allowed data classification.
• Obtain request IDs, build IDs, repository branch/commit, module version, SDK package versions, and non-secret environment metadata.
• Read references/official-docs.md and confirm whether log access is enabled and appropriately marked.
• Create the bundle in an access-controlled temporary location with an expiration owner.

Current Contract

• Foundry build reports, debugger sessions, and metrics are distinct evidence surfaces.
• Service and trace logs can contain values from prompts, objects, or upstream systems; viewing them can require Edit permission, log access, and markings.
• A caller can record OAuth grant type and scope names without recording a bearer token or client secret.
• Python transform debugging is an interactive investigation tool; debugger values are not proof of committed output.

Instructions

1. Write a manifest naming the incident, audience, time window, collection authority, and prohibited data.

1. Collect exact IDs, versions, branch/commit, timestamps, status or error names, sanitized request metadata, and relevant platform links.

1. Export only the smallest log excerpts authorized for the audience and replace tokens, secrets, personal data, and protected values with typed redaction markers.

1. Reproduce the issue with a safe request, preview, or sandbox build and record the result.

1. Review the bundle against the prohibition list, compute file hashes, set an expiration, and transfer through the approved channel.

Tool Discipline

• Use Glob to locate candidate repositories, manifests, configurations, and evidence without widening scope.
• Use Grep to find relevant identifiers, declarations, permissions, errors, and stale claims.
• Use Read to inspect the smallest required files and authoritative evidence.
• Use Write only for a new approved local draft, test, manifest, or evidence artifact.
• Use Edit only for a bounded approved change whose rollback is known.
• Do not use file tools as a substitute for authenticated Foundry operations or owner approval.

Approval Boundaries

The resource owner authorizes evidence collection; the security or data owner authorizes any logs; the support owner authorizes trans…

Palantir Application and Compute Deployment

Overview

Select the deployment primitive from the workload instead of defaulting to an external cloud runtime. Use Developer Console and Marketplace for OSDK applications, DevOps products for release-managed resources, or Compute Modules for compatible container workloads inside Foundry.

Prerequisites

• Identify the workload, owners, target environment, runtime needs, data access, availability objective, and rollback requirement.
• Determine whether it is an OSDK website/application, a packaged Foundry product, a container-backed function, or a container-backed pipeline.
• Read references/official-docs.md and the target enrollment's in-platform Compute Module or DevOps instructions.
• Prepare a versioned artifact and non-production target.

Current Contract

• Compute Modules run interactive container images in Foundry and support container-backed functions, pipelines, and custom integrations.
• Compute Module images must meet documented platform, user, tag/digest, and port requirements.
• Developer Console applications can be packaged through Marketplace with OAuth client metadata and resource restrictions.
• DevOps/Marketplace installation can remap supported environment parameters, while Ontology API-name handling still requires deliberate design.

Authentication

Use Developer Console OAuth for application access and Foundry's approved artifact/deployment authentication for publishing. Keep client secrets and bearer tokens in approved secret surfaces; do not bake them into images, code repositories, product parameters, or website assets.

Instructions

1. Classify the workload and select Developer Console/Marketplace, a DevOps product, or a Compute Module with a written rationale.

1. Inventory dependencies, OAuth grants, resource restrictions, parameters, markings, artifact repository, and target-space ownership.

1. Build and test a versioned artifact; for containers, verify non-root numeric user, linux/amd64, allowed ports, and a non-latest tag or digest.

1. Install or configure in a non-production environment and run functional, security, scaling, and failure-path checks.

1. Promote the exact artifact through the approved release path, verify health and logs, and retain the prior version for rollback.

Tool Discipline

• Use Glob to locate candidate repositories, manifests, configurations, and evidence without widening scope.
• Use Grep to find relevant identifiers, declarations, permissions, errors, and stale claims.
• Use Read to inspect the smallest required files and authoritative evidence.
• Use Write only for a n…

Palantir Foundry Access-Control Design

Overview

Treat access as the intersection of several control planes. Project roles govern discretionary capabilities, mandatory controls continue to apply, and OAuth application restrictions constrain API clients independently.

Prerequisites

• Identify the resources, projects, spaces, organizations, markings or CBAC requirements, groups, users, service users, and Developer Console applications in scope.
• Name the data owner, project owner, application owner, information-security owner, and access-review cadence.
• Read references/official-docs.md and use the Check access panel for concrete principals and resources.
• Begin with a read-only entitlement inventory; do not grant access while discovering it.

Current Contract

• Default project roles are Owner, Editor, Viewer, and Discoverer, and deployments may also define custom roles.
• Palantir recommends group role grants at the project level to reduce individual-grant sprawl.
• Organizations, markings, and CBAC can deny access even when a project role is present.
• Developer Console token authority is limited by the user/service-user permissions, application restrictions, and requested OAuth scope.

Authentication

For API clients, record the OAuth grant type, service user or delegated user, requested scopes, and Developer Console resource/operation restrictions. Never treat possession of a token as evidence that the underlying principal should have access.

Instructions

1. Build a matrix of principal or group, project role, resource purpose, mandatory requirements, application restrictions, owner, and expiry.

1. Replace unnecessary direct user grants with reviewed group grants while preserving break-glass and accountable-owner requirements.

1. Use Check access on representative resources to explain both discretionary and mandatory requirements for each persona.

1. For service applications, restrict the Developer Console client to the minimum operations and Ontology or Platform SDK resources.

1. Run positive and negative access tests, obtain owner attestations, remove temporary access, and schedule recertification.

Tool Discipline

• Use Glob to locate candidate repositories, manifests, configurations, and evidence without widening scope.
• Use Grep to find relevant identifiers, declarations, permissions, errors, and stale claims.
• Use Read to inspect the smallest required files and authoritative evidence.
• Use Write only for a new approved local draft, test, manifest, or evidence artifact.
• Use Edit only for a bounded approved change whose rollback is known.
• Do not use fil…

Palantir OSDK First Read and Validated Action

Overview

Prove the smallest safe vertical slice: Developer Console application, generated OSDK, authenticated client, bounded object read, and an optional validation-only Action. Avoid mixing the Platform SDK, OSDK, transforms, and deployment in the first proof.

Prerequisites

• Choose a non-production Foundry environment and a low-sensitivity object type with a few synthetic or approved test objects.
• Identify the application owner, Ontology owner, OSDK language, user-delegated or backend-service grant, and selected Ontology resources.
• Read references/official-docs.md plus the generated application-specific documentation in Developer Console.
• Prepare an approved Action only if validation-only behavior is available and no production write is required.

Current Contract

• Developer Console creates and manages OSDK applications and generates language-specific packages for selected Ontology resources.
• The generated OSDK exposes the actual object types, links, Actions, and Functions selected for that application.
• An OSDK application authenticates with OAuth as a public/confidential user application or backend service, according to its design.
• A first read should be bounded by filters, selected properties, deterministic ordering, and pagination.

Authentication

Use the Developer Console generated setup for the chosen grant. Keep client secrets and bearer tokens in approved local or deployment secret storage. Record grant type, scopes, restrictions, redirect behavior, and principal without recording credential values.

Instructions

1. Create or select the Developer Console application and add only one test object type plus an approved Action if needed.

1. Generate and install the OSDK version shown by Developer Console; pin the generated package and compatible client.

1. Initialize the authenticated client using the generated setup and verify the expected principal/environment.

1. Read a small deterministic page of objects with selected properties and record pagination behavior.

1. If writeback is in scope, run the generated Action in validation-only mode, review the result, and stop before execution unless separately approved.

Tool Discipline

• Use Glob to locate candidate repositories, manifests, configurations, and evidence without widening scope.
• Use Grep to find relevant identifiers, declarations, permissions, errors, and stale claims.
• Use Read to inspect the smallest required files and authoritative evidence.
• Use Write only for a new approved local draft, test, manifest, or evidence artifact.
• Use Edit only for…

Palantir Foundry Incident Response

Overview

Protect data integrity and access controls while restoring service. Classify the failing Foundry surface, preserve request/build/release evidence, apply the least risky reversible mitigation, and validate recovery before closing.

Prerequisites

• Name the incident commander, technical owner, data owner, communications owner, severity, affected resources, and start time.
• Capture request IDs, build IDs, branch/commit, product or artifact version, module state, and recent approved changes.
• Read references/official-docs.md and the target enrollment's operational procedures.
• Confirm the rollback authority and protected-data handling rules before collecting logs.

Current Contract

• API 429 or 503 can represent rate or concurrency limiting and should receive bounded backoff rather than an unbounded retry storm.
• Transform build reports and metrics distinguish queue, CPU, memory, dependency, and data-related failures.
• DevOps/Marketplace release management can retain prior versions and support controlled upgrades or rollback.
• Logs may expose sensitive content and require explicit log access plus appropriate markings.

Authentication

Record grant type, principal, scope names, and application restrictions for API incidents, never token values. Do not rotate credentials until evidence distinguishes an authentication failure from permissions, restrictions, mandatory controls, throttling, or platform availability.

Instructions

1. Declare severity, impacted workflow, current data-integrity risk, access-control risk, and the last known healthy version or build.

1. Classify the incident as API/auth, transform/build, OSDK/application, Compute Module, data quality, permissions, or release regression.

1. Preserve bounded evidence and freeze unrelated changes; restrict retries and writeback when integrity is uncertain.

1. Choose the safest reversible mitigation: reduce concurrency, pause a schedule, disable a failing consumer, restore an artifact/product version, or isolate a bad output.

1. Verify recovery through service health plus data correctness and permission checks, then publish a timeline and corrective actions.

Tool Discipline

• Use Glob to locate candidate repositories, manifests, configurations, and evidence without widening scope.
• Use Grep to find relevant identifiers, declarations, permissions, errors, and stale claims.
• Use Read to inspect the smallest required files and authoritative evidence.
• Use Write only for a new approved local draft, test, manifest, or evidence artifact.
• Use Edit o…

Palantir SDK Selection and OAuth Setup

Overview

Choose the SDK from the job: a generated OSDK for application-specific Ontology access, or the Platform SDK for broader Foundry/AIP REST APIs. Then configure OAuth through Developer Console with the minimum grant, scope, resources, and operations.

Prerequisites

• Identify the application type, language, Foundry environment, acting user or service user, required APIs, and accountable owner.
• List the minimum Ontology entities or Platform API operations before creating credentials.
• Read references/official-docs.md and use Developer Console's generated Start developing instructions for the target application.
• Prepare an approved secret store and non-production verification resource.

Current Contract

• Foundry APIs use OAuth 2.0 bearer tokens.
• Authorization Code grant is for applications acting on behalf of users; Client Credentials grant is for backend services acting as a service user.
• Developer Console application restrictions limit available Ontology resources or Platform SDK operations in addition to requested scopes and principal permissions.
• Temporary user API tokens may support development, but production applications should use the appropriate OAuth grant.

Authentication

Never ask for, print, or commit a bearer token, client secret, authorization code, or refresh token. Store secrets only in an approved manager. Record the client ID only where allowed, and inventory grant type, redirect URLs, requested scopes, application restrictions, service-user permissions, owners, and rotation.

Instructions

1. Choose generated OSDK or Platform SDK and document why the other surface is insufficient or unnecessary.

1. Create or select the Developer Console application and configure the user-delegated or backend-service grant.

1. Restrict the client to the required Ontology entities or Platform SDK operations and request the minimum scopes.

1. Install and pin the generated/package SDK plus its compatible client using the application-specific instructions.

1. Verify a bounded read in the target environment, test denial outside the intended restriction, and record secret rotation and revocation.

Tool Discipline

• Use Glob to locate candidate repositories, manifests, configurations, and evidence without widening scope.
• Use Grep to find relevant identifiers, declarations, permissions, errors, and stale claims.
• Use Read to inspect the smallest required files and authoritative evidence.
• Use Write only for a new approved local draft, test, manifest, or evidence artifact.
• Use Edit only for a bounded approved change wh…

Palantir Local and In-Platform Development Loop

Overview

Keep pure logic fast and local while treating Foundry preview, checks, and builds as separate evidence. A local mock can verify application logic, but it cannot prove Foundry permissions, lineage, transactions, or full-data behavior.

Prerequisites

• Identify the Code Repository or Developer Console application, language, branch, data sensitivity, and target environment.
• Install the supported Palantir VS Code extension or use an in-platform workspace as appropriate.
• Read references/official-docs.md and the repository's generated in-platform documentation.
• Prepare lightweight unit fixtures without production data and a sandbox branch.

Current Contract

• Foundry Code Repositories support sandbox branches, automatic checks, unit tests, previews, pull requests, and full builds.
• Preview can use sample or subset data; a full build runs on platform data and commits pipeline output.
• The VS Code extension can preview, debug, synchronize, and initiate Foundry builds from a local workspace.
• Local tests should isolate business logic and avoid relying on live external resources.

Authentication

Use the approved Palantir VS Code or Developer Console sign-in for the intended environment. Keep generated OAuth settings and any test credentials in approved local secret storage, and never place tokens or production object data in fixtures, logs, or repository files.

Instructions

1. Separate pure transformation or application logic from Foundry adapters and generated SDK code.

1. Write deterministic unit tests using synthetic fixtures and run them before any platform request.

1. Synchronize the sandbox branch, run Foundry checks, and preview representative inputs with protected-data rules intact.

1. Use the Foundry debugger for Python transform behavior when needed; treat observed values as diagnostic only.

1. Push the exact branch, run the full Foundry build or bounded OSDK smoke test, inspect results, and open a reviewed pull request.

Tool Discipline

• Use Glob to locate candidate repositories, manifests, configurations, and evidence without widening scope.
• Use Grep to find relevant identifiers, declarations, permissions, errors, and stale claims.
• Use Read to inspect the smallest required files and authoritative evidence.
• Use Write only for a new approved local draft, test, manifest, or evidence artifact.
• Use Edit only for a bounded approved change whose rollback is known.
• Do not use file tools as a substitute for authenticated Foundry operations or owner approval.

Approval Boundaries

Palantir Foundry Migration and Cutover

Overview

Migrate contracts and evidence, not just bytes. Inventory data semantics, identities, access controls, pipeline transactions, Ontology entities, applications, and operational dependencies before dual-running a bounded slice.

Prerequisites

• Name source and target owners, business workflows, datasets, schemas, identities, controls, service objectives, retention, and rollback deadline.
• Choose the target Foundry primitives: connectors, transforms, Ontology resources, OSDK application, DevOps product, or Compute Module.
• Read references/official-docs.md and document features or resources that do not map directly.
• Establish a frozen baseline and approved non-production landing zone.

Current Contract

• Foundry applications and resources can be packaged and promoted with DevOps and Marketplace across environment spaces.
• Developer Console application installation remaps supported parameters, but API-name consistency and dependencies still require explicit handling.
• Incremental transforms have transaction-history requirements and must reconcile with snapshot behavior.
• Access control combines project roles, mandatory controls, Ontology policies, and application restrictions.

Authentication

Inventory source and target identities, OAuth grant types, service users, scopes, and application restrictions as separate migration contracts. Store secrets in approved managers, rotate them through a staged cutover, and never copy source credentials into the target environment.

Instructions

1. Inventory source contracts: identifiers, schemas, update/delete semantics, volumes, SLAs, consumers, permissions, audit requirements, and failure modes.

1. Design target datasets, transforms, Ontology entities, Actions, applications, and controls with an explicit mapping for every source contract.

1. Load a bounded historical slice, then establish incremental capture or repeatable deltas with reconciliation keys.

1. Dual-run representative workflows and compare counts, aggregates, sampled records, actions, permissions, latency, and failure handling.

1. Freeze changes, reconcile final deltas, obtain owner sign-off, cut consumers over in stages, and retain the tested rollback window.

Tool Discipline

• Use Glob to locate candidate repositories, manifests, configurations, and evidence without widening scope.
• Use Grep to find relevant identifiers, declarations, permissions, errors, and stale claims.
• Use Read to inspect the smallest required files and authoritative evidence.
• Use Write only for a new approved local draft, test, manifest, or evidence artifact.
• U…

Palantir DevOps Environment Separation

Overview

Represent long-lived environments with Foundry spaces and promote versioned products through DevOps and Marketplace. Use Global Branching for isolated changes within an environment, not as a substitute for every long-lived environment boundary.

Prerequisites

• Identify the enrollment, DevOps store, source products, target spaces, owners, dependencies, security policies, external systems, and approval chain.
• Inventory environment-specific sources, sinks, URLs, OAuth clients, markings, organizations, schedules, and release windows.
• Read references/official-docs.md and inspect the current product dependency and parameter contracts.
• Establish the development source product and at least one non-production installation.

Current Contract

• Spaces provide environment separation for development, test, and production workflows.
• DevOps products package resources and their dependencies; downstream products should resolve inputs from the corresponding target environment.
• Marketplace installations can use release channels, locks, maintenance windows, and parameter inputs.
• Supported Developer Console application parameters can be remapped during installation, but Ontology API-name behavior and source-code parameters need explicit review.

Authentication

Give each environment an appropriately restricted OAuth application or mapped Developer Console application according to the supported product contract. Do not copy production client secrets into development or embed environment credentials in packaged source.

Instructions

1. Define each environment as a space with owners, security policy, external integration boundary, approval workflow, and recovery objective.

1. Package the workflow into bounded DevOps products with explicit inputs, outputs, dependencies, and parameter contracts.

1. Install upstream products before downstream dependents in test, resolving every input from the matching environment.

1. Verify parameter remapping, OAuth/restrictions, Ontology references, markings, schedules, and external endpoints.

1. Promote an immutable product version through the approved release channel and test downgrade or prior-version rollback.

Tool Discipline

• Use Glob to locate candidate repositories, manifests, configurations, and evidence without widening scope.
• Use Grep to find relevant identifiers, declarations, permissions, errors, and stale claims.
• Use Read to inspect the smallest required files and authoritative evidence.
• Use Write only for a new approved local draft, test, manifest, or evidence artifact.
• Use Edit only…

Palantir Foundry Observability Design

Overview

Use Foundry-native telemetry for Foundry workloads and export only when there is a governed consumer. Distinguish operational metrics, service/trace logs, execution history, monitoring notifications, and audit logs because they have different access and retention semantics.

Prerequisites

• Identify the resource, owner, service objectives, failure modes, audiences, data classification, and incident process.
• Inventory available build metrics, resource metrics, execution history, logs, monitoring views, audit exports, and external notification targets.
• Read references/official-docs.md and confirm current log-access and marking policy.
• Define the minimum telemetry needed to detect user-visible or data-quality failures.

Current Contract

• Transform build metrics expose CPU, memory, and job behavior in build reports.
• Ontology and AIP metrics, execution history, and logs have different permission requirements; logs may require Edit permission, enabled log access, and markings.
• Organization log exports support Palantir or OpenTelemetry payload formats and must respect source-executor and export-dataset marking requirements.
• Audit logs record high-level security and administrative activity and require tightly controlled export datasets.

Instructions

1. Define measurable service and data objectives, owners, thresholds, and response actions before creating dashboards.

1. Map each signal to the authoritative Foundry surface and identify its permission, marking, retention, and export requirements.

1. Create views or exports with minimum fields and protected destinations; avoid logging object values, prompts, or secrets.

1. Test each alert with a controlled failure and confirm routing, deduplication, acknowledgement, escalation, and recovery.

1. Review false positives, blind spots, access, retention, and evidence quality after a representative operating window.

Tool Discipline

• Use Glob to locate candidate repositories, manifests, configurations, and evidence without widening scope.
• Use Grep to find relevant identifiers, declarations, permissions, errors, and stale claims.
• Use Read to inspect the smallest required files and authoritative evidence.
• Use Write only for a new approved local draft, test, manifest, or evidence artifact.
• Use Edit only for a bounded approved change whose rollback is known.
• Do not use file tools as a substitute for authenticated Foundry operations or owner approval.

Approval Boundaries

Resource owners approve service objectives; security/data owners approve log access, markings, and…

Palantir Workload Performance Tuning

Overview

Identify whether delay comes from build scheduling, compute, data shape, transaction history, query breadth, network concurrency, or interactive replicas. Change one layer at a time and retain output parity and access controls.

Prerequisites

• Name the workload owner, service/data objective, representative window, exact build/query/module, and correctness tolerance.
• Capture queue time, duration, CPU, memory, input/output volume, retries, pagination, selected properties, and replica behavior.
• Read references/official-docs.md and confirm required engine features before changing compute.
• Prepare a sandbox branch or non-production application and a repeatable benchmark.

Current Contract

• Foundry build metrics show requested and observed CPU/memory and can distinguish scheduling from execution constraints.
• Single-node and Spark engines support different features; Polars is recommended for many production single-node transforms but is not universally interchangeable.
• Incremental histories can become progressively slow and may require a snapshot build.
• OSDK query performance depends on filters, selected properties, pagination, links, aggregations, and subscription shape.

Instructions

1. Define one user-visible or data objective and reproduce the miss on an exact workload version.

1. Locate the dominant bottleneck using Foundry metrics, build reports, query traces or timings, and module replica evidence.

1. Choose one bounded experiment: engine/resource request, partition/join shape, incremental snapshot, query filter/property selection, pagination, concurrency, or replica configuration.

1. Run the benchmark and compare correctness, access behavior, latency distribution, throughput, queue time, resource use, and failure rate.

1. Promote only a statistically and operationally meaningful improvement, then observe a representative production window.

Tool Discipline

• Use Glob to locate candidate repositories, manifests, configurations, and evidence without widening scope.
• Use Grep to find relevant identifiers, declarations, permissions, errors, and stale claims.
• Use Read to inspect the smallest required files and authoritative evidence.
• Use Write only for a new approved local draft, test, manifest, or evidence artifact.
• Use Edit only for a bounded approved change whose rollback is known.
• Do not use file tools as a substitute for authenticated Foundry operations or owner approval.

Approval Boundaries

Data and pipeline owners approve transform or snapshot changes; application owners approve query changes; p…

Palantir Production Readiness Gate

Overview

Prove the exact artifact, data contract, access model, observability, failure path, and rollback before promotion. A collection of green local tests is insufficient without Foundry checks and target-environment evidence.

Prerequisites

• Identify the accountable product, application, data, security, and operations owners.
• Freeze the candidate commit, generated OSDK/package, product version, or container digest.
• Read references/official-docs.md and collect non-production receipts for every required gate.
• Name the release window, maintenance constraints, rollback target, and recovery objective.

Current Contract

• Code Repository checks and unit tests validate supported repository and transform contracts.
• DevOps and Marketplace provide versioned product installation and release management across environment spaces.
• Compute Modules require compatible immutable container images and produce active-replica usage and operational telemetry.
• OAuth scopes, Developer Console restrictions, Foundry permissions, and mandatory controls all participate in effective access.

Authentication

Verify the production grant type, acting principal, requested scopes, Developer Console restrictions, secret storage, rotation, and revocation. Never copy a non-production secret into production or log a production token during validation.

Instructions

1. Freeze and inventory the candidate artifact, dependencies, datasets, Ontology entities, Actions, external systems, parameters, schedules, and owners.

1. Verify tests, Foundry checks, representative builds or application flows, data expectations, and positive/negative access.

1. Verify production parameters, secrets, restrictions, markings, log policy, metrics, alerts, runbooks, capacity, and limits.

1. Rehearse failed deployment, bad data, auth denial, throttling, dependency outage, and prior-version rollback in non-production.

1. Obtain independent approvals, promote the exact artifact, observe the defined window, and record post-release evidence.

Tool Discipline

• Use Glob to locate candidate repositories, manifests, configurations, and evidence without widening scope.
• Use Grep to find relevant identifiers, declarations, permissions, errors, and stale claims.
• Use Read to inspect the smallest required files and authoritative evidence.
• Use Write only for a new approved local draft, test, manifest, or evidence artifact.
• Use Edit only for a bounded approved change whose rollback is known.
• Do not use file tools as a substitute for authenticated Foundry operations or owner approval.

Palantir API Limit and Concurrency Control

Overview

Protect Foundry and the caller from retry storms. Budget requests across the acting user, bound concurrent work, honor server responses, and distinguish retryable throttling from authorization, validation, or permanent resource errors.

Prerequisites

• Identify the acting user or service user, applications sharing it, endpoints, workload peaks, page/batch shape, and service objective.
• Capture response status, request identifiers, timestamps, server timing guidance, retry count, and current concurrency.
• Read references/official-docs.md immediately before setting numeric budgets because effective and endpoint-specific limits may change.
• Prepare load tests in an approved non-production scope.

Current Contract

• The current general API documentation lists global per-user rate and concurrency limits across Foundry API endpoints.
• Individual endpoints may impose stricter limits and return 429 or 503.
• Palantir recommends exponential backoff for throttled requests.
• Limits can vary in practice, and disruptive throttling may require Palantir Support rather than client-side limit evasion.

Authentication

Attribute the request budget to the actual OAuth principal. Do not distribute calls across extra tokens, users, or service users to evade a limit. Keep token material out of metrics and retry logs.

Instructions

1. Inventory every worker and application using the same principal and estimate peak request rate plus in-flight concurrency.

1. Set a conservative shared concurrency budget and bounded queue with deadlines and cancellation.

1. Retry only documented transient statuses, honoring server guidance and using capped exponential backoff with jitter.

1. Use pagination, selective properties, batching supported by the endpoint, idempotency controls, and workload coalescing to reduce demand.

1. Load-test below the approved ceiling, simulate 429 and 503, and verify recovery without duplicate writes or unbounded backlog.

Tool Discipline

• Use Glob to locate candidate repositories, manifests, configurations, and evidence without widening scope.
• Use Grep to find relevant identifiers, declarations, permissions, errors, and stale claims.
• Use Read to inspect the smallest required files and authoritative evidence.
• Use Write only for a new approved local draft, test, manifest, or evidence artifact.
• Use Edit only for a bounded approved change whose rollback is known.
• Do not use file tools as a substitute for authenticated Foundry operations or owner approval.

Palantir Foundry Integration Architecture

Overview

Start from business decisions and data authority, then map each responsibility to a Foundry primitive. Keep ingestion, transformation, Ontology semantics, application access, deployment, and telemetry independently governable.

Prerequisites

• Identify users, decisions, source systems, data owners, update/writeback semantics, service objectives, compliance boundaries, and recovery needs.
• Inventory current and proposed Foundry projects, datasets, transforms, Ontology entities, applications, products, modules, and external integrations.
• Read references/official-docs.md and resolve target-enrollment feature availability with platform owners.
• Declare trust boundaries and authoritative systems before drawing components.

Current Contract

• Python transforms provide batch/incremental pipelines with multiple compute engines and data expectations.
• The Ontology represents domain objects, links, Actions, and Functions; OSDK applications receive a generated subset of it.
• Platform SDKs expose broader Foundry/AIP REST APIs, while OSDKs provide application-specific Ontology contracts.
• DevOps/Marketplace and Compute Modules cover different release-managed and interactive-container deployment needs.

Authentication

Define user-delegated and service authentication at each application boundary. Record OAuth grants, principals, scopes, Developer Console restrictions, secret storage, rotation, and revocation without placing credential values in the architecture artifact.

Instructions

1. Define capabilities, owners, authoritative data, side effects, latency/freshness objectives, and failure domains.

1. Place ingestion and transformations into projects with explicit inputs, outputs, lineage, expectations, and compute choices.

1. Model domain semantics and writeback in the Ontology, including object/property security and Action validation.

1. Choose generated OSDK or Platform SDK per application boundary and constrain OAuth scopes, restrictions, and principal permissions.

1. Choose DevOps product, Developer Console application, or Compute Module deployment, then add metrics, governed logs, audit evidence, and rollback.

Tool Discipline

• Use Glob to locate candidate repositories, manifests, configurations, and evidence without widening scope.
• Use Grep to find relevant identifiers, declarations, permissions, errors, and stale claims.
• Use Read to inspect the smallest required files and authoritative evidence.
• Use Write only for a new approved local draft, test, manifest, or evidence artifact.
• Use Edit only for a bounded approved…

Palantir SDK Boundary and Client Patterns

Overview

Keep application-specific Ontology access in the generated OSDK and broader platform operations in the Platform SDK. Wrap transport concerns without hiding the generated entity contract, OAuth authority, request identifiers, or Action validation.

Prerequisites

• Identify the application job, language, required Ontology entities or Platform API operations, write behavior, and owner.
• Select the target Developer Console application or current official Platform SDK package and pin its version.
• Read references/official-docs.md, generated application documentation, and relevant migration guide.
• Define request deadlines, page bounds, retryable statuses, idempotency, telemetry, and secret storage.

Current Contract

• OSDK packages are generated for selected Ontology resources and support application-specific typed access.
• Official Python and TypeScript Platform SDKs wrap Foundry/AIP REST APIs for broader platform operations.
• Authentication authority is the intersection of OAuth scope, Developer Console restrictions, and principal permissions.
• Generated OSDK versions can change call syntax; migration guides are part of the upgrade contract.

Authentication

Inject an approved token provider or OAuth client into the boundary; never accept a raw long-lived token as ordinary configuration. Log grant/principal identifiers and request IDs where permitted, but never bearer tokens, client secrets, object values, or protected payloads.

Instructions

1. Write a decision record choosing OSDK or Platform SDK and list the exact required resources or operations.

1. Expose one client boundary that owns token acquisition, deadlines, request correlation, retry classification, and telemetry.

1. Implement deterministic pagination and property selection; return continuation state rather than silently loading every page.

1. Keep generated object, Action, and Function definitions visible to callers and validate Actions before approved execution.

1. Add contract tests for auth denial, restrictions, page continuation, 429/503, non-retryable errors, validation failures, and SDK upgrades.

Tool Discipline

• Use Glob to locate candidate repositories, manifests, configurations, and evidence without widening scope.
• Use Grep to find relevant identifiers, declarations, permissions, errors, and stale claims.
• Use Read to inspect the smallest required files and authoritative evidence.
• Use Write only for a new approved local draft, test, manifest, or evidence artifact.
• Use Edit only for a bounded approved change whose rol…

Palantir Foundry Security Baseline

Overview

Apply least privilege across discretionary roles, mandatory controls, OAuth clients, Ontology policies, logs, and exports. Test both intended access and denial because each control plane covers a different boundary.

Prerequisites

• Identify owners, users/groups, service users, projects, organizations, markings/CBAC, datasets, Ontology resources, applications, logs, exports, and incident contacts.
• Classify the maximum data sensitivity and writeback impact for the workflow.
• Read references/official-docs.md and the target enrollment's policies.
• Begin with a read-only inventory and approved synthetic test personas.

Current Contract

• Projects and roles govern discretionary access; organizations, markings, and CBAC remain mandatory.
• Developer Console application restrictions and OAuth scopes constrain API clients alongside user/service-user permissions.
• Ontology object/property policies support granular read controls, but mandatory controls are needed where downstream propagation matters.
• Logs and audit exports may contain sensitive values and require explicit access, marking, audience, and retention decisions.

Authentication

Prefer the grant designed for the architecture, keep secrets in an approved manager, restrict resources and operations, request minimum scopes, and assign rotation/revocation owners. Never use personal tokens for unattended production workloads.

Instructions

1. Inventory every principal and control plane, then map each permission to a business purpose, resource, owner, and expiry.

1. Move routine access to groups and reduce project roles to the minimum capability.

1. Restrict Developer Console clients to required Ontology entities or Platform operations and verify the acting principal separately.

1. Apply object/property policies and mandatory controls according to read and propagation requirements.

1. Govern logs and exports, run positive/negative tests, scan artifacts for secrets, and schedule access recertification.

Tool Discipline

• Use Glob to locate candidate repositories, manifests, configurations, and evidence without widening scope.
• Use Grep to find relevant identifiers, declarations, permissions, errors, and stale claims.
• Use Read to inspect the smallest required files and authoritative evidence.
• Use Write only for a new approved local draft, test, manifest, or evidence artifact.
• Use Edit only for a bounded approved change whose rollback is known.
• Do not use file tools as a substitute for authenticated Foundry operations or owner approval.

Approval Boundarie…

Palantir SDK and Application Upgrade

Overview

Treat generated OSDK changes and official Platform SDK releases as contract migrations. Freeze the old and new artifacts, read the relevant migration guide or release notes, update one boundary, and prove compatibility in a non-production environment.

Prerequisites

• Identify the current and target package/product versions, generated Developer Console application, language/runtime, call sites, owners, and target environments.
• Capture lockfiles, generated metadata, OAuth restrictions, tests, representative queries/Actions, and prior product or image version.
• Read references/official-docs.md and the language-specific migration guide or official release history.
• Prepare a branch and non-production installation with a documented downgrade.

Current Contract

• Generated OSDK packages are tied to selected Ontology resources and compatible client versions.
• TypeScript OSDK migration guides document syntax changes for object access, Actions, batch Actions, and Functions/queries.
• Official Platform SDK repositories publish immutable releases and generated API changes.
• DevOps/Marketplace release management can promote and roll back versioned products across environments.

Authentication

Do not change grant type, scopes, resource restrictions, service-user permissions, or secrets as an incidental SDK upgrade. If an auth change is required, review and test it as a separate security migration.

Instructions

1. Freeze the old state and create a compatibility inventory of imports, generated entities, operations, scopes, runtime, and tests.

1. Review official migration/release evidence and classify source, generated-code, runtime, and behavior changes.

1. Update the pinned SDK/client or product on a branch without unrelated refactors.

1. Run unit/contract tests plus representative reads, pagination, Actions in validation-only mode, auth denials, throttling, and error mapping.

1. Install in non-production, compare behavior and telemetry, obtain approval, promote the exact version, and retain the tested downgrade.

Tool Discipline

• Use Glob to locate candidate repositories, manifests, configurations, and evidence without widening scope.
• Use Grep to find relevant identifiers, declarations, permissions, errors, and stale claims.
• Use Read to inspect the smallest required files and authoritative evidence.
• Use Write only for a new approved local draft, test, manifest, or evidence artifact.
• Use Edit only for a bounded approved change whose rollback is known.
• Do not use file tools as a substitute for authenticated Foundry ope…

Palantir Event and Subscription Integration

Overview

Start from the event producer and delivery guarantee: real-time Ontology object updates use OSDK or Object Set Watcher WebSocket subscriptions, while monitoring notifications and outbound integrations use their documented webhook surfaces. Never invent a general ontology.object.created registration API.

Prerequisites

• Identify the producer, consumer, object set or monitoring view, supported delivery surface, data sensitivity, latency objective, and recovery behavior.
• Confirm the generated OSDK version or direct WebSocket contract, or the configured Data Connection webhook required by monitoring.
• Read references/official-docs.md and verify target-enrollment feature access.
• Prepare a non-production object set or monitoring view and an idempotent consumer.

Current Contract

• TypeScript OSDK subscriptions require a compatible generated OSDK/client and receive object-set updates through .subscribe.
• Direct Object Set Watcher subscriptions use a documented WebSocket endpoint and authenticate with a bearer token encoded in the WebSocket subprotocol format.
• Subscriptions can report an out-of-date state that requires reloading the full object set.
• Monitoring views can route notifications through webhooks configured in Data Connection; that is distinct from Ontology object subscriptions.

Authentication

Use the generated OSDK token provider or the documented WebSocket bearer subprotocol. For outbound webhooks, use the authentication configured by the supported Data Connection webhook. Never invent or assume a signature header; record the actual configured authentication and secret owner.

Instructions

1. Classify the event need as Ontology object-set change, monitoring notification, or another documented Foundry integration.

1. Choose TypeScript OSDK subscription, direct WebSocket, or monitoring/Data Connection webhook and document why it matches.

1. Define bounded object filters or monitoring criteria, returned properties/message content, authentication, reconnect/backoff, and cancellation.

1. Implement idempotency and durable reconciliation; on onOutOfDate, disconnection, or delivery gap, reload authoritative state.

1. Test create/update/delete or alert cases, duplicate delivery, reconnect, stale state, denied access, secret rotation, and consumer recovery.

Tool Discipline

• Use Glob to locate candidate repositories, manifests, configurations, and evidence without widening scope.
• Use Grep to find relevant identifiers, declarations, permissions, errors, and stale claims.
• Use Read to inspect the smallest required files and…