Running an Organisation on Palantir Foundry: An Organisation Modelled Once, Read Differently by Everyone

Every function of a services business is a different view of the same handful of facts: who works here, what they did this week, which client it was for, and what money moved as a result. Sold separately, those views become products -an HR system, a timesheet tool, a billing package, a CRM - and each one keeps its own copy of the facts. Most of what gets called integration is the work of making those copies agree.

So, we stopped buying views and modelled the organisation once, on Palantir Foundry. People operations went first, because it is the function where the awkward question - once this is all in one place, who is allowed to see it? - bites hardest. That part runs today: one application, one deployment, four roles, where what you are shown is derived from your identity at the platform layer, and the data model rather than the interface is what refuses a read.

SECTION 01
Why nothing ever got consolidated

Two things sat underneath the mess. There was no single version of a person: the same employee existed as a row in several workbooks, under several spellings, against several manager fields, with no key joining any of them, so every cross-cutting question -utilisation, billability, cost against a project - waited on somebody doing the join by hand and hoping. And a workbook cannot express who should see what. Salary lived two columns from designation; disciplinary notes shared a file with the holiday calendar. The only control on offer was the choice of who received the attachment, so managers worked from hand-cut extracts already stale on arrival, practice heads asked for allocation data and waited, employees could serve themselves nothing, and one mis-addressed email was a genuine incident. Nobody merges a pile of workbooks when the merged file is one everybody can read - and buying the modules separately would only have traded spreadsheets for as many products, each with an access model of its own to keep aligned.

What Aavya configured in Palantir Foundry: a sign-in resolves to an identity, group membership decides the role, and one Workshop shell assembles the home and the navigation around it. Ontology permissions on the objects do the actual enforcing - for people operations today, and for every function that reads the same graph later.

SECTION 02
What runs today

Resolved from your identity

-Your landing page

Leadership opens on an org-wide home, HR on an operations home, managers on their own team, everyone else on self-service. One deployment, four experiences, and no menu choice that picks between them.

-The navigation itself

Eight sections, each gated on its own. A practice head does not meet a greyed-out HR Operations entry with a request-access link behind it. There is nothing there to click.

-Your own record

The application takes the signed-in identity, resolves it to that person's employee object and scopes every widget to them - leave balance, timesheet, allocations, certifications. There is no colleague to land on by accident.

Still a person's call

-One menu entry, two implementations

Approvals & Tasks returns what you submitted if you are an employee, and that plus what is waiting on you if you approve. No duplicate item that most of the company can see and cannot use.

-Field-level authorship

You maintain your personal details and documents. Designation, cost centre and compensation are readable to you and writable by HR, and the split is enforced on the objects rather than in the form.

-Handing over authority

When an approver is away, delegation is granted explicitly - scoped to a request type and a date window and recorded - instead of a queue quietly stopping.

The home a person lands on, assembled from their identity. The left navigation is not a filtered view of a longer menu - sections the viewer is not in the group for are absent from the build they are served. Names and figures substituted for publication.

SECTION 03
How we used the platform

None of what follows was written as application infrastructure. Each is a Palantir Foundry capability configured against our own organisational model, and each description covers Aavya's configuration of this deployment rather than Foundry's capabilities in general.

Hours are logged against real allocations rather than reconstructed at month end. Saving a draft and submitting for approval are separate Actions against the timesheet object, each validated before the write lands and each carrying its author. The same entries are what an invoice line will later read. Figures substituted for publication.

SECTION 04
Where the access model actually lives

Hiding a section is a courtesy to whoever is looking at the screen; the Ontology is what declines the read. That distinction is the reason the consolidation was possible at all - and it is why a joiner, a promotion or an exit is a change of group membership that lands on the next sign-in, with no application change and no ticket to us.

SECTION 05
What consolidating actually bought

SECTION 06
What the same model already carries

The reason to model the organisation rather than the HR department is that the next function stops being a system to buy. Each of the following is a Workshop module and one gated navigation entry against object types the ontology already declares - which is why none of them begins with a data migration. The right-hand column describes Aavya's own intentions for its own internal platform: none of it is a commitment, a date, or something we sell.

Reimbursement, Travel Request and Insurance Claim sit in the same model, which is why expense settlement arrived as a module rather than a procurement exercise. The pattern is the point: an organisation is one object graph, and a function is a surface over part of it.

SECTION 07
SCOPE AND LIMITS

This is the platform we run our own organisation on. It was built for Aavya rather than as a product, it is not offered for sale, and nothing here is a proposal to deploy it elsewhere. We are describing it because the interesting part is not the HR domain - it is what becomes possible once roles sit in the platform instead of in the application.

The screenshots come from our own deployment, with employee names and every figure on screen replaced before publication: the people, headcounts, project counts and hours shown are illustrative and are not our operating data. Everything counted here describes the configuration at the time of writing - role groups, navigation sections, modules - and not performance, productivity or cost. We have measured no cycle times, no effort saved and no accuracy figures, and we make no claim about any of them. Hiring is in build. Payroll, invoicing and client relationship management are functions we have modelled for and intend to build for ourselves - they are not commitments, not dates, and not products offered to anyone else.

Built by Aavya on Palantir Foundry. This post describes Aavya's own application and its own configuration of Palantir Foundry, and statements about permissioning and attribution describe that configuration rather than Palantir's products. It is not published on behalf of Palantir Technologies Inc., does not represent Palantir's views, and is not a statement about Palantir's products, certifications or compliance posture generally. Figures describing role groups, navigation sections, modules and object types refer to this configuration at the time of writing and are not performance, security, accuracy or compliance claims. Forward-looking statements describe Aavya's own intentions only and are not commitments, delivery dates or offers. Press, analyst and investor enquiries relating to Palantir are referred to Palantir. Palantir, Palantir Foundry, Foundry, Workshop and AIP are trademarks of Palantir Technologies Inc.