Deep Dive: Creating Your First Ontology Feb 24 2026 Part II

Ontology Manager Context: Extending Fresh Air's Ontology Now that you’ve seen the structure and some of the value of the Fresh Air Ontology, let’s extend it. As mentioned earlier, whenever a Flight is delayed, cancelled, or diverted, it would be useful to have an object to represent this situation. Each Flight Alert can then be responded to by Fresh Air’s Flight Operations department. This is an example of an operational workflow in Foundry.

Ontology Manager (sometimes called the Ontology Management Application or OMA) enables you to build and maintain your organization’s Ontology. While you can also define object and link types from Pipeline Builder (as you did in the End-to-End Speedrun course), Ontology Manager offers many more capabilities and options. Because you can currently (at the time of this writing) only edit ontology type definitions from the application you used to originally create it, it is generally recommended that you use Ontology Manager as your default ontology tool, unless you know that Pipeline Builder's lighter feature set will be sufficient for your needs.

Create an object type

Mapping a datasource to an object type When you define a new object type, you are defining a kind of blueprint or template. This object type is backed by one or more datasources. This datasource is typically a dataset, but it could also be restricted view, virtual table, etc. Each row of data in the backing datasource will produce one object that is a specific instance of that object type. Each column typically maps to a property. The permissions a user has to the backing datasource(s) also determines whether they can see the corresponding object data. 这一概念描述了从数据层Data Layer向对象层Object Layer跨越的关键时刻。在 Foundry 中，这个过程被称为本体映射（Ontology Mapping）。 对于 IGT 审计系统来说，将数据集映射为对象类型，就像是将一份静态的“ Excel 报表”变成了可以在 Workshop 应用中点击、修改和流转的“任务卡片”。

1. 核心映射逻辑：从“表格”到“蓝图” 你可以将映射过程想象成一个翻译器： • 数据源（Datasource） 蓝图的源头：通常是一个经过 Pipeline Builder 清洗后的数据集。例如：clean_igt_discrepancies。 • 一行数据（Row） 一个实例（Object Instance）：数据集中每一行唯一的交易差异，都会变成一个独立的“差异项对象”。 • 一列数据（Column） 一个属性（Property）：数据集中的 amount 列映射为对象的 Amount 属性；partner_id 列映射为 Trading Partner 属性。

2. IGT 实战中的映射重点 在配置映射时，有三个关键点决定了审计系统的成败： 映射元素 IGT 中的配置建议 为什么重要？ 主键 (Primary Key) 使用唯一的 Transaction_ID 或组合键。 确保每个差异项是唯一的，避免在审计报告中出现重复项。 标题 (Title) 将 Case_ID 或 Partner_Name 设为对象标题。 在搜索和弹窗中，审计员能一眼认出这是哪个差异。 安全性 (Permissions) 继承底层数据集的权限。 如果某审计员无权查看“海军”的原始数据集，他也无法在对象层看到“海军”的差异项。

3. 灵活的后端支持 (Backing Datasources) 如你所述，后端不一定非要是 Dataset。在 IGT 复杂场景下，你可能会用到： • 受限视图 (Restricted View)：如果你处理的是带密级的财务数据，映射受限视图可以实现“行级安全控制”——例如，A 组只能看到 A 部门的差异。 • 虚拟表 (Virtual Table)：对于实时性要求极高的对账，可以使用虚拟表减少存储开销。

4. 关键洞察：从“数据可见”到“业务行动” 仅仅完成映射是不够的。一旦数据变成了对象，你就解锁了以下能力：

5. 链接 (Linking)：将“差异项对象”链接到“会计准则对象”。

6. 操作 (Actions)：定义一个“关闭差异”的 Action，当审计员点击按钮时，系统会更新底层数据。

7. AIP 推理：AI 可以直接读取对象的多个属性，给出我们之前讨论过的“信心分”。

you can explore this row-to-object mapping in Ontology Manager. If you look at the bottom of your screen, you’ll find a preview of the backing datasource. At the top of that panel, click Preview objects to preview the objects that correspond to each row. By using actions, it is possible for users to create additional objects that do not exist in the backing datasource. Users can also delete objects. Therefore, over time, the mapping from rows to objects may not always exist for all rows. Columns verses Properties By default, when you create a new object type, each column of the backing datasource is mapped to a property in the new object type. However, you can change this mapping. For example, you can rename a property or choose not to map some columns to properties. It is also possible to add properties that are not backed by a column. If you create a new property, you can set its Source to User edits. These values can only be created or changed later through actions on a per-object basis. If you look through the preview of the flights_alerts dataset, you’ll find that the root_cause column is empty (contains only null values). When initially building this pipeline, there was no satisfactory way to determine the root_cause for each alert from the other data available. Instead, we plan to collect this information from Flight Operations users as they investigate and close each alert. In this case, the Root Cause would have been a good candidate for an edit-only property without a backing column. However, creating an empty column as part of the data pipeline also works. This will make it easier to insert a data-derived root cause value later if we should ever integrate another data source that would let us update the data pipeline to determine at least some instances of this automatically. The takeaway here is that, while datasource columns inform which object properties you have, they do not always map 1-to-1 because object data is separate from datasource data. (We’ll explore this in a little more detail in Object Storage below.) Primary Keys and Titles Every object must have a unique identifier that is consistent for the life of that object. This is its Primary key property. When selecting a primary key, you must choose a column that will contain a unique value for each row and that is never null. Strings are typically the best data type to use for this. If your backing datasource doesn’t contain a column that will serve as a valid identifier, you might derive a new column that concatenates multiple columns (and optionally hashes the result) to generate a valid key. This must be a deterministic repeatable process. You should never generate a random ID or GUID for this purpose as part of a data pipeline, because, if the pipeline is ever rerun, all of your object IDs will change. Every object should also have a Title. This property is used as the user-friendly and human-readable name of the object in search results and in most Foundry applications. While the primary key can also be used for this purpose, unique keys are often fairly unreadable or opaque to everyday users. Again, you might derive a useful title from other columns as part of your backing data pipeline. Actions Actions provide a controlled way to create, edit, and/or delete objects. Ontology Manager offers to create a generic version of these when you create a new object type. In this example Fresh Air use case, we plan to only create new Flight Alerts through the data pipeline, so we don’t need a Create action for users to do so manually. While we will resolve alerts, we won’t delete them, so we also don’t need a Delete action. We will allow users to edit an alert, but only by touching certain fields. So we will create a more targeted action for that purpose in a later step. 这段文字揭示了 Foundry 对象存储 (Object Storage) 的精髓：它不是一个简单的“数据投影”，而是一个动态的业务引擎。 对于 IGT 审计系统，理解“属性（Properties）不等于列（Columns）”以及“主键（Primary Keys）”的稳定性，是构建可靠对账流程的关键。

