What a knowledge graph actually is, without the hand-waving

Ask five vendors what a knowledge graph is and you get five answers, most of them a diagram with circles on it. Here is the version that survives contact with a real warehouse.

Entities, not rows

Your warehouse has an accounts table, your CRM has an organisations object and your support tool has companies. All three describe the same thing. A graph records that, once, and then knows that a ticket about Lanternfly and an invoice for Lanternfly are about the same account.

Edges are the hard part

Joining on a shared identifier is easy when it exists. Most of the time it does not, so the graph has to infer the link from names, domains, foreign keys that were never declared and the way people talk about the data in docs and tickets.

Getting an edge wrong is worse than missing it, so every inferred edge is shown to you with the evidence behind it and can be rejected in one click.

Where the model fits

The model does not answer from memory. It reads the graph, chooses tables, writes a query, runs it against your warehouse and reports what came back along with the sources. If the graph is wrong the answer is wrong, which is exactly why the graph is the product and the model is a component.