What is Palantir - Part 4 : Analytics on the Ontology

A question lands on an analyst's desk at 9am. Plant 7 is missing its delivery targets, and the plant manager wants to know why before the afternoon review.

In a lot of companies, the next few hours go like this. Work out which tables hold deliveries, which hold suppliers, and which hold the plant hierarchy. Write the joins, find that two of them disagree, raise a ticket with data engineering, and wait. By the time a number comes back, the review has moved on, and nobody quite trusts the number anyway.

Part 3 put the supplier on the map: an object with properties, links to its plants and purchase orders, permitted actions, and access rules. This part is about the people who use that map all day, and what changes about their work once the business is already modelled.

The drill, without the joins

The analyst's question is about things, not tables. Which supplier sits behind Plant 7's late deliveries? That's a walk across objects the business already recognises: the plant, the purchase orders raised against it, the suppliers behind those orders.

Object Explorer is the front door. The analyst searches for Plant 7 and gets the object, not a table scan, along with everything the model links it to. Following a link, what Palantir calls a search around, pulls in the connected objects: the open purchase orders, then the suppliers behind them.

The drill itself runs in Insight, a point-and-click surface built for exactly this walk. Each move goes onto an analysis path: filter the orders to the last quarter, follow the link to the suppliers, keep the ones below ninety percent on-time, chart what's left. The path reads as a sequence of named steps, so a colleague who opens the analysis sees how the answer was reached, not just what it was.

Because the links are part of the model, there are no joins to write and no primary or foreign keys to chase. An indexing pipeline (Part 2) turns the rows into objects and links held in a store built for these lookups, so by the time the analyst clicks, the relationship is already indexed. A hop is a lookup, not a join planned at query time. By mid-morning the analyst has the one supplier dragging Plant 7's number, without SQL and without a ticket.

When the question turns quantitative

Finding the supplier raises the next question. Is this one bad month, or a slide that's been building? Quiver is where that digging happens: search the Ontology for the objects, filter them down, and chart what's left, no code required.

The analyst pulls in Supplier C's purchase orders, filters to the last eighteen months, and builds a bar chart of on-time delivery by month, the same filter-then-chart motion as any object analysis in Quiver. A bad month stands out at a glance; a slide across eighteen bars is unmistakable. Quiver also carries a dedicated time series engine for genuine sensor and signal data, so if Plant 7's machines are already wired up, the same canvas can plot delivery performance against equipment readings side by side, without exporting either one to another tool.

The finished chart is part of the analysis, and the analysis saves and shares directly with colleagues. The next person who asks the same question about Supplier C starts from this chart instead of rebuilding it.

From one supplier to the whole network

A supplier that slips rarely slips alone. The plant it feeds misses targets, the orders behind those targets slide, and the effect surfaces two links away from the cause. Vertex is built for that view: the modelled operation drawn as a system graph, plants and suppliers in one connected picture, so cause and effect can be traced across the network instead of argued about across teams.

It also runs forward. A scenario in Vertex is a set of proposed changes, a different supplier on the problem parts, say, evaluated on the graph rather than applied to it. The scenario works through what else moves under the model's own logic, and nothing is written to the live objects. The review's follow-up question, "what happens if we switch", gets its answer from the same model that found the problem.

So which tool does the analyst open?

The answer is about where the data lives.

The object tools, Object Explorer, Insight, Quiver and Vertex, are for questions about the Ontology: objects, their links, their time series, their network. Contour is for tabular data at scale, the cases the Ontology isn't the right home for: a very large dataset nobody has modelled, an intermediate table halfway down a pipeline, a one-time extract nobody plans to reuse. Contour works in paths and boards, filtering, pivoting and charting across tables, and it can save its result as a new dataset for the rest of Foundry to build on. Insight borrows that same grammar on purpose; Palantir's docs describe it as a Contour analysis experience on the Ontology.

