0:00This video is about what happens inside a knowledge graph when identity goes wrong. One company, Acme, has a record in three systems, each with its own spelling of the name.
0:12Suppose nobody ever resolved those three records into one entity.
0:16The C-R-M spelling becomes one node.
0:18Billing's spelling becomes another.
0:20And support's becomes a third. Three provisional identities, each with an I-D of its own.
0:26They're one supplier. Count companies and you get three. Revenue per supplier splits across three rows that should have been one, and that's before any query does anything interesting.
0:38Now some recorded facts. Beta buys from Acme, and that purchase was recorded against the C-R-M identity. That's where a traversal starting at Beta will arrive.
1:18And Acme supplies a component called Valve, recorded against the support identity. Both facts are in the graph. Nothing connects the two nodes they're attached to.
1:29Now let's ask this graph a question.
1:31Same five nodes, same two recorded facts, nothing added.
1:35Which components come from suppliers that Beta buys from? That's a two hop question. Follow the purchase, then follow what that supplier supplies.
1:44We start at Beta, because Beta is the entity we were given.
1:48Follow buys from, and we arrive at the C-R-M identity.
1:51And that's where it stops. Nothing supplies anything from this node, so the query returns no result under these conditions. Notice what it doesn't say. It doesn't say Acme supplies no components.
2:05An empty result is a statement about the data and the query, not about the world.
2:10Here we happen to know why it's empty, because we watched the identity split earlier. Without that, all you'd have is an empty answer and no way to tell whether to trust it.
2:21Nothing about those two facts was wrong. The identity underneath them was.
2:25Here's the same broken graph, and here's the decision we already made. Those three records are one company, and it has an I-D.
2:33Apply it, and the three provisional nodes become one. Same three records behind it, and the same identifier we assigned back at the canonicalize step.
2:41The supplies relationship was always there. It now starts from the entity it was always about.
2:47And the path connects. Beta buys from Acme, Acme supplies Valve, and the two hop question has an answer.
2:54Nothing was invented to make that work. No relationship was added to the graph at all. The facts that were already recorded got attached to the identity they were always describing, and the source records are exactly where they were.
3:09Splitting is one failure. The other one is worse, because it's confident.
3:13Here's C-R-M one oh two, a genuinely different company whose name also normalizes to acme. It supplies a component called Pump, and that's a real recorded fact about it.
3:26And here's Acme, the company we resolved correctly.
3:29Now suppose the pipeline had merged those two. The name matched, the threshold was set too low, nobody reviewed it. The supplies relationship reattaches to Acme.
3:39And now the graph says Acme supplies Pump.
3:42Traversals will find it. Aggregations will count it.
3:45An LLM that asked about Acme's components will report it as grounded in the graph.
3:50It's false, and nothing downstream can tell.
3:53Better retrieval just finds the wrong fact faster, and a bigger model repeats it more fluently.
3:59The identity underneath an answer isn't something the answer layer can check.
4:04New records keep arriving. Corrections keep arriving. Resolution isn't something you run once.
4:10So here's the whole pipeline, with one new record entering it. Normalize first: build the values you'll compare on, and keep the originals beside them.
4:19Block selectively, and run more than one pass, so a single cheap key doesn't quietly lose you half your matches.
4:26Combine evidence from several fields, and treat a missing value differently from a disagreeing one.
4:32Set the cut points around what each kind of error actually costs you, and leave a band in the middle where a person decides.
4:38Then canonicalize one field at a time, keep the links back to every source record, and keep every decision revisable. Because tomorrow another record arrives, and the whole thing runs again.
4:51So here's where that leaves you.
4:52You can recognize a split identity by what it does to a query. A path that should connect stops short, and the empty result says nothing about the world.
5:03And you can recognize an incorrect merge, the failure that is worse because it is confident. The graph reports a fact that is false, and nothing downstream can tell.
5:14One thing to carry out of this. Every answer a graph gives rests on the identities underneath it, and those have to be right before the answer can be.

What a Wrong Identity Does to a Knowledge Graph

Created by Abhyuday DesaiPublished 3 Oct, v1Runs 5 min 29 sec

0 views

About this video

One company, three unresolved spellings, three nodes. This video asks the graph a two-hop question and watches the traversal stop short, then applies the resolution decision and watches the path connect with no relationship added. The worse failure follows: two companies merged into one, and a false fact that every traversal, aggregation and language model downstream will report as grounded.

You'll learn how to:

Read an empty traversal result as a statement about the data, not the world
See how resolving identity reconnects recorded facts to the entity they were always about
Recognize why an incorrect merge is worse than a split: it is confident, and nothing downstream can tell
Run the resolution pipeline end to end, because new records keep arriving

For developers who query a graph and need to trust what comes back.

What changed

v103 Oct 2026abhydesai5 min 29 sec21ba95b

First published version.

0 views0 likes on this version