Ontology: The Soul of Palantir and Its Deepest Moat
The word "Ontology" comes from the Greek ontos (being) and logos (study), tracing back to Aristotle (384-322 BC).
Ontology: The Soul of Palantir and Its Deepest Moat
“Series: S1 Palantir Decoded · Article 5 | Level: Beginner | Reading Time: 15 min
#TL;DR
- Ontology is not a database model, not an ER diagram, not a UML class diagram -- it is a "world model" that represents an enterprise's core business objects (customers, orders, equipment, parts) and their relationships as an operable entity graph. Its three pillars are ObjectType, LinkType, and ActionType, with DerivedProperty adding dynamic computation capabilities.
- Ontology's philosophical lineage traces back to Aristotle's Categories, through AI knowledge representation and the Semantic Web (OWL/RDF), before being engineered by Palantir into a runtime model that directly drives business applications. The key difference from academic ontology: Palantir's Ontology is not a read-only knowledge graph but an operable system with Actions and permission controls.
- Ontology is Palantir's deepest moat because once an enterprise models its core business on Ontology, accumulates Actions and derived properties, trains teams, and integrates dozens of downstream applications -- migration costs become astronomical. This lock-in is not contractual but cognitive lock-in and ecosystem lock-in.
#1. Philosophical Origins: From Aristotle to Palantir
#1.1 Aristotle's Categories
The word "Ontology" comes from the Greek ontos (being) and logos (study), tracing back to Aristotle (384-322 BC).
In his work Categories, Aristotle posed a fundamental question: "Into what basic categories can existing things be classified?"
He proposed 10 categories: Substance, Quantity, Quality, Relation, Place, Time, Position, State, Action, and Passion.
The core insight of this thinking is: To understand the world, you must first classify and model the things in it.
#1.2 From Philosophy to Computer Science
The Evolution of Ontology
==========================
350 BC Aristotle's Categories
| "What are the basic categories of being?"
|
v
1960-1980 AI Knowledge Representation (KR)
| Semantic Networks, Frame Systems
| "How can we make computers understand the world?"
|
v
1990s Tom Gruber's Definition
| "An ontology is an explicit specification
| of a conceptualization"
|
v
2001 Tim Berners-Lee's Semantic Web
| RDF, OWL, SPARQL
| "Let machines understand web content"
|
v
2004 Palantir Founded
| "Help analysts understand intelligence data"
|
v
2008-2014 Gotham Ontology Matures
| "Turn Ontology from academic concept
| into a running product"
|
v
2014 Foundry Released
| "Bring Ontology to the enterprise market"
|
v
2023 AIP Released
| "LLMs understand and operate enterprise
| data through Ontology"
|
v
2024-2025 Ontology Becomes Industry Discussion
"Every enterprise needs its own Ontology"
#1.3 The Semantic Web's Failure and Palantir's Success
The Semantic Web was a vision proposed by WWW inventor Tim Berners-Lee in 2001: standardize all data on the internet using RDF/OWL so that machines could automatically understand and reason about it.
The Semantic Web achieved some academic results but largely failed in industry. The reason is simple:
| Dimension | Semantic Web | Palantir Ontology |
|---|---|---|
| Goal | Standardize the entire internet | Standardize a single enterprise |
| Scope | Global consensus | Enterprise-internal consensus |
| Modelers | Ontology experts (rare) | Business analysts + FDEs |
| Expressiveness | Extremely rich (overly complex) | Good enough (pragmatism) |
| Operability | Read-only knowledge graph | Operating system with Actions |
| Adoption barrier | Extremely high | Moderate |
Palantir's insight was: You don't need the whole world to agree -- you just need one enterprise to agree internally. When the scope shrinks to a single enterprise, Ontology modeling becomes feasible.
#2. The Three Pillars of Ontology: ObjectType, LinkType, ActionType
#2.1 ObjectType
ObjectType is the fundamental building block of Ontology, representing a class of business objects in the enterprise.
ObjectType: Employee
===============================
Properties:
+----------------+----------+----------+-----------------+
| Property Name | Type | Required | Description |
+----------------+----------+----------+-----------------+
| employeeId | String | Yes (PK) | Employee ID |
| name | String | Yes | Full name |
| department | String | Yes | Department |
| title | String | No | Job title |
| hireDate | Date | Yes | Hire date |
| salary | Decimal | Yes | Salary |
| email | String | Yes | Email |
| location | GeoPoint | No | Office location |
+----------------+----------+----------+-----------------+
Derived Properties:
+--------------------+---------------------------------------+
| tenure | today() - hireDate (years of service) |
| teamSize | count(direct reports) |
| totalCompensation | salary + bonus + stock_value |
| flightRisk | ML model-predicted attrition risk |
+--------------------+---------------------------------------+
Security & Permissions:
+--------------------+---------------------------------------+
| salary property | Visible only to HR + manager + C-Suite|
| flightRisk | Visible only to HR |
| Entire ObjectType | All logged-in users (subject to |
| | property-level permissions) |
+--------------------+---------------------------------------+
Key point: an ObjectType is not merely a data model -- it also includes permissions, derived properties, and business rules. This is its fundamental difference from an ordinary database schema.
#2.2 LinkType
LinkType defines relationships between objects.
LinkType Examples
==================
Employee --REPORTS_TO--> Employee
| |
| Properties: |
| - since: Date |
| - dotted_line: Boolean |
| |
| Constraints: |
| - Cardinality: 1:N (one employee, one direct manager,
| multiple reports)
| - Directionality: Directed
+------------------------+
Employee --WORKS_ON--> Project
| |
| Properties: |
| - role: String |
| - allocation: Float | (e.g., 0.5 = 50% time)
| - startDate: Date |
| |
| Constraints: |
| - Cardinality: N:M (many-to-many)
+----------------------+
Project --DEPENDS_ON--> Project
| |
| Properties: |
| - dependencyType: |
| "BLOCKS" | "SOFT" |
| |
| Constraints: |
| - Acyclic (DAG constraint)
+-----------------------+
#2.3 ActionType
ActionType is the key feature that distinguishes Palantir's Ontology from all other data modeling approaches.
Traditional data models are "read-only" -- they describe what data is, but not "what can be done with data." ActionType encodes business operations into the Ontology:
# ActionType Definition Example
class TransferEmployeeAction:
"""Transfer an employee from one department to another"""
# Input Parameters
parameters:
employee: ObjectType["Employee"] # employee to transfer
target_department: String # destination department
effective_date: Date # effective date
reason: String # reason for transfer
# Preconditions
preconditions:
- employee.status == "ACTIVE"
- target_department in VALID_DEPARTMENTS
- requesting_user.role in ["HR_MANAGER", "DEPARTMENT_HEAD"]
# Side Effects
effects:
- employee.department = target_department
- employee.REPORTS_TO = target_department.head
- CREATE AuditLog(action="TRANSFER", employee=employee,
from=employee.department, to=target_department)
- NOTIFY target_department.head
- NOTIFY employee
# Permissions
permissions:
- HR_MANAGER: can execute for any employee
- DEPARTMENT_HEAD: can execute for own department employees only
# Approval Workflow
approval:
- if employee.level >= "DIRECTOR":
requires_approval_from: ["VP_HR", "CEO"]
- else:
requires_approval_from: ["HR_MANAGER"]
The revolutionary aspect of ActionType is: it makes the Ontology not just a map, but an operations manual. Users can not only "see" employee information but can directly execute a "transfer department" operation on the Ontology -- complete with automatic permission checks, approval workflows, audit logs, and notifications.
#2.4 DerivedProperty
Derived properties are properties that are automatically computed from other properties, giving the Ontology "intelligence":
Derived Property Examples
==========================
Base Properties --> Derived Properties
======================================
1. Simple Calculation:
Order.total_amount = sum(OrderLine.quantity * OrderLine.unit_price)
2. Cross-Object Aggregation:
Customer.lifetime_value = sum(all related Order.total_amount)
3. Time-Window Calculation:
Equipment.avg_daily_output_30d = avg(daily_output over last 30 days)
4. Conditional Calculation:
Supplier.risk_level =
CASE
WHEN quality_issues_90d > 5 THEN "HIGH"
WHEN quality_issues_90d > 2 THEN "MEDIUM"
ELSE "LOW"
END
5. ML Model Inference:
Customer.churn_probability = ml_model("churn_predictor",
features=[tenure, usage_trend,
support_tickets_90d,
contract_renewal_date])
6. Graph Traversal Calculation:
Person.degrees_from_suspect = shortest_path(Person, SuspectList,
via=CONTACTED | MET_WITH)
Derived Property Dependency Graph (DAG):
+-----------------------------------------------+
| |
| OrderLine.unit_price --+ |
| OrderLine.quantity ----+-> Order.total_amount |
| | | |
| | v |
| +-> Customer.LTV |
| | |
| Customer.tenure ---------------+| |
| Customer.support_tickets ------+| |
| Customer.usage_trend ----------+| |
| vv |
| Customer.churn_prob |
| |
+-----------------------------------------------+
Key Rules:
- Derived properties can only depend on base properties or other derived properties
- Dependencies must form a DAG (acyclic)
- When a base property changes, downstream derived properties auto-recompute
- Computation can be real-time or batch (configured based on performance needs)
#3. Ontology Compared to Other Modeling Methods
#3.1 Comprehensive Comparison Table
| Dimension | ER Diagram | UML Class Diagram | OWL/RDF | Knowledge Graph | Palantir Ontology |
|---|---|---|---|---|---|
| Origin | DB design | Software engineering | Semantic Web | AI/NLP | Intelligence analysis |
| Primary use | DB structure | Code design | Knowledge sharing | Knowledge retrieval | Business operations |
| Instantiation | Rows/records | Object instances | RDF triples | Nodes/edges | Business objects |
| Relationships | Foreign keys | Association/composition | ObjectProperty | Edges | LinkType |
| Derived props | Views/computed columns | Getters | Inference rules | Limited | DerivedProperty |
| Operations | Stored procedures | Methods | None | None | ActionType |
| Permissions | Table/row level | None | None | None | Object/property level |
| Versioning | Migration scripts | None | Limited | None | Lifecycle management |
| Runtime | Needs ORM | Needs compilation | SPARQL engine | Graph DB | Ontology Runtime |
| Business readability | Low | Medium | Low | Medium | High |
#3.2 Why ER Diagrams Are Not Enough
ER Diagram vs. Ontology
========================
ER diagrams describe "data storage structure":
+--------------+ +--------------+
| employees | | departments |
|--------------| |--------------|
| id (PK) | FK | id (PK) |
| name |--------->| name |
| dept_id (FK) | | head_id (FK) |
| salary | | budget |
| hire_date | +--------------+
+--------------+
Problems:
1. No business semantics -- What relationship is "dept_id"?
Reporting to? Belonging? Temporary assignment?
2. No derived properties -- "tenure" is not in the table
3. No operation definitions -- How do you "transfer department"?
4. No permission model -- Who can see salary?
5. No business rules -- Does transfer require approval?
Ontology describes a "business world model":
+--------------+ +--------------+
| Employee | | Department |
|--------------| |--------------|
| name | | name |
| salary [L] |--BELONGS_TO-->| budget |
| tenure [D] | | headcount [D]|
| flightRisk[D]| | avgTenure [D]|
+--------------+ +--------------+
|
| Actions:
| - TransferDepartment (requires approval)
| - Promote (requires HR + manager confirmation)
| - UpdateSalary (requires CompBand validation)
|
[L] = permission-protected [D] = derived Actions = executable
#3.3 Why OWL/RDF Is Too Heavy
OWL (Web Ontology Language) is the most comprehensive ontology language from academia, but it has several fatal problems in enterprise practice:
-
Overly expressive: OWL DL supports Description Logic, capable of expressing things like "all employees who have at least one subordinate and a salary exceeding X." But 99% of enterprise scenarios don't need that expressiveness.
-
Reasoning complexity: OWL DL reasoning is ExpTime-complete (exponential time), impractical at enterprise data volumes.
-
Lacks operational semantics: OWL is declarative "knowledge" -- it cannot define "operations."
-
Immature toolchain: Editors like Protege target ontology experts, not business analysts.
Palantir's approach: take the essence (entity-relationship-property model), discard the excess (complex reasoning, global namespaces), and add practical innovations (ActionType, DerivedProperty, permissions, version control).
#4. Ontology Lifecycle Management
#4.1 State Transitions
ObjectTypes in Palantir's Ontology have a well-defined lifecycle:
Ontology Type Lifecycle
========================
+----------+ Publish +----------+
| DRAFT | -------------> | ACTIVE |
| | | |
| Free to | | In prod |
| modify | | Changes |
| | | governed |
+----------+ +----+-----+
^ |
| Deprecate (add replacement annotation)
| |
| v
| +--------------+
| Revert to draft | DEPRECATED |
| (rare) | |
+---------------------| Still |
| queryable |
| No new |
| instances |
+------+-------+
|
Archive (after data migration)
|
v
+--------------+
| ARCHIVED |
| |
| Read-only |
| Historical |
| audit only |
+--------------+
Version Management:
+------------------------------------------------+
| ObjectType: Employee |
| |
| v1.0 (2023-01-15) -- Initial version |
| Properties: name, department, salary, hireDate|
| |
| v1.1 (2023-06-01) -- Add remote work properties |
| + remoteWorkStatus: Enum |
| + primaryWorkLocation: GeoPoint |
| |
| v2.0 (2024-01-01) -- Breaking change: split name|
| - name: String |
| + firstName: String |
| + lastName: String |
| + middleName: String (optional) |
| Migration: auto-split existing name |
| |
| v2.1 (2024-03-15) -- Add ML derived properties |
| + flightRisk: Float (derived, ML model) |
| + performanceScore: Float (derived, formula) |
+------------------------------------------------+
#4.2 Backward Compatibility
When an Ontology type is upgraded, what happens to applications built on the old version?
Backward Compatibility Strategies
==================================
Change Type Compatible Strategy
-------------------------------------------------------
Add optional property Safe Old apps ignore new props
Add derived property Safe Old apps unaffected
Add ActionType Safe Old apps don't call it
Rename property Migrate Provide alias transition
Remove property Breaking DEPRECATED -> migrate -> remove
Change property type Breaking Create new prop + migrate + deprecate
Remove ObjectType Breaking DEPRECATED -> ARCHIVED
#5. "Model Once, Use Everywhere"
#5.1 Core Principle
This is the most powerful idea in Palantir's Ontology: once you define an ObjectType in the Ontology, it becomes the shared foundation for all applications, analytics, dashboards, APIs, and AI.
"Model Once, Use Everywhere"
==============================
+------------------+
| Ontology |
| |
| ObjectTypes: |
| Employee |
| Department |
| Project |
+--------+---------+
|
+----------------+----------------+
| | |
v v v
+----------+ +----------+ +----------+
| Dashboard| | Mobile | | API |
| | | App | | (OSDK) |
| | | | | |
| Viz + | | Approval | | 3rd-party|
| Analytics| | Workflows| | Integr. |
+----------+ +----------+ +----------+
| | |
v v v
+----------+ +----------+ +----------+
| Pipeline | | AIP/LLM | | Reports |
| Data | | AI | | |
| | | Analysis | | |
| ETL + | | Natural | | Compli- |
| Transform| | Language | | ance + |
| | | Queries | | Audit |
+----------+ +----------+ +----------+
All these applications share the same Ontology.
When Ontology changes, all applications automatically adapt.
No need to model separately for each application.
#5.2 Practical Example: Multi-Scenario Reuse of Employee ObjectType
# Scenario 1: HR Dashboard
# Directly use Employee ObjectType properties and derived properties
dashboard.add_chart(
type="bar",
data=ontology.Employee.group_by("department")
.aggregate(count(), avg("salary")),
title="Headcount and Average Salary by Department"
)
# Scenario 2: Approval Workflow App
# Use Employee ObjectType's ActionType
app.register_action(
action=ontology.Employee.actions.TransferDepartment,
ui="form",
approval_chain=ontology.Employee.actions.TransferDepartment.approval
)
# Scenario 3: API (OSDK)
# External systems access the same Ontology via API
@osdk.endpoint("/employees/{id}")
def get_employee(id: str) -> Employee:
return ontology.Employee.get(id)
# Permissions auto-applied: caller can't see salary without access
# Scenario 4: AIP (LLM Integration)
# LLM understands business data through Ontology
aip_query = "List senior employees with tenure over 10 years and flight risk above 70%"
# AIP converts natural language to Ontology query:
# ontology.Employee.filter(tenure > 10, flightRisk > 0.7)
# And automatically applies caller's permissions
# Scenario 5: Data Pipeline
# ETL process writes to the same Ontology
pipeline.transform(
source="raw_hr_data",
target=ontology.Employee,
mapping={
"emp_no": "employeeId",
"full_name": ["firstName", "lastName"], # split
"dept_code": lambda x: ontology.Department.resolve(x) # FK resolution
}
)
#6. Network Effects and Lock-In Mechanisms
#6.1 Why Ontology Creates Extreme Lock-In
The Four Layers of Ontology Lock-In
=====================================
Layer 1: Data Lock-In
+--------------------------------------------+
| Enterprise core data is integrated into |
| the Ontology. |
| Migration = redo all data pipelines + |
| mappings + cleansing |
| Cost: $$$ |
+--------------------------------------------+
|
v
Layer 2: Model Lock-In
+--------------------------------------------+
| Business logic encoded in ObjectType / |
| LinkType / ActionType / DerivedProperty |
| Migration = redefine all business models |
| Cost: $$$$ |
+--------------------------------------------+
|
v
Layer 3: Application Lock-In
+--------------------------------------------+
| Dozens of dashboards, apps, APIs, and |
| pipelines built on the Ontology |
| Migration = rebuild all downstream apps |
| Cost: $$$$$ |
+--------------------------------------------+
|
v
Layer 4: Cognitive Lock-In
+--------------------------------------------+
| Teams think in Ontology terms: |
| "Customer has LTV", "Order has FULFILLED_BY"|
| becomes the team's shared language |
| Migration = change the entire |
| organization's mental model |
| Cost: Priceless |
+--------------------------------------------+
#6.2 Network Effects Analysis
The value of Ontology grows super-linearly with usage:
Value = f(ObjectType count, LinkType count, users, apps)
ObjectType
Count
^
| / Value
| /
| /
| /
| /
| /
| /
| /
| /
| /
|/
+-----------------------------------> Time
Why super-linear?
- 10 ObjectTypes can have up to 45 relationships (C(10,2))
- 20 ObjectTypes can have up to 190 relationships (C(20,2))
- Each new ObjectType can relate to all existing types
- Each new relationship can produce new derived properties and Actions
- Each new derived property can drive new dashboards and apps
#6.3 Migration Cost Estimates
| Enterprise Size | Ontology Complexity | Estimated Migration Cost | Estimated Timeline |
|---|---|---|---|
| Mid-size | 50 ObjectTypes, 100 LinkTypes | $5-15M | 12-18 months |
| Large | 200 ObjectTypes, 500 LinkTypes | $20-80M | 18-36 months |
| Very large | 500+ ObjectTypes, 1000+ LinkTypes | $100M+ | 3-5 years |
This is why Palantir's customer renewal rate exceeds 120% (net revenue retention) -- customers not only renew but continuously expand usage. Once you're on the Ontology path, the cost of turning back is too high.
#7. Deep Comparison with Traditional Data Modeling
#7.1 ER Diagrams (Entity-Relationship Diagrams)
Comparison: Semantic Richness of Relationships
================================================
In an ER diagram:
employees.dept_id --> departments.id
This tells you:
[Y] Two tables are linked by a foreign key
[N] What business relationship is this? (Belonging? Managing? Temp assignment?)
[N] Does this relationship have properties? (Since when?)
[N] Does this relationship have directionality?
[N] Does this relationship have cardinality constraints? (beyond 1:N)
In Ontology:
Employee --BELONGS_TO--> Department
| since: Date
| primary: Boolean
| cardinality: N:1
Employee --TEMPORARILY_ASSIGNED_TO--> Department
| since: Date
| until: Date
| reason: String
| cardinality: N:M
Two completely different business relationships that would be
the same foreign key in an ER diagram.
#7.2 UML Class Diagrams
Comparison: Runtime Capabilities
=================================
UML Class Diagram:
+------------------+
| Employee |
+------------------+
| - name: String |
| - salary: double |
+------------------+
| + getName() |
| + setSalary() |
| + transfer() |
+------------------+
This is a design-time blueprint. It must be compiled into code to run.
Modify UML -> modify code -> compile -> test -> deploy
Palantir Ontology:
ObjectType Employee is a runtime object.
Modify ObjectType -> immediately effective (hot update).
No recompilation needed. No redeployment needed.
This is like the difference between editing an Excel formula
vs. modifying Java code.
#8. coomia-dip Platform's Ontology Implementation
coomia-dip implements the same core philosophy but in an open-source manner:
coomia-dip Ontology Architecture
=================================
+---------------------------------------------+
| Control Layer (Spring Boot) |
| |
| +----------------------------------------+ |
| | Ontology Service (gRPC) | |
| | | |
| | ObjectTypeManager | |
| | LinkTypeManager | |
| | ActionTypeManager | |
| | DerivedPropertyEngine | |
| | VersionManager (DRAFT->ACTIVE->...) | |
| | PermissionEngine | |
| +----------------------------------------+ |
| | |
| | gRPC |
| v |
| +----------------------------------------+ |
| | Data Layer (Quarkus + Iceberg) | |
| | | |
| | Actual data stored in Apache Iceberg | |
| | Data versioning via Nessie | |
| | Schema syncs with Ontology ObjectType | |
| +----------------------------------------+ |
| | |
| | gRPC |
| v |
| +----------------------------------------+ |
| | Intelligence Layer (FastAPI) | |
| | | |
| | DerivedProperty computation (Python) | |
| | ML model inference | |
| | AIP Logic workflows | |
| +----------------------------------------+ |
+---------------------------------------------+
External SDK:
+--------------------------------------------+
| Python SDK (ontology_sdk) |
| |
| # Use Ontology like Palantir's OSDK |
| client = OntologyClient("http://...") |
| employees = client.Employee.filter( |
| department="Engineering", |
| tenure__gt=5 |
| ) |
| for emp in employees: |
| print(emp.name, emp.derived.flightRisk)|
+--------------------------------------------+
Key differences between coomia-dip and Palantir:
| Dimension | Palantir Foundry | coomia-dip |
|---|---|---|
| Open source | No | Yes, Apache 2.0 |
| Ontology engine | Java (proprietary) | Spring Boot + gRPC (open) |
| Data storage | Proprietary | Apache Iceberg + Nessie (open) |
| Derived properties | Proprietary | Python + DAG engine (open) |
| SDK | OSDK (TypeScript) | Python SDK + (future) TypeScript SDK |
| Deployment | SaaS + on-prem | Docker Compose / K8s (self-hosted) |
#9. The Future of Ontology: Industry Standard or Proprietary Moat?
#9.1 Industry Trends
In 2024-2025, more and more companies are talking about "Ontology":
- Snowflake discusses "Semantic Layer" -- essentially a simplified Ontology
- Databricks Unity Catalog offers metadata management, moving toward Ontology
- Microsoft Fabric's OneLake has a similar unified model concept
- dbt's Semantic Layer is another directional attempt
But none of these match the completeness of Palantir's Ontology -- most achieve only "unified metadata," lacking ActionType, DerivedProperty, and a complete permission model.
#9.2 The Open-Source Opportunity
Precisely because the market lacks a complete open-source Ontology solution, projects like coomia-dip have enormous opportunity. Key differentiators include:
- Complete Ontology stack: Not just metadata, but a full model with Object, Link, Action, and Derived
- Open standards: Avoid vendor lock-in
- Extensible: Enterprises can freely customize to their needs
- Community-driven: Not subject to a single company's commercial strategy
#Key Takeaways
-
Ontology is the core concept behind Palantir's success, but Palantir didn't invent it. Its philosophical lineage traces to Aristotle, through AI knowledge representation and the Semantic Web, before Palantir engineered it into an "operable business world model." Its uniqueness lies in embedding ActionType (operations) and permission controls into the data model -- something ER diagrams, UML, and OWL never achieved.
-
"Model once, use everywhere" is not a marketing slogan but a genuine architectural principle. Once you define Employee in the Ontology, every dashboard, app, API, and AI assistant automatically gains the ability to understand and operate on Employee. This unity eliminates the enormous waste of "each application maintaining its own data model."
-
Ontology's lock-in effect is the foundation of Palantir's business model. Data lock-in -> model lock-in -> application lock-in -> cognitive lock-in: four layers of lock-in make migration costs grow exponentially. Open-source alternatives like coomia-dip offer strategic value by providing an Ontology platform free from lock-in, letting enterprises enjoy Ontology's power while retaining full control over their data and models.
#Next Article
“S1-06: Palantir's Branching: Managing Data Worlds Like Git
If Ontology is Palantir's soul, then Branching is its time-travel superpower. Imagine forking the entire enterprise's data into a branch, running what-if analysis (What if oil prices hit $200? What if this supplier goes dark?), then deciding whether to merge that branch back to main. Next up, we dive deep into Palantir's data branching technology.
Tags: #Palantir #Ontology #ObjectType #LinkType #ActionType #DerivedProperty #DataModeling #KnowledgeRepresentation #SemanticWeb #coomia-dip