How Palantir Turns Ontology into Code: The Rise of “Ontology‑as‑Code” in Enterprise AI

Palantir’s newly announced SuperRepo appears as a professional‑developer monorepo, but its real breakthrough is embedding the Ontology layer directly into the software engineering workflow. Developers can now declare object types, relationships, interfaces and actions using TypeScript, store Ontology definitions, Functions and React applications in the same repository, preview them locally, and publish them as a single versioned artifact.

Why Ontology matters

Historically Ontology answered the question “what composes the enterprise business world”. SuperRepo pushes the question further to “how to continuously develop and deliver applications around this business world”. By turning Ontology into code, business objects become subject to branch development, code review, automated testing, CI/CD and rollback, just like regular application code.

Cross‑layer change management

In traditional projects, the data model lives in a schema repository, backend logic in a Functions repo, and UI in a front‑end repo. When a business concept such as “high‑risk supplier” is added, developers must manually synchronize schema changes, logic updates, UI fields and Agent permissions, often leading to semantic drift. SuperRepo collapses this workflow into a single edit‑preview‑build cycle. The Foundry CLI launches embedded services that emulate the real Foundry environment, routing Function‑backed actions through a local Ontology instance and connecting OSDK‑based applications to those services.

Ontology‑as‑Code capabilities

Business model definition : TypeScript‑based Ontology‑as‑Code and import of existing Ontology resources.

Functions : Currently TypeScript v2 Functions; Python Functions are planned.

Applications : React/OSDK apps with local preview.

Agent integration : Agents can access Ontology via Ontology MCP or Palantir MCP, respecting OAuth 2.0 permissions and Action‑level constraints.

Automatic OSDK generation : Changes to Ontology trigger regeneration of type bindings that both Functions and front‑end code can consume without a separate release step.

Import workflow : Existing Ontology objects and Actions can be imported into SuperRepo with foundry import ontology, producing corresponding TypeScript definitions and lock‑file metadata.

Linting and testing : Embedded Ontology enables cross‑component integration tests and Ontology lint rules that enforce naming, structural and design conventions before deployment.

Beta status and limitations

SuperRepo is still in beta; not all Foundry environments may have it enabled, and features are subject to change. Functions are limited to TypeScript; Python Functions, external data‑source calls, Agent Engine, Agent SDK, Automate and full data pipelines are still under development. Direct definition of PySpark transforms and Compute Modules is not supported, and deployments may overwrite manual Ontology edits.

Strategic implication

By unifying business semantics, execution logic, permissions and applications in a single versioned product, Palantir aims to own the runtime layer of enterprise AI. The model reduces the risk of version mismatch where an Agent assumes an Action exists while the back‑end has removed it, or where front‑end displays a new state but Functions still use old rules. This “Ontology‑as‑Code” discipline makes the business world itself a code artifact that can be audited, tested and governed, positioning Palantir’s platform as a barrier to entry for competitors.

Conclusion : SuperRepo demonstrates that the next frontier after AI‑generated code is a codified business world. When objects, relationships, rules and actions are all versioned and governed like software, AI agents can operate safely within enterprise contexts, but the approach is still early and limited to the beta capabilities described above.