Palantir Ontology 比語意層多了什麼？

This article is also available in English: What Does Palantir’s Ontology Add Beyond a Semantic Layer?

如果你每天用的是 dbt 的 Semantic Layer、LookML 或 Snowflake 的 semantic view，看到 Palantir 的 Ontology，大概會先問：這不就是語意層換個名字？

Palantir 自己的文件用一句話回答了。arch-ontology-system 頁寫著 The Ontology is not a “semantic layer”。理由是資料、邏輯、動作、安全四項的整合與落地執行，薄薄的 semantic layer 或單一巨石式設計做不到。

同一家公司的 2025 財年 10-K 另說，一般意義的 ontology 通常指 “the systematic mapping of data to meaningful context”。自家版本遠遠超過這個範圍，把決策裡的 data、logic、actions 整合進一個對組織的基礎表述。

兩句話擺在一起，留下一個問題：超過的部分是什麼？

下面沿著一條線看：資料怎麼變成物件，物件怎麼被一次送出的動作修改，誰有權限動它，動完之後查得到什麼。文中引述的機制來自 Palantir 文件，不是本文的實測。

資料先變成物件，決策才有東西可改

ontology-overview 頁的定義句是：

The Palantir Ontology is an operational layer for the organization.

它坐在已經接進 Palantir 平台的 datasets、virtual tables、models 之上，把這些資產連到現實世界裡對應的東西。這些東西有工廠、設備、產品這類實體資產，也有客戶訂單、財務交易這類概念。文件說，在許多情境下，它是組織的「數位分身」。

why-ontology 頁把重點說得更直接：

The Ontology represents the decisions in an enterprise, not simply the data.

它的論述是，傳統資料架構不記錄決策背後的推理，也不記錄推理之後採取的行動；一般的分析架構則脫離真實運作。所以建模的單位是「決策」，不只是資料。

同一頁把每個營運決策拆成四個成分：

• Data：做這個決策所用的資訊。
• Logic：評估這個決策的邏輯與計算過程。
• Action：被選定的決策怎麼被協調與執行。
• Security：確保這個決策符合營運政策。

資料與邏輯這一側，core-concepts 頁給了每個概念一句定義：

• object type：現實世界一個實體或事件的 schema 定義。一個物件是一個實例，一組物件叫 object set。
• property：物件類型某個特徵的 schema 定義。
• link type：兩個物件類型之間關係的 schema 定義。
• interface：描述物件類型的形狀與能力，讓不同物件類型能用同一種方式互動。
• function：吃輸入、回輸出的程式邏輯，可接收物件與 object set 作為輸入，供 action type 與應用程式使用。

物件怎麼出現？文件說，靠在 Ontology Manager 替物件類型加上資料源（backing datasource）。要建出 Employee 這種物件，得先把員工目錄與其他企業資料接進那個物件類型。資料倉儲裡的單位是表與欄位，這裡的單位是物件、屬性與關聯。

動作與權限：一次送出要過哪些條件，誰看得到什麼

決策做出來，要有人動手。core-concepts 頁把 action type 定義為使用者一次可以對物件、屬性值、關聯做的一組變更或編輯的 schema 定義，也包含送出時觸發的副作用。action-rules 頁列出 rules 能做的五類事：建立物件、修改物件、刪除物件、建立多對多關聯、刪除關聯。規則不夠用時，action type 可以改呼叫一段 function，定義更複雜的修改。

能不能送出，取決於 submission criteria。文件說這些條件 “determine whether an action can be submitted”，舊名叫 validations。它讓業務邏輯可以編進資料編輯的權限裡，用來確保 Ontology 的資料品質與編輯治理。

送出之後，side effects 讓資料送出 Foundry，對接既有的組織流程。文件把這種模式稱為 “decision orchestration”。其中一種是 webhook，對 Salesforce、SAP 或任何設定過的 HTTP 伺服器送出請求，通常是為了改那邊的資料。外部那一側的成敗怎麼處理，下一篇專門談。

誰看得到，是另一套規則。ontology-permissions 頁寫道，要看到一個物件，需要物件類型上的 View 權限，以及對底層資料的存取權，兩樣要同時有。原文是 “you must hold View permissions on the object type and access to the data”。

• 物件的安全策略可以直接設在物件類型上，獨立於資料源。restricted views 把資料列層級的存取控制，套到由那些資料列建出的物件上。
• property 層級靠 markings：Foundry 逐一核對每個屬性值掛的 security markings。
• markings 是全有全無。使用者必須是資源上所有 markings 的成員才能存取。從被標記的檔案、資料夾或 Project 衍生的資源，會繼承同一個標記，除非被明確移除。
• 刪除物件也受限：看不到物件的完整內容（所有屬性），就不能刪它。
• Roles 是 Ontology 裡的中央權限模型，可以設在整個 Ontology，也可以設在單一資源。

人與 AI agent 適用同一套規則。文件說，人類或 agent 的每個操作，都要遵守嚴格的 role、marking、purpose 控制。工具呼叫則依賴對底層物件、屬性、關聯的存取權。

