Palantir OSDK Deep Dive: How Ontology-first Development Is Reshaping Enterprise Software

#TL;DR

Palantir's OSDK lets developers interact with Ontology entities as if they were ordinary programming objects, powered by auto-generated type-safe client code derived from the Ontology Schema
The core philosophy is "Ontology-first, not table-first" -- developers never write SQL or worry about underlying storage; everything revolves around business Objects, Links, and Actions
Coomia DIP achieves equivalent (and in some ways deeper) developer experience through a Python SDK with an OntoPlatform facade covering 28 sub-modules and 39 gRPC clients, plus a TypeScript OSDK code generator

#1. What Is OSDK?

OSDK (Ontology Software Development Kit) is Palantir's official SDK that enables developers to interact with the Foundry Ontology using familiar programming languages -- primarily TypeScript and Python. Rather than working with raw database tables or generic REST endpoints, developers work with business-meaningful objects, relationships, and actions.

#Where OSDK Fits in the Palantir Ecosystem

Code

+------------------------------------------------------------------+
|                     Developer Application Layer                   |
|  +------------------+  +------------------+  +----------------+  |
|  | Web App (React)  |  | Backend Service  |  | Data Pipeline  |  |
|  | uses TS OSDK     |  | uses Python OSDK |  | uses Python    |  |
|  +--------+---------+  +--------+---------+  +-------+--------+  |
|           |                      |                    |           |
+-----------+----------------------+--------------------+-----------+
            |                      |                    |
            v                      v                    v
+------------------------------------------------------------------+
|                     OSDK Abstraction Layer                        |
|  +------------------+  +------------------+  +----------------+  |
|  | TypeScript OSDK  |  | Python OSDK      |  | REST API       |  |
|  | Type-safe client |  | Type-safe client |  | (underlying)   |  |
|  +--------+---------+  +--------+---------+  +-------+--------+  |
|           |                      |                    |           |
+-----------+----------------------+--------------------+-----------+
            |                      |                    |
            v                      v                    v
+------------------------------------------------------------------+
|                     Ontology Layer                                |
|  +------------+  +-----------+  +---------+  +----------------+  |
|  | Object     |  | Link      |  | Action  |  | Function       |  |
|  | Types      |  | Types     |  | Types   |  | Registry       |  |
|  +------------+  +-----------+  +---------+  +----------------+  |
+------------------------------------------------------------------+
            |                      |                    |
            v                      v                    v
+------------------------------------------------------------------+
|                     Data Layer                                    |
|  +------------+  +-----------+  +----------------------------+   |
|  | Datasets   |  | Streams   |  | External Sources           |   |
|  +------------+  +-----------+  +----------------------------+   |
+------------------------------------------------------------------+

#Core OSDK Capabilities

Code

+---------------------------+------------------------------------------+
| Capability                | Description                              |
+---------------------------+------------------------------------------+
| Type-safe object access   | Compile-time checking of property names  |
|                           | and types                                |
+---------------------------+------------------------------------------+
| Object query & filtering  | Complex conditional filters, sorting,    |
|                           | aggregation                              |
+---------------------------+------------------------------------------+
| Relationship traversal    | Navigate between objects via Link Types  |
+---------------------------+------------------------------------------+
| Action execution          | Invoke pre-defined business operations   |
+---------------------------+------------------------------------------+
| Function invocation       | Execute custom logic registered in the   |
|                           | Ontology                                 |
+---------------------------+------------------------------------------+
| Real-time subscriptions   | Listen for object change notifications   |
+---------------------------+------------------------------------------+
| Permission-aware          | Automatically respects Ontology-level    |
|                           | access controls                          |
+---------------------------+------------------------------------------+
| Code generation           | Auto-generate client code from Ontology  |
|                           | Schema                                   |
+---------------------------+------------------------------------------+

#2. Core Design Philosophy: Ontology-first

The most important concept to understand about OSDK is its design philosophy: Ontology-first, not table-first.

#Table-first vs. Ontology-first

