What is a knowledge graph and why does your team need one?

You've used enterprise search. You type "Meridian pricing" and get 47 emails, 12 documents, and 3 Slack threads. You scan the results, open a few, piece together the timeline yourself, and — 20 minutes later — you know what happened.

A knowledge graph flips this. Instead of searching for content that mentions Meridian, you ask the graph: what do we know about Meridian? And it answers with a structured map:

• Meridian Industries is a company with $2.4M estimated ACV
• They're connected to Sarah Kowalski (14 emails, 3 meetings), James Palmer (legal owner), and Marcus Fielder (security contact)
• There's an open renewal due April 28
• The MSA redline v4 has an unresolved DPA clause from March 12
• The Q3 forecast lists them at 60% probability

All of this is extracted automatically. Nobody tagged it, nobody organized it, nobody built a CRM record for it. The graph inferred it from the raw data.

How it works (briefly)

A knowledge graph has two building blocks:

1. Entities — the things in your data. People, companies, deals, documents, meetings, dates, amounts.
2. Relationships — how those entities connect. "Sarah Kowalski authored the Meridian MSA." "James Palmer flagged section 14.2." "The Q3 forecast references Meridian."

Building a knowledge graph manually is prohibitively expensive — it requires someone to read every email and document and annotate the entities. But AI can do it automatically:

• Named entity recognition identifies people, organizations, monetary amounts, dates, and document names in every email and document.
• Relationship extraction detects verbs and prepositions that connect entities: "authored," "sent to," "approved by," "blocked on."
• Entity resolution merges duplicates: "Sarah K.", "S. Kowalski", "sarah.kowalski@meridian.co" are the same person.
• Temporal ordering builds timelines: this email happened before that meeting, which generated this follow-up.

The result is stored in a graph database (we use Neo4j) where every entity is a node and every relationship is an edge. In Doyna the graph is one of three indexes over the same corpus, not the whole system: a vector index holds meaning, the graph holds the links, and PostgreSQL holds the values that have to be exact. Queries that would take 20 minutes of inbox archaeology become a single fused lookup across all three.

What you can do with a knowledge graph

"Who on our team knows X best?"

Traditional search: type the company name, scan results, count who appears most. Knowledge graph: one query returns the people with the strongest ties (most emails, most meetings, most shared documents), ranked by recency and depth.

"What's the full history of this deal?"

Traditional search: reconstruct the timeline from email threads, meeting notes, contract versions, CRM updates. Knowledge graph: traverse the graph from the deal node. Every connected entity (people, documents, meetings, decisions) is already linked and ordered.

"Are there any connections between these two companies?"

Traditional search: good luck. Knowledge graph: path finding between two nodes. "Company A's CEO attended the same conference as Company B's VP Sales. They were introduced by your colleague James, who co-authored a whitepaper with Company B's CTO last year."

"Which decisions are blocking which deals?"

Traditional search: requires reading every email and meeting note to identify decisions and blockers. Knowledge graph: blockers and decisions are entities. Relationships connect them to deals. Query: "show all decision nodes with status=pending that have an edge to any deal with close_date < 30 days."

The difference between a knowledge graph and a search index

A search index (what Glean, Copilot, and most enterprise search tools use) maps keywords to documents. You type a word, it finds documents containing that word.

A knowledge graph maps entities to entities. It understands that "Sarah Kowalski" is a person who works at "Meridian Industries" and authored a document called "MSA v4" which contains a clause about data residency. This is fundamentally richer than keyword matching.

The practical consequence: search gives you documents to read. A knowledge graph gives you answers to act on.

How Doyna builds your graph

When you connect your email, documents, and meetings to Doyna, the system:

1. Embeds every piece of content into vector space (for semantic search)
2. Extracts entities from every email and document
3. Resolves duplicates across sources (the "S. Kowalski" problem)
4. Writes entities and relationships to Neo4j as they're discovered
5. Updates continuously as new emails arrive and new meetings happen

The graph grows automatically. After a week of running on a typical inbox (5,000-10,000 emails), Doyna has mapped hundreds of people, dozens of companies, and thousands of relationships — none of which required manual input.

You can ask the assistant questions that require relationship reasoning. Behind the scenes it queries all three indexes together — the vector index proposes the passages, the graph decides which of them actually belong to the thing you asked about, and the relational store supplies the exact values — and presents the answer with its sources.

See the knowledge graph in action →