98 lines
6.4 KiB
Markdown
98 lines
6.4 KiB
Markdown
|
|
---
|
|||
|
|
# Post metadata
|
|||
|
|
id: "ai-knowledge-tool-who-keeps-it-alive"
|
|||
|
|
title: "AI is a Knowledge Tool. But Who Keeps the Knowledge Alive?"
|
|||
|
|
slug: "ai-knowledge-tool-who-keeps-it-alive"
|
|||
|
|
subtitle: "Talisman is right — and stops exactly where the hard problem begins"
|
|||
|
|
excerpt: "Jessica Talisman's KGC 2026 talk is the clearest articulation of why AI strategies fail: organizations invest in data infrastructure and expect reasoning to emerge. She's right. But her solution — build knowledge infrastructure — stops exactly where the hard problem begins: who keeps the knowledge from drifting?"
|
|||
|
|
|
|||
|
|
# Publication info
|
|||
|
|
author: "Jesús Pérez"
|
|||
|
|
date: "2026-05-10"
|
|||
|
|
published: false
|
|||
|
|
featured: false
|
|||
|
|
|
|||
|
|
# Categorization
|
|||
|
|
category: "ontoref"
|
|||
|
|
tags: ["ontoref", "knowledge-graphs", "ontology", "ai-infrastructure", "reflection"]
|
|||
|
|
|
|||
|
|
# Display
|
|||
|
|
read_time: "7 min read"
|
|||
|
|
sort_order: 1
|
|||
|
|
css_class: "category-ontoref"
|
|||
|
|
category_description: "Ontoref — protocol and tooling for structured self-knowledge in software projects"
|
|||
|
|
category_published: true
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
# 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 [github.com/jesusperezlorenzo/ontoref](https://github.com/jesusperezlorenzo/ontoref).*
|