Most developers are accustomed to the table-first paradigm: start with database tables, then use an ORM to map those tables to code objects. OSDK inverts this: define the Ontology (business objects and relationships) first, and let the platform handle storage.

Code

Table-first (Traditional ORM Pattern):

  Database Table --> ORM Mapping --> Code Object

  employees table              Employee class
  +---------+--------+        class Employee:
  | id      | INT    |          id: int
  | name    | VARCHAR|          name: str
  | dept_id | INT    |          dept_id: int  <-- FK, manual JOIN needed
  +---------+--------+

  Problems:
  - Developer must understand table structure and SQL
  - Relationships expressed via foreign keys and JOINs -- error-prone
  - Permissions require separate implementation
  - Business semantics live in code, not in the data model

Ontology-first (OSDK Pattern):

  Ontology Definition --> Code Generation --> Type-safe Client

  Employee Object Type          Generated Code
  +------------------+         const employee = await
  | Properties:      |           client.objects.Employee
  |   name: string   |             .where({ dept: "Eng" })
  |   email: string  |             .fetchPage();
  |   role: string   |
  | Links:           |         // Automatically handled:
  |   department ->  |         // - Storage query
  |     Department   |         // - Relationship traversal
  |   manages ->     |         // - Permission filtering
  |     Employee[]   |         // - Type checking
  +------------------+

#Why Ontology-first Is Superior

Code

+---------------------+------------------+-------------------------+
| Dimension           | Table-first      | Ontology-first          |
+---------------------+------------------+-------------------------+
| Abstraction level   | Low (rows/cols)  | High (objects/relations)|
| Type safety         | Runtime          | Compile-time            |
| Relationship expr.  | FK + JOIN        | Declarative links       |
| Access control      | Requires code    | Built into Ontology     |
| Schema evolution    | Migration scripts| Platform handles it     |
| Cross-data-source   | ETL required     | Transparent federation  |
| AI comprehension    | Low              | High (semantic metadata)|
| Learning curve      | Low              | Moderate (Ontology      |
|                     |                  | concepts needed)        |
+---------------------+------------------+-------------------------+

#3. TypeScript SDK: Type-Safe Ontology Operations

Palantir's TypeScript OSDK is the primary tool for frontend and full-stack developers to interact with the Ontology.

#Setup and Initialization

TypeScript

// Installation (Palantir style)
// npm install @osdk/client @osdk/oauth

import { Client } from "@osdk/client";
import { createConfidentialOauthClient } from "@osdk/oauth";

// Initialize client
const auth = createConfidentialOauthClient({
  clientId: "your-client-id",
  clientSecret: "your-client-secret",
  url: "https://your-instance.palantirfoundry.com",
});

const client = new Client({
  auth,
  baseUrl: "https://your-instance.palantirfoundry.com",
  ontologyRid: "ri.ontology.main.ontology.abc-123",
});

#Object Queries

TypeScript

// Fetch all Employee objects (paginated)
const employees = await client.objects.Employee.fetchPage({
  pageSize: 100,
});

// Conditional filtering
const engineers = await client.objects.Employee
  .where({
    department: "Engineering",
    startDate: { $gte: "2023-01-01" },
    status: "Active",
  })
  .orderBy("name", "asc")
  .fetchPage({ pageSize: 50 });

// Property access -- type-safe!
for (const emp of engineers.data) {
  console.log(emp.name);        // string -- confirmed at compile time
  console.log(emp.salary);      // number -- confirmed at compile time
  // emp.nonExistent;           // Compile error! Property does not exist
}

#Relationship Traversal

TypeScript

// Get all direct reports for a manager
const manager = await client.objects.Employee.get("emp-123");
const directReports = await manager.links.manages.fetchPage();

// Get the employee's department
const dept = await manager.links.department.get();
console.log(dept.name);  // "Engineering"

// Chain traversal: get all projects under a department
const projects = await dept.links.projects.fetchPage();

#Aggregation Queries

TypeScript

