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 OSDK 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 OSDK 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 OSDK 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 OSDK 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 OSDK 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.
Two capabilities of interfaces are central to how the Defense OSDK models complex, real-world relationships: interface extensions and interface link type constraints.
An interface can extend another interface, creating a more specific child that inherits all of its parent's properties and link type constraints while adding its own. Object types implementing the child interface automatically satisfy the parent interface as well. For example, in the Order of Battle domain, the Unit interface extends the more general Organization interface. A third-party application querying against Organization will seamlessly include units alongside other organizational entities such as task forces or commands without additional code.
Interface link type constraints define relationships that any implementing object type must satisfy. Rather than hard-coding link types between specific object types, a link type constraint declares the shape of a relationship at the interface level: its target type, cardinality, and whether it is required. Implementing object types then provide concrete link types that fulfill those constraints. This enables the Defense OSDK to model relational patterns — such as organizational hierarchies — that work across any object types implementing the relevant interfaces.
These patterns reflect the Ontology best practice of favoring composition over deep inheritance hierarchies: interfaces are designed around capabilities, and object types compose multiple interfaces rather than descending from a single long inheritance chain.
To develop against the Defense OSDK, 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 OSDK ↗.
Select a Defense OSDK 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.