To enable Joint All-Domain Command and Control (JADC2), the U.S. military and its allies and partners rely heavily on the organizational and institutional efforts necessary to:
Central to the final element in that list is the ability to integrate, understand, and derive decision dominance from a legion of disparate source systems across warfighting functions that, in its end state, will connect sensors to shooters to sustainers at echelon. To help orient the defense software industrial base around the challenge of data model complexity across Joint Force and partner nation systems while providing an API surface for third-party application development, Palantir developed the Defense Ontology resulting from the functional expertise continuously honed supporting the Army, Air Force, Navy, Marine Corps, and the Combatant Commands across several domains central to military doctrine.
Developed as an API to abstract away the need to understand complex, heterogenous, and disparate data models across warfighting functions and domains, Palantir’s Defense Ontology provides an explicit, semantically consistent data layer that is consumable by third-party applications from the environments in which they are built. Palantir persistently modifies the Defense Ontology alongside the Services to ensure its types serve as a trusted foundation, as opposed to a static data model, upon which third-parties develop and deploy operational applications that strengthen the military's most flexible tool: its software.
Learn more about the Ontology in Foundry.
The Ontology SDK provides access to the Defense Ontology and its interfaces to extend third-party applications from where they are developed. The Ontology SDK grants ergonomic access to Ontology APIs, generates only relevant functions and types for querying, provides TypeScript bindings to enable rapid React application development, and is secured by a token scoped precisely to the ontological entities a third-party application should access based on its intersection with your own permissions to the Ontology’s backing data.
Interfaces describe an object type's shape and capabilities to ensure consistent modeling of and interaction with object types that share a common shape. Composed of shared properties, link types, and their metadata, interfaces provide type safety and enable users to interact with the Ontology without knowledge of or familiarity with its object types or their underlying data models. Interfaces can be implemented by multiple object types, extended with other interfaces as a means of composability, and conceptualized as an API layer enabling third-party applications to interact with the Defense Ontology without the need to support each individual object type.
Interfaces are inherently abstract, and their schemas are defined only by shared properties. Unlike object types, they do not contain a backing dataset and cannot be instantiated. Rather, interfaces help third-party builders reuse code by defining the shape of a virtual object and its properties which concrete object types implement. As an example, a developer building an Ontology SDK-driven React application plotting real-time location data for a unit's major end items could simply reference in its code a Major End Item interface that contains geotemporal properties shared and implemented by distinct object types representing multiple major end item object types, such as Tank, Humvee, or Aircraft.
To develop against the Defense Ontology, generate an Ontology SDK client using Foundry’s Developer Console. Once generated, Developer Console creates packages documenting the endpoints available to consume all relevant Ontology entities selected during the client creation process using TypeScript, Python, Java, or cURL.
Learn more about application building on top of Palantir Ontologies using the Ontology SDK.
While the Ontology SDK ensures third-party developers can treat Foundry as their application’s backend, Palantir’s platform-specific APIs, tailored to enable JADC2 workflows as their own SDK, enable interactions with Foundry and Gotham applications. Review the sample React ↗ applications in the Defense SDK's GitHub repository ↗. To begin developing with Palantir’s platform APIs, create a bearer token. To leverage these APIs in production applications, create a confidential client in Developer Console using a similar workflow required for the Ontology SDK. Learn more about using platform APIs alongside the Defense Ontology ↗.
Select a Defense Ontology domain to learn more about the interfaces which serve as abstract representations of its component real-world entities and the complex relationships between their properties.
Materiel interfaceTraversing the journey of a single object within an object type that implements the Materiel interface to see how it interacts with other entities in the ontology is a helpful learning exercise. The Materiel interface represents a specific asset, such as a Night Vision Goggle or M1 Abrams Tank. The materielId shared property uniquely identifies each materiel item and also includes properties like materielIdType (such as as a National Stock Number), materielName, and a list of materielTaxonomyId properties.
Through link type constraints, each Materiel object can be associated with one or more Materiel Taxonomy entries. For example, a Night Vision Goggle might have a materielTaxonomyId which points to a certain taxonomy code, such as Optical Equipment, which in which in turn may have a parent taxonomy like Electronics. This hierarchical classification is enforced by link type constraints between Materiel:Materiel Taxonomy and Materiel Taxonomy:Parent Taxonomy.
Materiel items also play a critical role in operational requirements and event tracking. The Materiel Requirement interface expresses the need for a particular materiel item by a unit. For instance, a unit may have a Materiel Requirement specifying it needs 20 Night Vision Goggle items. This requirement references both the Unit Id (which links it to a given unit) and the Materiel Id (which links it to a Materiel item) to identify who needs what.
Similarly, when materiel quantities change, such as when equipment is issued, received, or serviced, these actions are recorded as instances of an object type that implements the Materiel Change Event interface and references the impacted Materiel Id and Unit Id. The Defense Ontology enables you to record the current status and quantity of materiel for a unit within instances of an object type that implements the Materiel Status Event interface that also links back to the relevant Materiel Id and Unit Id
The Materiel interface serves as a hub in the Defense Ontology's Sustainment domain, connecting classification (via taxonomy), operational needs (via requirements), and historical or real-time tracking (via events), all through well-defined shared properties and link constraints. This structure enables your application's users to navigate from a single item to its broader context by answering questions like: