Palantir 文件自己說：Ontology 不是資料庫，也不是 semantic layer

This article is also available in English: Palantir Says Its Ontology Is Not a Semantic Layer

Palantir 的技術文件裡有一句話，正面否定了業界最常拿來形容它的那個詞。arch-ontology-system 頁（Palantir 官方文件，2026 年 8 月查閱）寫著 The Ontology is not a “semantic layer”——理由是把資料、邏輯、動作、權限四樣整合並落地執行，一層薄薄的 semantic layer 或單一巨石式設計做不到這件事。（Palantir 官方文件頁面不標日期，這篇引用的 docs 頁面都是 2026 年 8 月查閱的版本。）同一家公司在 2025 財年 10-K 裡又說，一般意義的 ontology 通常指”the systematic mapping of data to meaningful context”，然後聲稱自家版本遠遠超過這個範圍，把決策裡的 data、logic、actions 整合進一個對組織的基礎表述裡。兩句話擺在一起，這篇要拆開的就是「超過的那部分」到底是什麼。

還有第三件怪事：同一家公司的文件，數出來的層數並不一樣。ontology-overview 頁把 Ontology 切成兩塊——semantic elements（objects、properties、links）與 kinetic elements（actions、functions、dynamic security）；why-ontology 頁把每個決策拆成 Data、Logic、Action、Security 四個成分，arch-ontology-system 頁用同樣四項、並自稱 fourfold；2024 年 1 月的官方 blog〈Connecting AI to Decisions with the Palantir Ontology〉只講 data、logic、action 三項；更早的 2022 年 10 月官方 blog〈Ontology: Finding meaning in data〉列出六項 Ontology 必須具備的 service，其中已經包含 security architectures。這篇選四分法，理由只有一個：arch-ontology-system 頁是這幾份文件裡唯一明確自稱「fourfold」的一頁。後面用的「四層」，是 Palantir 文件裡的一種講法，不是唯一講法。

Palantir 文件把 Ontology 定義為組織的 operational layer

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.” 傳統資料架構不記錄決策背後的推理過程，也不記錄推理之後採取的行動；一般的分析架構則脫離真實運作場景。文件把「把動作循環關起來」——決策做成之後即時執行、即時反映——當成操作型系統與分析型系統的分界線。

Palantir 把每個決策拆成四個成分：Data、Logic、Action、Security

why-ontology 頁寫道，Palantir 把每一個 operational decision 拆成四個成分：Data 是拿來做這個決策所用的資訊，Logic 是評估這個決策的邏輯與計算過程，Action 是被選定的決策要怎麼被協調與執行，Security 則確保這個決策符合營運政策。同一份文件另外講了第五樣：一個決策是什麼時候做的、依據哪個版本的企業資料、透過哪個應用程式，這條「decision lineage」會被自動記錄下來，並且對人類開發者與 AI agent 都能安全存取。

這篇後面用「語意」「動作」「權限」「血緣」四個中文詞組織全文，對應關係是：語意＝Data 加 Logic，動作＝Action，權限＝Security，血緣＝decision lineage。這是對 Palantir 文件用語的改寫，不是 Palantir 自己的名詞——四層對照表整理了這層對應，以及這四樣在 ontology-overview 頁二分法裡各自落在語意還是動態那一半。

語意層把資料表對應到現實世界的實體與事件

Ontology 的 core-concepts 頁對語意層的每個概念都給了一句定義。文件寫道：“An object type is the schema definition of a real-world entity or event.”——物件類型是一個現實世界實體或事件的 schema 定義；一個物件對應一個實例，一組物件的集合叫 object set。property 是物件類型底下某個特徵的 schema 定義；link type 是兩個物件類型之間關係的 schema 定義；interface 描述一個物件類型的形狀與能力，讓不同物件類型可以共用同一種互動方式；function 則是一段吃輸入、回輸出的程式邏輯，可以被物件、object set 呼叫，也能被 action type 與應用程式共用。

這一層跟資料倉儲的差別在於對應對象：資料倉儲對應的是表與欄位，語意層對應的是「組織的語意」怎麼被定義——把既有的資料源 map 進物件、屬性、關聯裡。文件明講，物件是靠在 Ontology Manager 裡替一個物件類型加上資料源（backing datasource）才被建立與顯示出來；要建出 Employee 這種物件，得先把員工目錄與其他企業資料接進那個物件類型。roles 是這一層之上、Ontology 裡的中央權限模型，可以設在整個 Ontology 層級，也可以設在單一資源層級。

動作層把前置條件、副作用、寫回、稽核綁在一起

