Who Decides Which Version Is True

Here is a small test you can run on your own company.

Pick one product. Ask for its specification. Not the idea of it, the actual document.

In most places, you will not get one document. You will get ten. Plus a couple of drafts someone is editing right now. Plus two that describe features that no longer exist. Plus one that looks authoritative but was abandoned eighteen months ago.

The information is all there. The knowledge is not obvious at all.

I keep coming back to this gap, because it sits right under a word everyone is using lately: knowledge graph.

Linking objects is not the same as knowing the truth

A lot of what gets sold as a knowledge graph is, more honestly, a data graph.

A data graph links objects. People, teams, code, documents, tickets, who touched what and when. That is genuinely useful, and the good ones do it well. They connect the work.

But linking objects is not the same as knowing which object carries the truth.

Back to the ten specs. A data graph will happily connect all ten to the product, to the author, to the related Jira tickets. What it will not do is tell you that version 32 is the one that matters and the other nine are noise. An agent crawling Confluence or SharePoint for “the spec” finds all of them. It has no idea which one is real.

That decision, which version is authoritative, is knowledge. And it is precisely the part that does not fall out of the crawl.

The demo runs on tidy data

The usual answer is: just point retrieval at it, RAG will sort it out.

RAG works. I use it. But it works best when the data underneath is already clean and organized. “It worked in the demo” almost always means the demo ran on tidy data.

Real companies do not have tidy data. They have ten versions of the spec, three naming conventions, a wiki no one has pruned since 2021, and tribal knowledge that never got written down. Point an automated pipeline at that and you do not get knowledge. You get a very well connected pile of contradictions.

We automated the cheap part

There is a flood of open-source projects and tutorials promising automatic knowledge extraction. Feed in your documents, get a graph out.

Very little of it touches the harder question underneath: how do I verify that what I extracted is correct, current, and coherent, rather than half-hallucinated?

Look at the tooling that does exist and the pattern shows. Google’s LangExtract grounds every extracted value back to the exact span it came from. Google Cloud’s Check Grounding scores whether an answer is supported by the source facts you gave it. Both are real, both are useful.

But notice what they actually check. Provenance, not truth. “This quote really is in the document” is not the same as “this is the right document, and this is the true version.” I could not find a standard way to measure that second thing at all. That absence is the tell.

The same gap shows up in the smartest do-it-yourself methods. Karpathy’s LLM wiki, a well-known pattern for letting an agent maintain a knowledge base, has a periodic “lint” pass that health-checks the wiki. It looks for contradictions between pages, stale claims superseded by newer sources, orphan pages, missing links. All of it is about keeping the wiki consistent with itself and current. None of it re-checks whether a digested claim is actually faithful to its source, or which of two contradicting pages is right. It is a structural check, not a truth check, and that is not an oversight. Consistency is the part a machine can do alone.

And consistency has a nasty failure mode, which one of the commenters put more sharply than I could: a confident fabrication gets filed back as a page, and then it is a source. Once the guess is written down, the next pass treats it as ground truth. The consistency checks will happily keep it consistent with everything else. The fabrication does not get caught, it gets integrated.

Because the expensive part of a real knowledge graph was never the extraction. It is the curation. Someone with domain expertise deciding what is authoritative, what is stale, what contradicts what. That work is slow, it does not scale cleanly, and it needs a human who actually understands the domain.

So we automated the cheap part, the extraction, and quietly assumed the expensive part went away.

What I am not saying

I am not arguing for purity. A data graph is a legitimate, useful substrate. Half my point is that it is valuable, which is exactly why relabeling it as validated knowledge is so easy and so misleading.

I am also not saying humans have to curate everything by hand forever. The interesting design question is where the human goes, not whether. Let the machine do the bookkeeping, the linking, the tedious consistency work it is good at. Keep a domain expert on the one judgment that still matters: this one is true, that one is stale, these two contradict and here is which wins.

That division of labor is the actual product. Not the graph.

The hard part never moved

The uncomfortable version of all this is that the graph was never the hard part. Deciding what counts as knowledge, and keeping that decision current as the company changes underneath it, is the hard part. It always was.

The tools got much better at the easy half. That is real progress, and I use it every day. It just makes it easier than ever to ship something that looks like knowledge and is only data wearing its clothes.

If you are building one of these, I would ask one question before anything else. When two sources disagree, who or what decides which one is true, and how do you keep that decision from going stale? If the answer is “the model figures it out,” you have a data graph. That might be fine. Just call it what it is.