ONTOLOGYOntology and Data ModelingFeb 25, 2026

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

#ontology#foundry#data modeling#digital twin#semantic layer#action layer#audit trail

✦ AI SUMMARY

The Palantir Ontology transforms raw data into meaningful, interconnected 'living objects' that mirror real-world entities. It comprises a Semantic Layer (defining object types and properties), a Relational Fabric (linking objects), and an Action Layer (enabling operational decisions and audit trails), serving as a digital twin for an organization to eliminate data silos, foster reusability, and empower decision-making.

Deep Dive: Creating Your First Ontology Feb 24 2026 Introduction The Ontology The data that is used most regularly in Foundry is presented as objects. For example, you can open a specific Airline object, Aircraft object, or Customer object and see the essential data (that you have permission to see) about that particular real-world thing. This object’s data is typically aggregated from many different original data sources. For example, an Aircraft object might contain information pulled from purchase records, maintenance systems, flight systems, and more. The Ontology defines the set of object types available. Each instance of Foundry has its own unique set of object types that are specific to that organization and the problems they face. For example, an airline or a military organization would typically have an Aircraft object type, whereas a pharmaceuticals company would not. Furthermore, the Aircraft object type might have different properties and different relationships to other object types at an airline than it does for the military. In this way, the Ontology reflects the real-world objects that users at a given organization think about and operate on every day.

The Ontology offers several benefits: It makes data easier to use. It provides a common operational vocabulary across workflows and across the organization. It supports operational decisions through well-defined actions. It powers AI solutions in an operational day-to-day context. 扩展本体（Ontology）不仅是进行数据建模，更是为整个组织构建一个数字孪生（Digital Twin）。在国防部或大型企业的审计环境中，本体的深度和广度直接决定了决策的质量。以下是本体的深度扩展及其对组织产生的变革性影响：

深入理解本体的三大支柱 (The Trinity of Ontology) 为了让数据产生行动，本体不仅仅包含静态的“对象”，它由三个相互作用的层级组成： A. 结构层 (The Semantic Layer) 这是本体的基础，将“行与列”映射为“名词”。 • 对象类型 (Object Types)：如“拨款（Appropriation）”、“合同（Contract）”、“付款单据（Voucher）”。 • 属性 (Properties)：不仅是基础数值（金额、日期），还包括计算属性（例如，通过公式自动计算的“剩余可用预算”）。 B. 关系层 (The Relational Fabric) 这是本体的威力所在，将孤立的对象编织成知识网。 • 物理链接：将“交易”连接到对应的“供应商”。 • 逻辑链接：将一笔“陆军支出”与一笔“海军收入”链接，形成一个 IGT 对账对（Match Pair）。 • 影响：通过关系，审计师可以进行下钻分析（Drill-down）。点击一个供应商，立即看到与之相关的所有合同、未付发票和历史审计差异。 C. 行动层 (The Action Layer) 这是本体从“观察”转向“执行”的地方。 • Action Types：定义了用户可以对数据执行的操作。 • 规则验证：例如，如果差额超过 $50M，则禁止点击“手动核销”按钮，强制要求上传授权文档。
扩展本体对组织的深远影响 (The Impact) A. 消除“数据孤岛”与“词汇冲突” 在没有本体的情况下，陆军可能称其为 APPN_ID，而海军称其为 FUND_CODE。 • 影响：本体创建了一个统一语义层。无论是技术人员、财务官还是高级将领，在界面上看到的都是 Funding Source。这使得跨部门的联合审计成为可能。 B. 资产的复用性 (Compounding Value) 本体是一个活的资产。 • 影响：一旦你为审计建立了一个“合同”对象，其他部门（如后勤或采购）可以直接重用这个对象，而不需要重新清理数据。随着更多对象和关系的加入，本体的价值呈指数级增长，形成“数据复利”。 C. 审计追踪与合规性 (Impeccable Audit Trail) 在表格中修改数据是危险且难以追踪的。 • 影响：在本体中，所有更改都是通过 Actions 完成的。这意味着每一次状态变更（如将差异标记为“已解决”）都会自动记录：谁、在什么时候、基于什么证据、做了什么修改。这直接满足了 FIAR 审计对“数据完整性”的严苛要求。 D. 赋能决策者，而非仅仅是分析师 • 影响：由于本体将复杂的数据逻辑封装在简单的对象后面，非技术决策者可以通过 Workshop 应用直接进行操作。他们不需要知道数据来自哪个过时的 ERP 系统，只需要关注“这个对象代表的业务问题是否已解决”。

案例：从“数据湖”到“审计中枢” 阶段传统数据分析 (Data Lake) 本体化操作 (Ontology) 查询方式编写复杂的 SQL 关联 20 张表。搜索“Status: Discrepancy”的对象。异常处理在 Excel 中记录，无法反馈回系统。点击“Create Adjustment”按钮，实时更新状态。 AI 参与 AI 只能总结文本，无法理解业务逻辑。 AIP 自动推荐匹配关系，因为它知道“合同”与“支付”的逻辑联系。组织影响只有数据专家能处理数据。全体审计官都能在统一的数字环境中协作。

总结：本体是“作战地图” 如果原始数据是散落在地上的拼图碎片，那么本体就是那张拼图背后的底图。它告诉组织每一个碎片应该放在哪里，以及它们如何构成完整的业务图景。 In the world of data engineering and Palantir Foundry, the word Ontology is often the most confusing yet important concept. To understand it, you have to stop thinking like a "Data Architect" (tables and columns) and start thinking like a "Business Owner" (objects and relationships).
What is an Ontology? (The Big Picture) An Ontology is a digital map of your organization. It is a layer that sits on top of your datasets to give them real-world meaning. • It is NOT a data element. (A data element is like a single cell in Excel). • It is NOT a line of transaction. (That is a row in a dataset). • It is NOT a piece of record. (That is an individual file). Instead, the Ontology is the Definition of what those things represent. It transforms a row of data into a "Living Object" that you can click on, edit, and link to other things. Analogy: A Dataset is like a Spreadsheet of parts (screws, metal plates, glass). The Ontology is the Blueprint that tells you those parts combined are actually a "Tesla Model 3" and that it has a "Driver" and a "Battery."
A Concrete Example: The "Car Rental" Dataset Imagine you have a raw Dataset (a CSV file) called Rental_Logs.csv: ID Plate_Num Customer_Name Daily_Rate Status 101 ABC-123 John Doe 55.00 Rented 102 XYZ-999 Jane Smith 75.00 Available How the Ontology sees this:
Object Type: Instead of a "table," the Ontology creates a "Vehicle" object type.
Properties: The columns become Properties of the object (e.g., Plate Number, Rental Status).
The Record (Instance): One specific row (ID 101) becomes a Specific Vehicle Object. In the Ontology, you don't just see "Data"; you see "Vehicle ABC-123."
Relationships: The Ontology allows you to link this Vehicle to a Customer object (John Doe) and a Maintenance Log object.
What is a "Subset of Data" in this context? A Subset of Data is a filtered portion of your dataset. In the Ontology, we call this an Object Set. • Dataset View: SELECT * FROM Cars WHERE Status = 'Rented' • Ontology View: An Object Set of "Active Rentals." The difference is that a "subset" in a dataset is just a smaller table. A "subset" in the Ontology is a collection of interactive objects that you can immediately perform Actions on (like clicking a button to "End Rental").
Direct Answers to your Questions • Is Ontology a data element? o No. It is the framework that organizes data elements. A data element (like "Price") is a Property inside the Ontology. • Is it a line of transaction? o No. A line of transaction is the input. The Ontology takes that line and turns it into a Link or an Object. o Example: A transaction line saying "Sold Item A to Person B" becomes a Relationship Link between the "Item" object and the "Person" object. • Is it a piece of record? o No. It is the Identity of that record. A record is just a row; an Object in the Ontology is that row plus all its relationships, its history, and the actions you can take on it. Summary Table: Dataset vs. Ontology Feature Dataset (The "Kitchen") Ontology (The "Menu") Structure Rows and Columns Objects and Properties Format CSV, Parquet, SQL Business Entities (Car, Employee, Order) Connection Joins (Primary/Foreign Keys) Relationships (Links) Usability Requires SQL/Python to read Natural language, clickable in Apps Action Read-only / Update via code "Actions" (Buttons that change the world)

How to take a specific "Line of Transaction" from your dataset and map it to a "Relationship" between two objects? (e.g., Mapping a 'Payment' row to link a 'Buyer' and a 'Seller'). In the context of IGT, think of the Ontology as the "Universal Translator" and "Command Center" for audit. To understand it, we must contrast it with how you currently see data: as fragmented, messy spreadsheets from different ERPs (GFEBS, DEAMS, STARS).

The IGT Definition: What is the Ontology? The Ontology is a digital representation of your financial reality. It takes the thousands of raw, cryptic rows in your "Universe of Transactions" (UOT) and turns them into Entities that an auditor actually recognizes. • It is not the data itself: The data lives in the dataset. • It is the "Logic Layer": It tells the system: "This specific row in the Navy's dataset and this row in the Army's dataset are actually two sides of the same Order."
A Detailed IGT Example Let's look at how a single inter-agency transaction moves from a "Piece of Record" to an "Ontology Object." A. The Raw Datasets (The "Before") You have two datasets that don't talk to each other: • Seller Dataset (Navy): A row with ID: NV-99, Amt: 50000, Desc: SVC_REIMB_ARMY. • Buyer Dataset (Army): A row with ID: AR-44, Amt: 50050, Desc: VEH_MAINT_NAVY. In a normal database, these are just two lines of transaction. They are disconnected. B. The Ontology (The "After") The Ontology creates three things to bridge this gap:
Object Types (The "Nouns") Instead of seeing "Rows," the auditor sees a "Discrepancy Object." * Is it a data element? No. It’s the container. It pulls the Army's $50,050 and the Navy's $50,000 into one view called "IGT Case #123."
Properties (The "Adjectives") The Ontology defines what we need to know about this case: • Difference Amount: $50.00 (A calculated property). • Root Cause: "Timing Difference" (A property filled in by an auditor). • Confidence Score: 0.95 (A property generated by AIP).
Relationships (The "Verbs") This is the most powerful part. The Ontology links these objects. • The "Discrepancy Object" is linked to the "Navy Sale Object" and the "Army Purchase Object." • It is also linked to a "Support Document Object" (a PDF of the 7600B form).
Is it a Piece of Record or a Line of Transaction? To answer your specific question: No. * A line of transaction is a source of truth (the history). It is static. • An Ontology Object is a tool for action. It is dynamic. Concept Dataset (Line of Transaction) Ontology (Object) Perspective "I have a record of a $50k payment." "I have a Case that needs a signature." Changeability Usually Read-Only (Auditable history). Actionable (You can change the 'Status'). Scope One row = One system's view. One object = Both systems' views combined. Intelligence Just text and numbers. Knows its "parents" (Contract) and "children" (Invoices).