core-concepts 頁把 action type 定義為使用者一次可以對物件、屬性值、關聯做的一組變更或編輯的 schema 定義，也包含送出這個 action 時會觸發的副作用行為。action-rules 頁列出 rules 能做的五類事：建立物件、修改物件、刪除物件、建立多對多關聯、刪除關聯。

能不能送出，取決於 submission criteria——文件的說法是這些條件”determine whether an action can be submitted”，這個名稱是後來才換的，舊名叫 validations；submission criteria 支援把業務邏輯編碼進資料編輯的權限裡，確保 Ontology 資料品質與編輯治理。

送出之後，side effects 讓資料被送出 Foundry、對接既有的組織流程，文件把這個模式稱作「decision orchestration」；其中一種副作用是 webhook，用來對 Salesforce、SAP 或任何設定過的 HTTP 伺服器送出請求，通常是為了改那邊的資料。

編輯存哪、留什麼紀錄：使用者做的編輯會寫進 writeback dataset，而不是寫進物件類型或關聯類型背後的原始資料集——這讓分析時原始資料與編輯後的資料同時存在。每次 action 送出都會生成一筆 action log 紀錄，記下送出者的 Multipass 使用者 ID、時間戳、被改動物件的主鍵；文件說這個 log 能回答”what changed, by whom, and when?”。當 rules 不夠用，action type 也可以設定成呼叫一段 function 來定義更複雜的修改邏輯。

前置條件、副作用、寫回、稽核這四件事要同時做對，本文認為這是四層裡最難被複製的一層：光是把資料寫回外部系統不難，難的是同一個動作要先驗證能不能送、送出後知道會觸發什麼、寫回時留住原始資料，還要在每一步都留下可查的紀錄。

權限層要求兩把鑰匙同時打開

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 的規則是全有全無——文件寫著”a user must be a member of all Markings applied to a resource”才能存取這個資源；而且從一份被標記的檔案、資料夾或 Project 衍生出來的所有資源都會繼承同一個標記，除非被明確移除。刪除物件也受限制：看不到一個物件的完整內容（所有屬性），就不能刪除它。

這一整套規則，人與 AI agent 用的是同一套：文件說每一次由人類或 agent 執行的操作，都要遵守嚴格的 role、marking、purpose 控制；工具呼叫也受同一套安全架構動態約束，任何工具的呼叫都依賴對 Ontology 裡底層物件、屬性、關聯的存取權。2026 年 1 月 22 日一篇官方 blog〈Securing Agents in Production〉進一步說，一個 agent 實際持有的權限是三個因素共同決定的函數：設定並「擁有」這個 agent 的使用者是誰、agent 自己的服務帳號與 OSDK 權限範圍、以及這個 agent 當下是代表哪個使用者在執行。

血緣層留下每個決策可回溯的紀錄

decision lineage 這條線，官方說法是「一個決策是什麼時候做的、依據哪個版本的企業資料、透過哪個應用程式」會被自動記錄，並且對人類開發者與 agent 都能安全存取。落在平台工具上，這件事分成幾塊：Data Lineage 是一個互動工具，讓人看到資料怎麼在整個 Foundry 平台裡流動；平台的 audit logs 則提供 Foundry 裡每一個動作的完整紀錄，給安全團隊偵測威脅、調查事件、確認合規；如果一個 action type 是靠 function 驅動的，要讓它進到 action log，還得替背後的 Ontology edit function 額外設定 edits provenance。這一層本身不複雜，複雜的是它把前面三層——語意、動作、權限——每一次的變化都串成一條能回頭查的鏈。

官方文件裡，AI 觸發的 action 預設先交人審

Palantir 的 2025 財年 10-K 寫道，公司 2023 年開始部署新產品 AIP。AIP 的建構工具，像是 AIP Logic、AIP Chatbot Studio、AIP Evals，官方文件寫明是建在 Ontology 與開發者工具鏈之上。why-ontology 頁用一個虛構的公司 Onyx 當範例，說明 Ontology 怎麼替 AI 提供防護：在預設情況下，像是更改工單狀態或推送一份調度計畫這類 action，AI 只能先「暫存」（staged），交給人做最終審查；只有在 Onyx 累積足夠信任之後，才會考慮讓經過充分測試的 AI 流程自動關閉這個動作循環。

Palantir 執行長 Alex Karp 在 2026 年 5 月 4 日發出的股東信裡有一句相關的話：“The Ontology is based firmly in reality”——信裡接著把 ground truth、tribal knowledge 與後續增修描述成一種辯證關係。文件本身的講法也在變：2024 年 1 月那篇官方 blog 說 Ontology 把 data、logic、action 三項整合進一個決策中心的模型；2026 年的 docs 頁面則講四項，多了 security。這裡只能講文件裡的講法從三項變成四項，功能本身何時具備這道安全能力，不在這兩篇文件的比較範圍內。