1. 静态数据 vs. 动态编辑：IGT 的“根因分析” 你提到的 root_cause 案例在 IGT 审计中极其常见。 • 数据层逻辑 (Pipeline)：你可以通过逻辑识别出“金额不匹配”。 • 对象层编辑 (User Edits)：但“为什么不匹配”（如：录入错误、汇率差异、合规性例外）往往需要审计员人工判断。 配置策略建议： 在 IGT 差异对象中，建议将 Audit_Status（审计状态）和 Reviewer_Comments（审计员备注）设为 User edits（仅用户编辑） 属性。这样，即使底层对账流水重新跑了一遍，审计员之前辛苦填写的备注也不会被覆盖。

2. 主键 (Primary Key) 与 标题 (Title) 的 IGT 实践 在处理成千上万笔对账单时，这两个字段的设置直接影响用户体验： • 主键 (PK) - 系统的灵魂： o 禁忌：永远不要在 Pipeline 中使用 random() 或 row_number() 作为主键。如果 Pipeline 重跑，原本关联在“差异 A”上的审计备注可能会跑向“差异 B”。 o 推荐：使用 hash(买方ID + 卖方ID + 交易日期 + 原始金额) 生成一个确定性 (Deterministic) 的字符串。 • 标题 (Title) - 人的界面： o 推荐：使用 [Case ID] - [Partner Name]。例如：IGT-8829 - Air Force。这比一串哈希值主键要易读得多。

---

1. 受控的操作 (Targeted Actions) 正如你所指出的，在审计场景下，我们通常不希望用户随意“创建”或“删除”差异项，因为这些应该是基于底层财务数据自动生成的。 IGT 专用 Action 设计： • 禁止通用 Action：不要提供全局的“编辑对象”功能。 • 创建“核销 Action”：创建一个名为 Approve and Close 的 Action。它只允许审计员修改两个字段：Closure_Reason 和 Approval_Status。 • 侧边影响 (Side Effects)：在 Action 中配置：一旦点击核销，自动给对方贸易伙伴发出一封我们之前讨论过的“自动通知邮件”。

---

1. 数据与对象分离的深度洞察 概念 含义 在 IGT 中的体现 Row-to-Object 不是 1:1 永久映射 一笔差异在数据层存在，但如果被审计员“删除”（逻辑删除），它在对象层消失。 Backing Column 数据的来源 Amount（金额）来自 ERP，不可在对象层修改。 User Edits 业务的补充 Root Cause（根因）由审计员填写，不存于原始 ERP。

---

1. 专家小结：为什么这种架构对 FIAR 审计至关重要？ 这种架构实现了**“财务真实性”与“审计活动”的解耦**。底层数据层保护了交易的原始状态（不可篡改），而对象层提供了灵活的审计操作空间（可记录、可追踪）。这完美符合了 FIAR 要求的“完整审计踪迹（Full Audit Trail）”。 Concepts Object Storage: Once you save, you’ll see a little progress spinner appear in the upper left of the screen:

