--- # Post metadata id: "un-protocolo-tres-sujetos" title: "Un protocolo, tres sujetos" slug: "un-protocolo-tres-sujetos" subtitle: "La misma pregunta aplica a tu proyecto, tu infraestructura, y a ti mismo" excerpt: "Ontoref comenzó como un protocolo para el auto-conocimiento de proyectos de software. La misma arquitectura — DAG ontológico para lo que ES, DAG de reflexión para lo que DEVIENE — aplica sin modificación a entornos de infraestructura y a individuos. El sujeto cambia. La pregunta es idéntica: ¿qué eres, qué tensiones te definen, dónde estás versus dónde pretendes estar?" # Publication info author: "Jesús Pérez" date: "2026-05-10" published: false featured: false # Categorization category: "ontoref" tags: ["ontoref", "ontology", "infraestructura", "conocimiento-personal", "reflection"] # Display read_time: "7 min read" sort_order: 3 css_class: "category-ontoref" category_description: "Ontoref — protocolo y herramientas para el auto-conocimiento estructurado en proyectos de software" category_published: true --- # Un protocolo, tres 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 los individuos. El sujeto cambia. La pregunta es idéntica. ## Lo que los tres 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. 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é. El FSM 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. ## 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 nuevos constraints. El loop operacional es el mismo — observa, detecta deriva, ejecuta, registra. ## El mismo stack, sujeto distinto Los tres dominios corren 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 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:** | Superficie | Consumidor | |---|---| | CLI (Nushell) | Developer, scripts, CI | | UI (axum) | Revisión visual, onboarding | | MCP | Agentes AI | | GraphQL | Herramientas externas, dashboards | **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. 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. 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 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 [github.com/jesusperezlorenzo/ontoref](https://github.com/jesusperezlorenzo/ontoref).*