Palantir Ontology 拆解

Palantir 文件說 Ontology 不是 semantic layer：它把資料、邏輯、動作與權限接在同一個模型上。判斷這種整合，要問一次送出要過哪些條件、誰看得到什麼、事後查得到哪一種紀錄。

Palantir 的 action type 把送出條件、物件編輯、通知和 webhook 綁進同一個定義。但外部系統不一定跟著一起成敗：在 writeback 模式下，外部請求成功時，Ontology 的變更仍可能失敗；revert 也不撤通知與 webhook。

不買 Palantir，只用一頁 MODEL.md、一支測試和一份核准清單，能把資料守到哪裡？本文以作者自己的三個公開 repo 為例，看哪些事程式真的會擋、哪些仍靠人，以及什麼情況下該考慮更重的平台或授權引擎。

廠商都說自己有 ontology，採購時該問什麼？本文用四個問題讀官方文件：定義的基本單位、消費端的用途、有沒有形式推論、動作寫在哪裡。這是作者讀文件的框架，不是產品能力測試。

AI 或 SDK 把資料讀出去之後，原本的權限還管得到嗎？Palantir 的文件把讀取時的授權，和限制沿衍生資料往下傳，分成兩件事。row、column 的 granular 政策停在讀取當下；markings、CBAC、organizations 在 Foundry 管理的衍生路徑上預設跟著走，但有受控的移除路徑，action 的 read／write authorization（beta）也可以刻意切斷。聽到「有權限層」，先問資料離開之後規則在哪裡。