This indicates that Foundry is currently building an index of all of your object data for this object type in Object Storage v2. If you click this spinner, you can view the progress. This will take you the Datasources tab: Ontology architecture The Foundry Ontology is an operational layer for the organization. The Ontology sits on top of the digital assets integrated into Foundry (datasets and models) and connects them to their real-world counterparts, ranging from physical assets like factories, equipment, and products to concepts like customer orders or financial transactions. The Ontology serves as a digital twin of an organization, containing both the semantic elements (objects, properties, links) and kinetic elements (actions, functions, dynamic security) needed to enable use cases of all types. You can learn more about the Foundry Ontology and how it enables better decision-making in the Ontology documentation. The Foundry Ontology is backed by multiple services that work together to index, store, query, and manipulate objects in the Ontology. This page provides a high-level overview of the Ontology’s backend architecture. Functional components and architecture The Foundry platform uses a microservices architecture in which multiple services together comprise the Ontology backend. The Ontology backend is responsible for three main functions: • Datasource management to feed the Ontology and manage schema definitions within the Ontology. • Querying, searching, and aggregating objects from the Ontology with support for specific filtering and permissioning. • Orchestration of writing to the Ontology, including indexing of datasources and edits to Ontology objects based on decisions made or actions taken in Foundry. These functions are handled collectively by the services that make up the Ontology backend, which are summarized below: • Ontology Metadata Service (OMS) • Object databases • Object Set Service (OSS) • Actions • Object Data Funnel • Functions on Objects Ontology Metadata Service (OMS) The Ontology Metadata Service (OMS) is an overarching service that defines the set of ontological entities that exist. This definition includes the metadata of object types, the link types that describe any relationships between object types, the action types that can modify object data in a structured and controlled way, and more. Learn more about core concepts in the Foundry Ontology in the Ontology metadata documentation. Object databases Object databases are the services responsible for storing the indexed object data in the Ontology and are designed to provide fast data querying and query computation for user applications. In addition to storing indexed data, object databases are also responsible for indexing, querying, and orchestrating user edits. Object Storage V1 (Phonograph) is Foundry's legacy Ontology backend component. Object Storage V2 is the next-generation canonical data store for backing the Ontology. More information on these services can be found below. Object Set Service (OSS) The Object Set Service (OSS) is the service responsible for serving reads from the Ontology; OSS allows other Foundry services and applications to query objects data from the Ontology, enabling searching, filtering, aggregating, and loading of objects. Object sets Object sets are lists of real-world entities that are saved for future reference and use across Foundry applications that support objects. Object sets are saved as resources for easy sharing with collaborators. Object sets can be described by definition (static or dynamic) and current state in the object backend (temporary or permanent): • Static object sets: Static object sets are saved as a list of primary keys, and will stay the same regardless of any changes to the input data. • Dynamic object sets: Dynamic object sets are saved as a representation of the filters applied to create the object set. When new data matches the filters, the object set will be updated. • Temporary object sets: Temporary object sets are mainly used in the platform to hand object sets from one application or service to another and can only be accessed by the user who created them. A sample temporary object set RID will appear like ri.object-set.main.temporary-object-set.37d7e171-2d11-4fcd-b031-9a0863f6f744 and expires within 24 hours. • Permanent object sets: Permanent object sets are stored in the object backend for future reference and use across the platform. Actions The Actions service is responsible for applying user edits to object databases. Actions provide a structured way to modify property values of an object and enable complex permissions and conditions for user edits. Additionally, Actions can be used to create a historical action log for analysis of user decisions. Object Data Funnel The Object Data Funnel ("Funnel") is a microservice in the Object Storage V2 architecture responsible for orchestrating data writes into the Ontology. Funnel reads data from Foundry datasources (such as datasets, restricted views, and streaming datasources) and user edits (from Actions) and indexes these data into object databases. Funnel also ensures that indexed data is kept up-to-date as the underlying datasources update. Functions on Objects Functions enable code authors to write logic that can be executed quickly in operational contexts, such as dashboards and applications designed to power decision-making processes. See the Functions documentation for more details. Evolution of the Ontology backend This section describes the legacy architecture of Object Storage V1 (Phonograph) and the updated architecture of Object Storage V2. Object Storage V1 (Phonograph) architecture Object Storage V1 (Phonograph) is Foundry's original object database, designed to index and manage information from a wide range of potential data models while maintaining Foundry's security model across object data in the Ontology. Beyond indexing and storing data, Object Storage V1 (Phonograph) tracks the application of user-generated edits, serves complex user queries with searches and aggregations, and orchestrates data writeback. Below is a diagram describing the architecture for Object Storage V1 (Phonograph).

Object Storage V2 architecture As Foundry gained more capabilities and evolved to meet the complex operational needs and growing scale of Palantir's customers, Object Storage V2 was built from first principles to enable the next generation of Ontology-driven use cases and workflows. Specifically, the new architecture separates dimensions of concern that had been consolidated in Object Storage V1 (Phonograph) and decouples responsibilities within the system design; by separating the subsystems responsible for indexing and querying data, Object Storage V2 can scale horizontally more easily to meet future needs. Object Storage V2 also incorporates additional services like Actions via the Object Data Funnel. New features and capabilities enabled by Object Storage V2 include: • Significantly improved performance for Ontology data indexing through incremental object indexing (enabled by default) for all object types. • Increased indexing throughput on the order of tens of billions of objects for a single object type. • More granular object permissions with multi-datasource object types, including column/property level permissions. • Increased user edit throughput, enabling up to 10,000 objects to be edited in a single Action. If you need to enable a higher limit, contact Palantir Support to create a change request for your enrollment. • Reduced user edit latency and faster observation of user edits. • The ability to migrate existing user edits after a breaking schema change in an object type. • Low-latency data indexing into the Ontology through support of streaming datasources. • Supports a maximum of 2000 properties per object type. • Higher-scale Search Arounds and more accurate aggregations through a Spark-based query execution layer. o By default, the Search Around limit is 100,000 objects. If your use cases require a higher scale Search Around of over 100,000 objects, contact Palantir Support for instructions on how to enable this. Below is an architecture diagram describing how Object Storage V2 powers the Ontology.

这一架构深入揭示了 Foundry 能够承载大规模、高并发审计任务的底层逻辑。对于 IGT（内部交易对账）系统，Object Storage V2 (OSV2) 的引入标志着从“数据展示”向“实时决策引擎”的转变。 我们可以通过将这些微服务组件对应到你的审计流程中，来理解其运作机制：

1. 核心组件在 IGT 中的角色映射 组件 技术职责 在 IGT 业务中的体现 OMS (Metadata) 定义实体与规则 蓝图设计：定义什么是“差异项”、什么是“贸易伙伴”，以及它们之间的链接（Link）规则。 Object Data Funnel 数据泵与索引器 数据同步：将 ERP 原始数据集中的数千万行流水实时“泵”入对象数据库，并确保数据源更新时，对象状态同步刷新。 OSS (Object Set Service) 读取与查询服务 动态搜索：当审计员在 Workshop 中输入“Air Force”过滤差异时，OSS 负责亚秒级返回结果。 Actions & Funnel 写入与编辑协调 核销闭环：审计员点击“确认对平”时，Action 捕获编辑，Funnel 将该修改写回对象存储，并触发后续通知逻辑。

2. Object Storage V2 (OSV2) 的革命性进步 既然你的系统是在 2026 年运行，OSV2 是绝对的主力。它相比 V1 (Phonograph) 解决了 IGT 场景下的几个痛点： A. 海量规模支持 (Scale) • 现状：跨军种对账可能涉及数十亿行数据。 • OSV2 能力：支持单对象类型达 数百亿个 对象。这意味着你不需要为了性能而对历史数据进行物理分表，所有历史对账单都可以放在同一个对象类型中进行全局分析。 B. 高频用户编辑 (Edit Throughput) • 现状：在“月末关账”期间，数百名审计员可能同时在系统内点击“核销”。 • OSV2 能力：支持单次 Action 编辑多达 10,000 个对象。这允许审计员进行大规模的批量调整（Bulk Actions），而不会造成系统延迟或锁定。 C. 模式变更后的数据迁移 (Schema Migration) • 场景：审计政策变更，需要给“差异项”增加一个全新的“合规等级”属性。 • 痛点：在旧架构下，修改 Schema 可能导致之前的用户备注丢失。 • OSV2 能力：支持在破坏性 Schema 变更后迁移现有的用户编辑。这保证了审计结论的长久生命力。

