Palantir Ontology Explained: Modeling Decisions via 12306 Ticket Purchase

Introduction: Ontology vs. Objects and DDD

The author initially sensed that ontology's "entities" resemble object-oriented programming objects but with a different flavor. Domain-Driven Design (DDD) also unifies business descriptions with code (e.g., a "Student" in business maps to a Student class), yet ontology goes further: it describes not only business objects but also relationships between objects, executable actions, and the business logic behind those actions.

Palantir's official documentation defines ontology as: it models not data, but enterprise decisions.

The Blind Spot of Traditional Data Architectures

Data warehouses, BI, and ETL solve the same problem: gathering scattered data into one place for reporting, analysis, and visualization. This architecture is mature but has a long-ignored blind spot — it assumes decisions happen outside the data. Analysts create charts in BI; executives decide via email, meetings, or tribal knowledge. The system records only "what happened," never "why this decision was made" or "which rule version was the basis." Ontology adds this missing layer.

What Is Inside an Ontology: The Six Components

In plain terms, ontology writes the business as a machine-readable "dictionary + code." The dictionary defines "what things are"; the code defines "what is allowed." The six pieces are:

Nouns (Object Types) — e.g., Station, Train, Ticket

Verbs (Link Types) — e.g., Ticket "covers" Segment

Attributes (Properties) — e.g., Price, Remaining Quota

Rules (Functions / Rule Sets) — e.g., Student ticket requires valid qualification

Actions (Action Types) — e.g., Purchase, Refund, Change

Instances (Objects) — e.g., Zhang San's 100.50 CNY student ticket

The following table maps each component to the 12306 example and Palantir Foundry terminology:

Component | 12306 Example | Foundry Term | Note
----------|---------------|--------------|-----
Noun      | Station, Train, Ticket | Object Type |
Verb      | Ticket "covers" Segment | Link Type |
Attribute | Price, Remaining Quota | Property |
Rule      | Student ticket needs qualification | Function / Rule Set |
Action    | Purchase, Refund, Change | Action Type |
Instance  | Zhang San's 100.50 CNY student ticket | Objects |

Architecture: Where the Ontology Lives

Ontology does not replace any existing system. Order databases stay order databases; payment systems stay payment systems. A semantic layer is inserted between applications and data.

Two architectures compared:

Left (traditional): Purchase app, customer-service tickets, operational reports each connect to their own databases or even different systems. The same "student ticket" has multiple definitions; changing a refund rule requires multi-system updates.

Right (with semantic layer): A single semantic layer unifies the dictionary, the rules, and the write path. Databases remain untouched.

Three-Layer Architecture

1. Application Layer: Handles Interaction Only

Purchase page, customer-service tool, operational dashboard, AI assistant — all do only two things: translate user intent into reads against the ontology (query instances) or writes to Actions (trigger modifications).

2. Semantic Layer: Home of the Ontology, Governs Correctness

All six components reside here. Read path: underlying data tables are mapped via attributes into instances for all applications to query. Write path: every modification passes rule validation first; only after passing does the Action execute. Checks like student qualification, purchase limits, segment contiguity happen here.

3. Transaction + Data Layer: Handles Speed and Reliability

Inventory deduction uses single-row conditional updates with row locks to prevent overselling. Payment callbacks use idempotency keys to prevent duplicate charges. Ticketing failures trigger reverse compensations (SAGA). These are database and distributed-transaction concerns — millisecond-level, high-concurrency, unrelated to semantics.

4. The Core Architectural Decision

The semantic layer is the brain: legislation and adjudication. It answers "Is this operation correct? Should it proceed? Based on what?" The transaction layer is the muscle: execution and cleanup. It answers "Is it fast? Is it stable? How to recover if something breaks?"

