123 lines
7.3 KiB
Markdown
123 lines
7.3 KiB
Markdown
|
---
|
||
|
|
# 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).*
|