What Is an Ontology? A Guide for Investment Firms

An ontology is a shared, machine-readable model of the things in a domain, how they relate to each other, and what the words for them mean. Kepler builds one for each investment firm from its own documents and systems: every company, fund, vehicle, manager, person, deal and document resolved to one record, the firm’s definitions written down once, and every relationship tied to its source and the period it was true, so AI can answer in the firm’s own terms and every number can be proven.

The ontology is the core of what we call enterprise intelligence, and the part of Kepler our team has the longest history with: our engineers built this layer before at Palantir.

The plain-English definition

The word comes from philosophy, where it means the study of what exists. Computer scientists borrowed it for knowledge representation, and the definition they cite most often is Tom Gruber’s, from 1993: “An ontology is an explicit specification of a conceptualization.” In practice, an ontology answers three questions in a form software can use:

• What kinds of things exist? Funds, companies, people, documents, positions, capital calls.
• How can they relate? A fund is managed by a general partner. A company is a customer of another company. A person is a key person for a fund.
• What do the terms mean? What counts as “net IRR,” which costs come out of “adjusted EBITDA,” which companies are in “our semis peer set.”

A spreadsheet of holdings has rows. An ontology knows that the row labeled “SPACEX” is the same private company as “Space Exploration Technologies Corp.” in a fund report, “Space X” in an email subject and “SpaceX” in the CRM, and that the firm holds it through three different vehicles.

What an ontology looks like at an investment firm

Type of thing	Examples	Typical relationships
Fund or vehicle	Fund III, a co-invest SPV, a feeder	Managed by a GP; holds positions; invests in underlying funds
Manager	A buyout GP, a hedge fund manager	Manages funds; has key persons; reports quarterly
Company	A public filer, a private portfolio company	Issues securities; customer or supplier of another company; subsidiary of a parent
Person	A partner, a CFO, a board member	Works at; key person for; sits on the board of
Document	LPA, side letter, 10-K, capital call notice, IC memo	Describes a fund or company; is the source of a claim
Definition	Net IRR, adjusted EBITDA, look-through exposure	Computed from specific facts by a specific formula
Event	Capital call, distribution, restatement, guidance change	Affects a fund or company on a date

Two features separate a useful ontology from a diagram on a whiteboard.

Every link has a source. “Microsoft was CoreWeave’s largest customer” is a claim. A good ontology records who made it and in which sentence: here, CoreWeave’s 10-Q filed November 13, 2025, which says Microsoft accounted for approximately 67% of revenue for the quarter ended September 30, 2025. Clicking the link should open that sentence.

Every fact knows when it was true. Companies restate. Funds change names. A position held in Q2 may be gone by Q4. The ontology has to answer “what did we know on March 31” separately from “what’s true now,” and keep figures as filed apart from figures as restated. Without that, a backtest leaks the future and a reported number silently changes under an old memo.

Ontology vs knowledge graph vs data warehouse vs RAG

These terms get mixed together. They describe different things, and a working system usually needs more than one.

	What it holds	What it’s good at	Where it falls short for AI
Ontology	Types, allowed relationships, definitions, rules	Shared meaning the AI can reason with	Needs data shaped by it to answer anything
Knowledge graph	The actual entities and links, typed by an ontology	Questions that hop across connections	Links mean little without an agreed schema
Data warehouse	Structured tables	Fast, governed metrics on structured data	Leaves out documents; meaning lives in table design
RAG index	Text chunks and embeddings	Quick setup; finding relevant passages	No entities, definitions or time; limited to what’s retrieved
Kepler’s ontology	All of the above joined: types, resolved entities, the firm’s definitions, and claims tied to their sentences and dates	Answers in the firm’s terms, complete lists, numbers computed in code	Nothing to build or maintain by hand: our engineers and agents keep it current

Ontology and knowledge graph. The ontology is the schema and the meaning. The knowledge graph is the data that fills it. Most enterprise products, Kepler included, build them together, which is why people use the words interchangeably.