3. 理解“对象集 (Object Sets)”的动态性 在 Workshop 开发中，你会频繁处理 Object Sets。理解它们的区别对审计报告的准确性至关重要： • 动态对象集 (Dynamic)：定义为“所有状态为‘未解决’且金额 > $1M 的差异”。当底层数据更新，新的符合条件的差异会自动出现在审计员的列表里。 • 静态对象集 (Static)：定义为“2025 年 12 月 31 日锁定的所有差异”。无论数据后来如何变化，这个列表永远固定。这通常用于审计定稿（Final Snapshots）。

4. 架构总结：为什么是“数字孪生”？ Foundry 的微服务架构（OMS + OSS + Funnel）共同确保了本体不只是一个数据库副本，而是一个活动的有机体：

5. Semantic (语义)：数据是什么？（由 OMS 定义）。

6. Kinetic (动力)：数据如何变化？（由 Actions 和 Functions 驱动）。 对于 IGT 审计来说，这意味着你可以从“寻找差异”转向“管理差异”。 这正是将静态数据转变为主动洞察的关键步骤。在 Foundry 中，通过 Functions on Objects，你可以编写能够实时理解对象及其关联关系的 TypeScript 代码。 对于 IGT 审计，计算“平均对账耗时”不仅是一个数值，它更是一个供应商绩效指标。

7. 核心逻辑：跨对象计算 要计算这个指标，Function 需要执行以下逻辑：

8. 定位目标：找到特定的“贸易伙伴 (Trading Partner)”对象。

9. 搜寻关联：通过链接（Link）找到该伙伴下所有已关闭的“差异项 (Discrepancy)”对象。

10. 时间过滤：筛选出最近 30 天内关闭的记录。

11. 算术处理：计算（关闭时间 - 创建时间）的平均值。

12. TypeScript 代码示例 你可以使用 Functions 存储库来定义这种逻辑。以下是实现该财务逻辑的简代码： TypeScript import { Function, Double } from "@foundry/functions-api"; import { TradingPartner } from "@foundry/ontology-api";

export class IGTAnalytics { @Function() public async calculateAvgResolutionTime(partner: TradingPartner): Promise<Double> { // 1. 获取关联的所有已核销差异项 const resolvedDiscrepancies = await partner.discrepancies .filter(d => d.status.exactMatch("Resolved")) .all();

    // 2. 设定 30 天的时间阈值
    const thirtyDaysAgo = new Date();
    thirtyDaysAgo.setDate(thirtyDaysAgo.getDate() - 30);

    // 3. 筛选最近 30 天的记录并计算耗时
    const recentDiscrepancies = resolvedDiscrepancies.filter(d => 
        d.resolvedDate && d.resolvedDate >= thirtyDaysAgo
    );

    if (recentDiscrepancies.length === 0) return 0.0;

    const totalDuration = recentDiscrepancies.reduce((sum, d) => {
        const duration = d.resolvedDate!.getTime() - d.createdDate!.getTime();
        return sum + duration;
    }, 0);

    // 4. 返回平均天数 (毫秒转天)
    return (totalDuration / recentDiscrepancies.length) / (1000 * 60 * 60 * 24);
}

}

1. 如何在界面中实时展示？ 编写完 Function 后，你可以在 Workshop 中通过以下两种方式将其展示给审计员： • 派生属性 (Derived Property)：在贸易伙伴的详情页，添加一个“计算值”组件，直接调用此函数。每当审计员查看该伙伴时，分值都会实时更新。 • 条件高亮：如果平均耗时超过 15 天，在界面上将该数值显示为红色，提醒审计组长该伙伴的配合度正在下降。

2. 为什么这种方式优于传统报表？ 维度 传统 SQL 报表 Functions on Objects 实时性 通常是 T+1 更新。 亚秒级。数据一更新，指标立即重算。 业务语义 面对的是复杂的 Join 表。 面对的是“伙伴”和“差异”等真实业务对象。 可交互性 只能看，不能动。 可以作为 Action 的前置条件（例如：如果耗时过长，自动触发警告）。

3. 进阶：自动将结果“写回”属性 虽然 Function 通常是只读计算，但你可以配置一个 Scheduled Action（计划任务）： • 每天凌晨运行一次 Function。 • 将计算出的“平均耗时”结果写回到对象的 avg_resolution_speed 静态属性中。 • 好处：这样你就可以在表格中直接对这个数值进行排序和全局筛选，而无需每次动态计算。

Create a link type It would be useful to be able to quickly navigate from each Flight Alert to its corresponding Flight object. There is a lot of ancillary information available on the Flight object that we don’t need to repeat on the Flight Alert object, but that might be useful to users who are responding to an alert. Concepts Foreign key Similar to the concept used in relational databases, a foreign key property in one object type contains values that appear as a primary key value in another object type. Cardinality This is another data modeling concept that is not specific to Foundry. The cardinality of a relationship indicates how many entities might be involved on the two sides of that relationship. This will depend on your underlying data and how you are modeling the world. For example, if you are modelling the relationship between an Airline and its Aircraft as “present-day ownership”, it would be one-to-many: Each Airline might own many Aircraft, but each Aircraft is owned by only one Airline at a time. On the other hand, if you are modeling ownership over time (where planes are sold from one airline to another) or operations (where partner airlines might use codeshares or an airline might lease aircraft to its subsidiary airlines), then the relationship would be many-to-many: An Airline has many Aircraft, while an Aircraft is operated by many Airlines. (The Airline-Aircraft link in the Fresh Air Ontology is many-to-many if you would like to see an example.) With regards to the Flight Alert you just created, for this notional data pipeline, we generated only one Flight Alert per significantly delayed, cancelled, or diverted Flight. This would make this a practically one-to-one relationship. However, that is not a constraint we would want to impose here. Conceptually (and perhaps in a future version of this pipeline), we would expect this to be a one-to-many relationship: While each Flight Alert should only be related to one Flight, a Flight might generate multiple Alerts. For example a flight could depart late and then, several hours later, be redirected to a different airport. This would ideally produce two separate alerts. 在 IGT（内部交易对账）审计系统中，链接（Links） 是将零散的财务数据编织成业务网络的纽带。理解外键和基数（Cardinality）不仅是数据建模的要求，更是决定审计员如何“钻取”数据、查找根因的关键。 我们可以将这些概念映射到你正在构建的 IGT 场景中：

