0:00This video is about what the assertions in a knowledge graph establish, what they don't, and when the structure is worth maintaining.
0:07People say a graph holds what is true. That's shorthand, and it's worth being precise.
0:12Here's the assertion on its own, with the entities it's about. Notice the line about its source.
0:19Nothing has backed this up. Recording a claim is not the same as checking it.
0:24So when we say the graph holds what is true, we mean it holds what has been asserted. Evidence is separate.
0:31There's a second gap worth naming. Suppose the model never says whether an acquisition needs a date.
0:38Now two teams reading the same ontology can reasonably disagree about what a complete record looks like.
0:44And here's the third. An ontology with no assertions can still document a domain, but ask it who Acme acquired and you get nothing back.
0:54That empty answer is easy to misread. Rules don't supply missing data, and silence is not evidence of absence.
1:02There's a third term that gets folded in with ontology and knowledge graph, and it's worth separating out.
1:09It's the semantic layer. Think about what your organisation means by an active customer.
1:15Somebody has to define that. For example, here's one.
1:18Give that definition a name, and it stops being something every team reinvents on its own.
1:23Underneath, it's ordinary data logic, one query over tables you already have.
1:29The rule has two conditions doing the work. An order that actually completed.
1:34And a ninety day window. Those two conditions are the entire definition.
1:38Now here's who cares. A dashboard, somebody writing a query by hand, and an LLM agent answering a question.
1:46When all three pull from the same definition, they inherit the same meaning. The benefit is consistency, not a new database.
1:54So how is that different from an ontology? Put them side by side.
1:59One of them standardises business definitions over data you already have.
2:03The other models entity types, the relationships between them, and the constraints on those.
2:08They come from the same instinct, which is to make meaning explicit. But they work on different material.
2:15Now let's put a language model in the loop, because that's where a lot of this ends up.
2:19Suppose a model reads a document and proposes a fact from it. Alice acquired Beta, where Alice is a person.
2:27The ontology rule says both ends of an acquisition must be companies, so the check rejects it. Nothing special happens because a model produced it.
2:36But be careful what that buys you. A claim can fit the schema perfectly and still be false. Validation isn't verification.
2:44Here's the other side of it. Ask a question about a relationship you've actually recorded.
2:49The answer comes from following an edge, rather than guessing at a passage that looked similar.
2:55And it's scoped. Correct about the data we queried, under the conditions we set, and claiming nothing beyond that.
3:03There's one more thing the model can hold.
3:05A press release announcing an acquisition won't stop to mention that acquirers have to be companies. Everyone in the domain already knows it.
3:13So nobody writes it down. The ontology is a place to put that background rule where a system can act on it.
3:21So when is all of this worth the maintenance?
3:24Explicit structure pays off under three conditions.
3:26The domain holds still long enough to be worth modelling.
3:30Getting an answer wrong actually costs something.
3:33And several teams or systems need to mean the same thing by the same word.
3:38When those conditions don't hold, it often isn't worth it.
3:41Say you're exploring, and you don't yet know what you're looking for.
3:44The material changes faster than you could model it.
3:48And you're the only one asking. Then embeddings and similarity retrieval may be all you need. That's a real answer, not a lesser one.
3:56The thing to hold on to is what you're actually buying. Structure earns its keep through checks it can run and connections it can follow.
4:05So here's where that leaves you.
4:07You can treat every edge as a recorded claim, and keep the question of evidence separate from the question of whether the claim is allowed.
4:14And you can say when explicit structure is worth its upkeep. A stable domain, answers that cost something when wrong, and several systems that need to share a meaning.
4:27One thing to carry out of this. Everything in a graph is something somebody asserted, and the schema is what makes those assertions comparable.

What a Knowledge Graph Doesn't Prove

Created by Abhyuday DesaiPublished 3 Oct, v1Runs 4 min 41 sec

0 views

About this video

People say a knowledge graph holds what is true. This video is precise about that: an assertion is a recorded claim with its evidence kept separate, a rule the model never states leaves teams free to disagree, and an empty answer is not evidence of absence. It then separates the semantic layer from the ontology, puts a language model in the loop, and asks when all this structure earns its upkeep.

You'll learn how to:

Treat a graph edge as an assertion and keep the question of evidence separate
Tell a semantic layer (shared business definitions over tables) from an ontology
See why validation is not verification when a model proposes a fact
Judge when explicit structure pays off, and when similarity retrieval alone is the honest answer

For developers deciding whether to invest in a modeled domain for an AI system.

What changed

v103 Oct 2026abhydesai4 min 41 sec21ba95b

First published version.

0 views0 likes on this version