Data warehouse. A warehouse is the right home for structured data like trades, positions and NAVs, and BI tools compute governed metrics from it. Most of an investment firm’s knowledge sits outside it, in PDFs, emails and spreadsheets, and the meaning of each table often lives in the head of whoever designed it. A semantic layer over a warehouse is a close cousin of an ontology, limited to the structured slice.

RAG. Retrieval-augmented generation splits documents into chunks, finds the chunks that look relevant to a question, and has a model answer from them. It has no notion of an entity, so it can’t tell that two names are one company, and it returns the top matches, so “every fund agreement with a key-person clause” comes back incomplete. Our guides on where RAG breaks on financial data and checking AI-generated numbers cover what that does to answers and figures.

FIBO: the industry’s shared financial ontology

The Financial Industry Business Ontology (FIBO) is the standard reference ontology for finance. It’s maintained by the EDM Association (formerly the EDM Council) with practitioners from member firms, updated quarterly, written in OWL, the W3C’s Web Ontology Language, and published as open source under the MIT license on GitHub. Its domains include Business Entities, Securities, Loans, Derivatives, Indices and Indicators, Market Data, and Corporate Actions and Events.

FIBO is valuable as a shared vocabulary: it settles what a legal entity, a share class or a loan is, and how they relate. It can’t tell you which entities your firm holds, how your firm defines adjusted EBITDA, or which sentence in which side letter grants a fee discount. A firm’s ontology uses FIBO-style types and relationships as its frame and fills them with the firm’s own world.

Palantir’s Ontology: the best-known enterprise example

In enterprise software, the best-known ontology is Palantir’s. Its documentation describes the Palantir Ontology as “an operational layer for the organization” that in many settings serves as a digital twin of the organization, made of semantic elements (objects, properties, links) and kinetic elements (actions, functions, dynamic security). That last part is the important idea: the ontology carries what people and software are allowed to do, alongside what exists.

Our engineers built this layer before at Palantir. At Kepler we apply the same idea to investment firms, with two additions that high-stakes research needs: every link is a sourced claim, and every fact keeps time.

Why AI needs an ontology

A frontier model on its own starts every question from zero. It doesn’t know your portfolio, your internal nicknames for deals, or your definitions. An ontology gives it:

• Your entities. “Our exposure to this company” resolves to the firm’s actual positions, across every vehicle, which is what look-through exposure depends on.
• Your definitions. Your Q3 is its Q3. Your adjusted EBITDA is the one in the model.
• Complete answers. A question over resolved entities is a query, so “every portfolio company with a change-of-control clause” returns all of them.
• Proof. Each number points to a fact, and each fact points to a sentence, so answers can be checked.
• Permissions. Access rules attach to entities, so a deal behind a wall stays invisible to anyone outside it, including an agent.

The gap between a model with an ontology and one without is widest where documents are messy and every manager formats differently, as in how LPs use AI on fund documents. On Kepler, the ontology is also what scopes each agent’s reads to its owner’s access.

How to build one, and why it’s hard

1. Start from a template. A fund-of-funds, a hedge fund and a law firm need different types. Starting from the right template saves weeks.
2. Read every source. Fund reports, LPAs, side letters, CRM records, emails and filings, scanned pages and tables included.
3. Resolve entities. Match every alias to one record and anchor public companies to official identifiers. This is where most projects stall: a single company can appear under a dozen names.
4. Extract claims with their evidence. Each relationship needs its sentence, and its direction checked, so a customer is never recorded as a supplier.
5. Write definitions as code. A metric defined in prose gets computed three ways by three people. Our guide to getting AI to use your firm’s definitions covers owners, versions and effective dates.
6. Keep it current. New documents arrive daily. Facts get superseded. The ontology has to update itself without erasing history.

Hand-built, an enterprise ontology has typically taken months of consulting work, and keeping it current is a second, permanent project. We built Kepler to do both from the firm’s own documents.

How Kepler builds your firm’s ontology

Our engineers build each firm’s ontology, Kepler Orbit, from the firm’s own documents and systems, and it’s in place by the end of the first week. We start from a template for the kind of firm (allocator, hedge fund, private equity, bank) and draft the rest from what the firm has: funds, managers and portfolio companies with commitments and look-through holdings by period for an allocator; notes, models, emails and filings resolved to each company, with coverage and statuses, for a hedge fund.

