← Chimmani / RPT-003
Synthetic demo data
Report 003 · Value-Chain Twin · Palantir Foundry Ontology

A warehouse stores rows.
An ontology knows things.

Nine systems each held a true fragment of the same company and none of them could see each other. An ontology is not a nicer schema — it is a typed model of the real world where objects carry links you can traverse, where a PDF clause and a maintenance note become queryable relationships, and where the answer to a question writes back to the system that has to act on it. This report shows the mechanics, not the marketing.

S1

Scattered truth

One supplier. Eight systems. Eight different primary keys, none of which agree — and two of the richest sources aren't tables at all, they're documents nobody can query.

"If NL-03 Unit 3 goes down for ten days, which customers do we have to call?" OLD ANSWER PATH: 5 analysts · 6 exports · ~3 weeks · confidence low
The real problem

Every system is internally correct. The failure is in the space between them — nobody owns the relationships, so the relationships don't exist. An ontology's job is to make those relationships first-class, typed, and permanent.

S2

Objects & links

Seventeen object types, twenty-four typed links. A warehouse would call these foreign keys and make you write the join. Here the link is the model: named, directional, cardinality-aware, and traversable from either end. Click any object — orange properties are ones derived from unstructured sources.

Enterprise ontology · object graphClick an object to trace its links
↔ Scroll the graph sideways
Object type
Select an object

Every object is one real-world thing, assembled from every system that knows about it.

Properties
Links Sourced from
S3

Unstructured → links

This is the part people mean when they say an ontology is different. A contract PDF, an incident narrative, a call report — prose that no query could reach. Extraction pulls entities, resolution matches them to objects that already exist, and what lands is not text: it is links. Pick a document and run it.

Document → entities → resolved objects → links
Ready · 0 links materialized
The link that pays for the whole programme

The Gensuite incident narrative and the SAP work-order note are written by different people, in different systems, in different languages of practice. Both mention pump P-4471. Once both resolve to the same Equipment object, "seal weep observed on rounds" and "third seal failure this year" become one story about one pump — and that story was previously unreachable by any query in the company.

S4

Entity resolution

Extraction is easy. Deciding that two records are the same thing in the world is the hard part, and it is evidence, not magic. Toggle the signals to see the confidence recompute and the decision flip.

SAP vendor 100234 D365 acct 8f2a-…-c91 Icertis party ACM-0042 Coupa supplier 88-2 Bank "ACME CHEM BV" PDF "Acme Chemicals B.V."
Match confidence
0.97
AUTO-MERGE

All six records collapse into one Supplier object. Every contract, PO, invoice, and incident attached to any of them now hangs off a single node.

S5

Traversal

With links in place, questions stop being projects. Each path below crosses systems that have never spoken to each other — and two of them traverse links that only exist because a document was read.

Answer

Hops
Systems crossed
Before ontology
Now
S6

Actions & the twin

An ontology that can only be read is a very expensive report. Actions write back — permissioned, validated, audited, and recorded as objects themselves, so the decision becomes part of the model. And once the model is complete enough, you can ask it what happens next.

Disruption simulator · NL-03 Unit 3Propagated through the link graph
Outage duration 10 days
Batches at risk
Orders impacted
Customers to call
Revenue at risk
S7

Action plan

Ontology programmes fail by starting with the model instead of a question. Pick one decision that hurts, build only the objects it needs, then let the graph accrete.

Impact vs effort
Recommended sequence

O1 → O2 → O3 → O4 → O5 → O6