iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A production-ready Palantir Foundry Ontology models the entities, relationships, and decisions people work with—not just the tables that happen to supply the data. Define object types around clear domain concepts, make links express meaningful relationships, and govern actions through separate rules for eligibility, permissions, and data access.
Start with the domain, not the source tables
An object type is the schema for a real-world entity or event; an object is one instance of that type. Foundry documentation compares the distinction to a dataset schema and its rows, but an Ontology type should be named and shaped for the domain users who need to understand and act on it. See Palantir’s object and link type reference and object types overview.
Choose object boundaries people can recognize
Use concrete singular nouns that identify distinct concepts, such as Employee, Department, or Venture. Avoid generic type names such as Data, Item, or Record, and avoid embedding source-system or implementation details in names that are meant to describe the domain. Keep properties concise and unambiguous. Palantir’s structural guidance recommends modeling concepts rather than reproducing dataset structure indiscriminately.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →A useful boundary test is whether users would recognize the proposed type as a thing or event they need to find, describe, relate, or change. If a source table combines separate concepts, a single object type may blur their meanings. Conversely, a table’s existence alone is not a reason to create a new type. Let the domain, the source data, and the application workflow determine the model.
#1 Best Overall
- Used Book in Good Condition
Decide how objects are created
Use a backing datasource when objects represent existing operational data. Foundry also supports object types without backing datasources when actions create their objects. This can distinguish imported facts from records introduced through a workflow; choose the pattern that reflects the record’s actual lifecycle rather than assuming every type must map directly to a table. The object types overview describes both approaches.
Keep properties canonical and calculations appropriate
Palantir’s structural guidance puts the principle plainly: “Store each fact once. Use derived properties for convenience.” Duplicating a fact across objects can leave conflicting values when one copy changes and another does not. A value that depends on linked records or Ontology-level changes may be better derived than manually maintained.
Choose between pipeline transforms and derived properties
Use a pipeline transform for a value calculated from stable properties on the same object. Use a derived property when the value depends on linked objects or can change through Ontology actions. For example, a manager’s report count can be derived from linked employees if assignments may change through actions; manually maintaining a counter would create another value that must remain synchronized. These patterns are covered in Palantir’s structural guidance.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Derived properties run at query time, so weigh freshness and simpler maintenance against runtime cost. Palantir’s guidance describes them as generally suitable at low-to-moderate query scale under roughly 10,000 objects; this is a recommendation, not a benchmark or guaranteed performance boundary. Above that approximate scale, the documentation says they may add latency and that selective denormalization may be appropriate. If you denormalize, document which value is authoritative and how the copy is refreshed so the convenience field does not become a second source of truth.
Make links represent domain relationships
A link type defines a relationship between two object types and can be traversed from either side. Defining a link does not require creating a separate reverse link type. Before adding one because two datasets share a foreign key, ask whether the relationship has meaning in the domain. Palantir describes link metadata and traversal in its link type metadata documentation.
Choose a direct link or an object-backed relationship
| Pattern | Use it when | Example |
|---|---|---|
| Direct link | The association has no attributes of its own and does not need to be managed as a separate record. | Employee → Department |
| Object-backed relationship | The association has its own role, dates, status, allocation, or workflow context. | Employee → Venture Staffing → Venture |
For example, an employee’s role and start date on a venture describe that particular staffing relationship, not the employee in every context or the venture in general. Representing the association as a linking object gives those values an unambiguous home and lets an application inspect the relationship as a record. Palantir’s structural guidance advises against links created solely because datasets share a foreign key.
Rank #3
Configure cardinality and key mapping deliberately
Set the cardinality on both sides to match the domain and source data. For one-to-one and one-to-many relationships, Foundry can map a foreign key to a primary key. For many-to-many relationships, it uses a join table with key pairs; an object-backed arrangement is another option when the association itself needs properties. Link metadata also includes the related object types, key mappings, display and API names, and visibility. The configuration details are in Palantir’s link type metadata and create link type documentation.
Free tools Windows power users keep installed
One-click scans. No signup required.
A join table is suitable for straightforward membership. Prefer a backing object when relationship-specific information or workflow visibility makes the association a first-class domain record. Avoid choosing cardinality merely to match a convenient configuration: applications and users will rely on it to interpret which related objects are valid.
Use actions for governed changes
An action type defines edits to objects, property values, and links, and may include side-effect behavior. It gives an application a way to apply a domain-level decision rather than expose disconnected property edits. Palantir’s action types overview and type reference describe actions and their role in the Ontology.
Rank #4
Put business eligibility in submission criteria
Submission criteria—called validations in earlier documentation—determine whether an action can be submitted. Criteria can combine conditions involving the current user, action parameters, objects, and relationships. They are configured independently for each action type. Use them for business rules and eligibility checks, and give users a useful reason when a request cannot proceed. They are not permissions to view or edit the action configuration. See Palantir’s submission criteria documentation.
Record intent and inspect operational outcomes
For each production action, document its purpose, affected object and link types, inputs, criteria, side effects, and owner. Decide whether successful submissions need an action log: Palantir describes action logs as object types that capture successful submissions and can preserve context beyond the individual values edited. The action log documentation explains the feature.
Use action metrics to review usage and failure categories. Palantir says these metrics provide near-real-time information for the prior 30 days; they categorize failures including invalid parameters, scale limits, authentication, side effects, function failures, conflicts, and unclassified failures. Treat a category as a starting point for diagnosis: check the action’s inputs, dependencies, permissions, and affected records before changing its criteria. Details are in action metrics.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Review authorization as a full path
Foundry separates access to Ontology resources—the object, link, and action type schemas—from access to the actual objects and links. Production review therefore needs to cover both who can configure the model and who can read or change its data. Palantir’s object permissioning overview describes these layers.
Check user, data, and writeback permissions
According to Palantir’s action permissions documentation, an action user generally needs access to the edited object and link types and their data sources, and must pass the action’s submission criteria. Whether the user also needs edit permission on a writeback dataset depends on the object’s edit policy. The action configuration does not fully surface underlying object and data permissions, so builders must verify them separately.
New object types default to edits through actions, and Palantir discourages opening additional edit paths solely to make action-based editing work: dataset edit rights can expose more data than a workflow requires. Decide which edit paths users actually need, then verify each one against the intended data boundary. Action permissions and submission criteria serve different purposes; passing an eligibility rule does not grant access to data or to the action configuration.
Evaluate beta read/write authorizations in the target environment
Palantir marks read/write authorizations as beta. Its documentation says read authorization bounds the data an action may access, while write authorization sets a minimum security level for action outputs. Differing read and write boundaries can permit declassification. These controls do not replace user permissions or submission criteria. Because availability and behavior may depend on the Foundry environment and policy, verify the feature and its exact effect in the target tenant before relying on it. See read/write authorizations.
Production design review
Before releasing an Ontology-backed application, walk through the model with domain owners, application builders, and governance owners. Confirm the following:
Quick Recap
- Each object type represents a recognizable domain entity or event, with clear names and a deliberate source or action-created lifecycle.
- Each fact has an authoritative home; calculated values use a transform or derived property appropriate to their dependencies and expected query scale.
- Each link represents a meaningful relationship, with cardinality and key mapping that match the data; relationship-specific attributes belong on a linking object.
- Each action has a documented purpose, affected types, inputs, submission criteria, side effects, and owner.
- Access to ontology schemas, object and link data, action configuration, and any required writeback path has been checked separately.
- Someone is responsible for reviewing action metrics and deciding whether action logs are needed to retain successful-submission context.
- Any beta authorization feature has been checked against the behavior, availability, and policy of the deployment where it will run.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