Why this matters for the DoD (The Impact) When an auditor asks, "Why is there a $1B difference between the Army and Air Force?": • Without Ontology: You spend 3 weeks doing VLOOKUPs across 5 datasets to find the "Lines of Transaction." • With Ontology: You open the "Inter-Agency Relationship" map. You see the "Discrepancy Object." You see it is already linked to the missing "MIPR (Military Interdepartmental Purchase Request)" object. The Ontology doesn't just store the record; it explains the relationship between the records.
What is an Object? In Foundry, an Object is a "Digital Twin" of a real-world entity. • A "Row" in a spreadsheet is just data: 2026-02-24, $500k, GFEBS. • An "Object" is a discrete thing you can talk about, track, and assign to someone. Think of an Object as a Smart Folder. Inside this folder is all the data about a specific transaction, but on the outside, it has "buttons" (Actions) and "connectors" (Links). Example: Instead of "Row 450 in the Navy Sales Table," you have the "Navy Sale #NV-99" Object.
How does Data become an Object? (The Transformation) Data becomes an Object through a process called "Backing." You take a static dataset and use the Ontology Manager to map it.
The Raw Source: You have your cleaned IGT dataset (the result of your Pipeline Builder work).
The Mapping: You tell Foundry: "Every row in this table should be treated as a Discrepancy Object."
The Identity (Primary Key): You pick a unique column (like MIPR_Number or a Hash_ID). This is the "soul" of the object—it's what makes it unique so it doesn't get confused with other transactions.
The Metadata: You map columns to Properties. o Column A → Amount o Column B → Trading Partner
What is the relation with the Ontology? To put it simply: The Ontology is the Library; the Objects are the Books. • The Ontology is the System of Rules. It defines what an Object is allowed to be. It says: "In this organization, a 'Discrepancy Object' must have an amount, a status, and it must be linked to a 'Buyer' and a 'Seller'." • The Objects are the Instances. They are the actual data living inside those rules. The "IGT Family Tree" Relation: The Ontology defines the Relationships. In IGT, the most critical relation is the Link. • The Ontology Rule: "A Discrepancy Object can be linked to many Reference Document Objects." • The Object Reality: "Discrepancy #123 is linked to PDF_Contract_A and PDF_Invoice_B."
Summary: The IGT "Chain of Command" Layer Component IGT Example Data Layer Dataset (The Rows) 1 million rows of GFEBS and DEAMS data. Ontology Layer Object Type (The Definition) The rulebook that defines what a "Match Case" looks like. Object Layer The Object (The Instance) Match Case #882—a specific $1.2M difference between Army and Navy. Action Layer The Action (The Decision) A button on Case #882 that says "Certify for Audit."
Why the "Action" is the Final Step You asked earlier about generating a Journal Voucher (JV). Because the data is now an Object in the Ontology, you can attach an Action to it. The Workflow:
You select the Discrepancy Object.
You click the "Generate JV" button (The Action).
Because the Object "knows" its properties (Amount, USSGL Account), the Action automatically fills out the JV form using that data and sends it to the financial system. Would you like me to show you how to build that "Generate JV" Action inside the Ontology Manager so it pulls the correct dollar amount automatically? 既然我们已经讨论了 IGT（内部交易）的工作流程，让我们解析从原始数据到**对象（Object）的演变过程，以及它与本体（Ontology）**的关系。
什么是对象 (Object)？在 Palantir Foundry 中，对象是现实世界实体的“数字孪生”。 • “行 (Row)”：在电子表格中只是纯数据，例如：2026-02-24, $500k, GFEBS。 • “对象 (Object)”：是一个独立的实体，你可以对其进行讨论、追踪、并分配给具体的审计人员。你可以把对象看作是一个**“智能文件夹”**。文件夹内部包含了关于这笔交易的所有数据，但在文件夹外面，它有“按钮”（Action/操作）和“插头”（Link/关联）。 IGT 示例：它不再仅仅是“海军销售表中的第 450 行”，而是一个名为 “海军销售 #NV-99”的对象。
数据是如何变成对象的？（转换过程）数据通过一个被称为**“映射 (Backing)”**的过程变成对象。你将静态的数据集映射到本体管理（Ontology Manager）中。
原始数据源 (Raw Source)：你通过 Pipeline Builder 清洗后的 IGT 数据集。
映射 (Mapping)：你告诉 Foundry：“这张表里的每一行都应该被视为一个 ‘差异项对象 (Discrepancy Object)’。”
唯一标识符 (Primary Key)：你选择一个唯一的列（如 MIPR 号码或哈希 ID）。这是对象的“灵魂”——它让每个对象都是唯一的，不会与其他交易混淆。
元数据 (Metadata)：你将列映射为属性 (Properties)。 o A 列 → 金额 o B 列 → 贸易伙伴 (Trading Partner)
它与本体 (Ontology) 是什么关系？简单来说：本体是“图书馆”；对象是里面的“书”。 • 本体 (Ontology)：是规则系统。它定义了一个对象“允许”是什么样子的。它规定：“在这个组织中，一个‘差异项对象’必须包含金额、状态，并且必须关联一个‘买方’和一个‘卖方’。” • 对象 (Object)：是实例。它们是这些规则下具体的、真实的数据。 IGT 的“家族树”关联：本体定义了关系 (Relationships)。在 IGT 中，最关键的关系是关联 (Link)。 • 本体规则：“一个‘差异项对象’可以关联多个‘参考文档对象’。” • 对象现实：“差异项 #123 关联了 PDF 合同 A 和 PDF 发票 B。”

总结：IGT 的“指挥链” 层级组件 IGT 示例数据层 (Data) 数据集 (行) 100 万行来自 GFEBS 和 DEAMS 的原始财务数据。本体层 (Ontology) 对象类型 (定义) 规定一个“对账案例”应该长什么样的规则手册。对象层 (Object) 对象 (实例) 对账案例 #882 —— 一个具体的陆军与海军之间 $1.2M 的差异。操作层 (Action) 操作 (决策) 案例 #882 上的一颗按钮，显示为**“审计确认”**。

为什么“操作 (Action)”是最后一步？你之前问过关于生成调整分录 (Journal Voucher, JV) 的问题。因为数据现在是本体中的一个对象，你可以给它绑定一个操作。工作流程演示：
审计师选择差异项对象。
点击 “生成 JV” 按钮（这就是 Action）。
因为对象“知道”自己的属性（金额、USSGL 科目），该操作会自动使用这些数据填充 JV 表单，并将其发送到财务系统。太棒了。在 Ontology Manager 中配置 Action（操作）是将静态数据转变为“动态业务流程”的关键一步。对于 IGT（内部交易）对账，我们希望建立一个操作，让审计员只需点击一下，就能根据对账差异自动生成调整分录（JV）草案。配置“生成 JV”操作的三个核心步骤
定义操作类型 (Action Type) 与触发逻辑首先，在 Ontology Manager 中创建一个新的 Action Type，命名为 Generate Journal Voucher。 • Target（目标）：选择我们之前定义的 IGT Discrepancy 对象。 • Submission Criteria（提交准则）：你可以设置规则，例如：“只有当状态为‘已匹配但有差异’且金额小于 $1M 时，才允许执行此操作。”
设置表单参数 (Parameters) 当审计员点击按钮时，会弹出一个表单。我们需要配置哪些数据是自动提取的，哪些是手动输入的： • 自动提取（隐藏参数）：利用对象属性。操作会自动从 IGT Discrepancy 对象中抓取 Difference_Amount 和 USSGL_Account。 • 手动输入：审计员需要填写 Justification（调整理由）或选择 Accounting_Period（会计期间）。
配置逻辑规则 (Logic Rules) 这是最关键的一步，定义操作点击后会发生什么： • Update Object（更新对象）：将该差异项的状态属性更改为 JV_Generated。 • Create Object（创建新对象）：在本体中自动创建一个新的 Journal Voucher 对象，并将其与原始差异项对象**关联（Link）**起来。 • Notification（通知）：通过 Webhook 或集成功能，将此 JV 信息推送到外部 ERP 系统（如 GFEBS）。为什么这样做对审计有意义？功能传统方式 (手动) Foundry 操作 (Action) 数据准确性手动录入金额，容易出现填错数字的情况。自动提取：直接从差异对象抓取金额，零误差。合规性调整记录分散在 Excel 和邮件中。全流程留痕：本体自动记录谁在何时触发了 JV 生成。效率编写 JV 需要数小时查对账表。秒级响应：点击按钮，表单已预填完毕。

实际操作演示（逻辑示意）：假设差异项 #882 的金额是 $50.00。

审计员点击 “生成 JV”。
后台逻辑：New_JV.Amount = Selected_Object.Difference_Amount。
结果：系统生成了一张准确无误的 $50.00 调整单据。 Ontology As a new employee at Fresh Air, you are not familiar with all of their data systems yet. However, from your new hire orientation, you know some of the basic terms of the industry. These types are present in Fresh Air’s Ontology:

In summary, an Airline operates a fleet of Aircraft. These Aircraft regularly fly from one Airport to another, where they land or takeoff from a given Runway. The connection between any two Airports along which Aircraft regularly fly is a Route. A Flight is a specific instance of an Aircraft flying along a Route at a particular date and time. Occasionally, a Flight might encounter an issue, such as delay, cancellation, or even a diversion to another airport that is not normally part of the route. These non-standard events generate a Flight Alert, which the Flight Operations team then responds to.

