Guides
Firm Ontology

What is a firm ontology? The system of record for deal teams

The term the whole category hangs on, defined plainly. What a firm ontology is, how it differs from a CRM and from search over your files, and why it is the thing that makes AI actually useful to a firm.

CONNECTOR · STITCHES ON EVERY QUERYQ1Q2Q3sys 1sys 2sys 3sys 4sys 5the cost is paid again for every queryFOUNDATION · STITCHED ONCE, THEN FREEQ1Q2Q3One structured layersys 1sys 2sys 3sys 4sys 5one hop to a coherent view
Search over scattered files re-stitches your systems on every query. A firm ontology structures them once into one connected model the AI can reason over.

A firm ontology is a structured, machine-readable model of everything a firm works with: its deals, companies, funds, people and documents, and the relationships between them, defined once in the firm’s own terms. It says what a Deal is, what data belongs to it, how it links to a Fund and to the people involved, and where every fact came from. In plain terms, it is the system of record for a deal team, one authoritative version of the firm’s own knowledge, structured so a computer can reason across all of it rather than guessing from scattered files.

This guide defines the term the rest of this cluster hangs on. The pillar draws the line between a chat box bolted over your tools and a firm brain running on a structured record; the ontology is that structured record, and it is why the diligence and IC memo guides both keep coming back to the same idea: the data layer underneath matters more than the model on top.

What is a firm ontology, in plain terms?

Every firm already has an implicit ontology. It is the shared understanding in people’s heads of what a deal is, which fund it sits in, who the sponsor is, which model is the current one, and how a diligence finding relates to the memo it ends up in. The problem is that this understanding lives in people and in file names and in the tribal memory of whoever has been there longest, and none of that is legible to a machine.

A firm ontology makes that understanding explicit. It defines the objects the firm works with, Deal, Company, Fund, Person, Document, and whatever custom ones a particular firm needs, states the properties each one has, and models the relationships between them. A Deal links to the Fund considering it, to the people working it, to the data room, to the model, to the diligence findings. Once that structure exists, a computer can traverse it: it can start from a deal and know, without guessing, which documents belong to it, which version of the model is current, and where any given figure came from.

How is a firm ontology different from a CRM?

A CRM structures a slice of the firm, contacts, companies, and pipeline stages, and it structures that slice well. It is where relationship data and deal status live. And it stops there. A CRM does not hold the data room, the operating model, the diligence findings or the reasoning that led to a decision, and it does not link those things to the deal in a way a machine can walk through.

A firm ontology models the whole firm. The CRM’s contacts and companies are objects in it, but so are the documents, the models, the portfolio reports and the diligence, all connected to the deals and funds they belong to. The useful way to think about it: a CRM is one object type inside an ontology, not a substitute for one. A firm that has a good CRM and nothing else has structured its relationships and left everything a deal actually turns on, the documents and the numbers, in folders the machine cannot reason over.

Is a firm ontology just search over my documents?

No, and this is the distinction most AI tooling blurs. Search, including the retrieval that sits behind most AI assistants, works by finding text that looks relevant to a query. Ask a question, it pulls the passages that seem to match, and it re-stitches your scattered systems from scratch on every single query. It finds text. It understands no structure.

An ontology models the structure explicitly, once. This figure belongs to this deal. This deal belongs to this fund. This document is the current version, and these four are superseded history. That is knowledge a search cannot derive from text, and it is exactly what lets an AI fetch the few facts a question actually needs and trace each one to source, instead of guessing from whatever passages a search happened to surface.

Search finds text that looks relevant. An ontology knows what the text is, what it belongs to, and which version is true.

The difference is not academic. A model reasoning over a structured ontology fetches precisely the facts that matter, which means faster answers, lower cost and far fewer hallucinations than the same model raking over a haystack of files. We work through the retrieval-versus-structure argument in connectors or foundations, and the versioning problem, which of five files marked FINAL is the real one, in why AI needs a system of record.

Why an ontology is the thing that makes AI useful to a firm

Here is the part that matters commercially. A model is only ever as good as what it can reason over. Point a frontier model at a pile of scattered, unstructured files and it produces fluent, confident answers that nobody can verify, which is why so many firms run an impressive AI demo and then shelve the pilot. The tool was fine. It had nothing structured to reason over.

Point the same model at a firm ontology and the picture changes. It fetches the specific facts a question needs, reasons across the connected record, and cites each figure back to its source. The answers are consistent, because the record underneath is stable, and they are auditable, because every value has a lineage. The model did not get cleverer. It got a foundation.

This is why the ontology, not the model, is the edge. Frontier models are converging and every firm can rent the same ones, so the model is almost never the differentiator. The structured record of the firm’s own knowledge is, an argument we make in full in the AI model doesn’t matter. You can see the ontology built, from raw context to your firm’s brain, on the platform page.

The bigger prize: the intelligence you cannot see today

Automating individual workflows is the visible win: faster diligence, drafted memos, less re-keying. It is also the smaller half of the story. The larger prize only appears once the whole firm’s data sits in one connected record, because then you can ask questions of the firm itself, not just of a single deal.

Which channel actually sources your best deals, not the ones you remember but the ones the data shows. What proportion of everything you look at reaches LOI, and where in the funnel the rest fall away. How this deal compares to every similar one you have done. How your underwriting cases have held up against what actually happened after close. None of those questions can be answered while the data lives in separate inboxes, spreadsheets and tools, because no single system can see across them. Aggregated into one ontology, each one becomes a query you can run.