// Aggregate average salary by department
const avgSalary = await client.objects.Employee
  .aggregate({
    select: {
      salary: "avg",
      __count: true,
    },
    groupBy: ["department"],
  });

// Results are type-safe
avgSalary.data.forEach((group) => {
  console.log(`${group.group.department}: $${group.values.salary.avg}`);
  console.log(`  Count: ${group.values.__count}`);
});

#4. Python SDK: The Data Scientist's Ontology Gateway

The Python OSDK targets data scientists and backend engineers, providing a type-safe experience similar to the TypeScript SDK.

#Palantir Python OSDK Usage

Python

from foundry.v2 import FoundryClient

# Initialize
client = FoundryClient(
    auth=UserTokenAuth(
        hostname="https://your-instance.palantirfoundry.com",
        token="your-token",
    ),
)

# Query objects
employees = client.ontology.objects.Employee.list(
    page_size=100,
    where={
        "department": {"eq": "Engineering"},
        "status": {"eq": "Active"},
    },
    order_by=[{"field": "name", "direction": "asc"}],
)

# Iterate results
for emp in employees:
    print(f"{emp.name} - {emp.role}")

# Execute an Action
result = client.ontology.actions.PromoteEmployee.apply(
    employee_id="emp-123",
    new_role="Senior Engineer",
    effective_date="2024-01-01",
)

#Python in Data Pipelines

Python

import pandas as pd

# Export Ontology objects to DataFrame
df = client.ontology.objects.SalesOrder.to_dataframe(
    where={"status": "Completed", "year": 2024},
    properties=["order_id", "customer", "amount", "region"],
)

# Analyze with pandas
summary = df.groupby("region")["amount"].agg(["sum", "mean", "count"])
print(summary)

# Write results back to Ontology (via Action)
for region, stats in summary.iterrows():
    client.ontology.actions.UpdateRegionMetrics.apply(
        region=region,
        total_sales=stats["sum"],
        avg_order_value=stats["mean"],
        order_count=int(stats["count"]),
    )

#5. Code Generation: From Schema to SDK

One of OSDK's most powerful features is automatic code generation -- generating type-safe client code directly from the Ontology Schema definition.

#Code Generation Pipeline

Code

+-------------------+
| Ontology Schema   |
| (Defined in       |
|  Foundry:         |
|  Object Types,    |
|  Link Types,      |
|  Action Types)    |
+---------+---------+
          |
          v
+-------------------+
| Schema Export      |
| (JSON/Protobuf)   |
+---------+---------+
          |
          v
+-------------------+
| Code Generator    |
| (@osdk/generator) |
+---------+---------+
          |
          +----> TypeScript type definitions (.ts)
          |        interface Employee {
          |          name: string;
          |          department: string;
          |          salary: number;
          |          links: {
          |            manages: Link<Employee[]>;
          |            department: Link<Department>;
          |          };
          |        }
          |
          +----> Python type definitions (.py)
                   class Employee(OntologyObject):
                     name: str
                     department: str
                     salary: float
                     # links auto-generated

#Generated Code Structure

Code

generated/
├── objects/
│   ├── Employee.ts          # Employee object type definition
│   ├── Department.ts        # Department object type definition
│   ├── Project.ts           # Project object type definition
│   └── index.ts             # Export all object types
├── actions/
│   ├── PromoteEmployee.ts   # Promotion Action definition
│   ├── TransferEmployee.ts  # Transfer Action definition
│   └── index.ts
├── links/
│   ├── EmployeeToDepartment.ts
│   ├── EmployeeManages.ts
│   └── index.ts
├── queries/                 # Pre-defined queries
│   └── index.ts
└── index.ts                 # Main entry point

#Automatic Updates on Schema Changes

When the Ontology Schema changes (e.g., adding a new property to Employee), re-running the code generator produces updated type definitions. If code references a deleted property, the TypeScript compiler immediately reports an error -- this is the core value of compile-time safety.

Code

Schema change: Employee adds "location" property

