# Ontoref — Por qué los DAGs de ontoref son diferentes

Referencia para posts, slides, presentaciones.
Contexto: análisis de por qué DAGs son ubicuos pero nadie tiene la perspectiva de ontoref.

---

## DAGs son ubicuos — y todos hacen lo mismo

En CI/CD, compiladores, runbooks, Airflow, dbt, Bazel: el DAG es un **modelo de ejecución**.
Las aristas significan "esto antes que aquello". El grafo describe *cómo se computa*,
no *qué es lo que se computa*. Es ordenación topológica, no conocimiento.

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

Todos inerts. El grafo no sabe qué es el proyecto. No tiene semántica sobre sus propias aristas.

---

## Ontoref usa DAGs en dos modos distintos

**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"
```

No es "esto antes que aquello". Es 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 tomó.

**DAG de reflexión — aristas con contrato ejecutable + restricción de actor:**

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

No es solo ejecución. El DAG es validado como contrato antes de ejecutarse,
registra su propio progreso, y sabe quién puede hacer qué.

---

## El gap que nadie ha cerrado

```
Knowledge Graph world:  semántica sobre el dominio del negocio
Software tooling world: DAGs sobre la ejecución del software
ontoref:                semántica sobre el proyecto de software en sí mismo
```

El mundo de knowledge graphs (W3C, RDF/OWL, Talisman) aplica semántica a dominios
empresariales — productos, clientes, transacciones. Nunca al proyecto de software mismo.

El mundo de herramientas de software (GitHub, Jira, CI/CD) trata el conocimiento del
proyecto como documentos no tipados. Usa DAGs para ejecución, nunca para representación
de conocimiento.

---

## La pieza que lo hace no-trivial

Los dos DAGs se hablan:

- El DAG ontológico dice *qué es* el proyecto (prácticas, principios, constraints activos)
- El DAG de reflexión *opera sobre ese estado* — detecta deriva, ejecuta modos, registra transiciones
- Las migraciones propagan cambios del DAG ontológico a proyectos consumidores

Sin esa conexión: ontología bonita que nadie mantiene (buenas intenciones)
o runbooks sin semántica (ejecución ciega).

---

## Por qué no había emergido antes

Tres condicionantes que ahora se alinean:

1. **Agentes AI** — que necesitan consumir conocimiento estructurado del proyecto,
   no texto libre. Antes no había consumidor que lo requiriera con urgencia.
2. **NCL/Nickel** — contratos y tipos que permiten expresar ontología sin triplestore externo.
   RDF/OWL requería infraestructura pesada y expertise especializado.
3. **La escala correcta** — Knowledge Graphs empresariales son proyectos de años.
   Ontoref opera a escala de repositorio, con adopción incremental y sin enforcement.

---

## Para slides

**Una línea:** Todos usan DAGs para HACER cosas. Ontoref usa DAGs para CONOCER cosas
sobre el proyecto, Y para HACER cosas, Y hace que las dos capas se hablen.

**Contraste:**

| DAGs tradicionales | DAGs en ontoref |
|---|---|
| Modelo de ejecución | Modelo de conocimiento + ejecución |
| Aristas: "depende de" | Aristas: `implements`, `enforces`, `tension`, `enables` |
| Inert respecto al proyecto | Semánticamente cargado con el estado del proyecto |
| Evalúa y descarta | Evalúa, registra, propaga |
| Grafo describe proceso externo | Grafo describe el proyecto mismo |