That is the difference between a firm that runs on anecdote and one that runs on its own evidence. To get better at picking deals, and to forecast with any confidence, you need a clean read on your own past and present, and that only exists once the data is in one place. Automation buys back hours. This changes decisions.

Why the ontology has to be owned and persistent

The last property is the most important and the most overlooked. A firm ontology has to be owned, and it has to persist.

Step back from the mechanics, because the ownership point is bigger than data hygiene. Your firm’s real asset was never the files. It is the accumulated judgement of your people: every deal they have seen, every business they passed on and why, every pattern a partner carries after decades of doing this. Today that intelligence is scattered across inboxes, drives, models and the heads of whoever has been there longest, which means it cannot be queried, it cannot be valued, and it walks out of the door every time someone leaves. A firm ontology is the software embodiment of your firm: everything it has seen and everything it knows, structured into one record you own.

Your ontology is the software embodiment of your firm: everything it has seen, everything it knows, in one place you own and build on.

Put that way, building it is not an IT project to shave time off a few workflows. It is taking the most valuable and most scattered thing the firm has and turning it into an asset you build deliberately and protect like any other. The workflow automation is real. The asset is the point.

It has to persist because it is where the firm’s knowledge accumulates. Every deal adds to it, every diligence teaches it a red flag, every relationship extends the graph. Unlike a copilot that forgets each session, the ontology gets richer the more the firm uses it, so the work compounds instead of evaporating. A firm two years into building its ontology has an asset it did not have on day one, and that its competitors do not have at all.

And it has to be owned because it is the one part of an AI stack a rival cannot copy. Anyone can rent the same model. Nobody else has your firm’s record. If that record lives inside a generic vendor’s box, your edge lives there too, and you are renting your own advantage back. The principle is to own the context layer and rent the models that run on it, which we cover in AI sovereignty for deal firms. The ontology is that context layer. It is the moat, and it is the reason the whole rest of this cluster keeps pointing back here.

What goes into a firm’s ontology?

The objects the firm actually works with, and the real content connected to them. Standard objects, Deal, Company, Fund, Person, Document, plus the custom ones a given firm needs, each defined in the firm’s own nomenclature rather than a vendor’s. Around them sits everything the firm knows: emails, calendars, call transcripts, the data room, models, CRM records and portfolio reports, each tied to the objects it belongs to and versioned so there is one authoritative copy.

The result is one connected model of the firm’s own knowledge, which is what agents and apps run on. On top of it, the same structured record can draft a diligence memo, assemble an investment committee memo with lineage on every figure, or monitor a portfolio, because they are all reasoning over the same source of truth rather than re-keying it by hand.

If you want to see what a firm ontology looks like built on your own deals, rather than in the abstract, talk to us. We structure your firm’s own record and embed it in the workflow your team already runs, starting with one process.

Frequently asked questions

What is a firm ontology in the context of AI for deal teams?
A firm ontology is a structured, machine-readable model of everything a deal firm works with: its deals, companies, funds, people, documents and the relationships between them, defined once in the firm's own language. It says what a Deal is, what data belongs to it, how it links to a Fund and to the people involved, and where every fact came from. It is the system of record a deal team's AI reasons over, so answers are consistent, traceable and grounded in the firm's own knowledge rather than invented from scattered files.
How is a firm ontology different from a CRM?
A CRM structures a slice of the firm: contacts, companies and pipeline stages. It is useful, and it stops there. It does not hold the data room, the model, the diligence findings or the reasoning, and it does not link them to the deal in a way a machine can traverse. A firm ontology models the whole firm, the structured records and the documents and the relationships between them, as one connected system. A CRM is one object type in an ontology, not a substitute for it.
Is a firm ontology just search over my documents?
No, and the difference is the whole point. Search, including the retrieval that sits behind most AI tools, finds text that looks relevant to a query and re-stitches your scattered systems on every question. It finds passages; it understands no structure. An ontology models the structure explicitly: this figure belongs to this deal, this deal belongs to this fund, this document is the current version. That lets an AI fetch the few facts that actually matter and trace each one to source, rather than guessing from whatever text a search happened to surface.
Why does AI need a firm ontology to be useful?
Because a model is only as good as what it can reason over. Point a frontier model at a pile of scattered, unstructured files and it produces confident answers nobody can verify, which is why so many AI pilots stall after the demo. Point the same model at a structured ontology and it fetches the specific facts a question needs, reasons across them, and cites each one. The model is rented and roughly the same for everyone; the ontology is the part that decides whether the AI is trustworthy and whether it reflects your firm.
Why does a firm need to own its ontology rather than rent it?
Because the ontology is where the firm's proprietary knowledge lives, and it compounds. Every deal, every diligence, every relationship adds to it, and that accumulated record is the one part of an AI stack a competitor cannot copy, because it is your firm's own, not a model everyone can also rent. If the ontology lives inside a generic vendor's box, the firm's edge lives there too. Owning the context layer and renting the models that run on it keeps the compounding asset in-house.
What goes into a firm ontology?
The objects the firm actually works with and the links between them. Standard objects such as Deal, Company, Fund, Person and Document, plus the custom ones specific to the firm, all defined in the firm's own nomenclature. Around them sit the real content: emails, call transcripts, the data room, models, CRM records and portfolio reports, connected to the objects they belong to and versioned so there is one authoritative version of each. The result is one connected model of everything the firm knows, which is what an AI reasons over.

See it on your own deals.

We build AI on your firm's own record, then embed it in the workflow your team already runs. Start with one process.