Before regeneration:
  emp.name       // OK
  emp.salary     // OK
  emp.location   // Compile error! Property does not exist

After regeneration:
  emp.name       // OK
  emp.salary     // OK
  emp.location   // OK -- new property available

Schema change: Employee removes "fax" property

Before regeneration:
  emp.fax        // OK

After regeneration:
  emp.fax        // Compile error! Property has been removed
                 // Developer must handle this change

#6. Functions: Writing Logic on the Ontology

Functions are the mechanism by which Palantir allows developers to write custom logic on top of the Ontology. Unlike traditional stored procedures, Functions run in Foundry's secure containers and can access Ontology objects while respecting permission constraints.

#Function Definition Examples

TypeScript

// Define a Function within Foundry
import {
  Function,
  OntologyEditFunction,
} from "@foundry/functions-api";
import { Employee, Department } from "@foundry/ontology-api";

export class EmployeeFunctions {
  // Read-only Function: calculate department budget utilization
  @Function()
  public async departmentBudgetUtilization(
    department: Department
  ): Promise<number> {
    const employees = await department.links.employees.all();
    const totalSalary = employees.reduce(
      (sum, emp) => sum + (emp.salary ?? 0),
      0
    );
    return totalSalary / (department.budget ?? 1);
  }

  // Edit Function: batch salary adjustment
  @OntologyEditFunction()
  public async batchSalaryAdjustment(
    department: Department,
    percentageIncrease: number
  ): Promise<void> {
    const employees = await department.links.employees.all();
    for (const emp of employees) {
      const currentSalary = emp.salary ?? 0;
      emp.salary = currentSalary * (1 + percentageIncrease / 100);
    }
  }
}

#Function-Ontology Relationship

Code

+-------------------------------------------------------------------+
|                    Function Execution Environment                  |
|                                                                    |
|   +-------------------+                                           |
|   | @Function()       |  Read-only: query objects, compute, return |
|   +-------------------+                                           |
|                                                                    |
|   +-------------------+                                           |
|   | @OntologyEdit     |  Read-write: create, modify, delete objs  |
|   | Function()        |  All mutations committed as a transaction  |
|   +-------------------+                                           |
|                           |                                       |
|                           v                                       |
|              +------------------------+                           |
|              | Ontology Transaction   |                           |
|              | - Permission check     |                           |
|              | - Constraint validation|                           |
|              | - Audit logging        |                           |
|              | - Atomic commit        |                           |
|              +------------------------+                           |
+-------------------------------------------------------------------+

#7. Actions: Encapsulating Business Operations

Actions are the Ontology's mechanism for encapsulating business operations. Each Action defines input parameters, validation rules, and execution logic -- conceptually similar to Commands in Domain-Driven Design.

#Action Definition

Code

Action Type: "TransferEmployee"
+-----------------------------+
| Parameters:                 |
|   employee_id: string (req) |
|   target_dept: string (req) |
|   effective_date: date      |
|   reason: string            |
|                             |
| Validation Rules:           |
|   - employee must exist     |
|   - target_dept must exist  |
|   - date cannot be past     |
|   - user must have transfer |
|     permission              |
|                             |
| Side Effects:               |
|   - Update Employee.dept    |
|   - Create TransferRecord   |
|   - Notify HR system        |
|   - Write audit log entry   |
+-----------------------------+

#Invoking Actions via OSDK

TypeScript

// TypeScript invocation
const result = await client.ontology.actions.TransferEmployee.apply({
  employeeId: "emp-123",
  targetDept: "dept-456",
  effectiveDate: "2024-06-01",
  reason: "Team restructuring",
});

if (result.validation.result === "VALID") {
  console.log("Transfer completed successfully");
} else {
  console.log("Validation errors:", result.validation.errors);
}

Python

# Python invocation
result = client.ontology.actions.TransferEmployee.apply(
    employee_id="emp-123",
    target_dept="dept-456",
    effective_date="2024-06-01",
    reason="Team restructuring",
)

