用途：从业务决策和数据权威出发，设计跨数据管道、Ontology、OSDK 或 Platform API、部署、治理与运维的 Palantir Foundry 生产架构，使摄取、转换、Ontology 语义、应用访问、部署和遥测可独立治理。
主要能力：Python transforms 提供批量和增量管道，支持多种计算引擎与数据期望；Ontology 表示领域对象、链接、Actions 和 Functions，OSDK 应用获得其生成子集；Platform SDK 暴露更广的 Foundry/AIP REST API，OSDK 提供应用专属 Ontology 契约；DevOps/Marketplace 与 Compute Modules 覆盖发布管理与交互式容器部署。
使用方式：先识别用户、决策、源系统、数据所有者、更新/回写语义、服务目标、合规边界与恢复需求，盘点现有和拟建的 Foundry 项目、数据集、transforms、Ontology 实体、应用、产品、模块与外部集成，阅读 references/official-docs.md 并向平台所有者确认目标注册的功能可用性，在画组件前声明信任边界与权威系统。随后定义能力、所有者、权威数据、副作用、延迟/新鲜度目标与故障域；将摄取和转换放入项目并明确输入、输出、血缘、期望与计算选择；在 Ontology 中建模领域语义与回写，包括对象/属性安全和 Action 校验；按应用边界选择生成的 OSDK 或 Platform SDK，并约束 OAuth 范围、限制与主体权限；选择 DevOps 产品、Developer Console 应用或 Compute Module 部署，并补充指标、受治理日志、审计证据与回滚。
限制与边界：领域和数据所有者批准语义与回写，安全所有者批准边界与控制，平台所有者批准部署原语，运维所有者批准服务目标与恢复。不得用文件工具替代已认证的 Foundry 操作或所有者批准。若单一服务同时拥有摄取、策略、回写和发布，应先拆分职责与故障域；若架构依赖手写 Ontology API 名称，应锚定到生成的 OSDK/应用元数据；若假设细粒度安全会自动向下游传播，应增加强制控制或重新设计下游处理；若 schema 或 Ontology 变更没有回滚，应先分阶段兼容与双读/双写。官方文档与契约说明需在实时操作前重新核对，未解决或已变更的供应商行为应视为停止条件。