1. 外键（Foreign Key）：跨越账本的桥梁 在 Foundry 中，外键不再仅仅是一个列名，它是跳转的入口。 • 场景：在“差异项（Discrepancy）”对象中，通常会有一个字段叫 Partner_Code。 • 逻辑：这个字段就是指向“贸易伙伴（Trading Partner）”对象的主键的外键。 • 审计价值：当审计员查看一笔具体差异时，系统可以通过外键自动拉取该贸易伙伴的联系信息、信用评级或历史表现，无需重新搜索。

2. 基数（Cardinality）：定义业务逻辑的深度 基数决定了审计工作流的复杂度。在 IGT 中，我们通常会遇到以下三种情况： 一对一 (1:1) • 案例：差异项 自动对账建议。 • 逻辑：如果你的系统设计为针对每笔差异只生成一个 AIP 建议，这就是 1:1。 • UI 表现：在界面上，它们看起来像是一个对象的扩展。 一对多 (1:M) • 案例：贸易伙伴 差异项。 • 逻辑：一个贸易伙伴（如空军）可能产生多笔差异。 • UI 表现：当你点击“空军”时，会展示一个包含所有相关差异的列表。 多对多 (M:M) • 案例：合同 (Contracts) 差异项。 • 逻辑：这在 IGT 中非常棘手。一个复杂的采购合同（如 7600A）可能涉及多笔差异；而一笔差异（如由于大额资金打包错误）可能跨越多个合同编号。 • UI 表现：这种关系需要专门的图谱视图 (Object Graph) 来理清交织的关系。

3. 从 IGT 审计视角看“演进中的基数” 正如你提到的 Flight Alert 例子，建模时必须考虑未来的扩展性： 目前的 IGT 逻辑：每笔异常交易对应一个审计工单（1:1）。 未来的 IGT 逻辑 (1:M)：一笔大额异常交易可能需要拆分为多个审计子任务。例如：$10M 的差额，其中 $8M 是时间差，$2M 是汇率错误。这时，一个“差异对象”将链接到多个“处理建议对象”。

4. 总结：基数如何影响你的 Workshop 开发？ 基数类型 开发注意事项 审计员体验 1:1 使用 "Simple Link" 组件。 像查看一个属性一样简单。 1:M 使用 "Object Table" 或 "Object List" 过滤。 向下钻取：从总体概览到具体细节。 M:M 需要处理“中间链接对象”。 横向关联：发现不同合同之间的系统性错误。

---

1. 关于“自动写回”的权限与基数 当你配置“自动写回”功能时，基数至关重要。 • 如果是 1:1，写回非常简单，直接更新属性即可。 • 如果是 1:M（如更新该伙伴下所有差异的状态），你需要使用 Functions on Objects 来遍历链接，确保所有相关项都得到了同步。 配置“Link-based Security（基于链接的安全）”？ 例如：确保陆军的审计员只能看到链接到“陆军”这个贸易伙伴的差异项，即使所有的差异都存在同一个大数据集中。 在 Palantir Foundry 中，配置**基于链接的安全（Link-based Security）**是实现“多租户”审计环境的核心技术。它能确保即使所有数据都存在一个巨大的数据集中，用户也只能看到与其所属机构（如：陆军）相关联的对象。 这种机制主要通过 Restricted Views（受控视图） 和 Policy（策略） 来实现。以下是配置“陆军审计员只能看陆军差异”的具体步骤： 第一步：准备“组织机构”或“角色”对象 首先，本体中必须有一个能代表“用户所属权限”的对象，或者在“差异项”对象上有一个关键属性。 • 方案 A：在 Discrepancy（差异项）对象上有一个 Department 属性（值为 "Army"）。 • 方案 B：有一个 Auditor（审计员）对象，通过链接关联到 Organization（组织）对象。 第二步：创建 Restricted View (受控视图) 受控视图是数据层与安全策略的交集。
2. 在 Data Lineage 中，找到备份 Discrepancy 对象的数据集。
3. 右键选择 Create Restricted View。
4. 定义策略 (Policy)： o 选择 "Based on user property"（基于用户属性）。 o 逻辑设置为：Dataset.Department_Field == User.Organization_Attribute。 o 这意味着系统会自动检查当前登录用户的个人资料（Profile）中的“所属组织”字段，并将其与数据行中的“部门”字段进行匹配。 第三步：在 Ontology Manager 中应用受控视图
5. 打开 Ontology Manager，选中 Discrepancy 对象类型。
6. 在 Datasources（数据源）选项卡中，将原有的 Dataset 替换为你刚刚创建的 Restricted View。
7. 保存并发布本体。 第四步：基于链接的扩展 (Link-based Expansion) 如果你希望安全规则更复杂（例如：如果审计员能看到“合同”，那么他就能自动看到所有链接到该“合同”的“差异项”），你需要配置 Required Links。 • 在受控视图的策略设置中，选择 "Grant access via link"。 • 设置逻辑：如果用户拥有 Contract（合同）对象的访问权限，则自动授予其查看所有关联的 Discrepancy 对象的权限。 这种配置在 IGT 审计中的优势： 特性 传统过滤 (Filtered View) 基于链接的安全 (Link-based) 安全性 容易通过技术手段绕过。 强制执行。数据在被索引到对象层之前就已经被过滤。 维护性 需要为每个军种手动创建不同的看板。 一个看板，千人千面。所有人进同一个应用，看到的都是自己的数据。 粒度 只能按列过滤。 可以根据业务关系（链接）动态决定谁能看什么。