#Action vs. Traditional API Call

Code

+------------------+----------------------------+---------------------------+
| Dimension        | Traditional REST API       | Ontology Action           |
+------------------+----------------------------+---------------------------+
| Definition       | Code (Controller)          | Ontology Schema           |
| Validation       | Manual implementation      | Declarative rules         |
| Permissions      | Middleware / annotations   | Ontology permission model |
| Transactionality | Manual management          | Automatic transactions    |
| Auditing         | Manual logging             | Automatic audit trail     |
| Discoverability  | Swagger / OpenAPI docs     | Ontology Browser          |
| AI-callable      | Requires function-calling  | AIP auto-discovers and    |
|                  | definition                 | invokes                   |
| Cross-app reuse  | Requires microservice      | Shared across all apps    |
|                  | decomposition              |                           |
+------------------+----------------------------+---------------------------+

#8. Developer Workflow: From Code to Production

Palantir's complete developer workflow covers the entire lifecycle from design through deployment to monitoring.

#End-to-End Workflow

Code

Stage 1: Design Ontology
+-------------------------------------------------------------------+
| Foundry Ontology Manager                                          |
|                                                                    |
| 1. Define Object Types (Employee, Department, Project, ...)       |
| 2. Define Properties (name: string, salary: number, ...)          |
| 3. Define Link Types (Employee --manages--> Employee, ...)        |
| 4. Define Action Types (TransferEmployee, PromoteEmployee, ...)   |
| 5. Configure permissions and constraints                          |
+-------------------------------------------------------------------+
                    |
                    v
Stage 2: Generate SDK
+-------------------------------------------------------------------+
| Code Generator                                                    |
|                                                                    |
| $ osdk generate --ontology my-ontology --lang typescript           |
| $ osdk generate --ontology my-ontology --lang python               |
|                                                                    |
| Output: Type definition files in generated/ directory              |
+-------------------------------------------------------------------+
                    |
                    v
Stage 3: Write Code
+-------------------------------------------------------------------+
| Developer IDE (VSCode / IntelliJ)                                 |
|                                                                    |
| - Use generated type definitions for IntelliSense                 |
| - Write Functions (business logic)                                |
| - Build frontend apps (React + OSDK)                              |
| - Build backend services (Node.js / Python + OSDK)                |
+-------------------------------------------------------------------+
                    |
                    v
Stage 4: Test
+-------------------------------------------------------------------+
| Local Tests + Foundry Test Environment                            |
|                                                                    |
| - Unit tests: mock OSDK client                                    |
| - Integration tests: connect to test Ontology                     |
| - End-to-end tests: full flow verification                        |
+-------------------------------------------------------------------+
                    |
                    v
Stage 5: Deploy
+-------------------------------------------------------------------+
| Foundry Deployment Pipeline                                       |
|                                                                    |
| - Functions deploy to Foundry runtime                             |
| - Frontend apps deploy to Foundry Hosted Apps                     |
| - Automated CI/CD integration                                     |
+-------------------------------------------------------------------+
                    |
                    v
Stage 6: Monitor
+-------------------------------------------------------------------+
| Foundry Operations Dashboard                                      |
|                                                                    |
| - Function execution logs and performance metrics                 |
| - Action execution history and audit trails                       |
| - Object change timelines                                         |
| - Alerts and notifications                                        |
+-------------------------------------------------------------------+

While Palantir's end-to-end workflow is powerful, it is entirely locked into its closed ecosystem. For organizations that need self-hosted deployments or want to avoid vendor lock-in, Coomia DIP provides an equally comprehensive Ontology-first development workflow built on open standards and open-source technologies.

#9. Comparison: OSDK vs. ORM vs. REST API

To make OSDK's value concrete, let us compare it against traditional ORM and REST API approaches for the same requirement.

#Same Requirement, Three Implementations

Requirement: Fetch all active employees in the Engineering department, sorted by start date, including their project information.

Approach A: Traditional SQL + ORM (SQLAlchemy)