The data we will explore using this Ontology includes details from all US airlines, not only from Fresh Air. Because these are common object types beyond the bounds of this specific course, the object types include an OFT (Ontology Foundry Training) prefix to avoid any naming conflicts with any similar types found in your ontology Object Explorer There are many Foundry applications that let you work with objects and the Ontology. We will start with the simplest of them, which is Object Explorer. Object Explorer is used for object searches and for basic exploration and analysis across sets of objects. Step 1: Open Object Explorer Help: I can’t find these object types! The necessary marketplace bundle must be installed on your Foundry instance, the installation needs to be fully built to create all the necessary objects, and you then need permission to the see those objects and their data. See the previous Getting Started section for more. Traversing Links When you are exploring an object set, you can use the Linked objects entries in the lower right to switch to all of the linked objects according to some relationship link. For example, suppose we’re starting with all 320 of Fresh Air’s Routes. You could then switch to all of the Origin Airports for those Routes, or you could switch to all of the Flights that occur along those Routes. This process of traversing links from one object set to another is often called pivoting from one object set to another. (If you are already familiar with pivot tables, I recommend treating this as an unrelated concept with the same name. Trying to think of link traversals in terms of pivot tables will only lead to more confusion than if you start with a fresh mental model of the process as described above.) Object Explorer is a quick way for any user, regardless of technical background, to get started using objects. Using only point-and-click controls, you can search for single objects of interest, follow links to related objects, and explore a singe object set in detail.

Object Explorer is only one place were objects are used in Foundry. • For more complex object-based analysis—such as doing richer numerical analysis, building visualizations, deriving timeseries, comparing multiple object sets, or building interactive reporting dashboards--you should consider Quiver instead. • On the other hand, if you have a regular operational workflow, building a dedicated Workshop application (as you did as part of the earlier End-to-End Speedrun course) will provide users a smoother and more tailored tool than relying on Object Explorer alone. 对于 IGT（内部交易对账）任务，选择哪种工具取决于你处于审计流程的哪个阶段。在 IGT 场景下，这三种工具的关系如下：

Workshop：用于日常对账操作（首选）如果你是一名审计员，每天的任务是处理差异、上传凭证、核销分录，那么 Workshop 是你的核心战场。 • 为什么选它：你可以构建一个专门的“IGT 差异处理中心”。它有专门的按钮（Actions），比如“批准对账”、“提交 JV”或“指派给贸易伙伴”。 • IGT 示例：一个专门的仪表盘，左边显示所有“未对平”的交易，右边显示关联的买方和卖方数据，下方直接提供处理表单。
Object Explorer：用于快速搜索与单项调查如果你正在寻找一笔特定的、你只知道 MIPR 号码或交易 ID 的可疑交易，Object Explorer 是最快的方法。 • 为什么选它：它就像是本体数据的“谷歌搜索”。你不需要构建任何应用，直接输入 ID 就能看到该对象的所有属性。 • IGT 示例：老板问你：“那笔关于陆军医疗器材的 $5M 差异是怎么回事？”你直接搜索该 ID，查看它关联的合同和历史变动。
Quiver：用于深度分析与根本原因研究如果你是一名财务分析师，需要找出为什么本季度的 IGT 差异比上季度增长了 20%，那么 Quiver 是最佳选择。 • 为什么选它：它擅长数值分析和时间序列。你可以比较不同时间点的差异金额，或者通过图表分析哪个特定的“贸易伙伴代码 (TP Code)”总是导致对账失败。 • IGT 示例：创建一个透视表，按 USSGL 科目汇总所有差额，并生成一个趋势图，显示过去 12 个月的对账完成率。总结建议你的需求推荐工具我要解决差异、提交分录、审批流程 Workshop 我要找特定的某一笔账、看看它关联了什么 Object Explorer 我要研究趋势、做统计图表、找差异的规律 Quiver

如何在 Workshop 中设计一个针对“审计员”的专用界面在 Workshop 中为审计员设计 IGT 专用界面时，核心目标是**“降噪”和“引导”。审计员不应该在寻找数据上浪费时间，而应该专注于决策（Decision Making）**。一个高效的审计专用界面通常遵循 “发现 -> 分析 -> 处置” 的三段式布局。

顶部：全局状态卡片（发现阶段）界面的顶部应该提供“任务概览”，让审计员立即知道工作的优先级。 • 汇总指标（Metric Widgets）： o 待处理差异总额（红色高亮，显示风险敞口）。 o 今日截止的任务数（提醒紧迫性）。 o 自动匹配建议数（展示 AIP 辅助的效率）。 • 全局过滤器：允许按“军种”、“会计期间”或“差异等级（高/中/低）”一键筛选整个页面。
中间层：差异监控工作台（分析阶段）这是界面的核心，通常采用 “列表 + 详情” 的联动设计。 A. 对象列表（Object Table） • 条件格式化：如果差额超过容差（Tolerance），单元格自动变红。 • 影子属性：显示该差异已存在的天数。 • 联动功能：当审计员点击列表中某一行时，下方的“详情模块”自动加载该笔交易的全部信息。 B. 360 度视图详情（Object View） • 对比视图：左右并排显示“买方数据”与“卖方数据”，高亮显示不一致的字段（如金额或 USSGL 代码）。 • 关联路径图：展示该差异项关联的合同（Contract）、拨款（Appropriation）和原始凭证（Vouchers）。
右侧或底部：操作面板（处置阶段）这是审计员执行“动作”的地方，确保数据闭环。 • 审批流按钮（Action Groups）： o “一键核销”：仅在差额为 0 时可用。 o “发起申诉/查询”：自动给贸易伙伴发送系统内通知。 o “生成调整分录 (JV)”：触发我们之前讨论的自动填充逻辑。 • 附件与备注：集成文件上传组件，强制要求审计员在核销大额差异前上传支持性文档（如 7600A/B 协议）。
关键设计原则（审计特有）功能设计细节审计价值只读与编辑分离核心财务数据设为只读，只有备注和状态可编辑。保证原始凭证的不可篡改性。多级联动点击饼图中的“海军”，表格自动过滤为海军交易。极大地提高了数据下钻的速度。 AIP 侧边栏集成 AIP 助手，自动总结：“该差异极可能是由去年的跨年时间差导致的”。辅助审计员快速做出初步判断。
总结：审计员的一天
登录：看到顶部红色的“$2B 未对平”预警。
筛选：过滤出自己负责的“陆军对空军”部分。
分析：点击列表中的第一行，通过详情视图发现买卖双方金额不符。
处置：点击右侧按钮，上传证明材料，点击“生成 JV”，该差异项从列表中消失，处理完毕。下一步建议：设计这个界面时常用的 5 个核心 Widget（组件）及其配置参数，以便您直接在 Foundry 中开始拖拽构建？在 Foundry Workshop 中，设计高效的审计界面的诀窍在于合理配置组件之间的事件监听（Event Listening）。以下是构建 IGT 审计工作台最常用的 5 个核心 Widget 及其关键配置参数：
Object Table (对象列表组件) 这是审计员的主视图，用于显示所有的对账差异项。 • 核心配置 (Parameters): o Object Set: 绑定到你的 IGT Discrepancies 对象集。 o Columns: 挑选关键字段，如 Difference Amount、Trading Partner、Aging Days。 o Conditional Formatting: * 配置示例：当 Difference Amount > 1,000,000 时，背景色设为浅红色。 o Selection Mode: 设为 Single Selection 或 Multi-selection，并将其输出到一个 Active Object Variable（这是实现点击某行、下方显示详情的关键）。
Metric (指标组件) 放在页面顶部，用于实时汇总风险敞口。 • 核心配置 (Parameters): o Measure: 选择 Sum（求和）。 o Property: Difference Amount。 o Format: 设为 Currency（货币），缩写设为 Millions 以保持界面整洁。 o Interactive Mapping: 点击该指标时，可以触发一个过滤器（例如点击“高风险”指标，表格自动过滤出大额差异）。
Object View Container (对象视图容器) 用于展示选中交易的详细信息（360度视图）。 • 核心配置 (Parameters): o Object to Display: 绑定到第 1 步中定义的 Active Object Variable。 o Layout: 选择 Tabs（标签页），分为“交易详情”、“关联凭证”、“历史审计记录”。 o Context: 将其设置为“只读”，确保审计员在分析时不会误改基础财务数据。
Button Group (按钮组 / 操作组件) 这是审计员执行“动作”的地方。 • 核心配置 (Parameters): o Actions: 添加你之前在 Ontology Manager 中创建的 Generate Journal Voucher 或 Resolve Match 操作。 o Parameter Mapping: * 重要配置：将操作中的 Target Object 参数映射到当前的 Active Object Variable。 o Visibility Rules: * 配置示例：只有当 Selected_Object.Status == 'Unresolved' 时，才显示“核销”按钮。
Filter Bar (过滤器栏) 让审计员能够根据不同的维度缩小搜索范围。 • 核心配置 (Parameters): o Linked Widget: 关联到你的 Object Table。 o Filter Fields: 推荐添加 Accounting Period（会计期间）、Main Account（主科目）、Discrepancy Type（差异类型）。 o Default Selection: 可以设置为默认显示“当前会计期间”的未处理项。专家小贴士：如何实现“联动”效果？在 Foundry Workshop 中，最强大的功能是 Variables（变量）：
表格输出变量：当用户在 Object Table 选中一行，系统会把这个 Object 存入变量 var_selected_igt。
详情输入变量：你的 Object View 和 Action Button 都把 var_selected_igt 作为输入。
结果：审计员点击表格里的“交易 A”，下方的详情图表和侧边的“生成 JV”按钮会自动更新为“交易 A”的数据。这就是所谓的“点哪儿显哪儿”。使用 TypeScript Function 编写一个“计算字段” 例如：根据差异金额和逾期天数，自动给每一笔交易计算一个“风险优先级得分 (Risk Priority Score)”，并直接显示在表格中。在 Foundry 中，这种实时计算且不改变原始数据的字段被称为函数支持的列Function-backed columns。通过 TypeScript，你可以编写复杂的逻辑。在 IGT 对账中，这能帮助审计员从成千上万笔差异中，一眼看到最需要关注的那一笔。

