When knowledge graphs actually earn their place in your AI stack, when they don't, and the seven analytics questions that tell you which.
The whiteboard problem
Watch what happens the next time your analytics team tries to answer a real business question. Not "what was revenue last month", but something like "why did net revenue drop 4% in March?"
Someone pulls up three dashboards. Someone else opens a contract. A third person posts in Slack: "Does anyone remember why we changed the SKU categorisation in Q4?" Eventually, somebody walks to a whiteboard and starts drawing boxes for metrics, source systems, product lines, and customer segments, with arrows between them.
That whiteboard is a knowledge graph. It's just on a whiteboard.
Every organisation of any size already has one, implicitly. It lives in the heads of the senior analysts, the warehouse modellers, the customer-success leads, and the long-tenured PMs. When someone leaves, some of it walks out the door. When someone new joins, they spend six months rebuilding it.
The question in front of most leadership teams right now isn't "should we experiment with knowledge graphs?" It is "should we make the graph we already have explicit, so an AI can help us query it, so new hires don't have to rebuild it, and so decisions aren't gated on the availability of the three people who remember?"
This post is a plain-English guide to answering that question. No vendor pitches, no diagrams with fourteen arrows, no RDF or Cypher. Just: when it makes sense, when it doesn't, and what a reasonable first step looks like.
The short version
- Most AI use cases start fine with vector search (the "RAG" pattern). You don't need a knowledge graph to ask "summarise this policy."
- You need a knowledge graph when the connections between things are part of the answer. "Why did this happen", "what depends on what", "is this the same X as that one": these are graph questions.
- Analytics is unusually full of graph questions. Metric lineage, KPI root-cause, customer 360, impact analysis, regulatory scope. These all require walking relationships that no single document and no single dashboard contains.
- The best first step is to write down two or three real questions your business is already asking, label them, and pilot the graph only where nothing else will work. Don't boil the ocean.
Why vector search alone hits a wall for analytics
The standard AI-on-your-documents pattern, vector search plus an LLM, does one thing well. It finds passages of text similar in meaning to your question. Ask "what's our refund policy?" and it returns the paragraph that says so. Ask "what are comparable SaaS contracts to this one?" and it surfaces similar clauses.
It's genuinely useful. It's also incomplete for analytics, because analytics questions rarely live inside a single document.
Consider the difference:
| The question | What vector search does | What it can't |
|---|---|---|
| "What's our refund policy?" | Find the paragraph. | (No gap.) |
| "How does our refund policy affect renewal accounting in the Q2 dashboard?" | Find the policy paragraph. | Trace policy to accounting rule to dashboard to metric. |
| "Which customers are exposed if this SKU is discontinued?" | Find the SKU description. | Walk SKU to contracts to customers to revenue. |
| "Why did this KPI move last month?" | Find a blog post about KPI movement. | Connect metric to source table to freshness event to product-change note. |
The second column is where knowledge graphs earn their keep. They don't replace vector search; they sit next to it. Vectors find the right passage, and the graph follows the connections from that passage to everything related.
So what is a knowledge graph, really?
Strip away the jargon and it is exactly what your team draws on whiteboards: a map of the things your business cares about (customers, products, metrics) and the links between them.
A "thing" is an entity. A "link" is a relationship. That's the whole model.
What makes it useful to an AI, and to your analysts, is three practical properties:
- One identity per thing. "ACME Corp", "ACME Inc.", "Acme Holdings Ltd." collapse into one customer entity. Every document that mentioned any of them now points to the same node. This is called entity resolution, and a lot of the value hides here.
- Typed relationships. "Depends on", "is defined by", "is owned by", "supersedes". These aren't just edges, they are kinds of edges. That's what lets the AI answer "what depends on this" differently from "what defines this."
- It's navigable. You can follow chains: metric to dashboard to source to event. That is the part vector search cannot do.
That's it. The hard parts are operational, like keeping it fresh, resolving entities correctly, and making it cheap to query. But the concept is that simple.
Seven analytics questions that get easier with a knowledge graph
Each of these is a question your business is probably already asking. Today, each takes hours or days of manual cross-referencing. On a knowledge graph, they become a single natural-language query.
1. KPI root-cause, end-to-end
"Net revenue dropped 4% last month. Why?"
Today: An analyst opens three dashboards, reads a lineage doc, checks the data-quality channel in Slack, and if they're senior enough to remember, pulls up the product PRD from a renaming exercise last quarter. Two days later, there's an answer. The next time the same question comes up, half that work gets redone.
On a graph: The AI walks from the metric to the dashboards using it, to the upstream tables, to recent data-quality events on those tables, to product or pricing change notes tied to the affected SKUs. The answer comes back with a reasoning path and citations. Fifteen minutes, not two days, and reproducible, so the next analyst gets the same answer.
2. Metric definition consistency
"Is 'active user' defined the same way in the finance, product, and customer-success dashboards?"
Today: This gets discovered in a leadership review when two numbers don't match, and then someone spends a week reconciling them.
On a graph: Every metric definition is an entity. Every dashboard that uses it is linked to it. Inconsistencies are not something you hunt for; they are something the graph exposes automatically. The AI can show the definitions side-by-side with the documents that introduced them.
3. Customer 360 for QBRs and churn reviews
"Give me everything that matters about ACME's account right now."
Today: Pre-QBR prep is a cross-tool scavenger hunt across contracts, the CRM, the ticketing system, usage analytics, and whatever notes the AE has in their head.
On a graph: Contracts, support tickets, product usage, meeting notes, account plans, win/loss reports, all linked to one resolved customer entity. A single question returns a structured view, with citations, and the AI can flag why it thinks the account is at risk: "ticket volume up 40%, two open escalations, renewal in 90 days, last QBR mentioned pricing concerns."
4. Impact and dependency analysis
"If we deprecate this data source, what downstream reports and decisions are affected?" "If this customer churns, what revenue and contractual commitments are at risk?"
Today: Someone senior does a best-effort mental walk of the dependency tree. Often, something gets missed, like a report nobody looks at daily but which feeds a board deck once a quarter.
On a graph: Dependency traversal is literally what graphs do. The answer is exhaustive, not just "the ones I remembered."
5. Regulatory and policy mapping
"Which of our products, processes, and reports fall within scope of the new regulation?"
Today: Months of manual review by risk, compliance, and operations teams working from spreadsheets and email threads.
On a graph: Regulation to policy doc to process to system to dashboard. The scope is traceable, visible to every stakeholder, and re-computed automatically when the regulation changes. The first mapping exercise is still work; every subsequent update is not.
6. Institutional knowledge on demand
"Why did we deprecate this KPI last year?" "Who owns this report?" "What was the decision behind the Q4 pricing change?"
Today: Slack archaeology, or a message to the one person who was there.
On a graph: Tickets, design docs, PRDs, and meeting notes are ingested and linked to the entities they reference. The knowledge stays queryable long after the people who remember have moved on.
7. A live, semantic data catalog
"What data do we have about churn, where does it live, and who uses it?"
Today: Either a data catalog nobody updates, or a tribal-knowledge tour from the analytics lead.
On a graph: The catalog is the graph, maintained by the ingestion pipeline as new documents and datasets arrive. No separate tool to keep in sync, because there isn't a separate tool.
How we actually build this (without going technical)
You don't need to understand the engineering to decide whether to invest. Here's the shape:
- Ingest everything that matters. Contracts, PRDs, policies, meeting notes, data dictionaries, ticket histories, dashboard definitions. PDFs, Word docs, JSON exports, web pages. Each one goes into the pipeline.
- Extract entities and relationships. The pipeline reads each document and pulls out the business-relevant nouns (customers, products, metrics, systems, people, policies) and the verbs that link them ("owns", "depends on", "is defined by", "supersedes", "applies to").
- Resolve duplicates. "ACME Corp" and "ACME Inc." become one node. This step is where a lot of quality comes from. A graph full of duplicate customer nodes is worse than no graph at all.
- Store text and graph together. The original passages stay searchable via vector search, the entities and links sit in the graph, and both point at each other. When the AI answers a question, it uses both.
- Answer with citations. Every response traces back to the specific entities and source passages it came from. If the AI says ACME's renewal is at risk, you can see which meeting note and which ticket trend drove that.
- Keep it isolated by customer. Each organisation's graph lives in its own workspace. No cross-tenant leakage, ever.
The pieces aren't exotic. The discipline is in making them work together at production quality, on messy real-world documents, and on data that keeps changing.
When you should not build one
Intellectual honesty matters here, because most knowledge-graph projects that fail were never good ideas to begin with. Don't build one yet if:
- The questions are single-document. "Summarise this", "find similar contracts", "draft a reply to this email." Vector search is enough.
- Your domain has no meaningful entity overlap. If every document stands alone, there's nothing for a graph to connect.
- You don't have the source material. A graph is only as good as the documents you feed it. If the knowledge isn't written down anywhere, a graph won't invent it.
- You're chasing a buzzword. If "we should have a knowledge graph" came from a conference talk rather than a real, named business question, it's not time yet.
The worst knowledge-graph projects are the ones where the graph gets built first and the use case is retrofitted. The best ones start with a painful, specific question and let the graph grow to serve it.
A pragmatic adoption path
If one of the seven use cases above sounded uncomfortably familiar, here's a path that doesn't require a committee or a twelve-month evaluation.
1. Pick one painful, recurring question. Not a hypothetical, but one that eats your team's time right now. KPI root-cause and Customer 360 are usually the best first bets because the time-savings are easy to measure.
2. Scope the graph to that question. You don't need to model every entity in your business. You need customers, metrics, maybe a few systems, and the documents that connect them. Resist the urge to make it comprehensive on day one.
3. Measure the manual baseline. How long does the question take today, and who does it? Write that down before you start. Without a baseline, you won't be able to tell if it worked.
4. Pilot for four to eight weeks. Ingest the relevant documents, build the graph scoped to the question, and point an AI at it. See whether the answers are correct, fast, and trusted.
5. Only then, widen the scope. Add the next use case once the first has earned its trust.
The mistake most organisations make is going wide before going deep. One use case that genuinely works is worth ten that half-work.
What "good" looks like
A quick checklist for separating a knowledge-graph pilot that's actually working from one that only looks like it is:
- Citations on every answer. If the AI can't point at the specific entities and passages behind its response, you have a demo, not a system.
- Answers survive the "why" follow-up. Ask "why do you think that?" and the system should expose its reasoning path, not hallucinate a new one.
- Entities are resolved. Search for your three largest customers. If any of them show up twice under different spellings, entity resolution isn't working yet and the rest of the answers are unreliable.
- Fresh data shows up without manual intervention. If adding a new document requires a human to wire it into the graph, the pipeline isn't production-grade.
- It doesn't get worse as data grows. Performance and answer quality should be stable or improve as more documents are ingested. A graph that degrades with scale hasn't been architected for production.
Closing
Knowledge graphs are not magic, and they are not for everything. What they are is a way to make the map your best analysts already carry in their heads into something the whole organisation can query, and something that doesn't walk out the door when people do.
If you're evaluating whether it's worth the time, don't start with the technology. Start with two or three real questions your business wants an AI system to answer. If any of them require walking relationships across documents, dashboards, or systems, that's your knowledge-graph use case. Pilot there, measure it, and let the rest follow.
If one of the seven use cases sounded uncomfortably familiar, let's look at it together. We'll give you an honest read on which of your questions are graph-shaped and which aren't, no pitch required.
Schedule a 30-minute conversation to walk through your specific questions, or learn more at www.codd.ai. Bring the most painful, concrete question your team is asking right now, the more specific, the better.