Python

# Must understand table structure, foreign keys, SQL JOINs
from sqlalchemy import select, and_
from models import Employee, Department, ProjectAssignment, Project

stmt = (
    select(Employee, Project)
    .join(Department, Employee.dept_id == Department.id)
    .outerjoin(
        ProjectAssignment,
        Employee.id == ProjectAssignment.employee_id
    )
    .outerjoin(
        Project,
        ProjectAssignment.project_id == Project.id
    )
    .where(
        and_(
            Department.name == "Engineering",
            Employee.status == "Active",
        )
    )
    .order_by(Employee.start_date.asc())
)

results = session.execute(stmt).all()

# Still need to manually handle:
# - Permission filtering (who can see which employees?)
# - Data masking (should salary be hidden?)
# - Audit logging (who queried what, when?)

Approach B: REST API

Python

import requests

# Must know API endpoints, parameter formats, pagination logic
response = requests.get(
    "https://api.example.com/v1/employees",
    params={
        "department": "Engineering",
        "status": "Active",
        "sort": "start_date:asc",
        "include": "projects",  # Requires API support for includes
        "page_size": 100,
    },
    headers={"Authorization": f"Bearer {token}"},
)

employees = response.json()["data"]

# If API does not support includes, N+1 queries needed:
for emp in employees:
    projects_resp = requests.get(
        f"https://api.example.com/v1/employees/{emp['id']}/projects",
        headers={"Authorization": f"Bearer {token}"},
    )
    emp["projects"] = projects_resp.json()["data"]

Approach C: OSDK (Ontology-first)

TypeScript

// No need to know storage, write SQL, or handle JOINs
const engineers = await client.objects.Employee
  .where({
    department: "Engineering",
    status: "Active",
  })
  .orderBy("startDate", "asc")
  .fetchPage({ pageSize: 100 });

// Relationship traversal is a first-class citizen
for (const emp of engineers.data) {
  const projects = await emp.links.projects.all();
  console.log(`${emp.name}: ${projects.map(p => p.name).join(", ")}`);
}

// Permissions, masking, auditing -- all handled by the Ontology layer

#Comprehensive Comparison Matrix

Code

+--------------------+------------------+------------------+------------------+
| Dimension          | ORM (SQLAlchemy) | REST API         | OSDK             |
+--------------------+------------------+------------------+------------------+
| Learning curve     | Moderate         | Low              | Moderate         |
| Type safety        | Partial (runtime)| None             | Full (compile)   |
| Relation traversal | Requires JOIN    | N+1 or include   | First-class      |
| Access control     | Manual           | Middleware       | Built-in         |
| Audit logging      | Manual           | Manual           | Built-in         |
| Data masking       | Manual           | Manual           | Built-in         |
| Schema evolution   | Migration scripts| API versioning   | Auto-adapts      |
| Cross-data-source  | Multiple conns   | Multiple APIs    | Transparent      |
| AI integration     | None             | Requires wrapping| Native (AIP)     |
| Real-time subs     | Requires CDC     | WebSocket/SSE    | Built-in         |
| Code volume        | High             | Medium           | Low              |
| Debug complexity   | High (SQL trace) | Medium (HTTP)    | Low (Ontology)   |
+--------------------+------------------+------------------+------------------+

Of course, while Palantir's OSDK is technically impressive, its closed ecosystem and steep licensing fees ($1M+ per year) mean most organizations cannot access this developer experience. Coomia DIP is built on the same Ontology-first philosophy and provides a fully open-source SDK, enabling teams of any size to benefit from the same development paradigm.

#10. Coomia DIP Implementation: Python SDK + TypeScript OSDK

Coomia DIP follows the same Ontology-first philosophy as Palantir's OSDK but with its own implementation approach and some notable advantages.

#Architecture Comparison

Code