逻辑设计：风险优先级得分 (RPS) 我们假设一个简单的算法： Risk Priority Score = (差异金额 x 权重A) + (逾期天数 x 权重B) • 如果金额超过 $1,000,000，权重加倍。 • 如果逾期超过 90 天，得分额外增加。
在 Functions 存储库中编写代码你需要打开 Functions on Objects 存储库，并编写类似下面的代码。这个函数会接收一个 IGT_Discrepancy 对象并返回一个整数。 TypeScript import { Integer, Function, Visibility } from "@foundry/functions-api"; import { IGT_Discrepancy } from "@foundry/ontology-api";

export class RiskFunctions { @Function() public async calculateRiskScore(discrepancy: IGT_Discrepancy): Promise<Integer> { // 1. 获取基础属性 const amount = discrepancy.differenceAmount ?? 0; const dueDate = discrepancy.dueDate;

    if (!dueDate) return 0;

    // 2. 计算逾期天数
    const today = new Date();
    const diffInTime = today.getTime() - new Date(dueDate).getTime();
    const agingDays = Math.max(0, Math.floor(diffInTime / (1000 * 3600 * 24)));

    // 3. 定义风险权重逻辑
    let score = 0;
    
    // 金额风险 (每 10k 一分，百万级以上翻倍)
    const amountFactor = amount > 1000000 ? 2.0 : 1.0;
    score += Math.floor((amount / 10000) * amountFactor);

    // 时间风险 (每逾期 30 天加 50 分)
    score += Math.floor(agingDays / 30) * 50;

    // 4. 返回最终得分
    return score;
}

} 3. 在 Workshop 中将函数添加到表格编写并发布（Tag）函数后，按照以下步骤将其显示在 UI 中：

打开 Workshop，选中你的 Object Table 组件。
在右侧配置栏找到 Columns 部分，点击 Add column。
选择 Function-backed column（或者从现有函数中选择）。
搜索并选择你刚刚编写的 calculateRiskScore 函数。
输入映射 (Input Mapping)：系统会自动识别函数需要一个对象，将其映射为 Current Row（当前行对象）。
样式设置：你可以将此列命名为 “Risk Score”，并配合条件格式化（例如得分 > 500 显示为红色）。
为什么要在 IGT 中使用函数计算字段？ • 动态性：得分是根据“今天”的时间实时计算的。每天打开系统，逾期天数会自动增加，得分也会随之变化。 • 不污染原始数据：你不需要在 Pipeline Builder 中预先算好分值，这保证了底层财务数据的“纯净性”。 • 交互性：审计员可以直接点击这个“Risk Score”列表头进行降序排列，从而实现优先处理高风险账目。
进阶应用：多维度排序一旦有了这个函数列，你还可以将其用于： • 饼图 (Pie Chart)：展示“高分段”与“低分段”差异项的分布。 • 条件筛选：在 Filter Bar 中添加一个滑动条，只显示“得分 > 300”的严重差异。让 AI (AIP) 介入计算，根据历史对账成功的概率来给当前的差异项打一个“可自动对平信心分 (Confidence Score)”？引入 AIP (Artificial Intelligence Platform) 介入 IGT 对账，是将审计从“人工查找”转向“自动导航”的飞跃。在 Foundry 中，通过 AIP 逻辑，我们可以根据历史对账模式（例如：特定供应商的特定科目通常在 3 天内自动平账）来给当前的差异项打一个 “信心分 (Confidence Score)”。

核心架构：AIP 信心分是如何产生的？ AIP 不仅仅是一个聊天框，它可以被封装进 TypeScript Functions 中，作为一个“智能推理层”。 • 输入数据：当前差异项、该贸易伙伴的历史对账记录、历史手动核销的理由。 • AIP 逻辑：分析当前差异是否符合已知的“良性模式”（如跨月时间差）或“恶性模式”（如金额截断错误）。 • 输出结果：一个 0-100 的数值，以及推荐理由。

编写 AIP 函数 (AIP in Functions) 在代码存储库中，我们可以调用 Aip.prompt() 来进行逻辑推理。以下是一个简化的逻辑示例： TypeScript import { Function, Double } from "@foundry/functions-api"; import { AIP } from "@foundry/functions-api/aip"; // 假设的AIP API import { IGT_Discrepancy } from "@foundry/ontology-api";

export class AIPReconFunctions { @Function() public async getAIPConfidenceScore(discrepancy: IGT_Discrepancy): Promise<Double> { // 1. 准备上下文：获取该差异的属性及相关的历史对账成功率 const context = Current Discrepancy: ${discrepancy.amount}, Partner: ${discrepancy.tradingPartner}, Historical Success Rate for this partner: 85%. Common Reason: Timing Difference. ;

    // 2. 调用 AIP 进行推理
    const response = await AIP.prompt(`
        Based on the following financial context, what is the probability (0.0 to 1.0) 
        that this discrepancy is a simple timing difference that will resolve itself? 
        Return only the number. Context: ${context}
    `);

    return parseFloat(response);
}

}

在 Workshop 界面中的呈现将这个 AIP 函数绑定到 Workshop 后，审计员的体验将发生翻天覆地的变化： • 信心分列 (Confidence Column)：表格中新增一列，显示 95%、40% 等分值。 • 智能分组： o 90% 以上：系统自动标记为“建议批量核销”，审计员只需一键通过。 o 30% 以下：系统自动标记为“高风险，需人工介入”，并高亮显示。 • AIP 解释侧边栏：当审计员点击 95% 的分值时，弹出一个侧边栏解释：“AIP 分析：此贸易伙伴在过去 12 个月中，98% 的此类金额差异均在 48 小时内由系统自动补平。”
为什么这对 IGT 审计具有革命性？维度传统审计 (Manual) AIP 辅助审计 (AIP-Powered) 处理优先级只能按金额大小排序，效率低。按“解决可能性”排序，优先处理最棘手的问题。知识传承老师傅知道某些差异是正常的，新人不知道。知识沉淀在模型中，AIP 自动学习历史核销经验并告知新人。大规模对账面对数百万行数据，人工无法覆盖全量。自动化分流：AIP 处理 80% 的常规项，人类专家处理 20% 的复杂项。
进阶应用：自动建议操作一旦 AIP 给出了高分，你还可以配置一个 AIP Action： • 如果信心分 > 98%，Action 会自动预填好核销备注，甚至直接建议生成 JV 分录的科目代码。配置这种“AIP 理由生成”功能当审计员点击差异项时，AIP 会自动生成一段人类可读的分析报告，说明为什么它认为这笔账有问题。配置 AIP 理由生成（AIP Reasoning/Explanation）功能，本质上是在 Workshop 中创建一个“实时推导窗”。当审计员点击某项差异时，系统会动态将该对象的上下文发送给 AIP，并实时返回一段专业的审计分析报告。以下是实现这一功能的详细步骤：
核心原理：对象上下文注入要让 AIP 生成有意义的理由，不能只给它一个金额。你需要将**本体（Ontology）**中的关联信息“喂”给模型。 • 基本信息：金额、科目、日期、贸易伙伴。 • 关联信息：该贸易伙伴的历史对账成功率、最近 3 次类似差异的处理结果、合同条款摘要。
步骤一：创建 AIP 提示词模板 (Prompt Template) 在 Foundry 的 AIP Logic 或 Functions 存储库中，你需要定义一个结构化的提示词。提示词示例： "你是一名高级国防部财务审计专家。请分析以下 IGT 差异项： • 差异对象：{{object.label}} • 差异金额：{{object.difference_amount}} • 贸易伙伴：{{object.trading_partner}} • 历史模式：该伙伴 90% 的差异属于‘时间性差异’。请根据以上数据，生成一段 200 字以内的专业审计分析报告，解释为何该账目存在问题，并给出处理建议。语言要求：客观、严谨。"
步骤二：编写 TypeScript 函数你需要编写一个函数，作为 Workshop 和 AIP 之间的桥梁。 TypeScript import { Function, String } from "@foundry/functions-api"; import { AIP } from "@foundry/functions-api/aip"; import { IGT_Discrepancy } from "@foundry/ontology-api";

export class IGTReasoning { @Function() public async generateAuditReport(discrepancy: IGT_Discrepancy): Promise<string> { // 自动构建上下文 const context = 金额${discrepancy.amount}，科目${discrepancy.ussglAccount}，伙伴${discrepancy.partnerName};

    // 调用 AIP 
    const report = await AIP.complete({
        prompt: `请针对以下 IGT 差异生成审计报告：${context}`,
        model: "large-reasoning-model" // 使用高性能推理模型
    });

    return report;
}

}

步骤三：在 Workshop 中配置 UI 呈现这是审计员最终看到报告的地方。
添加组件：在 Workshop 布局的右侧添加一个 Text 组件或 TextArea 组件。
内容绑定：将该组件的内容设置为 “来自函数的输出” (Output from Function)。
函数选择：选择你刚刚编写的 generateAuditReport 函数。
输入映射：将函数的输入参数映射到当前页面选中的 Active Object Variable（即审计员在表格中点击的那一行）。
加载状态：配置一个“加载中”的动画（Spinner），因为 AIP 生成文字通常需要 1-3 秒。
审计员的使用体验 • 点击：审计员在表格中选中一笔 $2.5M 的异常交易。 • 思考：右侧面板显示“AIP 正在分析中...”。 • 生成：面板弹出报告： “审计分析：该笔差异金额巨大，且 USSGL 科目与贸易伙伴历史记录不符。AIP 检测到卖方（海军）已入账，但买方（陆军）尚未创建对应的采购订单。风险点：极可能是由于跨财年合同未及时结转导致。建议：核查 7600B 协议的有效期限。”
进阶：反馈循环 (Human-in-the-loop) 为了让 AIP 越来越聪明，你可以在报告下方添加两个小图标：👍 和 👎。 • 审计员点击 👍：系统记录该分析准确。 • 审计员点击 👎：系统提示审计员输入正确理由，并将此数据回传给模型进行微调（Fine-tuning）。

“一键生成 PDF 审计简报” 将 AIP 生成的理由与原始数据结合，直接导出一份符合 FIAR 审计标准的正式文档。在 Palantir Foundry 中实现“一键生成 PDF 审计简报”是一项高级功能，它将本体数据（Ontology）、AIP 智能分析和文档生成引擎完美结合。这不仅能节省审计员数小时的撰写时间，还能确保每一份导出的报告都符合 FIAR（财务改善与审计准备）的标准化要求。以下是配置这一功能的完整技术路径：

