Skip to content

Palantir Foundry Object Type Standards

Standard Operating Procedure · Version 1.0 · Last Updated: February 20, 2026
Scope: All Object Types built in Palantir Foundry


Executive Summary

Standard Requirement
ID Every Object Type must have an ID property as the Primary Key
Title Every Object Type must have a Name or Title property for display
Foreign Keys FK/Linked properties must be named [LinkedObjectType]ID
API Names and Property Details Use Palantir/Foundry defaults for each of these (Object Type API Name, Property Details: API and Property Name)

1. Overview

This SOP establishes naming and structural conventions for Object Types in Palantir Foundry. Adherence ensures:

  • Consistency — Predictable patterns across ontology objects
  • Maintainability — Easier navigation and onboarding
  • Data integrity — Reduced integration and referencing errors

2. Standards

2.1 Primary Key (ID) Property

Requirement: Every Object Type must include an ID property as the Primary Key.

Attribute Specification
Property name ID
Purpose Uniquely identifies each object instance
Mandatory Yes — no exceptions

Examples:

Object Type Primary Key Property
Company ID
Person ID
Project ID

2.2 Title Property

Requirement: Every Object Type must include a display/identification property.

Attribute Specification
Preferred names Name or Title
Flexibility Alternatives (e.g., Label, Display Name) permitted when domain terminology dictates and rationale is documented
Default Use Name or Title unless justified otherwise

Examples:

Object Type Title Property
Company Name
Document Title
Project Name

2.3 Foreign Key and Linked Type Naming

Requirement: Every Foreign Key or Linked Type property must include the Linked Object Type in its property name.

Attribute Specification
Naming pattern [LinkedObjectType]ID
Purpose Explicitly indicates the Linked Object Type and its Primary Key
Scope All FK and Linked Type properties

Valid examples:

PK Object Type PK Property Name FK Object Type FK Property Name FK Property Details API Name FK Property Details Property Name
Company ID Department Company ID companyId company_id
Department ID Employee Department ID departmentId department_id

Outliers

There might be use cases where there is a user facing property that includes ID in the name or label of the form field. These should not end in ID as properties ending with ID are reservered for foreign key or linked type properties.

Attribute Specification
Naming pattern CustomNameIDNumber
Purpose Ending the property with Number signifies that this is not a foreign key
Scope All properties that need ID in their names, should end with Number

Valid examples:

Property Name Property Field Label Property Details API Name Property Details Property Name
EmployeeIDNumber Employee ID employeeIdNumber employee_id_number
MaterialIDNumber Material ID materialIdNumber material_id_number
EquipmentIDNumber Equipment ID equipmentIdNumber equipment_id_number

2.4 API Names and Property Details:

Requirement: For each of these, use the Palantir/Foundry defaults.

Attribute Specification
Object Type API Name Casing PascalCase
Property Details API Name Casing camelCase
Property Details Property Name Casing snake_case
Purpose Following the defaults from Palantir/Foundry reduces the amount of work and tweaking for those creating these object types and properties
Scope All object types and properties

Valid examples

Attribute References Correct Casing
Object Type API Name Vendor Customer VendorCustomer
Property Details API Name Company ID companyId
Property Details Property Name Company ID company_id

3. Quick Reference Checklist

Use this checklist when creating or reviewing an Object Type:

  • ID — Object Type has an ID property as the Primary Key
  • Title — Object Type has a Name or Title property (or documented alternative)
  • Foreign Keys — All FK/Linked Type properties follow [LinkedObjectType]ID naming
  • Object Type and Property API Names and Details — All Object Type API Names and Property Type Details (API Name, Property Name) are using Foundry defaults

4. Exceptions and Deviations

Deviations from these standards require:

  1. Documentation — Written rationale for the exception
  2. Approval — Sign-off from the ontology/data model owner
  3. SOP update — If the deviation becomes recurring, update this document accordingly

5. Revision History

Version Author Description
1.00 Tyler DeVries Initial release