Responsibility          | Semantic Layer (Ontology)          | Transaction + Data Layer
------------------------|------------------------------------|--------------------------
Question Answered       | Is it right? Should it? Based on?  | Fast? Stable? Recovery?
Typical Operations      | Axiom validation, rule versioning, | Row-lock deduction,
                        | reasoning, lineage                 | idempotent callbacks,
                        |                                    | SAGA compensation
Performance Scale       | Validation in ms; reasoning offline,| Peak Spring Festival:
                        | results materialized               | tens of thousands txn/s
One-Liner               | Brain: legislate & judge           | Muscle: execute & clean

Ontology's Internal Four-Level Hierarchy

The ontology itself splits into four levels, each constraining the next. Upper levels are more abstract and stable; lower levels are more concrete and change frequently. This mirrors software layering: changes in lower layers don't disturb upper layers; switching domains only replaces the domain level and below. Abstract, reusable concepts stay on top; volatile specifics stay at the bottom, minimizing blast radius of changes.

Buying a Ticket: End-to-End Verification

Scenario: September 30, Beijing South → Shanghai Hongqiao, G1, second class. Four steps: search train, check availability, submit order, post-ticketing.

1. Search Train: Distinguishing Plan from Event

Entering G1, the system's first question is not "are there tickets?" but whether the query follows the train plan (TrainService — a template) or the actual run on Sep 30 (TrainRun — an event). This distinction embodies "modeling decisions, not data."

The resulting domain model:

2. Check Availability: Verifying Verbs + Attributes

Intuition says the system stores a number and returns "N tickets left." Ontology says: remaining tickets are not a number, they are an account. In the e-ticket era a ticket has no physical form; it is a "right certificate" — the right to occupy capacity on a specific segment × class. Beijing South to Shanghai Hongqiao passes Jinan West and Nanjing South, splitting the journey into three segments. Thus G1 second class is three independent ledgers:

# Sep 30 G1 Second Class: Three Independent Segment Ledgers (Quota Allocation)

Beijing–Jinan (Beijing South→Jinan West)  Remaining 25
Jinan–Nanjing (Jinan West→Nanjing South)   Remaining 18
Nanjing–Shanghai (Nanjing South→Shanghai Hongqiao) Remaining 3

# Two Sold Tickets Occupying Different Spans

t001 Li Si  Full-journey ticket  553.00 CNY  Covers all three segments
t002 Zhang San Student ticket    100.50 CNY  Covers only Nanjing–Shanghai segment

Three independent ledgers explain real-world oddities: sometimes the full journey shows tickets but a middle segment shows none; sometimes direct tickets are sold out while short segments still have availability. Each ticket deducts quota segment by segment according to the covers verb and the remaining quota attribute.

3. Submit Order: Verifying Rules + Actions — Three Checks, One Gate

Clicking "Submit Order" sends the request to the semantic layer first. Three validations run sequentially:

Student ticket must hold valid student qualification.

One person, one train, one day — maximum one ticket.

Covered segments must form a contiguous block.

Only after all three pass is a "validation pass" generated, stamped with the rule version number.

Mapping Back to Palantir: Comparison Table

After the ticket purchase, Palantir Foundry's terminology becomes familiar. The 12306 ontology in this article was built with standard semantic-web technologies (OWL/SHACL/SWRL); Foundry's Ontology is a commercial implementation of the same ideas. The mapping:

Article Concept | Foundry Term | 12306 Correspondence
----------------|--------------|-------------------
Noun            | Object Type  | Station, Ticket, Order
Verb            | Link Type    | Ticket "covers" Segment
Attribute       | Property     | Price, Remaining Quota
Action          | Action Type  | Purchase, Refund, Change
Function/Calc   | Function     | Transfer Route Calculation
Marking (Perm)  | Marking      | ID Card Masking Levels
Reasoning       | Scenario     | "Add one train — how much capacity recovered?"
Lineage         | Lineage      | Which three segments did this ticket deduct?

Returning to the opening statement: Ontology models not data, but enterprise decisions.