Why Palantir’s Valuation Soars: Large Models as the Brain, Ontology as the Skeleton and Memory

On March 19, 2026 the DataFun community held a deep live dialogue titled “Ontology and AI.” Host Lv Hangfei invited three senior practitioners—Hu Shenmin, head of Shanghai Bank’s intelligent data platform, Xi Zongzheng, senior R&D engineer at Alibaba Cloud, and an expert from Ping An Technology—to explore why both banking risk‑control and cloud‑operations teams converge on Palantir’s ontology approach.

Three data‑centric gaps before ontology

Xi described three “gaps” that make raw data unusable. The first is the data gap: logs, metrics and traces are fragmented, noisy, and over 99 % of alerts are irrelevant, forcing engineers to switch between Prometheus, SLS and APM consoles. The second is the model gap: AI models are black‑boxes that hallucinate and cannot infer causal relationships without prior knowledge (e.g., two failing services may share a hidden upstream dependency). The third is the engineering gap: petabytes of data must be ingested, cleaned, stored and computed, imposing huge cost and security challenges.

Ontology as a unifying graph

Hu added that traditional data warehouses and “data governance” only produce machine‑unreadable artifacts. He illustrated Palantir’s solution with a concrete server example: an entity ECS.instance (IP, CPU, memory, OS, status) runs a micro‑service entity APM.service; the relationship “runs on” links them, and observability streams (CPU usage, logs) are attached via a data edge. This graph‑based ontology turns each asset and its metrics into a single, queryable unit, enabling an AI agent to traverse links for automated fault isolation.

Business vs. technical ontology

Hu distinguished two layers. The business ontology clarifies domain concepts (e.g., customer, credit‑application, credit‑limit) and follows a five‑level modeling hierarchy—entity, process (five‑level: domain → value‑chain → activity → task → step), behavior, rule, and data mapping. The technical ontology aligns those concepts with existing APIs, databases and cloud resources.

Large models and ontology: brain, skeleton, memory

Xi used a metaphor: the large model is the brain, while ontology provides the skeleton and memory. Ontology defines the structural backbone (entities and relations), stores expert knowledge as layered runbooks (memory), and exposes a reflection capability that lets the model discover which tools or data an entity can invoke. He also mentioned Graph‑RAG, where the graph supplies precise context to a retrieval‑augmented generation model, and an incremental loading design that first presents a directory‑style index to avoid over‑loading the model’s context.

Extracting tacit expert knowledge

Both speakers acknowledged the difficulty of converting implicit expertise into structured form. Xi cited a senior credit‑approval expert who can instantly spot a risky application but cannot articulate the reasoning, and Hu described the hidden dependencies between services that only veteran operators know. Their solution combines a wiki‑style honor system to encourage contributions, Code‑LLM tools to auto‑extract rules from code, and a progressive modeling workflow that starts with the most painful scenario, builds a minimal MVP, and expands only after value is demonstrated.

Practical advice for newcomers

When asked for a starter checklist, Xi warned against “all‑in‑one” projects and over‑design; instead, pick the highest‑pain use case, build a tiny model, and iterate. Hu emphasized deep business involvement: 70 % of ontology work belongs to the business side, and concepts must be repeatedly discussed and validated rather than handed over to a closed‑door engineering team.

Future outlook

Both guests agreed that ontology will not be eclipsed by future AGI. Rather, as AGI matures it will rely on ever‑richer structured knowledge; ontology will become one of the core operating systems for intelligent agents, providing the necessary rules, boundaries and traceability.