There's a capacity line too. Past roughly 50,000 rows in an aggregation or 100,000 objects in a join, that's Contour's job, not the object tools'. So a working split: if the question is about things the business recognises and they're modelled, the object tools answer it and the answer stays live. If it's about a large table that isn't in the Ontology, or the output needs to become a dataset feeding a pipeline, that's Contour. As more of a domain gets modelled, more of the day's questions fall on the first side.

The analysis doesn't go stale

A spreadsheet export is a fossil the moment it's saved. It shows the data from the day someone pulled it, and it still shows that next week.

An exploration on the Ontology behaves differently. A saved object set can be stored as the filters that define it rather than a frozen list of rows. There's no refresh job behind that: the saved set is the query itself, and opening it runs the query against the objects as they stand. When tomorrow's pipeline run changes which suppliers are running late, the set re-evaluates, and the late suppliers are simply whoever is late today. A supplier that recovered overnight drops off the set without anyone editing it; one that slipped this morning appears in its place. The analyst reopens yesterday's drill and sees this morning's reality, because it sits on the same objects the pipelines from Part 2 keep current.

Saving Contour results as a dataset gives the opposite on purpose: a snapshot you can pin, version and hand downstream. The analyst only needs to know which of the two they're holding.

The spreadsheet habit itself doesn't have to produce fossils. Fusion is Foundry's spreadsheet: cells, formulas and lookups, except the lookups query datasets the pipelines keep current, and a finished sheet can write its results back as data instead of leaving the platform as an attachment.

The write-up can stay connected too. Notepad is an object-aware document editor: the charts in a report stay linked to the Quiver or Contour analysis behind them, the objects it references stay references rather than screenshots, and when a point-in-time record is the point, content can be frozen deliberately. Whether a document goes stale becomes the author's decision.

An analyst can't chart what they can't see

The permissions from Part 3 don't stop at the object. They follow it into every analysis. Object and property security policies are enforced wherever an object is read, so the same drill, run by two people, can return two different object sets. A regional manager exploring late suppliers sees their own regions and not the others, without setting a filter for it. Within a supplier, contract pricing stays hidden from anyone not cleared for commercial data, in the chart exactly as on the object.

The read path needs nothing extra. The analysis inherits the model's rules, so an analyst can't chart their way around access control, and the data they aren't cleared for never enters the analysis to begin with. Sharing the analysis itself, or any dataset it produces, still runs through its own access controls, the same as any other resource on the platform.

What this changes day to day

On a domain that's modelled, the queue disappears: the work that used to sit in it, joining tables, reconciling definitions, exporting extracts, moves to the person actually asking the question. The definition of a late supplier is the one the model carries, so two analysts asking the same thing start from the same answer, and the chart they bring to the plant manager points at the same object the plant manager can open and read. The day-to-day shift is less time waiting on data, and fewer meetings spent arguing about whose number is right before the real conversation can start.

Add up Object Explorer, Insight, Quiver, Vertex, Contour, Fusion and Notepad and the list covers much of what a business intelligence stack promises: object search, charts, pivots, a network view, connected spreadsheets, linked reports. The object tools read the Ontology directly, so the chart an analyst builds in Insight and the plant manager's own screen are looking at the same Plant 7.

One caveat, the same one Part 3 ended on. These tools are only as good as the model beneath them. Point them at a domain nobody has modelled and the analyst is back in Contour, writing joins by hand and working out which table is the real one. Good analytics is a symptom of a good model, not a substitute for one.

Finding it isn't fixing it

By the afternoon review, the analyst can point to the supplier behind Plant 7 and show the eighteen-month slide, on live data and inside their own permissions, without writing a join or raising a ticket.

Naming the supplier to switch is not the same as switching it. That's a different job: the operator needs a screen built for the decision, not the analysis behind it. Part 5 is about building that screen: an app on the same Ontology that brings Plant 7, the supplier and the permitted action into one place.