核心架构：Notepad 集成在 Foundry 中，生成 PDF 的标准工具是 Notepad。它允许你创建动态模板，将对象属性（如金额）和函数输出（如 AIP 理由）自动填充到文档中。
步骤一：创建 Notepad 审计模板首先，你需要建立一个符合审计规范的文档原型： • 静态部分：报告标题（如“IGT 差异分析报告”）、保密级别、机构 LOGO。 • 动态占位符： o {{Object.Property.Amount}}：自动插入差异金额。 o {{Object.Property.Trading_Partner}}：插入贸易伙伴名称。 o 函数调用：插入我们之前编写的 generateAuditReport 函数的实时输出。
步骤二：配置“导出 PDF” 操作 (Action) 为了实现“一键生成”，你需要在 Workshop 中配置一个专门的 Action。
Action 类型：创建一个名为 Export Audit Brief 的 Action。
逻辑设置： o 使用 Notepad Template Action。 o 输入映射：将当前选中的差异对象映射给模板。 o 输出配置：设置文件名为审计简报_{{Date}}_{{ID}}.pdf。
触发后果：配置操作执行后，自动将生成的 PDF 文件挂载到该差异对象的“关联文档”属性中。
步骤三：在 Workshop 界面添加按钮在你的审计员专用界面右侧的操作面板中，添加这个按钮。 • 按钮样式：使用 PDF 图标，并命名为“生成官方审计简报”。 • 交互逻辑：当审计员点击按钮时，Workshop 会调用背景函数，等待 AIP 生成理由，然后将所有数据填入 Notepad 模板，最后弹出下载窗口或直接存入数据湖。
符合 FIAR 标准的报告包含哪些内容？一份专业的 IGT 审计简报通常由以下几部分动态组成：章节数据来源审计意义
交易概览对象属性 (Ontology) 明确“谁欠谁多少钱”，这是审计的起点。
自动对账记录历史链接 (Links) 证明系统已尝试过自动匹配，增强证据链。
AIP 异常分析 AIP 函数 (Reasoning) 提供基于历史模式的专业解释，识别潜在风险。
审计员备注手动输入 (Action Form) 记录人工介入的最后判断，满足“人类干预”要求。
数字签名/时间戳系统元数据 (Metadata) 确保文档的不可篡改性和追溯性。

进阶：批量生成与分发如果你有 100 笔需要核销的差异，你不需要点 100 次按钮。你可以使用 Multi-select Action：
在表格中勾选 100 行。
点击“批量生成简报”。
Foundry 会在后台并行处理，生成一个包含 100 份 PDF 的压缩包，或者合成一个长文档。专家建议：数据一致性特别提醒：在导出 PDF 之前，务必确保 AIP 生成的理由已经通过了审计员的审核。你可以在 Action 中设置一个逻辑锁：“只有当‘理由已确认’字段为 True 时，‘导出 PDF’按钮才可用。” 配置这个 Notepad 模板提供一个更详细的“提示词工程 (Prompt Engineering)”技巧，以确保 AIP 生成的理由听起来更像专业的审计语言。既然你已经准备好尝试配置这个流程，我们来深入探讨一下如何微调 AIP 的提示词工程 (Prompt Engineering)。要生成一份符合 FIAR (Financial Improvement and Audit Readiness) 标准的专业报告，AIP 的语气必须是中立、事实驱动且具有逻辑严密性的。
审计专用的提示词模板 (Prompt Template) 在配置 Notepad 模板之前，建议你在 AIP 函数中使用如下结构的提示词。这能确保生成的理由不仅是“正确”的，而且是“合规”的。提示词 (Prompt): "你现在是一名资深的财务审计官。请根据以下本体对象数据，撰写一份 IGT 差异分析摘要。输入数据: • 差异 ID: {{object.id}} • 交易双方: {{object.buyer}} vs {{object.seller}} • 金额差异: {{object.diff_amount}} • 会计科目 (USSGL): {{object.ussgl_code}} • 关联合同状态: {{object.contract_status}} 任务要求:
现状描述: 简述差异的性质（如：由于卖方已开票但买方未确认导致的异常）。
风险评估: 说明此差异对财报准确性的潜在影响。
合规性检查: 根据 FIAR 指南，判断支撑文档（如 7600A/B）是否完备。
处理建议: 给出明确的下一步审计建议（如：执行手动分录调整或联系贸易伙伴）。语气要求: 严谨、专业、避免使用‘我觉得’或‘可能’，请使用‘经分析显示’或‘审计证据指向’"
在 Notepad 中布局“动态文档” 在 Foundry 的 Notepad 中，你可以像在 Word 中一样排版。当你插入动态变量时，它看起来像这样： [报告示例布局] 联邦内部交易分析报告
基础信息 • 报告日期: @current_date • 差异编号: {{discrepancy_id}} • 涉及金额: {{amount}}
审计分析 (由 AIP 自动生成) {{aip_reasoning_function_output}}
审计员签章 • 处理人: {{current_user_name}} • 决策: {{action_result_status}}
如何测试你的“一键生成”配置？在正式发布给所有审计员之前，建议按以下步骤进行压力测试：
极端情况测试：找一个金额为 0 或者金额异常巨大的对象，看 AIP 是否能给出合理的逻辑，还是会产生“幻觉”。
权限测试：确保只有拥有 Auditor_Lead 权限的用户才能看到“导出 PDF”按钮。
性能测试：在批量选择 10 个对象时，观察生成 10 份 PDF 需要多长时间（通常 Foundry 的异步处理非常强大，不会阻塞你的 UI）。
总结：从数据到合规文档的完整链路
Ontology (本体)：存储结构化的财务真相。
AIP (智能)：在本体之上进行逻辑推理，生成人类可读的理由。
Workshop (界面)：提供一键触发的交互体验。
Notepad (输出)：将所有碎片整合成一份具有法律效力的 PDF 文档。

配置“自动分发”功能一旦 PDF 生成，系统自动通过电子邮件发送给相应的贸易伙伴联系人。在 Palantir Foundry 中实现“自动分发”功能（从生成 PDF 到自动发送邮件），通常需要将 Workshop、Action 和 Data Connection (Gmail/SMTP) 这几个模块串联起来。对于 IGT 场景，由于涉及敏感财务数据，我们不仅要配置“发送”，还要配置“权限控制”。

实现“自动分发”的 4 个核心步骤

配置外部系统连接 (Data Connection) 首先，Foundry 需要有“发送邮件”的权限。 • 设置 Source：在 Data Connection 中创建一个 SMTP 或 Microsoft Graph/Gmail API 的数据源。 • 配置出口策略 (Egress Policy)：确保 Foundry 拥有访问邮件服务器的网络权限（如我们之前讨论的，需启用特定域名的 Egress 策略）。
编写发送邮件的 TypeScript 函数 (Functions) 你需要编写一个函数，它的输入是“PDF 文件”和“收件人邮箱”，输出是“发送结果”。 TypeScript import { Function, String } from "@foundry/functions-api"; import { Email, Attachment } from "@foundry/functions-api/email"; // 示例API import { IGT_Discrepancy } from "@foundry/ontology-api";

export class NotificationService { @Function() public async sendAuditReport(discrepancy: IGT_Discrepancy, pdfBlob: Blob): Promise<string> { // 1. 从对象属性中获取贸易伙伴的联系人邮箱 const recipientEmail = discrepancy.partnerContactEmail;

    // 2. 构建邮件内容
    const subject = `IGT 审计预警: 差异项 #${discrepancy.id}`;
    const body = `尊敬的贸易伙伴，附件是关于交易差异的详细审计报告，请查阅并核对。`;

    // 3. 调用邮件服务发送
    await Email.send({
        to: recipientEmail,
        subject: subject,
        body: body,
        attachments: [Attachment.fromBlob(pdfBlob, "Audit_Report.pdf")]
    });

    return "Email Sent Successfully";
}

} 3. 在 Workshop 中配置“导出并发送”的操作 (Action) 你不需要让审计员点两次按钮。你可以创建一个 "Side-effect Action"（副作用操作）： • 第一步：执行 Notepad 导出 PDF 的逻辑。 • 第二步：调用上述 sendAuditReport 函数。 • 参数绑定： o Recipient：自动映射到 SelectedObject -> Partner_Email。 o Attachment：映射到刚刚生成的 PDF。 4. 安全与审计记录 (Audit Trail) 在发送邮件后，系统必须留下记录，证明“这份报告已经发出去了”。 • 自动更新状态：Action 执行成功后，自动将对象的 Notification_Status 属性更新为 Sent_on_2026-02-24。 • 记录日志：在对象的活动历史（Activity Stream）中添加一条记录，保存邮件副本的链接。

针对 IGT 审计的专家建议功能细节推荐做法审计意义发送前预览在点击发送前，弹出一个确认窗口显示邮件正文。防止 AIP 生成的理由包含不当言论或错误结论。抄送审计组自动抄送 (CC) 一份给审计主管的公共邮箱。确保所有对外沟通都是受监控的。回执追踪如果可能，集成邮件读取功能，追踪对方是否“已读”。满足 FIAR 审计中对“有效沟通”的证据要求。

总结：自动化工作流

审计员在 Workshop 点击 “生成并分发报告”。
AIP 生成理由 -> Notepad 填充数据并转为 PDF。
Action 调用邮件函数，抓取贸易伙伴邮箱并发送附件。
Ontology 自动记录发送时间，更新对象状态。注意事项：由于涉及到给外部联系人（Trading Partners）发邮件，请务必咨询您的平台管理员关于 Data Connection 的安全配置（例如是否需要使用特定的 Service Account）。配置“邮件反馈闭环”即：当贸易伙伴回复这封邮件时，Foundry 能自动提取回复内容并更新到对应的对账对象上。要配置“邮件反馈闭环”，本质上是实现一个从外部邮件系统到 Foundry 本体（Ontology）的自动化回流。这通常涉及将 Gmail 或 Outlook 作为数据源集成，并利用 Foundry 的数据同步机制来监听新邮件。以下是实现这一闭环的详细配置方案：