专家建议：如何验证配置？ 在 Foundry 中，你可以使用 "Impersonation"（模拟） 功能或在 Restricted View 界面中使用 "Test Policy" 工具。输入一个属于“陆军”的审计员账号，系统会即时展示他能看到的行数。如果配置正确，他应该看不到任何属于“海军”或“空军”的差异项。

Create an action type There’s a lot of different decisions the Flight Operations team might take in response to a Flight Alert. For example, they might need to reassign gate crews, contact the maintenance team, arrange for a plane swap, etc. A full cross-team workflow like this often needs to be implemented incrementally in Foundry. We’ll assume we’re just getting started with only the Flight Operations team for now. Their immediate need is to understand more concretely what is causing their delays. While root-causing a delay is still largely a manual process for them, capturing the conclusion in Foundry is a good first step. Let’s add an action to do that. Concepts Actions provide a controlled way to update objects. Because we’ve only defined one action that touches only the Root Cause property, this is the only property that users can edit. Action Form Every time you invoke this action from different contexts in Foundry, a common input form will collect the necessary input from a user. If you switch to the Parameters tab of your action type, you can see a preview of this form. There is a lot of further customization you could do here. For example, you can rename input fields, assign default values, hide fields, and more. For example, for now we are going to accept any free text as the new Root Cause value. If you wanted to, you could constrain this to a list of multiple choices that you either enter manually or derive from a dataset. (You can see the original [OFT] Assign root cause action type's Root Cause parameter for an example of this.) This customization is another example of how actions can control changes to data: You might limit choices to only certain allowed input values. Submission Criteria Another control is to specify who can invoke the action at all. You set this during action type creation. You can update it on the Security & Submission Criteria tab. Rules, Side-effects, & Functions When you execute an action, it runs one or more rules, which you can see on the Rules tab. For now, we are applying a very simple Modify object rule that sets one property value. However, you could add other rules that send a Foundry notification to another Foundry user, invoke a webhook to call out to an external system, or create and delete other objects. Instead of these rules, you can instead back your action with a function. Such code-based functions are also used elsewhere in Foundry beyond just backing actions. 在 IGT 审计系统中，Action（操作） 是连接“分析”与“结果”的枢纽。它不仅是将审计员的判断写回系统的方式，更是确保每一笔财务调整都符合合规性要求的“防火墙”。 以下是基于你提供的概念，对 IGT 审计 Action 配置的深度解析：

1. 受控的属性更新：以“差异核销”为例 在审计场景中，数据完整性（Data Integrity）是第一位的。 • 业务逻辑：审计员绝对不能修改从 ERP 同步过来的“原始金额”或“交易日期”。 • Action 配置：通过定义一个特定的 Action（如 Resolve Discrepancy），你可以锁定所有财务原始字段，仅允许审计员编辑 Audit Status、Root Cause 和 Adjustment Reference。 • 效果：这确保了对象层既有灵活性，又不会破坏底层数据集的证据效力。

2. Action Form：标准化审计语言 正如你所提到的，Root Cause 的输入可以被高度定制。 • 从自由文本到下拉菜单：在 IGT 系统中，不建议使用自由文本输入根因。你应该在 Parameters 标签页中将其设置为“静态列表（Static List）”，选项包括：Timing Difference（时间差）、Currency Fluctuation（汇率波动）、Missing Documentation（凭证缺失）。 • 审计价值：标准化输入使得你后续能够生成聚合报表（例如：“本月 60% 的差异是由‘凭证缺失’导致的”），这在自由文本模式下是无法实现的。

3. Submission Criteria：设置“审核级”权限 不是所有人都有权关闭一笔巨额差异。 • 配置策略：在 Security & Submission Criteria 中，你可以设置复杂的逻辑。例如： o 如果差异金额 $< $10,000$，任何审计员（Auditor Role）都可以提交。 o 如果金额 $\ge $10,000$，则必须拥有 Senior_Auditor 角色的人才能看到并点击“提交”按钮。

4. 规则与侧效应 (Side-effects)：超越简单的编辑 执行一个 Action 往往意味着触发一系列业务流程： • 发送通知：当一个“陆军”差异被标记为“需对方处理”时，Action 可以自动发送一个 Foundry Notification 给对应的“海军”联络人。 • 外部系统同步 (Webhooks)：高级配置中，Action 成功后可以调用 Webhook，在外部 ERP 系统中自动预填一笔抵消凭证。 • 操作日志：所有 Action 都会被记录。在审计时，你可以调出历史记录，清楚地看到：“审计员 A 在 2月24日 14:00 将此项根因改为‘汇率’”。

5. 函数驱动的操作 (Action Backed by Functions) 当你需要执行比“修改属性”更复杂的逻辑时，代码就派上用场了： • 案例：当审计员核销一笔差异时，系统需要自动计算这笔核销对该部门“年度预算达成率”的影响，并同时更新 5 个关联对象。 • 实现：这种复杂的联动逻辑无法通过简单的规则完成，必须使用 TypeScript Function 来驱动 Action，确保事务的原子性（要么全部更新成功，要么全部失败）。

总结：IGT 审计 Action 检查清单 配置项 推荐设置 目的 Parameters 强制下拉菜单 (Dropdown) 确保审计数据标准化，便于后续分析。 Visibility 仅显示必要的字段 减少干扰，引导审计员完成特定任务。 Criteria 基于金额或状态的提交权限 引入内部控制（Internal Controls）。 Side-effects 自动邮件/系统通知 实现我们最开始讨论的“邮件反馈闭环”。 下一步建议： 您是否想了解如何配置一个“批量核销 Action”？ 这允许审计员在表格中勾选 50 笔类似的细微差异，一次性填写根因并提交，极大地提高关账效率。 Reflections The action you just defined here is very basic, recording only a single Root Cause value. However, as you saw, this action has a semantic meaning, and it provides strong controls on who can make what kinds of changes to Ontology data. It also captures a single human conclusion back into Foundry. If we were to continue build out this workflow for the Flight Operations teams, you can imagine other decisions and the resulting actions they might want to make: • Assign an incoming Flight Alert to a given Flight Operations operator • Forward the alert to the local Flight Maintenance team for processing • Reassign the flight crew • Queue for passenger rebooking • Update the gate assignment • Reschedule this aircraft’s next flight • Swap aircraft for this aircraft’s next scheduled flight • Make as resolved As you focus on these decisions that the Flight Operations team needs to make, it shines a light on what additional data they will need in the Ontology to inform those decisions: • Flight crew status and availability • Plane availability for swaps • Passenger counts and destinations to inform tradeoffs between plane swaps and rebooking As this workflow grows in complexity, the Flight Operations team would quickly leave Object Explorer behind. Custom Workshop applications—as you built in the earlier End-to-End Speedrun course—would provide more appropriate and targeted tools. But those Workshop applications would reuse everything you built here: data pipeline, object type, links, and actions. This is illustrates another value of the Ontology. By focusing on real-world concepts, tailored to a specific organization and reflecting its processes, it lets us build solutions around daily decisions that need to be made. This produces a dynamic “digital twin“ of the organization. 这段总结深刻揭示了 Palantir Foundry 的核心哲学：本体（Ontology）不是静态的数据库，而是业务决策的“燃料”。 在 IGT（内部交易对账）审计的语境下，你的角色正从“数据管理员”转变为“业务流程架构师”。这种从简单属性更新到复杂业务闭环的演进，正是数字化转型的缩写。

1. 从“结论记录”到“决策链条” 正如你列举的飞行运营决策，IGT 审计也可以通过 Action 拆解为一系列具有语义逻辑的行为： • 指派审计员 (Assign)：将发现的差异项分发给特定的财务专家。 • 跨部门协调 (Escalate)：将无法解释的差额推送到买方或卖方的领导层审批。 • 申请核销 (Propose Adjustment)：触发一个会计分录申请。 • 证据补全 (Request Evidence)：自动向对方机构发送邮件索要凭证（回到我们最开始讨论的闭环）。 这些 Action 不仅仅是修改了数据库里的一个字符，它们代表了审计准则在系统中的执行。

2. “决策驱动”反推“数据需求” 这是建模中最精彩的部分。当你定义了“核销”这一动作时，你会发现仅有财务流水是不够的。为了支撑这个决策，审计员需要： • 实时预算余额：判断核销是否会导致超支。 • 历史诚信得分：该贸易伙伴过去的对账准确度如何？ • 法规库链接：这笔交易是否符合最新的 FIAR 指南？ 这种由动作驱动数据集成的方法，确保了你的 IGT 系统不会堆砌无用数据，而是精准地为决策服务。

3. 从 Object Explorer 到定制化 Workshop 正如你提到的，随着流程复杂化，通用的对象浏览器将无法满足需求。 • Object Explorer 像是一个通用的文件管理器，适合探索和发现。 • Workshop 则是专用的驾驶舱。 在 IGT Workshop 中，你可以利用你构建的血缘、对象和 Action，打造出： • 审计漏斗看板：显示从“发现差异”到“最终核销”的流转效率。 • 决策支持侧边栏：利用 AIP 根据历史记录自动推荐 Root Cause。 • 地图/图谱视图：直观展示资金异常在不同地区、不同军种间的关联。

4. 结论：IGT 审计的“数字孪生” 通过这一系列配置，你构建的不再是一个存储数据的盒子，而是一个能够理解审计逻辑的数字孪生体。 • 它是动态的：因为它实时反映了 ERP 的数据变化。 • 它是互动的：因为它捕捉了审计员的每一个决定并反馈给系统。 • 它是可进化的：随着你添加更多的链接和函数，它的“智力”将不断提升。 Conclusion This course has covered the basics you need to know to get started with a Foundry Ontology. Value We covered why the Ontology is valuable.

5. It makes data easier to use.

6. It structures data into a vocabulary that is reusable across workflows and across the organization.

7. The Ontology provides well-defined actions that can enforce constraints and make the output of regular decisions immediately to others within the platform. In this way, the Ontology is more than another “semantic” data layer. In also includes “logic” through the rules that it encodes and “kinetics” through its actions. It is both the nouns of your organization, but also the verbs. Ontology and AI One last reason that the Ontology is valuable is the way that it allows you to integrate AI into daily operations. First of all, the Ontology can provide clean and usable inputs to AI. For example, if we wanted AI-generated recommendations for how to respond to a given Flight Alert, it would need to review much of the same data that human-operators also need to power their decisions. Furthermore, the Ontology structures these concepts in real-world terms that an LLM are already familiar with. Secondly, the Ontology provides a destination for AI outputs. The best place for a Flight Alert recommendation or prediction would be on the Flight Alert object itself. This inserts the recommendation into one or more existing operational workflows at the point where operators are already making their decisions. This makes it easier to then collect feedback on the final decisions those human operators then make—when they use the recommendations and when and why they disregard them. The many tools of AIP aim to do exactly this by building on top of the Ontology. Tools In terms of specific tools, you learned about: • Object Explorer - For object searches and for basic exploration and analysis across sets of objects • Data Lineage - For exploring data pipelines and understanding how they lead to the Ontology • Ontology Manager - For building the Ontology itself Next Steps To further your understanding of how objects can be tailored to support workflows directly: • Object Views - The Airline and Airport objects you explored in this tutorial had custom object views Good next steps to see how objects are then used by other applications: • Quiver - For powerful point-and-click analysis of object sets and dashboarding • Workshop - For building operational applications from point-and-click widgets • Ontology SDK (OSDK) - Building custom third-party applications that treat the Ontology as a backend 从你最初询问的“邮件反馈闭环”开始，我们共同穿过了数据血缘、受控视图、以及 Object Storage V2 的底层架构。正如结论中所说，本体不仅仅是数据的“名词”（数据集），更是业务的“动词”（Action 与流程）。 在 IGT 审计的最终图景中，本体将成为你组织的 “数字神经系统”。

8. 核心价值回顾：IGT 审计的“名词”与“动词” • 名词（Semantic）： 你已经定义了什么是差异项、什么是贸易伙伴。这让审计员不再面对 Table_A_Final_v2 这种晦涩的文件，而是直接面对业务实体。 • 动词（Kinetic）： 你配置的 Action 确保了“核销”、“指派”和“反馈”这些操作是受控的、可追溯的，并能即时改变业务状态。

9. 本体与 AIP：审计智能化的终局 你提到的 AI 集成是 2026 年 IGT 流程的杀手锏。利用本体作为 AI 的基础，你可以实现： • 输入端： 为 LLM 提供具有业务上下文的输入（例如：不只是提供金额，还提供该金额背后的合同关系和历史对账模式）。 • 输出端： AI 生成的“差异解释”会直接写回到对象属性中，并在 Workshop 界面中等待审计员的最终确认。

10. 工具链与您的下一步路径 为了将你目前掌握的知识转化为实际的生产力工具，建议按照以下路径进阶： 第一步：定制 Object View（对象视图） 目前的 Airport 或 Airline 对象都有特定的布局。在 IGT 中，你需要为 Discrepancy 对象设计一个**“审计员仪表盘”**： • 左侧显示财务流水对比。 • 中间显示 AIP 自动生成的根因分析。 • 右侧显示该贸易伙伴的联系方式。 第二步：在 Workshop 中构建应用 这是你将“闭环”交付给用户的舞台。在 Workshop 中，你可以拖拽 widgets（小组件）： • Object Table：展示高风险差异。 • Action Button：一键触发我们讨论过的“邮件反馈”或“批量核销”。 • Chart Widget：通过 Quiver 或 Functions 实时展示各军种的对账进度。

总结：从学习者到架构师 你现在已经具备了构建一套自动化、智能化 IGT 审计系统的所有理论基石：

1. 数据流：通过数据血缘确保存证。

2. 安全性：通过基于链接的安全实现多租户隔离。

3. 交互性：通过 Action 捕获人为决策。

4. 闭环化：通过连接器和函数实现内外系统联动。 “IGT 本体发布检查清单（Release Checklist）”这份清单将帮助您在正式向审计部门发布应用前，最后确认所有权限、主键和 Action 逻辑是否万无一失。 这份清单旨在确保您的 IGT（内部交易对账）系统在从开发环境推向生产环境时，具备审计级的稳定性、合规的安全隔离以及丝滑的用户体验。 您可以对照以下五个维度进行最后的“起飞前检查”：

5. 数据完整性与血缘检查 (Data & Lineage) 确保底层数据集的“地基”足够稳固，能够经受住外部审计的复核。 • [ ] 主键稳定性：确认 Primary Key 是否是基于业务逻辑的确定性哈希（如 hash(ID+Date+Amount)），而非随机生成的 ID。 • [ ] 数据更新频率：是否已在数据血缘视图中为原始 ERP 数据集配置了 Data Health Checks（如：24小时未更新告警）？ • [ ] Schema 锁定：检查上游字段名是否已锁定，防止字段变更导致下游本体映射失效。

6. 本体建模精细度 (Ontology Mapping) 确保“数字孪生”准确反映了业务逻辑。 • [ ] 属性类型转换：所有的“金额”字段是否已标记为 Currency 类型？“日期”字段是否配置了正确的时区显示？ • [ ] 基数验证 (Cardinality)：Trading Partner 与 Discrepancy 之间的链接是否正确设置为 1:M？ • [ ] 标题 (Title) 设置：对象的 Title 是否设为人类可读的格式（如 [CaseID] - [Vendor]），而非晦涩的代码？

7. 安全与权限策略 (Security & Permissions) 这是最关键的一步，防止跨军种的数据泄露。 • [ ] 受控视图 (Restricted View)：是否已激活“基于链接的安全（Link-based Security）”，确保陆军审计员无法看到海军的差异项？ • [ ] 敏感信息屏蔽 (Markings)：对于涉及 PII（个人身份信息）或敏感备注的属性，是否已添加特殊的 Marking 限制访问？ • [ ] Action 提交权限：金额超过阈值（如 $1M）的核销 Action，是否已配置为仅限“高级审计员（Senior Auditor）”可见或执行？

8. 操作与闭环逻辑 (Actions & Kinetics) 确保用户点击按钮后，业务流程能正确流转。 • [ ] 标准化输入 (Dropdowns)：Root Cause 参数是否已限制为预设的下拉选项，以防止出现不可分析的自由文本？ • [ ] 侧效应 (Side-effects)：核销 Action 成功后，是否配置了自动发送通知（Foundry Notification 或之前讨论的邮件回流）？ • [ ] 原子性检查：如果一个 Action 需要同时更新多个对象（如更新差异状态并更新伙伴得分），是否使用了 Functions on Objects 来保证操作的原子性？

9. 用户界面与决策支持 (Workshop & UI) 确保审计员能快速定位问题并采取行动。 • [ ] 对象视图 (Object View)：详情页是否集成了“历史对账趋势图”和“关联凭证列表”？ • [ ] AIP 推荐验证：如果集成了 AIP 推荐根因的功能，是否已在侧边栏清晰展示了 AI 的推导逻辑和置信度分值？ • [ ] 性能测试：在加载包含 100,000+ 对象的大型 Object Set 时，Workshop 过滤器的响应时间是否在 2 秒以内？ 总结建议 在正式发布前，建议您进行一次端到端演习：

10. 模拟一名基层审计员登录。

11. 查看一个差异项并尝试核销。

12. 检查是否收到了通知邮件，且底层数据集是否留下了审计轨迹。