The reading behind it is complete. Extraction models we train read every page of every connected source at ingest, including scans, tables and figures. In one published example, we read a 28 MB fund report in full in 136 seconds and kept 83,204 facts, 45,199 named entities and 9,042 relationships, each beside its passage (Stop Paying to Forget).

Every link in a Kepler ontology is a claim with its verbatim sentence. Each one shows how it’s known (stated outright, inferred, or computed from other claims), how many independent sources assert it, and whether they agree. When sources contradict each other, we show the split rather than picking a side. Each claim keeps two clocks, when it was true and when it was recorded, so you can see the graph as it stood on any date, with nothing from later leaking in.

The ontology maintains itself. As new documents land, agents re-read the sources behind each edge and repair what no longer holds. When documents describe something the schema has no type for, an agent proposes one for the firm’s team to approve. A correction made once becomes a rule applied everywhere the same mistake appears.

Every firm also starts with our public equities ontology, built claim by claim from 26M+ SEC filings, earnings calls and regulatory dockets, with names resolved against 900K+ SEC filers and 49 relationship types in five families. Its relationship types follow FIBO.

The ontology is what the rest of Kepler stands on. Our deterministic engine computes every number from facts in it, using the firm’s definitions, and cites each one to the line. Picking the model for each step is our job: extraction models we train handle the reading, the strongest frontier models reason over the graph and write the answer, and we replace them as better ones are released. The ontology carries over each time, so a new model works from the firm’s own entities and definitions on its first day. Agents walk the graph overnight on schedules and filings, following every path between two entities with evidence at each hop, and every read passes the firm’s access rules. The same graph is open to the firm’s own agents and apps through our API and MCP server. See it on our ontology page, and see how it compares with tools that run a model over selected documents in Kepler vs Hebbia.

Questions it answers in the first week: “Which of our funds hold this company, through which vehicles, as of March 31?” “Every customer relationship CoreWeave discloses, with the filing sentence for each.” “Who were this manager’s key persons on the date we committed?”

Try Kepler at app.kepler.ai, or book a demo to see your firm’s ontology built from your own documents.

Frequently asked questions

What is an ontology in simple terms?

An ontology is a written-down model of the things in a domain, how they relate, and what the words mean. Kepler builds one for each investment firm from its own documents: every company, fund, manager, person, deal and document resolved to one record, the firm's definitions recorded once, and every relationship tied to its source and the dates it held, so Kepler's engine can compute and cite every number from it.

What is the difference between an ontology and a knowledge graph?

The ontology is the schema and the meaning: which types of things exist, which relationships are allowed between them, and how terms are defined. A knowledge graph is the data shaped by that schema: the actual companies, funds and people, and the links between them. In practice, enterprise systems build both together and the words are often used interchangeably.

What is FIBO?

FIBO, the Financial Industry Business Ontology, is an open, industry-standard ontology for financial concepts, maintained by the EDM Association (formerly the EDM Council) and published in OWL under the MIT license. Its domains include business entities, securities, loans, derivatives and market data. Firms use it as a shared vocabulary and extend it with their own entities and definitions.

Why does AI need an ontology?

A language model doesn't know that four spellings refer to one company, which of three funds holds a position, or how your firm defines adjusted EBITDA. An ontology supplies that context, so answers use the firm's own entities and definitions, lists come back complete, and every number can be traced to the fact it came from.

How long does it take to build an ontology for an investment firm?

Hand-built enterprise ontologies have traditionally taken months of consulting work. At Kepler, extraction models read every document and our engineers start from a template for the kind of firm, so a working ontology is drafted from the firm's own documents in its first week, then refined by its people and kept current automatically.

What is Kepler Orbit?

Kepler Orbit is the ontology our engineers build for each firm from its own documents and systems. Every company, fund, manager, person and document resolves to one record, every link is a claim tied to the sentence it came from, and every fact keeps the dates it held. Kepler's engine computes numbers from it using the firm's own definitions.