那 AI 觸發的 action 呢？why-ontology 頁用虛構公司 Onyx 做範例：Onyx 讓幾個 AI agent 使用一小組 action。在這個範例的預設情況下，像更改工單狀態、推送調度計畫這類 action，AI 只能先「暫存」（staged），交給人做最終審查。範例接著寫，Onyx 可以審慎選擇，讓受信任、經過充分測試的 AI 流程不經人審，自動關閉這個動作循環。

這是一個虛構示例的設定，不是所有入口的規則。

所以動作和權限要放在一起看：條件決定一次送出能不能成立，權限決定誰看得到、動得到哪個物件。

執行之後，能回頭查到哪幾種紀錄

編輯去哪了。 使用者經 action 做的編輯，不會寫回物件類型背後的 backing dataset。文件說，這讓使用者在分析時，原始資料與編輯後的資料都拿得到。編輯的去向，下一篇細談。

action log。 action type 可以設定 action log。設定後，每次成功送出會多一筆紀錄，記下送出者的 Multipass 使用者 ID、時間戳，以及被改動物件的主鍵。文件說，這個 log 要回答的是 “what changed, by whom, and when?”

有三個邊界要記得：

• 被改動物件除了主鍵，其他屬性值不在支援範圍。所以它能告訴你哪些物件被動過，不能直接給你每個欄位的改前改後。
• function 驅動的 action 要進 action log，背後的 Ontology edit function 還得額外設定 edits provenance。
• 想看單一物件的完整編輯歷史，要靠另一項功能。它不追溯開啟前的變更，下一篇會談。

decision lineage。 why-ontology 頁在 Data 這一項的說明裡講到 “decision lineage”：一個決策是什麼時候做的、依據哪個版本的企業資料、透過哪個應用程式，都會被自動記錄。文件說，這條紀錄對人類開發者與 AI agent 都能安全存取。這是 Palantir 描述的目標。落到平台上，有幾種工具各答一個問題：

• Data Lineage 是互動式工具，讓人看到資料怎麼在整個 Foundry 平台裡流動。
• 平台的 audit logs，文件描述為 Foundry 裡每個動作的完整紀錄，給安全團隊偵測威脅、調查事件、確認合規。
• action log 看某個 action type 的送出。

三者回答的問題不同。合起來能不能還原一個決策的完整歷程，要看各自有沒有開、記了哪些欄位。所以「可追溯」這個詞，要先問清楚：追的是哪一種紀錄？

判讀：Palantir 說差別在整合

權限、稽核、語意模型，各有現成的產品類別。單一功能在別處也找得到，下一篇會提到，Looker 的 Action Hub 就有寫回外部系統的功能。

回到開頭那兩句話。10-K 說 Palantir 的版本遠遠超過一般意義，architecture 頁說 semantic layer 做不到四項的整合。照本文的讀法，「超過」的部分是 Action、Security 和 decision lineage 這幾塊，加上把它們接在同一個模型上的整合。這個讀法的依據是兩份 Palantir 文件，不是說別的產品做不到。

下次讀到 Palantir 或別家的「整合」主張，可以問三件事：這個決策要接的資料和邏輯，在哪裡定義？誰能送出，送出的條件是什麼？事後能查到哪一種紀錄？

本系列下一篇看動作這一塊：Palantir Action：送出成功，哪些東西改好了？。

常見問題

Palantir 的 Ontology 是資料庫嗎？

Palantir 文件給的定義是組織的 operational layer：它坐在已接進平台的 datasets、virtual tables、models 之上，把這些資產連到現實世界的對應物。這是 Palantir 的產品定義，不是獨立實測，也不表示底層資料儲存可以不要。

Ontology 跟 semantic layer 差在哪？

Palantir 的 architecture 頁寫著 Ontology 不是 semantic layer，理由是資料、邏輯、動作、安全四項的整合與落地執行，薄薄的 semantic layer 或單一巨石式設計做不到。這是 Palantir 的說法，不代表其他產品做不到。

Palantir Ontology 的 Actions 是什麼？

一個 action type 定義使用者一次可以做的變更，帶著送出條件（submission criteria）與送出後的副作用，例如用 webhook 對外部系統送出請求。action type 也可以設定 action log，記下成功送出的送出者、時間和被改物件的主鍵。

AI 觸發的 action 一定要人審嗎？

不能這樣概括。Palantir 文件用虛構公司 Onyx 舉例：預設情況下，AI 只能先暫存 action，交給人做最終審查；範例也寫明，Onyx 可以讓受信任、經過充分測試的 AI 流程不經人審直接關閉動作循環。這是示例的設定，不是所有入口的規則。

範圍與版本

• 本文引用的 Palantir 文件頁，都是 2026 年 8 月查閱的版本。Palantir 的文件頁面不標日期，所以不能用日後讀到的頁面，反推 8 月當時的內容。
• 10-K 的引文，沿用 2026 年 8 月的查閱。
• 2026 年 10 月 16 日的修訂，調整了結構與限定的寫法，沒有更新資料。