What is an ontology for venture capital?

It is a connected model of a fund's deal flow: companies, founders, rounds, deals, notes, data room documents and CRM records, with links between them. The same company resolves to one entity across systems, and every fact traces to its source, so people and AI agents can answer questions and spot contradictions reliably.

Do I need an ontology if I already have a CRM?

Not if your CRM holds everything. You need one when facts about a deal are split across the CRM, meeting notes and data room documents that disagree. A CRM only knows what was typed into it. An ontology links those sources and surfaces conflicts with evidence.

How do you match the same company across a CRM, notes and a data room?

Use hard identifiers first (domain, registration number), then soft signals like name similarity and shared founders, and keep the evidence for every match. Send ambiguous cases to a person.

How do I flag a deal marked passed that still has an open next step?

Write it as a rule over the Deal entity: stage is Passed and a future task or meeting exists. You approve which rules to keep, since they encode your fund's policy.

How to Build an Ontology for VC Deal Flow

An ontology for venture capital is a single connected model of your deal flow: companies, founders, rounds, notes, data room documents and CRM records, linked so the same company is one entity no matter which system or document names it. The point is not a tidier schema. An agent, or a partner on a Monday morning, can ask "what is our history with this company?" and get one answer with evidence behind it.

Most funds already have the pieces. A CRM holds stages and owners. Notes live in a doc tool or a meeting recorder. The data room is a folder of PDFs. None of them agree on what the company is called, and none of them know that a deal marked passed still has a follow-up booked next week. This guide covers how to model that, how to resolve the identity problem, how to write rules that catch contradictions, and how to do it in Helix Foundry.

What an ontology does for VC deal flow (and when a CRM is enough)

An ontology gives deal flow one shared model that every tool and every agent reads from, instead of each system keeping its own partial version of the truth. If your whole pipeline lives in one CRM, your notes are typed into CRM fields, and nobody uploads documents anywhere else, a CRM is enough. Stop reading and clean your picklists.

The case for an ontology starts when the facts about one deal sit in three or more places. The CRM says Series A, stage "Diligence". The partner's meeting notes say the founders are "still raising the seed extension". The data room has a cap table PDF that disagrees with both. A CRM can't reconcile those, because it only knows what someone typed into it.

Three signs you've outgrown the CRM: agents give confident answers that contradict your own notes, analysts spend Friday afternoons cross-checking spreadsheets against the CRM, and you can't say which source a number came from. If those sound familiar, our post on five signs your data needs an ontology goes through the general test.

The entities and links a fund actually has

A fund's deal flow reduces to about eight entity types and a handful of links. Start with exactly those rather than modelling every field your CRM exports.

Entities:

Company: the thing you invest in or track. Name, domain, sector, HQ.
Person: founders, executives, partners at your fund, partners at other funds.
Fund / Investor: your own fund plus co-investors and previous investors.
Round: a financing event with date, size, lead and instrument.
Deal: your fund's engagement with a company, with stage, owner and last-touch date. This is separate from the company on purpose, because one company can have several deals over time.
Note: meeting notes, memos, partner discussion write-ups.
Document: data room files such as decks, cap tables, financials and contracts.
CRM record: the source row, kept as evidence rather than flattened away.

Links are what make it a model and not a list: a Person founded a Company, a Company raised a Round, a Fund participated in a Round, a Deal concerns a Company, a Note mentions a Company and a Person, a Document belongs to a Deal.

Keep Deal separate from Company. Most CRM cleanups fail because the two are one row, and then "passed in 2023" overwrites "actively diligencing in 2025". The same shape works in other domains. See how it looks in a finance ops ontology with invoices, contracts and vendors.

The hard part: one company, five names

Entity resolution is where a VC ontology succeeds or fails. The same company shows up as "Acme Robotics Inc." in the CRM, "Acme" in meeting notes, "acme-robotics.io" in an email, "Acme Robotics, Ltd" on the cap table and "the robotics founders from Leeds" in a partner's memo. If those become five nodes, every downstream question is wrong.

Treat resolution as evidence gathering, not string matching. A workable approach, whatever tool you use:

Prefer hard identifiers first. A domain, a registered company number or a founder's email address is a much stronger signal than a name.
Add soft signals. Name similarity, shared founders, the same city and sector, overlapping dates on rounds.
Keep the evidence with the match. Every link from a mention to a canonical company should point back to the CRM row or the quote in the document that justified it.
Send ambiguous matches to a person. Two companies called "Atlas" is a real case. A wrong merge is worse than a missed one, because it quietly corrupts everything linked to it.

Founders have the same problem in a worse form: nicknames, name changes, two people with the same name, and the same person appearing as a founder of a previous company. The same discipline applies. For a deeper look at the mechanics when an LLM is doing the extraction, see entity resolution for knowledge graphs built by an LLM.

In Helix Foundry, the suggested ontology matches the same records across sources. When you open a record in the explorer you see its properties, every relationship in and out, and the load and version that wrote it. The README describes the result as every value traced back to the row or document quote it came from. That is the property you want from resolution: a merge you can audit.

Rules that flag what does not add up

Rules turn the ontology from a map into a checker. They encode what your fund believes must be true, and they surface the records where it isn't.

Start with the contradictions your team already trips over:

Passed with an open next step. A Deal with stage "Passed" that still has a task, meeting or follow-up scheduled in the future.
Closed with no round. A Deal marked invested with no matching Round that lists your fund as a participant.
Conflicting round size. The CRM says a $4M seed, the data room term sheet says $5M.
Orphaned diligence. Data room documents attached to a Deal that the CRM says was never opened.
Founder mismatch. A note names a founder who does not appear on the company's People links.

Foundry evaluates rules against the data, and rule breaks land in a review view rather than being silently fixed. The agent drafts rules and constraints as part of the ontology, and you decide which ones to keep. That split matters. A rule like "passed deals must have no open next step" is a policy your partners own, and a model shouldn't invent and enforce it on its own.

Write each rule so a human can read it in one sentence and name who fixes a violation. If nobody owns the fix, the rule is noise.

Build it in Helix Foundry: clone, connect, generate, review

Helix Foundry connects your tools and documents, drafts one ontology over them, and loads it into HelixDB as a connected graph you can explore and query. Foundry is the app; HelixDB is the database it loads into.

1. Run it. The README path is:

git clone https://github.com/helixdb/helix-foundry.git
cd helix-foundry
docker compose up -d --wait

then open http://localhost:3000. You need Docker with Compose v2, ports 3000 and 8333 free, and room for a few GB of images on first start. If you'd rather not host anything, Helix Cloud at foundry.helix-db.com runs the same build. The self-hosted install is single-user, for one person on their own computer, so don't expose it to a network.

2. Connect. Add the sources that hold your deal flow. The README lists connectors including PostgreSQL, MySQL, Amazon S3, Stripe, GitHub, Linear, Granola, Cal.com, Slack, Notion and Google Workspace, plus documents. Meeting notes in Granola or Notion, calendar data from Cal.com, a Postgres export of your CRM and data room files in S3 or Google Drive are the natural starting set. Test each source and sync its tables. Foundry never writes to your sources.

3. Generate. Select the tables and document sets that matter and generate an ontology. The agent drafts types, links, mappings, document routes, rules, constraints and questions. A generation sends your synced tables, and up to five of the newest documents of each set it picks, to Foundry's agent. Choose sources with that in mind, and use the model provider setup that your fund has approved.

4. Review. Each draft is reviewable: check the Types, Links, Mappings, Sources and Rules tabs and the generated TOML. Edit it as a new version and choose when to make it current. Versions are immutable, so earlier ones stay available.

Review in this order. Types first (are Company, Deal and Round separate?), then Links (does Deal point at Company?), then Mappings (is the CRM's "Account" mapped to Company and its "Opportunity" to Deal?), then Rules. Load it, open a company you know well in the explorer, and check that every relationship and value traces to a row or a quote. Then ask the Analyst a question you already know the answer to, such as "which passed deals still have an open next step?"

The broader walkthrough is in how to build an ontology from scattered company data.

Keeping it correct as the fund's data changes

An ontology that was right in March is wrong by June unless something keeps checking it. Deal flow changes constantly: new sources, renamed CRM fields, a new stage in your pipeline, a new kind of document in the data room.

Foundry handles this in two ways that matter here. First, every ontology is a version. When your CRM adds a "Term Sheet Out" stage, you edit the ontology as a new version, review it, and make it current when you're ready, with the old one still on record. Nothing changes under your agents without a deliberate step.

Second, self-healing audits the current load for gaps in the ontology or mappings and surfaces findings with evidence and proposals. A new column that maps to nothing, or a document type with no route, shows up as a finding rather than as silently missing data. Treat these as suggestions to assess, not automatic changes. When documents disagree, review the conflicting values instead of letting one win by default.

Operationally: re-sync on a schedule that matches how fast your CRM moves, glance at the "Needs review" view weekly, and have one named person approve schema changes. The ontology is shared infrastructure, and shared infrastructure needs an owner.

Trade-offs and limits

An ontology costs setup time and ongoing ownership, and it's the wrong tool for some funds.

Small funds with one tool. If everything is in the CRM, you're adding a layer for no gain.
Resolution is never finished. Ambiguous matches will keep arriving, and someone has to judge them. Foundry gives you the evidence to judge quickly, but it doesn't remove the judgment.
Generated drafts need review. The agent proposes types, links, mappings and rules. A partner who knows what "passed" really means in your process has to read them.
Data leaves your tables during generation. Synced tables and recent documents go to Foundry's agent, so confirm that fits your LPs' and portfolio companies' confidentiality expectations before you point it at a live data room.
Self-hosted is single-user. The local install has no sign-in and is for one person on their own machine. For a team, use Helix Cloud or keep it behind your own controls.
Read-only by design. Foundry never writes back to your CRM, so a rule violation is a flag for a human, not an automatic fix.

The honest comparison with enterprise ontology platforms such as Palantir Foundry is scope and weight. Those are built for whole-organization deployments, while Foundry is open source under Apache 2.0 and aimed at getting a connected, auditable model running on data you already have. Pick based on the size of the problem you actually have this quarter.

Start with one contradiction your partners already complain about

Don't model the whole fund. Pick the single contradiction that annoys your team most, probably a passed deal with a live next step, and build just enough of the ontology to catch it: Company, Deal, Note and the CRM record, with resolution you can audit. Clone helix-foundry, connect your CRM export and meeting notes, generate, and review the rules tab before anything else. If that one flag fires on real data with evidence attached, you have your case for the rest.