Los DAGs están en todos lados. Ninguno sabe lo que es.

Cada build system usa DAGs. Cada pipeline CI/CD usa DAGs. Compiladores, orquestadores de datos, runbooks, gestores de paquetes, operadores de Kubernetes — todos DAGs. Los grafos acíclicos dirigidos son tan ubicuos en la infraestructura de software que la pregunta “¿por qué DAGs?” ya ni registra como pregunta.

Pero hay una segunda pregunta que nadie hace: ¿qué representan esos DAGs?

La respuesta es siempre la misma: orden de ejecución. Esto antes que aquello. Ordenación topológica. Resolución de dependencias. El grafo describe cómo se computa algo, no qué es.

CI/CD:       test → build → deploy
Compilador:  parse → typecheck → codegen → link
Runbook:     check_health → drain → restart → verify

Estos grafos son inertes respecto al sistema sobre el que operan. Un pipeline CI no sabe qué es el proyecto, por qué se construyó así, o qué trade-offs definen su arquitectura. Sabe que los tests deben pasar antes del deploy. Eso es todo lo que sabe.

El gap semántico

Esta inercia no es un defecto — es apropiada. Los build systems deben ser rápidos y mecánicos. Los runbooks deben ser ejecutables sin requerir conocimiento filosófico sobre el sistema. Los grafos de ejecución y los grafos de conocimiento son herramientas distintas para propósitos distintos.

El problema es que la industria del software ha recurrido a DAGs para todo excepto la representación de conocimiento. El conocimiento sobre qué es un sistema — sus principios, sus decisiones arquitectónicas, sus tensiones activas, su superficie de capacidades — vive en documentos. Wikis. READMEs. Tickets. Tradición verbal.

Todo esto es no-estructurado, no-tipado, no-consultable, y garantizado a derivar del sistema real en meses. Describe lo que el proyecto era, no lo que es.

El doble DAG de ontoref

Ontoref usa DAGs en dos modos fundamentalmente distintos, y la distinción importa:

DAG ontológico — aristas con tipo semántico:

Practice "ncl-schemas"  --implements-->  Principle "type-safety"
Practice "ncl-schemas"  --enforces-->    Constraint "zero-runtime-deps"
Practice "ncl-schemas"  --enables-->     Capability "agent-queryable-state"
Practice "ncl-schemas"  --tension-->     Practice "adoption-friction"

Estas aristas no son “depende de”. Son relaciones tipadas: implements, enforces, enables, tension. El grafo es el conocimiento — compromisos formales sobre qué es el proyecto y cómo se relacionan sus conceptos. El equivalente sería un compilador que sabe por qué existe y qué trade-offs arquitectónicos tomó.

DAG de reflexión — contratos ejecutables con restricción de actor:

step "validate-state"  (actor: any)        -->  step "run-mode"  (actor: developer)
step "run-mode"        (actor: developer)  -->  step "report"    (actor: agent|developer)

Esto no es solo ordenación de ejecución. El DAG se valida como contrato antes de ejecutarse, registra su propio progreso a través de transiciones de estado, y codifica quién puede ejecutar cada paso. Un agente que intenta ejecutar un paso restringido a developer recibe un rechazo tipado, no un error en tiempo de ejecución.

La conexión faltante

Lo que hace esto no-trivial es que los dos DAGs se comunican:

El DAG ontológico declara lo que el proyecto ES — restricciones activas, prácticas en tensión, dimensiones de estado actuales
El DAG de reflexión OPERA sobre ese estado — detectando deriva, ejecutando modos, registrando transiciones
Las migraciones propagan cambios en el DAG ontológico a proyectos consumidores descendentes

En todos los demás sistemas que usan DAGs, el grafo se evalúa y se descarta. En ontoref, la evaluación modifica el estado que la siguiente ejecución lee. El grafo tiene memoria.

Por qué esto no existía antes

Tres cosas tuvieron que alinearse:

Los agentes como consumidores. Antes de la IA agéntica, no había ningún consumidor automatizado que necesitara conocimiento estructurado sobre un proyecto. Los humanos podían leer el wiki. Los agentes no pueden — necesitan conocimiento del proyecto tipado, consultable y machine-readable para trabajar con precisión en lugar de alucinar contexto. El DAG de conocimiento de ontoref es lo que los agentes consumen vía MCP.

Lenguajes de configuración con contratos. Expresar una ontología sin un triplestore externo requería un lenguaje de configuración con tipos y contratos. Nickel (NCL) provee exactamente eso: un lenguaje de configuración tipado y lazy donde las violaciones de esquema se detectan en tiempo de evaluación, no en tiempo de ejecución. RDF/OWL habría requerido infraestructura dedicada y expertise especializado.

Escala de repositorio, no de empresa. Los knowledge graphs enterprise son iniciativas de varios años. Ontoref opera a la escala de un repositorio único — adopción incremental, sin enforcement, sin equipo dedicado. La unidad más pequeña que puede adoptarlo es un proyecto de uno.

La consecuencia

Cuando un proyecto tiene un DAG de conocimiento que sus agentes pueden consumir, la aritmética de precisión cambia por completo. Los números de la investigación presentada en KGC 2026:

Retrieval anclado en ontología: 3.4× más preciso que vector RAG en queries enterprise
Queries validadas por ontología: la precisión salta del 16% al 72% en question-answering sobre SQL

La brecha se cierra no con un modelo más grande sino con conocimiento estructurado contra el que el modelo puede razonar. Un DAG donde las aristas significan algo.

Ontoref es open source. La especificación del protocolo, la automatización en Nushell, y los crates de Rust están en repo.jesusperez.pro/ontoref/ontoref.