Palantir OSDK                          Coomia DIP SDK
+--------------------+                 +--------------------+
| TypeScript OSDK    |                 | TypeScript OSDK    |
| (npm package)      |                 | (Code Generator)   |
+--------------------+                 +--------------------+
| Python OSDK        |                 | Python SDK         |
| (pip package)      |                 | (OntoPlatform)     |
+--------------------+                 +--------------------+
         |                                      |
    REST API                               gRPC (39 clients)
         |                                      |
+--------------------+                 +--------------------+
| Foundry Backend    |                 | 8-Plane Backend    |
| (closed source)    |                 | (open source)      |
+--------------------+                 +--------------------+

#OntoPlatform Facade: 28 Sub-Modules

The core of Coomia DIP's Python SDK is the OntoPlatform class -- a unified Facade covering all platform capabilities:

Python

from ontology_sdk import OntoPlatform

# One-line initialization connects to the entire platform
platform = OntoPlatform(
    host="localhost:50051",
    project_id="proj-001",
    world_id="world-main",
)

# 28 sub-modules, each covering a domain
platform.ontology         # Ontology CRUD
platform.objects          # Object instance operations
platform.query            # Query engine
platform.actions          # Action execution
platform.functions        # Function management
platform.decisions        # Decision trees
platform.reasoning        # Rule inference
platform.scenarios        # Scenario simulation
platform.worlds           # World/Branch management
platform.pipelines        # Data pipelines
platform.analytics        # Analytics queries
platform.search           # Full-text search
platform.subscription     # Real-time subscriptions
platform.metrics          # Metrics management
platform.governance       # Audit & governance
platform.auth             # Authentication & authorization
platform.data_export      # Data export
platform.datasources      # Data source management
platform.tenants          # Tenant management
platform.instance_detail  # Object aggregate details
# ... 28 sub-modules total

#Practical Usage Examples

Python

from ontology_sdk import OntoPlatform

platform = OntoPlatform(
    host="localhost:50051",
    project_id="proj-001",
    world_id="world-main",
)

# 1. Define an Object Type
platform.ontology.create_object_type(
    name="Employee",
    properties=[
        {"name": "name", "type": "STRING", "required": True},
        {"name": "email", "type": "STRING", "required": True},
        {"name": "department", "type": "STRING"},
        {"name": "salary", "type": "DOUBLE"},
        {"name": "start_date", "type": "DATE"},
    ],
    primary_key="employee_id",
)

# 2. Create an object instance
platform.objects.create("Employee", {
    "employee_id": "emp-001",
    "name": "Alice Chen",
    "email": "alice@example.com",
    "department": "Engineering",
    "salary": 120000,
    "start_date": "2023-06-15",
})

# 3. Query objects
results = platform.query.find_objects(
    object_type="Employee",
    filters={"department": {"eq": "Engineering"}},
    order_by=[{"field": "name", "direction": "ASC"}],
    page_size=50,
)

# 4. Execute an Action
platform.actions.execute(
    action_type="PromoteEmployee",
    params={
        "employee_id": "emp-001",
        "new_role": "Senior Engineer",
        "effective_date": "2024-01-01",
    },
)

# 5. Rule inference
inference = platform.reasoning.infer(
    ruleset_id="salary-band-rules",
    input_data={
        "role": "Senior Engineer",
        "years_exp": 5,
        "location": "Beijing",
    },
)
print(f"Recommended salary range: {inference.result}")

# 6. Decision tree execution
decision = platform.decisions.execute(
    tree_id="hiring-approval",
    variables={
        "candidate_level": "senior",
        "budget_remaining": 500000,
    },
)
print(f"Decision outcome: {decision.outcome}")

# 7. Scenario simulation (World Fork)
scenario = platform.scenarios.fork_world(
    name="2025-budget-scenario",
    description="Simulate impact of 20% budget cut in 2025",
)

#Palantir vs. Coomia DIP Developer Experience Comparison

Code

