The Ontology

The word is intimidating and the idea is plain. An ontology is a written-down account of what one part of your business consists of: the things in it, how they connect, and the evidence sitting behind every connection.

For the control from Part 2, the ontology reads like this. A Regulation mandates an Obligation. The Obligation is addressed by a Control. The Control is carried by a Capability, which runs on a System. And the System is implemented by functions in files you can open.

Notice what's in it: things a risk officer would recognise, with the names a risk officer uses, connected the way they'd describe them. No file paths, no document numbers.

The things are the nouns of the domain. The connections are the verbs. A walk across them makes sentences. "Which systems implement our sanctions controls." "What has to change if Obligation 4 tightens."

Here is where our ontology differs from every other one, and it's the thing worth taking from this article. Palantir document their version plainly, and it's a direct lift from the warehouse: a dataset becomes a type of object, a row becomes an object, a column becomes a property, a join becomes a link. Everything in their picture already exists in the data. The ontology makes it explicit.

Ours runs the other way. The map holds what the domain's rules require to exist, written down first, and then your material is checked against it. So a control with nothing implementing it isn't missing from the ontology. It's in it, marked, with what was expected named next to it.

Theirs makes explicit what your data already contains. Ours also states what your data should contain and doesn't.

None of this works on a grammar you can negotiate.

Six zones, and they're the six questions every organisation already has to answer about itself whether or not it wrote them down. Why. What we're trying to achieve. How we do it. What we run on. What rules bind us. What could break. Four kinds of thing inside each, twenty-four in all. Then a fixed set of connections, and which ones are legal depends on which zones you're joining: governance can enforce or constrain a capability, a capability runs on a system, a risk is mitigated by a capability. Four combinations are deliberately left empty, because each has its opposite already covered, so every statement has exactly one legal direction. One direction means one fact, which means one thing to be right or wrong about.

All of that is fixed in source code, identical in every deployment. Nobody edits it. Not in settings, not by request, not for a large enough contract.

This is the most argued-with decision in the platform, so here's the case rather than the slogan. An editable grammar is how architecture repositories died, and their failure was arithmetic rather than features. Keeping a hand-drawn model current costs more as the organisation grows, the labour available to do it doesn't, and every local extension becomes a private dialect. Then there's the harder point. On a negotiable grammar you can compute nothing. Every read in Part 4 exists because the vocabulary is finite and known. And nothing transfers. A new industry arriving as a vocabulary pack over the same engine only works if the engine is actually the same one.

The economics follow from that, and they're a design target rather than a measured result. Corrections your experts make get kept, familiar shapes get recognised without paying to extract them again, and you pay for reading only what's genuinely new. That property exists only while the grammar stays locked.

The elements are fixed. The molecules are yours.

There's a cost to that refusal and it's worth stating. If what your organisation needs is a formal, standards-based ontology for its own sake, with a reasoner over it, this is not that tool and won't become it. That's a real category with real products in it.