同一個 ontology，至少有三種不同的意思

W3C 對 OWL 2 的定義是”an ontology language for the Semantic Web with formally defined meaning”——這是一種知識表示語言，跟 Palantir 講的 Ontology 同名不同物。另一群同名異物來自 semantic layer 廠商：dbt 官方文件說它的 Semantic Layer “simplifies the process of defining and using critical business metrics”；Looker 的 LookML “is the language that is used in Looker to create semantic data models”；Databricks 的 metric views “are the core implementation of Unity Catalog semantics in Unity Catalog”；Snowflake 的官方文件寫”You can store semantic business concepts directly in the database in a Semantic View”；Microsoft Fabric 的 Power BI 語意模型則是 “a logical description of an analytical domain, with metrics, business friendly terminology, and representation”。這五家的定義句裡都在講定義與統一 metrics、語意模型，沒有一句提到寫回動作——這裡只能說定義句裡沒有，不代表這些平台做不到，本文沒有查證這件事。

「ontology」這個字最近還被更多平台拿去用：Microsoft 的 Azure blog 說 Fabric IQ 的 ontology “capture operational context by defining business entities and their relationships”；C3 AI 說自己的平台 “models your entire enterprise as a unified ontology graph”；ServiceNow 官方帳號在 2025 年 11 月的社群文章裡，把知識圖譜稱作 ontology，“which defines the language, structure, and logic the AI will use”。同一個字，現在至少疊著 W3C 的知識表示語言、semantic layer 廠商的語意模型、Palantir 的四層決策架構這三種不同意思。

外部有兩種不同角度的懷疑

BD Emerson 董事總經理（Managing Director）Leslie Sakal 在 2026 年 7 月 30 日的文章裡寫道：“The ontology is a poor data engineering environment, and treating it as one is expensive.”——她認為清洗、合併、去重、整併資料這些工作應該留在 ontology 底下的 pipeline，不是 ontology 本身該做的事。

Substack 作者 Pankaj Kumar 在 2026 年 5 月 30 日的文章裡則從搬遷成本切入：“You cannot export a Foundry ontology as an OWL file”——匯出來的東西別的平台無法拿去推理；Foundry 用自己的一套表示法（object types、link types、action types），不走 OWL、RDF、SPARQL 這些 W3C 標準；一旦業務邏輯、語意模型、操作流程都編碼進 Foundry，轉投其他平台的成本被他形容為極高。

語意、動作、權限、血緣，沒有 Palantir 各自能做到什麼程度

語意層有 W3C 的 OWL、有各家 semantic layer 廠商在做；權限層每個企業系統都有自己的一套；血緣層的稽核紀錄也不是 Ontology 專屬的概念。這四層裡哪幾層是可以拿現成工具拼出來的「概念」，哪幾層是需要整合工程才做得到的「工程」，這個問題留給系列第三、四篇展開。

回到這篇文章開頭那兩句話：10-K 說 Palantir 版本的 ontology 遠遠超過一般意義，超過的那部分，落在 Action 與 Security 這兩層，加上自動記錄的 decision lineage——這幾樣是語意層本身給不了的東西。本系列下一篇：Palantir 的 Action 是一筆交易：驗證、副作用、寫回、稽核綁在同一個定義裡。

常見問題

Q：Palantir 的 Ontology 是資料庫嗎？ 不是。Palantir 官方文件把 Ontology 定義為組織的 operational layer，坐在既有的 datasets、virtual tables、models 之上，把它們連到現實世界的對應物，再把資料、判斷邏輯、可執行的動作與權限規則接在一起，服務的是「決策」而不是「查詢」。

Q：Ontology 跟 semantic layer 差在哪？ Palantir 的文件裡有一句直接否定：Ontology 不是 semantic layer，理由是它把資料、邏輯、動作、權限四樣一起整合並落地執行，一層薄薄的語意層做不到這件事。dbt、Looker、Databricks、Snowflake、Microsoft Fabric 這五家的官方定義句都在講「定義並統一 metrics 與語意模型」，定義句裡沒有一句提到寫回動作。

Q：Palantir Ontology 的 Actions 是什麼？ Action 是官方文件裡「決策」的第三個成分，代表被選定的決策要怎麼被執行與協調。一個 action type 綁著能不能送出的前置條件（submission criteria）、送出後的副作用（例如用 webhook 把資料寫回 Salesforce 或 SAP）、寫進 writeback dataset 的編輯紀錄，以及記下誰、何時、改了什麼的 action log。

Q：Ontology 是 Palantir 的商標嗎？ 查 Palantir 2025 財年 10-K 的商標段落，公司列出的註冊商標是 Palantir、Gotham、Palantir Foundry 與公司 logo，沒有列出 Ontology。