--- name: palantir-reference-architecture-d1d9bd65b431 description: >- Design a production Foundry architecture spanning data pipelines, Ontology, OSDK or Platform APIs, deployment, governance, and operations. Use when defining a new platform integration or reviewing an existing one. Trigger with "Palantir architecture". allowed-tools: Read,Glob,Grep,Write,Edit version: 2.0.0 argument-hint: "[system-or-workflow]" model: inherit effort: high author: Jeremy Longshore license: MIT compatibility: Requires current Palantir Foundry documentation and approved access for any live resource, permission, data, build, application, or deployment change tags: [saas, palantir, foundry, architecture, integration] --- # 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. 2. Place ingestion and transformations into projects with explicit inputs, outputs, lineage, expectations, and compute choices. 3. Model domain semantics and writeback in the Ontology, including object/property security and Action validation. 4. Choose generated OSDK or Platform SDK per application boundary and constrain OAuth scopes, restrictions, and principal permissions. 5. 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 change whose rollback is known. - Do not use file tools as a substitute for authenticated Foundry operations or owner approval. ## Approval Boundaries Domain and data owners approve semantics and writeback; security owners approve boundaries and controls; platform owners approve deployment primitives; operations owners approve service objectives and recovery. ## Output A decision record, context/component/data-flow diagrams, responsibility and authority matrix, data contracts, access model, API/SDK choice, deployment topology, failure analysis, observability design, and staged rollout. ## Error Handling | Condition | Response | |---|---| | One service owns ingestion, policy, writeback, and release | Separate responsibilities and failure domains before scaling the design. | | The architecture depends on handwritten Ontology API names | Anchor it to generated OSDK/application metadata. | | Granular security is assumed to propagate downstream | Add mandatory controls or redesign downstream handling. | | No rollback exists for schema or Ontology changes | Stage compatibility and dual-read/write behavior before promotion. | ## Examples ### Example 1 Design a supplier-risk workflow with connector ingestion, incremental transforms, governed datasets, supplier Ontology objects, validated Actions, a generated OSDK application, and release-managed environments. ### Example 2 Review a container integration by deciding whether it belongs in a Compute Module, mapping OAuth/resource restrictions, data flows, replica behavior, logs, and prior-image rollback. ## Validation - Every component has one responsibility, owner, authority, and failure behavior. - Data lineage and writeback semantics are explicit. - SDK and deployment choices match current Foundry contracts. - Positive/negative access and downstream control propagation are testable. - Service objectives, alerts, recovery, and version rollback are complete. ## Resources - [Official documentation and contract notes](references/official-docs.md) - Re-check the dated contract before any live operation. - Treat unresolved or changed vendor behavior as a stop condition. --- Source attribution: jeremylongshore Original project: https://github.com/jeremylongshore/claude-code-plugins-plus-skills/blob/ab85a061f7bcc039dac13ee193de7a4cd4388571/plugins/saas-packs/palantir-pack/skills/palantir-reference-architecture/SKILL.md License: MIT License information: https://opensource.org/license/mit Original upstream instructions; downloaded from Mega AI Hub. ## Upstream license notice MIT License Copyright (c) 2025 Jeremy Longshore Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. # Mega AI Hub resource metadata Creator / publisher: jeremylongshore Original project: https://github.com/jeremylongshore/claude-code-plugins-plus-skills/blob/ab85a061f7bcc039dac13ee193de7a4cd4388571/plugins/saas-packs/palantir-pack/skills/palantir-reference-architecture/SKILL.md Attribution basis: Source repository record Fields of work: Development & Engineering, Operations, Product Management Roles: Backend Developer, Business Process Analyst, Data Engineer, Growth Product Manager, Product Manager Specialties: API, Backend, Design, Word Documents, Frontend, Stripe, Testing Tools: Palantir Country applicability: Country not specified Classification basis: Source catalog labels Instruction SHA-256: bff5d892d47e3183ecab110a69976111f7da70d644eab1b7450b8b068b33e9e8