核心章 · Chapter 03

Foundry:
Ontology 的

如果 Ontology 是大腦,Foundry 就是養出這顆大腦、並讓它連上真實世界的整套工廠:資料進得來、邏輯建得起、App 出得去。

Foundry 是給商業世界的平台(Gotham 是給國防的)。它可以拆成四段旅程:整合 → 建模 → 建構 → 操作。Ontology 是中間那顆結晶,Foundry 是它上下游的全部。

1 · Integrate資料整合:讓資料進得來

主張:Foundry 用 Pipeline Builder(低程式碼)與 Code Repositories(寫 PySpark/SQL)兩種介面,把幾百個異質來源接進來、清洗、轉換——業務人員與工程師用同一個平台的不同入口,產出物互通。

雙入口 · Pipeline Builder + Code

供應鏈分析師用拖拉的 Pipeline Builder 把 SAP 出貨表與物流商 API 併起來、算出「準時到貨率」;隔壁資料工程師用 Python repo 寫一段複雜的地理路徑最佳化。兩段產出落在同一個資料目錄、共享血緣,最後都餵進同一個 Shipment 物件。不需要把資料搬到第三個系統再對接。

2 · Versiongit 式的資料:分支、血緣、可回溯

主張:Foundry 把軟體工程的 branch / merge / lineage 帶進資料。你可以在分支上改 pipeline、驗證、再合併,不會炸到正式環境;而且任何一個數字都能一路追回它的原始來源

資料血緣 · 追一個爆掉的數字

週一早上 CFO 儀表板顯示「歐洲營收暴跌 40%」。分析師點那個數字 → 沿血緣往上游走 → 發現是某個匯率轉換的 pipeline 昨晚換了資料源、幣別欄位錯位。五分鐘定位,不是開三場會猜。

要修?開一條 branch 改那段轉換、在分支上確認數字對了、再 merge 回主線——正式儀表板全程沒被汙染。這是傳統「一坨 SQL + 排程」給不了的安全網。

3 · Model建模:資料變成 Ontology

主張:整合好的資料集,被「提升(promote)」成 Ontology 物件——這一步是 Foundry 與純資料倉儲的分水嶺:資料不再是資料集,而是帶行為的物件。(細節見第 02 章)

Dataset → Object

一張清洗好的 customers.parquet 資料表,綁定成 Customer 物件類型:定義主鍵、標題屬性、連到 Order 的連結、掛上 adjustCreditLimit() Action。從這一刻起,它不再只是被 SELECT 的表,而是能被 App 顯示、被 Action 改變、被 AI 呼叫的活物件。

4 · Build & Operate建構 App:讓非工程師也能做工具

主張:Foundry 讓人用低程式碼工具(如 Workshop)直接在 Ontology 上組出操作型應用,交到第一線手上——不是唯讀儀表板,是能按下去改變世界的 App。

操作型 App · Workshop

營運經理用 Workshop 拉出一個「延誤訂單處理台」:左邊列出所有 Order.status = DELAYED 的訂單,點一筆 → 看到關聯的 CustomerShipment → 直接按 expedite()notifyCustomer()。整個 App 沒寫半行前端框架程式,而且動作全走 Ontology 的權限與稽核。

Developer SurfaceOSDK:把 Ontology 當後端來寫 App

主張:如果你不想被關在 Foundry 的 UI 裡,OSDK(Ontology SDK) 會依你的 Ontology 自動產生型別化的 TypeScript / Python SDK,讓你在自己的 React App、外部服務裡讀物件、跑 Action——Ontology 變成一個有型別的 API 後端。

外部 App · @osdk/react

新創團隊想給客服自建一個 React 介面,但不想重做資料層。他們裝 OSDK,程式裡直接 client.ontology.objects.Customer.where(...) 拿到有型別的客戶物件,IDE 自動補全屬性;送出退款就呼叫 issueRefund()。2026 年 @osdk/react 正式 GA,提供現成的 React hooks 與效能最佳化——等於把 Ontology 當 Firebase 用,但帶企業級治理。

De-mystification祛魅:它不就是「有 UI 的 Databricks」?

「Foundry = Databricks + 一層漂亮介面」

攻擊

底層一樣是 Spark、一樣是資料湖,Palantir 只是包了 UI 還收三倍價。我用 Databricks + dbt + 一個 BI 工具就能拼出來。

回應

整合層(Spark/湖)確實可替代。不可替代的是上面:物件的動能層(寫回 Action)、動態治理、以及 Apollo 的跨環境部署。你的確能自己拼——但你要自己維護「拼裝物」的血緣、權限、寫回、上線流程。Palantir 賣的是「已經拼好且會持續運維」的那一整條。值不值,看你的團隊規模與退出成本,見第 08 章