An ontology is a vocabulary, not a schema: how packs work

Most software that claims to understand your industry has the industry compiled into it. There is a table with columns, the columns were chosen by someone who interviewed four customers in 2021, and your firm's job is to map itself onto them. Where you do not fit, you use the notes field.

That arrangement has a specific failure mode. The parts of your practice that are distinctive — the ones that are actually worth remembering — are precisely the parts that do not fit the columns, so they end up in free text, which is where knowledge goes to become unsearchable.

What does the engine actually know?

No industry nouns at all. There is nothing in it that knows what a covenant is, or a matter, or a workpaper, or an investment committee. It knows about observations, facts, entities, citations, visibility and reconciliation — the machinery — and nothing about what any of it is for.

Everything domain-shaped arrives from outside, declared by packs: which entity types exist, which document types, which fact kinds may be asserted about what, the metrics, the taxonomies, and the guidance used when reading. A pack for private credit knows about facilities and covenants; a pack for audit knows about workpapers and management letters. The engine running both is identical.

This is not an abstraction for its own sake. It is what makes the twenty-third discipline cost roughly what the third one did.

Is a pack the thing I buy?

No, and this is the part that usually surprises people. A pack is a starter bundle, not the unit of adoption.

A firm enables packs, and it also adopts individual modules out of packs it has not enabled. A private equity firm that does a lot of restructuring work can take the pieces it needs from the restructuring pack without taking the whole thing. The result is that your live ontology is a composition — your firm's own selection — rather than an edition somebody sold you.

The dependency closure of that selection is derived when the library loads, never stored. That is a small technical fact with a real consequence: the composition can change without a migration, because there is no frozen schema for it to be inconsistent with.

Your ontology is a per-firm composition, not a product tier. Two customers on the same plan can be running quite different vocabularies.

What happens when my firm does not match any of them?

You add to it. The ontology arrives with your discipline and grows from your own documents — the concepts your firm actually uses, including the ones no vendor has heard of, and the rules you apply that others do not.

This is where the vocabulary framing earns its keep. Extending a schema means a migration, a release, and a vendor's roadmap. Extending a vocabulary means declaring another word. Your firm's distinctive practice is the reason it wins work; a system that could only represent the generic parts would be remembering the wrong half.

What does the agent see?

The vocabulary, as documentation. When Claude or ChatGPT connects over MCP, the tool descriptions it receives are generated from your live ontology, so it is told what your firm tracks rather than having to infer it from question wording.

That has a practical effect worth noticing: an assistant that has been told your firm distinguishes a minuted resolution from a recommendation will ask about them as different things. One that has not will treat them as synonyms, and produce the exact error the private equity worked example turns on — reporting a conditionally approved deal as approved.

A pack you have not enabled contributes nothing to that documentation. The agent's picture of your firm is the composition you chose, which is the correct answer both for accuracy and for the buyer who asks what else it can see.

Who owns the additions?

You do, and the question is worth asking of anyone selling this. If your firm's distinctive vocabulary — the distinctions it draws that its competitors do not — becomes part of a vendor's product, you have paid to improve something you cannot take with you.

Structurally, the separation is that packs are a library and your composition is yours. The ontology is per-firm, derived on load from what you enabled and adopted, and your additions sit inside your own schema with everything else. Nothing about your vocabulary is pooled into a shared model, for the same reason your documents are not: they are read to build your memory and for nothing else.

The practical test for a buyer is to ask what happens on the way out. Deleting a firm here drops its schema and its object-store prefix — the ledger, the passages, the facts, the summaries, the index — and the deletion behaviour and what survives is named rather than described as thorough. An ontology you can leave with is an ontology you actually own.

Why does this matter to someone buying it?

Three reasons, in ascending order of importance. It means the product can serve your discipline without a bespoke project. It means the parts of your practice that do not generalise are representable rather than relegated to notes. And it means the thing you build up over years — the vocabulary plus your firm's additions — is a description of how your firm thinks, which is a considerably more durable asset than a folder of summaries.