AI is a Knowledge Tool. But Who Keeps the Knowledge Alive?

Jessica Talisman delivered a talk at KGC 2026 called “Stop Betting, Start Building.” The data she opens with is brutal:

• 89% of firms report zero productivity impact from AI after three years (NBER, Feb 2026, n=5,937 executives)
• Experienced developers are 19% slower with AI tools, not faster (METR RCT, 2025)
• The average AI-using worker gains −14 minutes per week in net productivity (Foxit/Sapio, March 2026)

The market is bullish. The evidence is not.

Her diagnosis is correct: AI is a knowledge tool, not a data tool. Organizations are pouring money into data lakes, vector stores, and ETL pipelines and expecting context and reasoning to emerge from raw tokens. It won’t. Models were trained on linked data, RDF triples, and controlled vocabularies — the top fifteen C4 training sources are knowledge-graph-heavy. They’re then deployed against environments stripped of all that structure, and we wonder why they hallucinate.

Her prescription is also correct: build knowledge infrastructure. Controlled vocabularies first. Taxonomies. Thesauri. Ontologies — formal commitments, classes, properties, constraints. Knowledge graphs on top. And govern them. Forever, not as a project.

She’s right. And she stops exactly where the hard problem begins.

The Governance Gap

The sixth step in her stack is “Govern — this is infrastructure, stewardship, versioning, growth, forever.” She names the problem. But naming it is not a mechanism.

The real question is: who ensures the ontology doesn’t drift from the system it describes?

Software evolves. An architectural decision made in March invalidates a node in the graph by October. A new team joins with different mental models. A library gets replaced and a constraint becomes fictional. Knowledge graphs accumulate debt the same way codebases do — silently, without an alarm.

In the enterprise knowledge graph world, the answer to governance is headcount: hire ontologists, librarians, knowledge engineers. That works at organizational scale with dedicated budgets. It is not a viable answer for a software project, an infrastructure environment, or an individual trying to maintain structured self-knowledge.

What’s Actually Missing: the Operational Loop

Every serious ontology without an operational closure layer becomes archaeology within eighteen months. Beautiful, formally correct, and describing a system that no longer exists.

The missing piece is not more knowledge. It’s a feedback loop that:

1. Observes the current state of the system against its declared intent
2. Detects drift before it becomes permanent
3. Executes operations that reduce that drift
4. Records decisions with lasting architectural weight
5. Propagates changes to everything that depends on this knowledge

This is the Yang to the ontology’s Yin. Talisman describes the Yin in precise detail. The Yang is what makes it not an artifact.

Ontoref: Both Halves

Ontoref is a protocol for structured self-knowledge in software projects. It operates as two coexisting layers that cannot function without each other:

Ontology (what IS): typed nodes and edges representing practices, principles, tensions, capabilities. Not documentation — formal commitments. A Practice node that implements a Principle, enforces a Constraint, enables a Capability, and is in active tension with another Practice. The project as a knowledge graph.

Reflection (what BECOMES): executable DAGs — operational modes that run against the ontological state, detect drift, report transitions, and propagate changes. The sync diff --docs command that catches when a crate’s documentation has drifted from its ontology node. The FSM in state.ncl that tracks where each project dimension is versus where it intends to go. The migrations system that ensures protocol changes reach every consumer project.

The tension between these two layers is not a design flaw — it’s named explicitly in the project’s own ontology as its core identity:

“Ontology captures what IS. Reflection captures what BECOMES. Both must coexist without one dominating.”

Without Reflection, the Ontology crystallizes. It becomes a snapshot of what the project wanted to be at the moment it was written. Without Ontology, Reflection is execution without truth — it knows how to operate but not what it’s operating on.

The Accuracy Numbers

Talisman’s data on what structured knowledge actually does to AI accuracy is worth repeating:

• Question-answering on enterprise SQL: 16% → 72% when an ontology checks and repairs LLM-generated queries (Allemang & Sequeda, data.world AI Lab, 2024)
• GraphRAG vs. vector RAG: 3.4× accuracy across 43 enterprise queries (Diffbot KG-LM Benchmark, 2023)
• Vector RAG collapses to 0% accuracy past five entities per query. KG-grounded retrieval sustains performance well beyond that

The accuracy gap is not closed by a bigger model. It is closed by a defined schema, an ontology, and a validated query.

But only if the ontology is kept alive. Only if someone — or something — is running the operational loop that keeps it from drifting into fiction.

That’s the part Talisman’s framework doesn’t provide. That’s what Reflection is for.

Ontoref is open source. The protocol specification, Nushell automation, and Rust crates are at repo.jesusperez.pro/ontoref/ontoref.