How to Design a Palantir Foundry Ontology That Survives Production at Scale

Palantir Foundry pilots often succeed with small teams mapping datasets into an Ontology, but problems emerge as more use cases are added and design shortcuts from the proof-of-concept phase get inherited by production systems. Key issues include ambiguous Object Type definitions, link types that cause double-counting, and Actions with no clear ownership or audit trail. A well-structured Foundry Ontology should treat Object Types as entities users actively track or act on, with stable and deterministic primary keys that won't break downstream references during pipeline rebuilds. Link Types should reflect relationships the business actually uses, not every foreign key in the source schema, and properties should be limited to what users filter on or reason about. In production, the Ontology functions like a public API with many consumers, requiring stable definitions, named owners, controlled changes, secure access, and auditable writes.