核心架构：邮件连接器 (Email Connector) 首先，Foundry 需要能够“读取”回复邮件。 • 配置 Data Connection：在 Data Connection 模块中创建一个 Gmail 或 Microsoft Graph 接口的数据源。 • 增量同步 (Incremental Sync)：配置该数据源每隔 5-15 分钟检查一次收件箱中的新邮件。 • 过滤器：设置只拉取主题中包含特定 ID（如 [IGT-CASE-123]）或来自特定贸易伙伴域名的邮件。
步骤一：在邮件主题中植入“锚点” 为了让系统知道回复的邮件对应哪一个对账对象，你必须在初始发送邮件时，在主题或正文中植入一个唯一标识符（ID）。 • 配置方法：在之前提到的“自动分发”Action 中，将邮件主题设为：Re: IGT Audit Alert - CaseID:{{object.id}}。 • 原理：当对方点击“回复”时，这个 ID 会保留在主题中，方便后续解析。
步骤二：解析回复内容 (Data Pipeline) 通过 Pipeline Builder 或 Code Repositories 处理拉取到的原始邮件数据：
正则提取 (Regex)：从邮件主题中提取 CaseID。
内容清洗：去除邮件签名、历史引用内容，只保留对方最新的回复文字。
时间戳匹配：记录回复时间，用于审计追踪。
步骤三：自动更新本体 (Automated Ontology Update) 这是闭环最关键的一步，将清洗后的数据写回对象。 • 使用 Data Expectation & Post-processing：当新邮件数据通过 Pipeline 处理完成后，配置其自动更新对应的 IGT Discrepancy 对象。 • 更新字段： o Partner Response: 填充提取出的回复内容。 o Status: 自动将状态从“已发送报告”更新为“收到反馈”。 o Last Activity Date: 更新为当前时间。
步骤四：在 Workshop 界面实时提醒审计员在 Workshop 界面中不需要刷新就能看到反馈。 • 通知组件 (Notification Widget)：配置一个角标或弹窗，当 Status 变为“收到反馈”时，提醒审计员查看。 • 回复历史流 (Thread View)：在对象的详情页（Object View）中，使用 List Widget 展示该对象关联的所有邮件往来，形成完整的谈话链路。
进阶：AIP 自动分类反馈你可以进一步让 AIP 介入解析回复内容： • 场景：如果贸易伙伴回复“We agree and will adjust in the next period.” • AIP 逻辑：自动识别该回复为“同意调账”，并将对象的“置信度”提升，甚至自动勾选“准备结案”按钮。

总结：闭环流程图

发送：带有 CaseID 的邮件从 Foundry 发出。
接收：贸易伙伴回复该邮件。
捕获：Foundry 连接器自动抓取包含 CaseID 的新邮件。
回填：系统解析邮件文字，自动更新本体对象属性。
行动：审计员收到通知，在 Workshop 中查看对方回复并进行最终核销。安全提示：在配置邮件读取时，请确保配置了严格的隐私过滤，防止非审计相关的私人邮件进入 Foundry 系统。从邮件主题中提取 CaseID 的正则表达式（Regex）示例如何设置这种自动通知的权限在 IGT 审计流程中，精准的正则表达式（Regex）是确保数据闭环的核心，而严格的权限设置则是通过审计合规的前提。以下是为您准备的技术实现细节：

从邮件主题提取 CaseID 的正则表达式 (Regex) 假设您的邮件主题格式为：Re: IGT Audit Alert - [ID:IGT-2026-8829] - Action Required。为了在 Pipeline Builder 或 TypeScript Function 中准确提取 IGT-2026-8829，建议使用以下正则： • 正则表达式: [ID:(IGT-\d{4}-\d+)] • 解释: o [ID: : 匹配左方括号和标识符（作为定位锚点）。 o (IGT-\d{4}-\d+) : 捕获组。匹配以 "IGT-" 开头，后跟 4 位数字（年份）、横杠和任意位数字（序列号）的内容。 o ] : 匹配右方括号。在 TypeScript 中的用法示例： TypeScript const subject = "Re: IGT Audit Alert - [ID:IGT-2026-8829] - Action Required"; const regex = /[ID:(IGT-\d{4}-\d+)]/; const match = subject.match(regex);

