Data Governance in Palantir Foundry: Markings, Lineage and Quality
How your policies become controls the platform enforces on its own
Quick Answer
In Foundry, data governance is not a separate module: it is four mechanisms applied as you model. Mandatory controls — markings, classification-based access control and organisations — which travel with the data as it is derived. Discretionary controls, which filter what somebody reads but do not follow an export. Lineage, which answers "if I change this, who is affected?". And quality monitoring, which raises the alarm before the business notices.
The important decision is not technical but a design one: what gets a mandatory control and what gets a discretionary one. Confusing them is the mistake we have seen cost the most in regulated deployments.
And there is still a part the platform does not solve: somebody has to decide the classification, the owners and the quality thresholds.
The platform enforces the policy. Writing it is still your job.
In a multinational with subsidiaries in several countries, the governance conversation repeats in every project: which data can teams in another subsidiary see, who authorises an exception, and how it is demonstrated to an auditor. Usually that conversation ends in a document and a permissions spreadsheet that drifts out of date within three months.
Foundry changes where it happens: controls are declared once over the data and the model, and the platform applies them to every query, every application and every agent.
A policy you have to remember to apply is not a policy. It is an intention.
Mandatory or Discretionary: The Decision That Shapes Everything
Palantir's security documentation distinguishes two families, and they are worth being clear about:
- Mandatory: markings, classification-based access controls and organisations. They apply to the unit of data and follow it as it is derived, supported by the platform's provenance and lineage.
- Discretionary: resource roles — owner, editor, viewer — and row and column filtering through restricted views and object and property policies. They determine what can be read, but do not extend to what is exported afterwards.
The rule we apply when designing: if the data must never appear in a file somebody downloads, it needs a mandatory control. A filtered view is excellent for shaping the working experience, not for containing sensitive information.
Organisations: How Subsidiaries Are Separated
Organisations are the natural mechanism for separating environments between subsidiaries or jurisdictions. In our deployments, the pattern that works combines three layers: the organisation sets membership, the marking protects sensitive categories — personal data, financial information, trade secrets — and roles distribute the work inside each domain.
When those three layers are designed together, the question "can this user in the French subsidiary see the German plant's cost?" has a verifiable answer rather than a political one.
Lineage: Answering Before You Break Something
Lineage supports two questions that in most organisations are answered by asking around the office:
- Impact analysis: if I change this source or this object, which applications, reports and agents stop working?
- Root cause: this number that does not add up, where did it come from?
It is the same problem we cover outside Palantir in data lineage in multi-cloud environments, with one difference: here you do not have to build it, it comes with the platform, and it is what makes mandatory controls propagate.
Quality: Warning Before the Business Does
A well-governed object is worth little if its data arrives late or incomplete. The platform includes data health monitoring and monitoring rules, documented in its monitoring section, with checks over builds and alerts when something degrades.
Our recommendation: define three thresholds for each critical object — maximum staleness, minimum completeness and expected volume — and route the alert to the domain owner, not to the platform team.
Who Decides What
Governance collapses when the platform decides alone. The split that works is the one we described in federated data governance: a shared group defines classification and minimum standards; each domain decides its objects, actions and thresholds; and the platform only enforces.
Checklist for a Regulated Deployment
- Is the classification written down before the first object is modelled?
- Which categories are protected with mandatory controls, and which with views?
- How are subsidiaries separated, and who approves an exception?
- Does each critical object have an owner, thresholds and an alert recipient?
- Can you reconstruct, for a specific action, who ran it and on which data?
Does your data governance live in a document and your permissions in a spreadsheet?
At Galde we deploy Palantir Foundry in multinational corporations in regulated sectors and in public administrations, where governance is not decoration: we translate your policies into controls the platform applies to every query.
How Galde Can Help
Through our Palantir consulting and implementation, we design classification, separation between subsidiaries and mandatory controls before modelling, which is when it is cheap.
Through data governance, we define owners, quality thresholds and the exception procedure, and leave them documented where they are used.
And through data platforms, we connect the sources and build the alerts that sustain those thresholds without manual intervention.
Conclusion
Foundry does not hand you data governance: it gives you a place where governance is enforced. The difference between a deployment that passes an audit and one that does not comes down to three decisions taken early: what is protected with mandatory controls, how subsidiaries are separated and who receives the alert when quality drops. None of that is a module you switch on. It is design.
Palantir®, Foundry® and AIP® are trademarks of Palantir Technologies Inc. Galde is not an official Palantir partner and is not affiliated with the company; we implement the platform for our clients.
Frequently Asked Questions
What is the difference between a marking and a restricted view?
A marking is a mandatory control: it follows the data as it is derived or copied. A restricted view filters what a user reads, but that filter does not travel with whatever is exported later.
How is data separated between subsidiaries in different countries?
With organisations for membership, markings or classification-based control for sensitive categories, and roles for day-to-day work inside each domain. The three layers are designed together.
Is Foundry's lineage useful for impact analysis?
Yes. It shows what depends on a source or an object before you change it, and traces where a number that does not add up came from. It is also what makes mandatory controls propagate.
How is data quality monitored?
With checks and monitoring rules over builds and datasets. What works is setting staleness, completeness and volume thresholds per critical object and routing the alert to the domain owner.
Do you need a dedicated governance team?
You need a small group that sets classification and minimum standards, and owners in each domain who decide about their objects. A central team deciding for everyone becomes the bottleneck.
