Un protocolo, múltiples sujetos

La pregunta que ontoref hace a un proyecto de software es precisa: ¿Qué eres? ¿Qué principios te definen? ¿Qué tensiones estás gestionando activamente? ¿Qué decisiones has tomado con consecuencias duraderas? ¿Dónde estás versus dónde pretendes estar?

Resulta que es la misma pregunta que los entornos de infraestructura necesitan responder. Y una obra autorada. Y los individuos.

El sujeto cambia. La pregunta es idéntica.

Lo que todos tienen en común

Cualquier sistema con identidad e intención comparte el mismo problema estructural:

• Identidad — qué es, qué principios lo definen
• Tensiones activas — trade-offs que no se resuelven, se gestionan
• Decisiones duraderas — elecciones con consecuencias que restringen el futuro
• Estado observable — dónde está versus dónde pretende estar
• Deriva — la distancia entre intención y realidad, creciendo silenciosamente con el tiempo
• Operaciones — las acciones que reducen esa deriva

Los proyectos de software tienen todo esto. Los entornos de infraestructura también. Una obra autorada también. Las personas también.

Y todos se benefician de la misma arquitectura: una capa ontológica que captura lo que ES, y una capa de reflexión que captura lo que DEVIENE y opera para mantener ambas alineadas.

Infraestructura

La infraestructura ya usa DAGs — Terraform, Pulumi, Ansible. Todos describen cómo se provisiona el sistema. Ninguno captura por qué existe como existe.

El “por qué” es donde vive el conocimiento:

Servicio "auth"            --tension-->    Principio "stateless"
    razón: necesita session state, pero el principio lo prohíbe

Constraint "zero-downtime" --enforces-->   Práctica "blue-green"
    razón: ADR-infra-003, después del incidente de deploy de 2025

Esta información no está en el plan de Terraform. Está en la memoria del engineer que estuvo allí, en un hilo de Slack de hace ocho meses, o en ningún lado. Cuando ese engineer se va, la infraestructura pierde su propia historia — sabe lo que es, no por qué.

El ontoref de infraestructura captura las decisiones arquitectónicas de la propia infraestructura, con el mismo formalismo de ADR que los proyectos de software. Registra dimensiones de estado — qué entornos están estables, cuáles en migración activa, qué está bloqueado y por qué. La máquina de estados no registra el estado de deploy; registra el estado epistémico — qué tan bien se entiende a sí misma la infraestructura.

La federación vía NATS significa que cada entorno (dev, staging, prod) se describe a sí mismo y puede ser consultado desde los proyectos que dependen de él. GitOps soberano: el conocimiento de infraestructura vive con el código de infraestructura, no en la base de datos de un vendor.

Autoría — la obra

Este es el sujeto al que ontoref llegó el último, y aquel donde la deriva es más visible para el lector.

Una obra — un libro, un curso, un método documentado, un corpus de investigación — es un todo coherente autorado. Tiene una tesis, una arquitectura, y decisiones que restringen cada edición posterior. Enfrenta el problema estructural idéntico:

Capítulo "notas de campo"   --tension-->   Tesis "método sobre receta"
    el capítulo gana su lugar solo si sirve al todo

Decisión "reestructuré la Parte II"  --constraint-->  toda traducción y adaptación
    con el mismo peso arquitectónico que un ADR-001

Estado "borrador"   --blocker-->   "segunda edición"
    una dimensión de la máquina de estados de la obra, no una tarea en un backlog

La deriva aquí tiene un nombre que los autores ya sienten: la obra se difunde como fragmentos — un post, una charla, un extracto, un hilo — y cada fragmento viaja sin el todo. Con el tiempo los fragmentos dicen cosas que la obra ya no significa, o la obra se mueve y los fragmentos se quedan atrás. El lector encuentra el fragmento, nunca el todo gobernado.

La autoría con ontoref trata la obra como el sujeto y cada fragmento como una arista provenada de vuelta a ella. La capa ontológica sostiene lo que la obra es — su tesis, su estructura, las decisiones que atan las ediciones futuras. La capa de reflexión opera la difusión: qué fragmentos están vivos, cuáles han derivado, a qué edición pertenecen. El libro es el arquetipo, no el límite; la difusión es un efecto de la obra, nunca su esencia. La puerta lo dice en una línea: difunde la obra entera, no fragmentos sueltos.

Personal

Esta es la aplicación más radical. Pero se sigue directamente de la misma lógica.

Una persona con valores, roles e intenciones a largo plazo enfrenta exactamente el mismo problema estructural que un proyecto de software:

Valor "profundidad"   --tension-->   Rol "padre"
    razón: el tiempo es finito y los dos lo demandan completamente

Decisión "dejé empresa X"  --constraint-->   Elecciones de carrera futuras
    con el mismo peso arquitectónico que un ADR-001

Estado "aprendiendo Rust"  --blocker-->   "contribuir a ontoref-core"
    una dimensión FSM personal, no un ítem de lista de tareas

El knowledge graph aquí no es un sistema de productividad. No es un segundo cerebro de notas. Es un grafo de compromisos — tipados, provenados, con tensiones activas nombradas en lugar de suprimidas.

El problema de deriva es idéntico: quién estás llegando a ser versus quién pretendías ser. Los modos de reflexión para una persona pueden ser revisiones semanales, evaluaciones anuales de estado, o revisiones disparadas cuando una decisión mayor introduce nuevas restricciones. El loop operacional es el mismo — observa, detecta deriva, ejecuta, registra.

El mismo stack, sujeto distinto

Cada uno de estos dominios corre en la misma infraestructura:

Almacenamiento soberano: El conocimiento vive junto a su sujeto — en el repo del proyecto, en el código de infraestructura, en el repositorio de la obra del autor, en una bóveda personal. Ningún vendor lo retiene. Sin dependencia de plataforma. Archivos NCL versionados con la misma disciplina que el código.

Acceso multi-superficie:

Alineación VCS: El modelo de jj — donde el working copy es siempre un commit — se alinea naturalmente con el enfoque de ontoref de captura continua de estado. No hay “dirty state”; cada momento es capturable. Radicle como transporte hace el stack soberano y P2P — colaboración de código sin plataforma central.

Federación: Proyectos consultando los knowledge graphs de otros sin un broker central. Entornos de infraestructura exponiendo su auto-conocimiento a los proyectos que dependen de ellos. Autores cuya obra expone su estructura para que cada cita y extracto resuelva de vuelta al todo. Individuos cuyo knowledge graph personal informa sus contribuciones a los proyectos en los que trabajan.

Por qué la escala importa

La unidad más pequeña que puede adoptar ontoref es una persona. Un developer, un proyecto, un entorno de infraestructura, un autor con una obra. Sin equipo requerido. Sin conversación de presupuesto.

La unidad más grande es un ecosistema de proyectos federados y auto-descritos que pueden consultarse mutuamente sin que ninguno sea la fuente central autoritativa.

Ese rango — de individuo a ecosistema — es posible porque el protocolo es el mismo a cada escala. El DAG ontológico y el DAG de reflexión no cambian de forma según el tamaño del sujeto. Cambian en densidad y profundidad, no en estructura.

Las organizaciones que Talisman argumenta deberían invertir en infraestructura de conocimiento intentan construirla top-down, con equipos dedicados y programas de varios años. Ontoref lo hace disponible bottom-up — empezando con un solo proyecto, un solo entorno, una sola obra, una sola persona, cada uno describiéndose a sí mismo en el mismo lenguaje.

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.