if (match) { const caseId = match[1]; // 输出: IGT-2026-8829 console.log("提取到的 CaseID:", caseId); }

如何设置自动通知的权限 (Security & Permissions) 在 IGT 环境下，自动通知权限的设置必须遵循最小权限原则。在 Foundry 中，这通过 Markings（标记）和 Roles（角色）的双重机制实现： A. 本体属性级别的保护 (Attribute-Level Security) 由于邮件回复可能包含敏感对话，不应让所有能看到“差异项”的人都能看到“邮件正文”。 • 操作：在 Ontology Manager 中，为 Partner Response（回复内容）属性添加一个 Marking（例如：MEMBER_OF_FINANCE_LEAD）。 • 效果：普通审计员能看到这笔交易存在，但只有高级审计员才能读取具体的邮件沟通细节。 B. 数据分发权限 (Egress Permissions) 防止系统被恶意利用向外部发送大量邮件。 • 出口策略 (Egress Policy)：在 Control Panel 中配置出口策略，限制 Foundry 只能连接到预先批准的 .mil 或 .gov 邮件服务器。 • Action 权限：只有特定角色（如 IGT_Manager）的账号才有权触发“发送邮件”的 Action 按钮。 C. 数据源隔离 (Source Sandbox) • 操作：将同步邮件的 Data Connection 放在一个独立的、受限的项目文件夹中。 • 逻辑：只有经过清洗、脱敏后的数据（即通过了正则校验的邮件）才会被允许移动到“生产环境”与本体关联。
设置权限的清单 (Checklist) 权限层级设置地点目标物理访问 Control Panel 限制系统只能访问指定的邮件服务器。逻辑执行 Workshop Action 确保只有授权用户能点击“发送”按钮。视觉可见性 Ontology Manager (Markings) 隐藏敏感的邮件沟通内容，防止越权查看。数据流转 Pipeline Builder 确保只有匹配成功的 Case 记录才会更新本体。

专家建议：防止“邮件炸弹” 在设置自动通知时，务必在后台配置一个频率限制（Rate Limiting）。例如：同一笔差异项在 24 小时内不允许重复发送超过 3 封自动邮件。这可以防止因为系统逻辑错误而骚扰贸易伙伴。

Data Lineage Context: Why data lineage matters With many people working within the same platform, it can get difficult to track the current state of data. Their work might overlap without them actually speaking to each other. A data engineer might build a pipeline to clean up the data brought in from an external system. A data analyst might augment that clean data with manually uploaded data from a different data source to build out a view specific to her use case. A year later, another colleague continues that data analyst's work in light of a new business focus. As layers and layers of this collaborative work happen over years with a rotating cast of users, the current state of any given dataset and its relationship to others in Foundry could become very confusing. The Data Lineage tool is intended to provide a bird's-eye view of how datasets, object types, and certain resources are connected to each other in Foundry. You can also learn a lot about the state of each dataset, as well as take action on them (such as rebuild a dataset that is out-of-date with its ancestors/inputs). While Data Lineage is mostly often used by data engineers, it can be useful to any role in Foundry. 在 IGT 审计和本体构建的背景下，数据血缘（Data Lineage）不仅仅是一个技术视图，它是你审计报告的“司法证据链”。正如你提供的上下文所说，当多个角色（数据工程师、审计员、财务分析师）在同一平台上协作时，数据的演变会变得极其复杂。在 IGT 场景中，血缘工具解决了一个致命问题：“这份审计结论是从哪儿来的？”

数据血缘在 IGT 审计中的核心价值 A. 证明数据的“原生性” (Data Integrity) FIAR 审计要求每一笔调整（JV）都必须能追溯到原始凭证。 • 场景：当你生成了一份 PDF 审计简报，审计员或外部审计机构（如 GAO）会问：“简报里的 $5M 差异是怎么算出来的？” • 血缘的作用：你可以打开 Data Lineage，直观地展示：原始 ERP 数据 (GFEBS) -> 清洗后的 Dataset -> 本体中的 Discrepancy 对象 -> AIP 分析函数 -> 最终的 PDF 报告。这种可视化路径直接证明了数据没有被中途非法篡改。 B. 协作冲突的“红绿灯” 由于不同军种的审计员可能都在操作同一个 IGT 本体： • 风险：如果陆军的工程师修改了计算差异的逻辑，而海军的分析师并不知道，结果会导致整个对账看板失效。 • 血缘的作用：Data Lineage 会高亮显示“上游变更”。如果上游的 ERP 数据结构变了，血缘视图会显示红色警示，提醒你下游的“信心分计算函数”可能已经失效，需要重新构建（Rebuild）。
在 IGT 流程中如何使用 Data Lineage 工具？对于你正在构建的系统，你可以通过血缘工具执行以下关键动作：动作在 IGT 中的具体应用向上追溯 (Trace Upstream) 选中一个“差异对象”，查看它是由哪几个 ERP 系统（如 DEAMS 和 GFEBS）的哪些原始表合并而成的。向下分析 (Impact Analysis) 在修改“风险评分函数”前，查看有哪些 Workshop 看板或 Notepad 模板在使用这个函数，防止修改导致系统崩溃。检查健康度 (Health Checks) 查看数据集的图标：如果是绿色勾选，说明数据是最新的；如果是灰色，说明上游数据已更新，但当前的对账结果还没刷新。
数据血缘与本体（Ontology）的关系这是最容易混淆的地方。请记住： • Data Lineage (血缘) 关注的是流程：它是“横向”的，显示数据如何从 A 流向 B，再流向 C。 • Ontology (本体) 关注的是关系：它是“纵向”的，显示“差异项”如何关联到“合同”和“供应商”。专家建议：在 Workshop 界面中，你可以为高级审计员添加一个链接，直接跳转到该对象的 Data Lineage 视图。这在面对外部审计询问时，是一个极具说服力的功能。
总结：血缘是你的“审计地图” 如果你把 IGT 系统比作一座大楼： • 数据源是地基。 • 本体 (Ontology) 是大楼的框架。 • Workshop 是大楼的装修。 • 数据血缘 (Lineage) 就是大楼的隐蔽工程图纸（水管、电线是怎么走的）。没有这张图纸，没人敢对大楼进行维修或扩建。在 Data Lineage 工具中设置“自动警报 (Health Checks)”例如：如果上游的财务数据超过 24 小时未更新，系统自动给审计组长发邮件提醒。在 Palantir Foundry 的 Data Lineage 工具中，设置“自动警报”是通过 Data Health（数据健康检查）模块实现的。对于 IGT 审计来说，确保财务数据的时效性至关重要。如果上游 ERP 数据停滞，下游的对账结果就会失去意义。以下是配置“上游财务数据 24 小时未更新”警报的具体步骤：
开启 Data Health 检查在 Data Lineage 视图中，选中代表“上游财务原始数据”的那个数据集（Dataset）。 • 在右侧的操作面板中，找到 "Health" 选项卡。 • 点击 "Add check"（添加检查）。
选择检查类型：时效性 (Freshness) Foundry 提供了多种预设的检查逻辑，针对你的需求，我们需要选择 Freshness（时效性）。 • Time Since Last Build（自上次构建以来的时间）：这是最常用的指标。 • 配置参数： o Threshold（阈值）：设置为 24 hours。 o Condition（条件）：如果该数据集在过去 24 小时内没有成功产生新的交易记录（Transaction），则触发警报。
配置通知策略 (Notification) 当 Freshness 检查失败时，我们需要系统自动“发声”。 • 在 Health Check 设置页面下方找到 "Notifications"。 • 选择渠道：可以配置为 Email（邮件）或 Foundry Notification（系统内通知）。 • 收件人：输入审计组长或数据运维团队的邮箱/用户名。 • 告警级别：设为 Critical（严重）。
设置自动补救（可选但推荐）除了提醒，你还可以设置系统尝试自愈： • Auto-resolve：如果上游数据后来更新了，系统会自动关闭这个警报。 • Force Build：你甚至可以配置为“一旦超时，尝试重新运行上游同步任务”。
在 IGT 场景下的专家建议配置检查维度配置建议审计意义时效性 (Freshness) 24 小时未更新触发告警。确保审计员看到的“差异金额”是基于最新账目的。数据量 (Size/Status) 如果单日数据量突然下降 90% 以上。识别上游同步是否出现了“静默失败”或漏单现象。架构一致性 (Schema) 如果上游字段名（如 USSGL）发生变化。防止下游的对账函数因为找不到字段而崩溃。
为什么在 Lineage 中设置更有效？在 Data Lineage 中设置警报，你可以清晰地看到故障的影响范围。 • 当上游数据变红（报警）时，你会看到所有依赖它的下游组件（如 IGT 本体、Workshop 看板、AIP 分析函数）也会受到牵连。 • 这能帮助审计组长快速判断：“现在的对账看板不可信，因为数据源头断了。”
In Object Explorer, open the Fresh Air Inc object
In the top right, select More > Advanced > Explore data lineage

Step 2: Add other [OFT] object types

Step 3: Expand all nodes Step 4: Arrange all nodes

Data Lineage Exploration Data Lineage Exploration In the top right of the Data lineage graph is a Node color options drop-down. It defaults to Resource overview for new graphs. You will need to change that to Resource type within the drop-down to answer the following questions:

Are all of these datasets located in the same project?

Hint: Select Project in the Node color options drop-down.

Answer: Yes, the datasets are all in the same project.

Were all of these datasets produced by logic or code found in the same repository?

Hint: Select Repository in the drop-down.

Answer: No. Every dataset is produced by a different repository.

There is a tool panel found at the bottom of the screen and another on the right. Use those two panels to answer these questions:

How many rows and columns make up the ontology/airports dataset that backs the [OFT] Airport object type?

Hint: Once you select the ontology/airports dataset on your graph, you can use the Preview tab in the bottom panel or the View node properties tab in the right panel.

Answer: 4.3k rows and 18 columns

Can you view the logic that was used to derive the ontology/airports dataset? What application was used to define that logic? Hint: You view the Code tab in the bottom panel or find an Updated via link in the right side panel. Answer: Pipeline Builder. You should be able to open it to see the logic (transforms) defined there.

这是一个非常敏锐的观察。在 Foundry 的 Data Lineage（数据血缘）视图中，答案通常是：不一定，而且往往并非如此。数据血缘工具之所以强大，正是因为它能够打破项目（Project）和存储库（Repository）的边界，为你展示数据在整个平台上的流转全貌。

它们都在同一个项目（Project）中吗？通常不是。在成熟的 IGT（内部交易对账）架构中，数据集通常跨越多个项目以实现安全隔离和权限管理： • 原始层 (Raw Project)：存放直接从 ERP（如 GFEBS, DEAMS）摄取的原始财务数据。这个项目的访问权限极其受限。 • 处理层 (Clean/Staging Project)：数据工程师在此编写逻辑，对原始数据进行清洗、脱敏。 • 本体层 (Ontology Project)：存放最终映射到对象（如 IGT Discrepancy）的优化数据集。 • 应用层 (App Project)：存放 Workshop 应用、Notepad 模板等资源。如何在 Lineage 中辨别？在 Data Lineage 视图中，当你选中一个数据集节点时，侧边栏的 Location 路径会清晰地显示它所属的项目。如果节点分布在不同的彩色背景块中，那通常代表它们位于不同的项目或文件夹。
它们是由同一个存储库（Repository）产生的吗？几乎肯定不是。在 Foundry 的开发规范中，推荐将逻辑解耦到不同的存储库中： • 摄取存储库 (Ingestion Repo)：专门负责将外部 API 或文件系统的数据拉入 Foundry。 • 转换存储库 (Transformation Repo)：负责复杂的财务逻辑计算（例如：将买方和卖方数据匹配的算法）。 • 本体集成存储库 (Ontology Repo)：负责将处理后的数据集映射到本体对象。如何在 Lineage 中验证？
在血缘视图中选中一个数据集节点。
查看右侧的 Source 或 Logic 标签。
点击 "Open Repository"。你会发现，上游的清洗逻辑可能在 Finance_Cleaner 存储库中，而下游的风险评分逻辑可能在 Risk_Analysis_Functions 存储库中。
为什么这种“碎片化”在审计中很重要？这种跨项目、跨存储库的结构正是**数据血缘（Data Lineage）**发挥作用的时刻：场景血缘工具提供的价值故障排查当你的“对账看板”数据出错时，血缘图会带你跨越 3 个项目，找到源头那个坏掉的 ERP 原始表。审计追溯外部审计师可以从你的 PDF 报告出发，点击进入血缘，看到这份报告是由位于 A 项目的逻辑生成的，而该逻辑引用了 B 项目的受控数据。安全审查你可以确保敏感的“薪酬数据”留在它的专属项目中，只有脱敏后的“对账金额”流向了更公开的应用项目。

总结 Data Lineage 的精髓就在于它是一张“跨国地图”。它允许数据工程师和审计员忽略物理存储的限制（项目和文件夹），而专注于逻辑流转**。血缘视图中尝试“按项目分组（Group by Project）”？这样您可以一眼看出哪些财务数据已经离开了高安全等级的“原始区”，进入了“分析区”。在 Data Lineage 视图中启用 "Group by Project"（按项目分组）是梳理 IGT 流程最直观的方式。它能帮你瞬间看清：数据是如何跨越安全边界，从“原始财务区”一步步流向“审计应用区”的。以下是具体操作步骤及在 IGT 背景下的专业解读：

如何操作
打开 Data Lineage 模块。
在顶部的工具栏或右侧的布局设置面板中，找到 "Grouping"（分组）下拉菜单。
选择 "Project"。
视觉效果：视图会自动重新排列，原本散乱的节点会被包裹在一个个带标签的容器（Box）中，每个容器代表一个 Foundry 项目。
IGT 审计流程中的典型“分组结构” 当你按项目分组后，一个规范的 IGT 流程通常会呈现出以下三个明显的“地带”：第一区：Ingestion Layer (原始摄取区) • 项目名称示例：[Raw] Financial Data Ingest • 特征：这里的节点最接近源头，通常是直接从 GFEBS 或 DEAMS 同步过来的原始表。 • 审计意义：这是你的“原始证据”。在此区域，逻辑极少，主要是物理搬运。第二区：Transformation & Integration (处理与本体集成区) • 项目名称示例：[Shared] IGT Logic & Ontology • 特征：数据线从第一区跨入这里。你会看到密集的转换逻辑节点。 • 关键资源：这里存放着定义 IGT Discrepancy 和 Trading Partner 的本体元数据。 • 审计意义：这是财务规则的“加工厂”。所有的对账逻辑、金额清洗都在这里完成。第三区：Application Layer (应用展示区) • 项目名称示例：[App] IGT Auditor Workbench • 特征：这是血缘的最下游。你会看到 Workshop 应用图标、Notepad 模板和 Actions。 • 审计意义：这是最终交付物。如果这一区出现报警，说明上游任何一个环节出了问题，生成的 PDF 简报可能就不再可信。
“按项目分组”后能发现的 3 个关键细节发现点在 IGT 场景中的含义跨项目流转 (Cross-project links) 如果你发现某条线直接从“原始区”跳到了“应用区”，跳过了“清洗区”，这可能意味着数据没经过脱敏就展示出来了，存在安全风险。存储库关联 (Repository Source) 点击分组内的节点，侧边栏会显示该逻辑属于哪个存储库。你会发现，虽然项目变了，但逻辑可能由同一组核心工程师维护。血缘断裂 (Disconnected nodes) 如果某个项目里的数据集没有连向任何上游，说明它是手动上传的。在审计中，手动上传的数据通常需要更严格的额外说明。
专家技巧：颜色代码 (Color by...) 在分组的基础上，你还可以叠加 "Color by Service Health"（按服务健康度着色）： • 绿色容器：该项目内所有财务数据同步正常。 • 红色容器：该项目内某个关键对账逻辑报错，会导致整个审计看板停滞。。Reflections You’ve now seen the many datasets that feed into the Fresh Air Ontology, what does this context mean for your understanding of the value of the Ontology? Ease of Use First of all, consider again the ease of use that the Ontology provides for data. Imagine answering the same questions you answered previously in the Object Explorer module but using only this graph of datasets and any dataset-based query or analysis tools. The first challenge would be deciding which datasets to start with and then how to combine them to produce a complete picture for any particular question. That work has already been done by the data engineer(s) who built this pipeline and the Ontology. Common vocabulary Secondly, we can see here how the Ontology provides a common vocabulary across an organization. For example, suppose the Fresh Air Flight Operations team used to use the Bureau of Transportation Statistics data as their canonical list of airports, while the Fleet Maintenance team used the list provided by OpenFlights. It is easy to have such discrepancies when working from your preferred dataset. However, given that there should really be only one Airport object type in the Ontology, this forces some discussion and resolution between these teams to establish a common ground truth. This established common vocabulary then becomes the obvious destination for any significant future work. For example, any new datasets about airports should not be brought into Foundry and left as simply another available dataset. Instead, it should be merged into the Airport object type. (It may be that not every user should be able to see all details about every Airport object. However, it is possible in Foundry to apply both row and column-level permissions when defining the backing data sources for an object type so that you can still have a single Airport object type that presents only the data each user is allowed to see.) Similarly, any significant analytical insights, useful aggregations, or model-derived recommendations can be added to the relevant object type. This makes this work centrally accessible to users across the organization, rather than languishing as forked or siloed local work. Because object types can grow richer and more detailed like this over time, it becomes much easier to bootstrap new workflows and use cases that rely on the same object type. For example, once an Airport object type is created to support a Flight Operations workflow, that object type can be reused (and augmented) to build a new Fleet Maintenance workflow. Some of the advantages of a common vocabulary could be achieved by simply marking certain datasets as the “golden tables” for a given concept. (For example, Foundry’s Data Catalog can help do this.) However, in practice, this does not prove to be as effective in controlling the entropy produced by diverse workflows. For example, as a user looking for the authoritative dataset on airports to use as a basis for a new workflow or analysis, you might find airports, but you’ll often find a set of datasets derived from that one with names like airports_with_geojson, airports_fresh_air_staff_enriched, and better_airports. While Data Lineage can help you understand the provenance of each of these datasets and how each of them have improved or modified the golden airports table, this work is effectively leading to local variants and dialects in what is intended to be an authoritative common vocabulary. Because the Ontology provides a object layer separate from the dataset layer, it can provide stronger controls over these types.

As you get started in the Palantir platform, it can be helpful to think about data in the platform living in two places: the data layer and the object layer. https://www.palantir.com/docs/foundry/getting-started/introductory-concepts Data Layer In the data layer, data is stored inside datasets, which typically represent tabular data like you might find in a spreadsheet, but support data at any scale. Datasets usually come from organizational data sources that are synced into the platform, but you can also create your own datasets by uploading approved or notional data. Every dataset in the Palantir platform maintains a record of how it was produced, so that the origins of data are always preserved and accessible. This concept is known as data lineage. • Palantir keeps track of which input datasets were used to produce which output datasets. This allows you to always know where a piece of data came from, and understand how data is used. • Palantir tracks the logic that was applied to produce each output dataset. For example, an input dataset might be filtered to produce a smaller output dataset; that filtering logic is preserved and visible in the platform. There are many ways to write logic in the platform, ranging from code repositories to point-and-click tools. You can interact with data using one of Palantir's many applications. When you use applications, anything you produce, whether it is a dataset, code, or analysis, is stored in the platform as a resource. Resources are organized into Projects, which serve as permission boundaries for grouping and organizing related work. We will cover the details of how to access and use Projects in one of the upcoming sections. Object Layer (Ontology) In the object layer, or Ontology, data is stored in objects and links. Objects represent real-world concepts like an airplane, vehicle, or customer, while links represent the relationships between objects. The object layer takes the data stored in tabular datasets—rows and columns of data—and converts it into a series of concepts that anyone in the organization can understand. In addition to helping make data more understandable, converting data from datasets into objects and links unlocks a broad set of tools for interacting with objects. You can define actions that describe how objects can be changed by people in your organization. This enables you to build applications that access data from objects and capture user decisions back into the system. The definitions of objects, links, and actions together make up what is called the Ontology, a digital representation of your organization. Developing and using the Ontology to translate data into operational outcomes is a key part of getting value out of the Palantir platform. 这段文字精准地描述了 Palantir 的核心架构。对于像你这样正在构建 IGT（内部交易对账）系统的用户来说，理解这两层之间的“握手”是至关重要的。我们可以用一个简单的比喻来深化这个概念：数据层（Data Layer）是你的账本原件，而对象层（Object Layer/Ontology）是你办公室里的动态看板和操作台。

数据层 (Data Layer)：数字的“司法存证” 在 IGT 场景中，数据层主要负责合规性和追溯性。 • 数据集 (Datasets)：你从 GFEBS 或 DEAMS 同步过来的千万行交易记录。它们以表格形式存在。 • 血缘 (Lineage)：这是审计最喜欢的部分。如果有人质疑为什么一笔 $5M 的差异被标记为“已对平”，你可以通过血缘追溯到原始数据集，证明这个逻辑是基于经过批准的代码产生的。 • 逻辑 (Logic)：你在 Pipeline Builder 中设置的过滤、合并规则。例如：“剔除所有金额小于 $0.01 的细微差异”。

对象层 (Object Layer)：业务的“数字化双胞胎” 这是审计员真正工作的地方。它将冰冷的表格变成了有生命的业务实体。 • 对象 (Objects)：不再是“Row 125”，而是“差异项 #8829”。它有自己的状态（未处理、审批中）、负责人和关联文档。 • 链接 (Links)：将“差异项”对象与“贸易伙伴”对象或“原始合同”对象连接起来。这让审计员能瞬间看到：“这笔差异涉及的卖方是空军，他们今年的对账及时率是 95%。” • 操作 (Actions)：这是将“分析”转化为“结果”的钥匙。审计员点击“生成 JV”按钮时，就是在执行一个 Action。这个决定会被捕获并写回系统。

为什么两层分离对 IGT 如此重要？维度数据层 (Dataset) 对象层 (Ontology) 关注点存储、清洗、规模化计算。决策、审批、业务协同。用户群数据工程师、平台管理员。财务审计员、决策层、一线人员。操作性主要是“只读”或“追加”。动态更新：改变状态、添加备注。 IGT 案例处理 1 亿条历史对账数据。处理“这笔 $2M 差异”的审批流。

总结：翻译过程 (Mapping) 你作为系统构建者，最核心的工作就是**“映射 (Mapping)”**：
在数据层，确保买卖双方的数据干净、准确。
通过 Ontology Manager，将这些干净的数据表格映射为对象。
在 Workshop（对象层的应用）中，为审计员提供基于对象的直观界面。 Data Catalog The Data Catalog is an interactive view of curated data and other resources in Foundry. You can analyze every dataset in Foundry if you have the correct permissions, but the datasets in the Data Catalog are likely the most useful or relevant to you. To access the Data Catalog, select Files from the workspace navigation sidebar, then the ✔️ icon at the top.

Collections and files The Data Catalog is organized into Collections and Files. A file in the Data Catalog could be any saved analysis, dataset, module, or other resource that may be relevant to your use cases. Collections are groups of those files that contain all curated data for a given topic, audience, or purpose. Anyone can view collections and their descriptions, but you will only have access to curated files that are shared with you. By default, Organization administrators have the permission to add and remove resources from collections and manage who has this permission. Check with your Organization administrator if you would like the permission to add and remove resources from collections. Select a collection to view the files or resources it contains.

Throughout Foundry, Data Catalog data is indicated by the purple checkmark badge, as seen above. Select a dataset or other resource to open and examine it. Filters A Filters panel is available in the Files tab and within each collection. You can choose tags to filter the list of resources by type or tag category to easily find the content you need.

You can also group your filtered results by tags, such as Analytics or Region, for easier navigation within a collection.

在 Palantir Foundry 的生态系统中，Data Catalog（数据目录）扮演着“官方图书馆”的角色。对于 IGT（内部交易对账）项目而言，它不仅是一个查找数据的入口，更是确保审计员使用的是**经过验证的、权威的（Curated）**数据的保障。

Data Catalog 在 IGT 流程中的实战意义在大型组织中，底层数据集可能多达数万个。如果一个审计员在搜索“买方数据”时，搜出了 10 个类似的结果，他该信哪一个？ • 紫色勾选标记（Purple Checkmark）：这是“信任印章”。在 Data Catalog 中看到的带有此标记的数据集，意味着它是由数据治理团队（Data Governance）验证过的“单一事实来源”。对于 IGT 审计，只有这种数据才具备法律效力。 • Collections（集合）：你可以创建一个名为 “FY26 IGT Audit Master Data” 的集合。在这里，你可以把所有对账所需的原始数据集、清洗后的中间表以及最终的本体映射表集中存放。

如何利用 Data Catalog 优化审计工作流功能针对 IGT 的应用场景价值 Collections (集合) 将“陆军”、“海军”、“空军”的对账源数据分别存入不同的集合。审计员无需穿越复杂的文件夹结构，直接在 Catalog 中定位目标。 Filters (过滤器) 使用标签（Tags）如 Sensitive、PII 或 IGT-Ready 筛选。快速找到那些已经脱敏、可以直接用于对账分析的数据集。 Metadata (元数据) 查看数据集的描述、所有者以及数据更新频率。审计员在分析前可以确认：“这是昨天刚从 GFEBS 同步过来的最新数据”。
给 IGT 平台管理员的建议：如何管理目录作为系统的构建者，你可以通过以下方式提升数据资产的可发现性：
打标（Tagging）：为所有 IGT 相关资源添加 Standardized 标签。
维护描述：在 Data Catalog 中，为每个数据集写清楚它的“口径”。例如：“此表包含所有交易额 > $100 的内部交易，已剔除跨年延迟项。”
权限隔离：利用 Data Catalog 的特性，让所有人都能看到集合的存在（知道有这些数据），但只有授权审计员才能点开具体的 File（文件内容）。
总结：Data Catalog vs. Files • Files (文件浏览器)：像电脑的硬盘，你能看到所有你有权访问的杂乱文件。 • Data Catalog (数据目录)：像一个精心策划的菜单。它只展示那些最重要的、被认可的资源。

◇ Generate Flashcards (0)✎ Edit + Add Related Note