Google escribió la especificación de lo que yo hacía mal

El 12 de junio de 2026 Google Cloud publicó una especificación llamada Open Knowledge Format. La leí un martes por la noche, y tardé unos veinte minutos en darme cuenta de que llevo meses construyendo exactamente eso, mal.

Mal no en el sentido de roto, que eso habría sido fácil de ver. Mal en el sentido de que funcionaba para mí, no habría funcionado para nadie más, y yo no tenía forma de notarlo.

Qué es OKF, sin adornos

Un directorio de archivos Markdown con frontmatter YAML, enlazados entre sí con enlaces Markdown normales. Eso es todo.

Un archivo es un concepto, la ruta del archivo es su identidad, y los enlaces entre archivos forman un grafo de relaciones explícitas en vez de relaciones inferidas por similitud de vectores.

La regla obligatoria es una sola: todo archivo lleva frontmatter con un campo type no vacío. El resto es opcional, y la especificación obliga a los consumidores a tolerar campos que no conocen, tipos que no conocen y enlaces rotos.

Cabe en una página y está en GitHub.

Y conviene aclarar algo antes de seguir, porque he visto varios artículos diciendo lo contrario: OKF no reemplaza una base de datos vectorial. Es un formato de contenido, no un sistema de recuperación, y un bundle OKF se ingiere sin problema en Pinecone o en Qdrant. Lo que cambia es que las relaciones entre conceptos están escritas en vez de adivinadas.

Lo que ya coincidía

Llevo meses operando un sistema de decisión que es, literalmente, un directorio de Markdown: un archivo por concepto, enlaces entre ellos, un archivo de historia al que solo se agrega al final, y un índice que resume y enlaza en vez de duplicar.

Cuando leí la especificación, cinco de sus seis convenciones ya estaban ahí, y no por visión: porque son las que aparecen solas cuando trabajas a diario con un agente y te cansas de repetirte.

Esa fue la parte agradable de la lectura. Lo útil vino después.

Error 1: todo mi estado vive en prosa

Mis archivos marcan el estado de cada afirmación: HECHO, INFERENCIA, SUPUESTO, EVIDENCIA PENDIENTE. Sigo convencido de que es la mejor decisión de diseño que tomé y la voy a seguir defendiendo.

El problema es dónde la puse, que fue dentro del texto.

Para saber si un archivo mío es fiable hay que abrirlo y leerlo entero. OKF pone esos mismos datos en el frontmatter, donde se consultan sin leer el cuerpo, y si bien la diferencia parece cosmética, deja de serlo en cuanto tienes cuarenta archivos y un agente con ventana finita: ahí es la diferencia entre poder decidir qué cargar y tener que cargarlo todo para averiguarlo.

Yo había resuelto el problema correcto en el lugar equivocado.

Error 2: nada caduca

OKF v0.2 tiene un campo llamado stale_after, una fecha después de la cual el concepto se considera vencido.

Mi sistema exige fecha de evaluación a toda idea que se guarda sin ejecutar, y yo estaba bastante orgulloso de esa regla. El detalle es que solo la aplico a las ideas.

Mi archivo de conocimiento personal dice “última actualización” y esa fecha lleva meses igual. Mis prioridades tienen fecha de revisión, pero nada me avisa cuando llega. O sea que construí un sistema que distingue con precisión entre un hecho y una suposición, y que no distingue en absoluto entre un hecho de esta semana y uno de hace cinco meses.

Un hecho viejo se lee exactamente igual que uno reciente, y esa es la forma más silenciosa de estar equivocado.

Error 3: no distingo quién escribió qué

Este es el que me dejó incómodo, y el que sigo sin resolver.

OKF v0.2 usa una convención de actor: cuando algo lo produjo o lo confirmó una persona se anota como human:<id>, cuando lo produjo un agente se anota con el nombre y la versión del modelo, y de ahí se derivan tres niveles, sin verificar, confirmado por máquina y revisado por humano.

En mis archivos, una conclusión que escribí yo después de pensarla una semana y una que redactó un agente en cuatro segundos se ven idénticas.

Y cada vez escribo yo una proporción menor. Este año delegué buena parte de la redacción de mi propio contexto a agentes, que es justo lo que se supone que hay que hacer, y en el camino perdí la capacidad de saber qué revisé de verdad.

No es un problema teórico. Un agente puede escribir una inferencia razonable a partir de datos incompletos, guardarla, y leerla tres semanas después como antecedente propio, y sin la marca de quién la produjo el sistema no tiene forma de darse cuenta. Yo tampoco.

Lo que voy a hacer, y lo que no

No voy a migrar nada esta semana. Estoy en mitad de otro experimento, y cambiar la estructura de mi contexto mientras mido otra cosa es la manera perfecta de no aprender ninguna de las dos.

Lo que sí hice fue registrarlo con fecha de evaluación, que es exactamente la regla que acababa de reconocer que aplico a medias.

Cuando lo haga, el orden es este:

1. generated y verified, porque distinguir mi criterio del de un agente es lo que más me duele hoy.
2. stale_after en los archivos que envejecen: conocimiento personal, prioridades, cifras.
3. type en todo, que es la única regla obligatoria y la más fácil.

Deliberadamente al revés del orden de dificultad. Primero lo que arregla el fallo que ya me está costando algo.

La parte que no esperaba

Llevaba meses convencido de que mi sistema estaba bien porque a mí me funcionaba, que es el mismo argumento que usa cualquiera que nunca le ha mostrado su trabajo a nadie.

Una especificación escrita por gente que no me conoce, para un problema que yo creía particular, me mostró tres agujeros en veinte minutos. Ninguno era de implementación, los tres eran de diseño, y los tres llevaban meses ahí.

Por eso recomiendo leerla aunque no vayas a adoptarla. No te dice cómo hacer lo que ya haces, te muestra lo que dejaste de mirar.