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).
106 lines
6.8 KiB
Markdown
106 lines
6.8 KiB
Markdown
---
|
||
# Post metadata
|
||
id: "dags-en-todos-lados-ninguno-sabe-lo-que-es"
|
||
title: "Los DAGs están en todos lados. Ninguno sabe lo que es."
|
||
slug: "dags-en-todos-lados-ninguno-sabe-lo-que-es"
|
||
subtitle: "Cada build system, pipeline CI y runbook usa DAGs para ejecución. Ontoref los usa para conocimiento."
|
||
excerpt: "Pipelines CI/CD, compiladores, runbooks, orquestadores de datos — todos usan grafos acíclicos dirigidos. Todos sin excepción los usan como modelos de ejecución: esto antes que aquello, ordenación topológica, resolución de dependencias. Ninguno los usa para representar qué es el sistema, por qué existe, o qué trade-offs lo definen. Ese es el gap que llena ontoref."
|
||
|
||
# Publication info
|
||
author: "Jesús Pérez"
|
||
date: "2026-05-10"
|
||
published: false
|
||
featured: false
|
||
|
||
# Categorization
|
||
category: "ontoref"
|
||
tags: ["ontoref", "dag", "ontology", "knowledge-graphs", "arquitectura-software"]
|
||
|
||
# Display
|
||
read_time: "6 min read"
|
||
sort_order: 2
|
||
css_class: "category-ontoref"
|
||
category_description: "Ontoref — protocolo y herramientas para el auto-conocimiento estructurado en proyectos de software"
|
||
category_published: true
|
||
---
|
||
|
||
# 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 de runtime.
|
||
|
||
## 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 — constraints activos, 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 schema se detectan en tiempo de evaluación, no de runtime. 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 [github.com/jesusperezlorenzo/ontoref](https://github.com/jesusperezlorenzo/ontoref).*
|