+----------------------+---------------------+-------------------------+
| Dimension            | Palantir OSDK       | Coomia DIP SDK          |
+----------------------+---------------------+-------------------------+
| Language support     | TypeScript, Python  | Python (full), TS (gen) |
| Protocol             | REST + WebSocket    | gRPC + WebSocket + SSE  |
| Facade pattern       | Per-resource split  | OntoPlatform unified    |
| gRPC client count    | N/A (REST)          | 39 dedicated clients    |
| Sub-module count     | ~15                 | 28                      |
| Code generation      | Yes                 | Yes                     |
| Async support        | Yes                 | Yes                     |
| Streaming support    | Limited             | Native gRPC streaming   |
| Open source          | No                  | Yes                     |
| Self-hosted          | No                  | Yes                     |
| Reasoning/Decision   | Via AIP             | Native (9 inference     |
|                      |                     | clients)                |
| Scenario simulation  | Limited             | Native World Fork       |
+----------------------+---------------------+-------------------------+

#Key Takeaways

OSDK's core value is not "yet another SDK" but a paradigm shift to Ontology-first development. Developers no longer worry about underlying storage, JOIN logic, or permission implementation -- the Ontology layer handles all of this automatically. This paradigm also enables AI (via AIP) to understand and operate on business systems.
Code generation is the key to type safety. Type definitions auto-generated from the Ontology Schema let developers catch schema-change errors at compile time rather than runtime. This dramatically reduces maintenance costs for large-scale systems.
Coomia DIP's Python SDK already exceeds Palantir's OSDK in depth -- 28 sub-modules, 39 gRPC clients, native inference/decision/scenario-simulation integration. Open-source availability and native gRPC support are key differentiators, enabling more flexible deployment and higher performance.

#Want Palantir-Level Capabilities? Try Coomia DIP

Palantir's technology vision is impressive, but its steep pricing and closed ecosystem put it out of reach for most organizations. Coomia DIP is built on the same Ontology-driven philosophy, delivering an open-source, transparent, and privately deployable data intelligence platform.

AI Pipeline Builder: Describe in natural language, get production-grade data pipelines automatically
Business Ontology: Model your business world like Palantir does, but fully open
Decision Intelligence: Built-in rules engine and what-if analysis for data-driven decisions
Open Architecture: Built on Flink, Doris, Kafka, and other open-source technologies — zero lock-in

👉 Start Your Free Coomia DIP Trial↗ | View Documentation↗

#TL;DR

#1. What Is OSDK?

#Where OSDK Fits in the Palantir Ecosystem

#Core OSDK Capabilities

#2. Core Design Philosophy: Ontology-first

#Table-first vs. Ontology-first

#Why Ontology-first Is Superior

#3. TypeScript SDK: Type-Safe Ontology Operations

#Setup and Initialization

#Object Queries

#Relationship Traversal

#Aggregation Queries

#4. Python SDK: The Data Scientist's Ontology Gateway

#Palantir Python OSDK Usage

#Python in Data Pipelines

#5. Code Generation: From Schema to SDK

#Code Generation Pipeline

#Generated Code Structure

#Automatic Updates on Schema Changes

#6. Functions: Writing Logic on the Ontology

#Function Definition Examples

#Function-Ontology Relationship

#7. Actions: Encapsulating Business Operations

#Action Definition

#Invoking Actions via OSDK

#Action vs. Traditional API Call

#8. Developer Workflow: From Code to Production

#End-to-End Workflow

#9. Comparison: OSDK vs. ORM vs. REST API

#Same Requirement, Three Implementations

#Comprehensive Comparison Matrix

#10. Coomia DIP Implementation: Python SDK + TypeScript OSDK

#Architecture Comparison

#OntoPlatform Facade: 28 Sub-Modules

#Practical Usage Examples

#Palantir vs. Coomia DIP Developer Experience Comparison

#Key Takeaways

#Want Palantir-Level Capabilities? Try Coomia DIP

Related Articles

Palantir Stock from $6 to $80: What Did the Market Finally Understand?

Why Can't Anyone Copy Palantir? A Deep Analysis of 7 Technical Barriers

Palantir's Pricing & Business Model: Why Customers Pay $100M/Year