82a358f18d
ontoref-derive: #[onto_mcp_tool] attribute macro registers MCP tool unit-structs in
the catalog at link time via inventory::submit!; annotated item is emitted unchanged,
ToolBase/AsyncTool impls stay on the struct. All 34 tools migrated from manual wiring
(net +5: ontoref_list_projects, ontoref_search, ontoref_describe,
ontoref_list_ontology_extensions, ontoref_get_ontology_extension).
validate modes (ADR-018): reads level_hierarchy from workflow.ncl and checks every
.ncl mode for level declared, strategy declared, delegate chain coherent, compose
extends valid. mode resolve <id> shows which hierarchy level handles a mode and why.
--self-test generates synthetic fixtures in a temp dir for CI smoke-testing.
validate run-cargo: two-step Cargo.toml resolution — workspace layout first
(crates/<check.crate>/Cargo.toml), single-crate fallback by package name or repo
basename. Lets the same ADR constraint shape apply to workspace and single-crate repos.
ontology/schemas/manifest.ncl: registry_topology_type contract — multi-registry
coordination, push targets, participant scopes, per-namespace capability.
reflection/requirements/base.ncl: oras ≥1.2.0, cosign ≥2.0.0, sops ≥3.9.0, age
≥1.1.0, restic declared as Hard/Soft requirements with version_min, check_cmd, and
install_hint (ADR-017 toolchain surface).
ADR-019: per-file recipient routing for tenant isolation without multi-vault. Schema
additions: sops.recipient_groups + sops.recipient_rules in ontoref-project.ncl.
secrets-bootstrap generates .sops.yaml from project.ncl in declarative mode. Three
new secrets-audit checks: recipient-routing-coherent, recipient-routing-coverage,
no-multi-vault. Adoption templates: single-team/, multi-tenant/, agent-first/.
Integration templates: domain-producer/, mode-producer/, mode-consumer/.
UI: project_picker surfaces registry badge (⟳ participant) and vault badge
(⛁ vault_id · N, green=declarative / amber=legacy) per project card. Expanded panel
adds collapsible Registry section with namespace, endpoint, and push/pull capability.
manage.html gains Runtime Services card — MCP and GraphQL toggleable without restart
via HTMX POST /ui/manage/services/{service}/toggle.
describe.nu: capabilities JSON includes registry_topology and vault_state per project.
sync.nu: drift check extended to detect //! absence on newly registered crates.
qa.ncl: six entries — credential-vault-best-practice (layered data-flow diagram),
credential-vault-templates (paths A/B/C), credential-vault-troubleshooting (15 named
errors), integration-what-and-why (ADR-042 OCI federation), integration-how-to-implement,
integration-troubleshooting.
on+re: core.ncl + manifest.ncl updated to reflect OCI, MCP, and mode-hierarchy nodes.
Deleted stale presentation assets (2026-02 slides + voice notes).
7 KiB
| id | title | slug | subtitle | excerpt | author | date | published | featured | category | tags | read_time | sort_order | css_class | category_description | category_published | |||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| la-ia-herramienta-conocimiento-quien-mantiene-vivo | La IA es una herramienta de conocimiento. ¿Pero quién mantiene vivo el conocimiento? | la-ia-herramienta-conocimiento-quien-mantiene-vivo | Talisman tiene razón — y se detiene exactamente donde empieza el problema difícil | La charla de Jessica Talisman en KGC 2026 es la articulación más clara de por qué fallan las estrategias de AI: las organizaciones invierten en infraestructura de datos y esperan que emerja el razonamiento. Tiene razón. Pero su solución — construir infraestructura de conocimiento — se detiene exactamente donde empieza el problema difícil: ¿quién evita que el conocimiento derive? | Jesús Pérez | 2026-05-10 | false | false | ontoref |
|
7 min read | 1 | category-ontoref | Ontoref — protocolo y herramientas para el auto-conocimiento estructurado en proyectos de software | true |
La IA es una herramienta de conocimiento. ¿Pero quién mantiene vivo el conocimiento?
Jessica Talisman dio una charla en KGC 2026 llamada "Stop Betting, Start Building." Los datos con los que abre son contundentes:
- 89% de las empresas no reportan impacto de productividad de la IA después de tres años (NBER, Feb 2026, n=5.937 ejecutivos)
- Los developers experimentados son 19% más lentos con herramientas de IA, no más rápidos (METR RCT, 2025)
- El trabajador promedio que usa IA gana −14 minutos netos por semana en productividad (Foxit/Sapio, marzo 2026)
El mercado es alcista. La evidencia, no.
Su diagnóstico es correcto: la IA es una herramienta de conocimiento, no de datos. Las organizaciones invierten en data lakes, vector stores y pipelines ETL esperando que el contexto y el razonamiento emerjan de tokens crudos. No va a ocurrir. Los modelos fueron entrenados sobre linked data, triples RDF y vocabularios controlados — las quince principales fuentes de entrenamiento de C4 son intensivas en knowledge graphs. Luego se despliegan en entornos despojados de toda esa estructura, y nos preguntamos por qué alucinan.
Su prescripción también es correcta: construye infraestructura de conocimiento. Primero vocabularios controlados. Taxonomías. Tesauros. Ontologías — compromisos formales, clases, propiedades, constraints. Knowledge graphs encima. Y goviernalos. Para siempre, no como un proyecto.
Tiene razón. Y se detiene exactamente donde empieza el problema difícil.
El gap de governance
El sexto paso en su stack es "Govern — esto es infraestructura, stewardship, versionado, crecimiento, para siempre." Nombra el problema. Pero nombrarlo no es un mecanismo.
La pregunta real es: ¿quién asegura que la ontología no derive respecto al sistema que describe?
El software evoluciona. Una decisión arquitectónica tomada en marzo invalida un nodo del grafo en octubre. Se incorpora un nuevo equipo con modelos mentales distintos. Una librería se reemplaza y un constraint se convierte en ficción. Los knowledge graphs acumulan deuda igual que los codebases — silenciosamente, sin alarmas.
En el mundo enterprise de knowledge graphs, la respuesta al governance es headcount: contratar ontólogos, bibliotecarios, knowledge engineers. Funciona a escala organizacional con presupuestos dedicados. No es una respuesta viable para un proyecto de software, un entorno de infraestructura, o un individuo que intenta mantener auto-conocimiento estructurado.
Lo que realmente falta: el loop operacional
Toda ontología seria sin un cierre operacional se convierte en arqueología en dieciocho meses. Hermosa, formalmente correcta, y describiendo un sistema que ya no existe.
La pieza que falta no es más conocimiento. Es un loop de retroalimentación que:
- Observa el estado actual del sistema contra su intención declarada
- Detecta la deriva antes de que se vuelva permanente
- Ejecuta operaciones que reducen esa deriva
- Registra decisiones con peso arquitectónico duradero
- Propaga los cambios a todo lo que depende de este conocimiento
Este es el Yang al Yin de la ontología. Talisman describe el Yin con precisión. El Yang es lo que evita que sea un artefacto.
Ontoref: las dos mitades
Ontoref es un protocolo para el auto-conocimiento estructurado en proyectos de software. Opera como dos capas coexistentes que no pueden funcionar la una sin la otra:
Ontología (lo que ES): nodos y aristas tipadas que representan prácticas, principios, tensiones, capacidades. No documentación — compromisos formales. Un nodo Practice que implements un Principle, enforces un Constraint, enables una Capability, y está en tension activa con otra Practice. El proyecto como knowledge graph.
Reflection (lo que DEVIENE): DAGs ejecutables — modos operacionales que corren contra el estado ontológico, detectan deriva, registran transiciones y propagan cambios. El comando sync diff --docs que detecta cuándo la documentación de un crate ha derivado de su nodo ontológico. El FSM en state.ncl que registra dónde está cada dimensión del proyecto versus adónde pretende ir. El sistema de migraciones que asegura que los cambios de protocolo lleguen a cada proyecto consumidor.
La tensión entre estas dos capas no es un defecto de diseño — está nombrada explícitamente en la ontología del propio proyecto como su identidad central:
"Ontology captures what IS. Reflection captures what BECOMES. Both must coexist without one dominating."
Sin Reflection, la Ontología cristaliza. Se convierte en una fotografía de lo que el proyecto quería ser en el momento en que se escribió. Sin Ontología, Reflection es ejecución sin verdad — sabe cómo operar pero no sobre qué opera.
Los números de precisión
Los datos de Talisman sobre lo que el conocimiento estructurado hace a la precisión de la IA merecen repetirse:
- Question-answering sobre SQL enterprise: 16% → 72% cuando una ontología verifica y repara queries generadas por LLM (Allemang & Sequeda, data.world AI Lab, 2024)
- GraphRAG vs. vector RAG: 3.4× precisión en 43 queries enterprise (Diffbot KG-LM Benchmark, 2023)
- Vector RAG colapsa a 0% precisión más allá de cinco entidades por query. El retrieval anclado en KG sostiene el rendimiento mucho más allá
La brecha de precisión no se cierra con un modelo más grande. Se cierra con un schema definido, una ontología, y una query validada.
Pero solo si la ontología se mantiene viva. Solo si algo o alguien ejecuta el loop operacional que evita que derive hacia la ficción.
Esa es la parte que el framework de Talisman no provee. Para eso existe Reflection.
Ontoref es open source. La especificación del protocolo, la automatización en Nushell, y los crates de Rust están en github.com/jesusperezlorenzo/ontoref.