Palantir Foundry
Objects. Links. Actions.
Your ontology determines what is possible in Foundry. Get it wrong and you are rewriting pipelines and applications for months. BaileyFinch designs ontologies that work from day one and scale as the program grows.
Discuss Your Ontology →Why ontology design matters
Object types, relationships, properties: these decisions affect every pipeline, every Workshop application, every query your users run. Most teams start by mapping database tables directly to object types. That works until it does not. Then they discover their relationships are backwards, their property types do not match actual use cases, and their security model cannot support what they need to build.
A well-designed ontology models the operation, not the data schema. It captures how work actually happens, how objects relate to each other, and what actions users need to perform. Everything downstream (pipelines, Workshop apps, analytics) inherits the quality of the ontology design.
Our engineers design ontologies that reflect real operations and hold up under production load.
What we deliver
A complete, production-ready ontology implemented in your Foundry instance with documentation explaining the design decisions and how to extend it.
Object types that match how your organization works. Properties with the right data types, validation rules, and structure to support actual use cases. Not a copy of your database schema.
Link types that capture how objects connect to each other with the right cardinality, directionality, and business meaning. This determines what questions users can answer and what workflows are possible.
Row-level security policies, restricted views, organization markings for multi-tenant setups, and property-level access controls where needed. Security designed in from the start, not bolted on after the fact.
Action definitions with validation rules, permission checks, and parameters configured for the workflows your users need to perform in Workshop applications. Actions that write back to the ontology correctly.
Ontology interfaces for shared behavior across object types. Function-backed properties that compute derived values without duplicating data in pipelines. The patterns that keep ontologies maintainable at scale.
Space and organization isolation for multi-tenant deployments. Controlled data sharing across business units or customers. Restricted views configured properly, with Marketplace packaging where distribution is required.
How we approach ontology design
01
We start with how your organization works, not what your database looks like. Who makes decisions, what data do they need, and what actions do they take? The ontology exists to serve the operation.
02
Object types modeled around operational concepts. Link types with correct cardinality and directionality. Properties with the right data types and structures. Every decision documented so your team can extend it.
03
Row-level security, restricted views, and organization markings designed alongside the ontology, not retrofitted later. Access controls that match your actual authorization requirements without blocking legitimate use.
04
The ontology is built in your Foundry instance with full documentation. We walk through every design decision with your team so they understand the structure and can maintain it independently as needs evolve.
Multi-organization architectures
If you are building for multiple customers or business units, your ontology needs to support organization isolation while allowing controlled data sharing. This requires careful space and security design from the beginning.
Organization Isolation
Organizations, spaces, and marking schemes configured so each tenant sees only their data. No cross-contamination, no accidental exposure. The isolation boundary is the security model, not application logic.
Controlled Sharing
Restricted view policies that allow specific data sharing without compromising the isolation model. Cross-organization patterns that work correctly with Foundry's security engine, not workarounds that break under edge cases.
Distribution
Ontology objects, pipelines, and Workshop applications packaged as Marketplace products for distribution across environments. Build once, deploy to many tenants with version control and managed updates.
Tell us about your data and what you are trying to build. We will propose an ontology design approach and walk you through the tradeoffs.
Architecture Audit
For teams scaling an agent pilot, inheriting an agent system, or moving toward ATO.