La carpeta que convierte tus notas en contexto para la IA

Cuando hablamos de inteligencia artificial solemos fijarnos en el modelo: cuál razona mejor, cuál tiene más contexto o cuál responde más rápido. En el trabajo real, sin embargo, aparece antes un problema menos vistoso: ¿dónde está el conocimiento que necesita ese modelo?

Parte está en documentos, correos y bases de datos. Otra parte vive en wikis que nadie actualiza. Y una cantidad incómodamente grande sigue en la cabeza de las personas que llevan años tomando decisiones.

Google Cloud presentó el 12 de junio de 2026 una propuesta para ordenar ese conocimiento: Open Knowledge Format, abreviado como OKF. La primera versión, OKF v0.1, definía una idea deliberadamente sencilla: una carpeta con archivos Markdown, un pequeño bloque de metadatos YAML al principio de cada archivo y unas convenciones comunes para enlazar y recorrer la información.[1]

La propuesta resulta familiar para cualquiera que use Obsidian. No por casualidad: el anuncio de Google menciona expresamente los vaults de Obsidian entre los patrones que OKF intenta hacer interoperables.[1]

Desde aquel anuncio la especificación ha avanzado a OKF v0.2. La base no ha cambiado, pero ahora también puede indicar de dónde procede una afirmación, quién creó o revisó una nota, si sigue vigente y qué grado de confianza merece.[2]

La respuesta corta: ¿OKF es Markdown?

Sí, aunque conviene expresarlo con precisión.

OKF no es un lenguaje nuevo ni una variante incompatible de Markdown. Es una especificación para organizar conocimiento mediante archivos Markdown con metadatos YAML. También define cómo se distribuyen esos archivos en carpetas, cómo se enlazan, qué nombres tienen un significado especial y qué información mínima debe aportar cada documento.[2]

La distinción se entiende mejor con una comparación:

Markdown dice cómo escribir un título, una lista, un enlace o una tabla.
YAML permite añadir datos estructurados al comienzo del documento.
OKF establece cómo combinar ambas cosas dentro de una carpeta de conocimiento que puedan leer personas, programas y agentes de IA.
Obsidian es una aplicación capaz de abrir, editar, enlazar y visualizar ese conjunto de archivos.

Markdown es el material. OKF es la convención constructiva. Obsidian puede ser una de las herramientas con las que trabajamos sobre el conjunto.

Por qué Google propone un formato y no otra plataforma

El problema que intenta resolver OKF no es la falta de aplicaciones. Tenemos gestores documentales, catálogos de datos, wikis, buscadores y bases de datos de sobra. El problema es que cada sistema guarda el conocimiento con su propia estructura y lo ofrece mediante su propia API.

Cuando un agente necesita responder una pregunta, debe reunir contexto procedente de fuentes distintas. Cada integración añade coste, dependencias y una nueva posibilidad de que la información quede atrapada en la herramienta que la creó.

OKF cambia el enfoque. En vez de imponer un servicio central, define un formato que cualquiera pueda producir y consumir. Un paquete OKF se puede guardar en Git, copiar a otro ordenador, comprimir en un ZIP o abrir con un editor de texto. No exige una cuenta, un SDK o un proveedor concreto.[1][2]

Esto tiene una consecuencia práctica: el documento que lee una persona es el mismo que recibe el agente. No hace falta mantener una versión "para humanos" y otra "para la IA".

Cómo funciona OKF

La unidad completa se llama bundle o paquete de conocimiento. En la práctica es una carpeta con subcarpetas y archivos .md.

Cada archivo representa un concepto. Un concepto puede ser una tabla de datos, una API, una métrica, un procedimiento, una norma, una decisión o cualquier otra pieza de conocimiento. Su identificador no depende de una base de datos: es la ruta del archivo dentro del paquete, sin la extensión .md.[2]

Una estructura sencilla podría ser esta:

rehabilitacion-edificio/
├── index.md
├── normativa/
│   ├── index.md
│   └── cte-db-he.md
├── decisiones/
│   ├── index.md
│   └── aislamiento-fachada.md
├── procedimientos/
│   └── control-puentes-termicos.md
└── log.md

En este ejemplo, decisiones/aislamiento-fachada sería el identificador de un concepto.

Un archivo por concepto

Cada documento de concepto contiene dos zonas:

Un bloque YAML entre dos líneas con ---.
Un cuerpo escrito en Markdown.

Por ejemplo:

---
type: Decision
title: Sistema de aislamiento de fachada
description: Criterio adoptado para mejorar la envolvente térmica del edificio.
tags: [rehabilitacion, fachada, energia]
status: stable
generated: { by: "human:responsable-proyecto", at: "2026-08-14T10:00:00Z" }
verified: { by: "human:director-ejecucion", at: "2026-08-14T12:30:00Z" }
stale_after: 2027-08-14
---

# Decisión

Se adopta un sistema SATE en la fachada principal.

# Motivo

La solución reduce los puentes térmicos y permite mantener la hoja exterior.
Consulta los [criterios de control](/procedimientos/control-puentes-termicos.md).

Aunque al principio pueda parecer técnico, la idea es bastante simple. La parte superior contiene campos que una máquina puede filtrar y ordenar. La parte inferior contiene la explicación que leería cualquier miembro del equipo.

El único campo siempre obligatorio

En OKF v0.2, el único campo obligatorio para un concepto es type. Indica qué clase de conocimiento contiene el archivo: Metric, Playbook, API Endpoint, Decision o cualquier tipo descriptivo que defina quien produce el paquete.[2]

La especificación recomienda añadir:

title: nombre legible del concepto.
description: resumen de una frase.
resource: dirección del activo al que se refiere, si existe.
tags: etiquetas para clasificarlo.

OKF permite campos adicionales. Esta flexibilidad es útil porque una empresa de construcción, un equipo de datos y un investigador no describen el conocimiento de la misma manera.

Enlaces que forman un grafo

Las carpetas crean una jerarquía, pero el conocimiento rara vez es un árbol perfecto. Una decisión puede depender de una norma, afectar a un procedimiento y aparecer en varias actas.

OKF utiliza enlaces Markdown normales para representar esas relaciones. Por ejemplo:

Consulta el [control de puentes térmicos](/procedimientos/control-puentes-termicos.md).

Los enlaces convierten la carpeta en un grafo. Un visor puede dibujarlo; un buscador puede recorrerlo; un agente puede seguir las relaciones sin cargar todos los documentos de una vez.[2]

Hay aquí una diferencia práctica con Obsidian. Muchos usuarios escriben enlaces internos con la sintaxis [[Nombre de nota]]. OKF especifica enlaces Markdown como [texto](ruta.md). Obsidian puede trabajar con enlaces Markdown, por lo que un vault pensado para interoperar con OKF debería preferir esta sintaxis estándar.

`index.md` y la lectura progresiva

Un archivo index.md puede aparecer en cualquier carpeta. Su función es enumerar el contenido disponible mediante enlaces y breves descripciones.

# Decisiones

- [Sistema de aislamiento](aislamiento-fachada.md) - Solución adoptada para la envolvente.
- [Carpinterías](carpinterias.md) - Prestaciones y criterio de selección.

Esto permite una lectura progresiva. La persona o el agente abre primero el índice, identifica qué documentos parecen relevantes y solo entonces entra en ellos. No necesita introducir todo el paquete en la ventana de contexto.[2]

`log.md` y la historia de cambios

El nombre log.md también está reservado. Sirve para registrar actualizaciones en orden cronológico:

# Historial de actualizaciones

## 2026-08-14
- **Update**: revisado el criterio de aislamiento de fachada.
- **Creation**: añadido el procedimiento de control de puentes térmicos.

Git ya puede conservar el historial línea por línea, pero log.md ofrece un resumen narrativo rápido de consultar.

Qué añadió OKF v0.2

La versión presentada en junio era la v0.1. Definía la estructura básica y campos como type, title, description, resource, tags y timestamp.[1]

OKF v0.2 mantiene esa sencillez, pero trata un problema que aparece en cuanto dejamos que los agentes creen o actualicen conocimiento: una nota puede estar bien escrita y ser falsa, antigua o imposible de verificar.

La versión actual añade cuatro familias de señales.[2]

Procedencia

sources registra los materiales de los que deriva el concepto. Una fuente puede ser una URL externa, otro archivo del paquete o una referencia interna. También puede incluir autor, fecha de modificación y datos de uso.

Para atribuir una afirmación concreta se usan notas al pie de Markdown vinculadas al identificador de la fuente. Así, la procedencia no queda escondida en una bibliografía genérica al final.

Autoría y verificación

generated indica quién creó o modificó de forma significativa el contenido y cuándo lo hizo. verified registra quién lo comprobó.

La separación importa. Que un agente redacte una nota no significa que otro proceso o una persona la haya validado. Un consumidor puede distinguir entre contenido sin revisar, confirmado por una máquina o revisado por un humano.[2]

Estado y vigencia

status puede marcar un concepto como draft, stable o deprecated. Si no se indica nada, se considera estable.

stale_after fija una fecha a partir de la cual el contenido debe tratarse como antiguo. Es un campo pequeño, pero evita uno de los fallos más comunes de cualquier base de conocimiento: respuestas correctas hace seis meses que hoy ya no lo son.

Cálculos verificables

OKF v0.2 incorpora el tipo Attested Computation. Permite describir un cálculo autorizado, sus parámetros, cómo ejecutarlo y cómo comprobar que el resultado procede del método previsto. OKF no ejecuta el cálculo; documenta el contrato necesario para que otro sistema pueda hacerlo y verificarlo.[2]

Esta parte está orientada a métricas y sistemas de datos, pero ilustra hacia dónde evoluciona el formato: el conocimiento debe ser legible y, cuando sea posible, explicar su procedencia y ofrecer señales para decidir cuánto confiar en él.

Markdown desde cero

Si nunca has usado Markdown, no necesitas aprender programación. Es texto normal al que se añaden unos pocos signos para indicar estructura.

Un archivo Markdown termina normalmente en .md. Puedes abrirlo con el Bloc de notas, TextEdit, VS Code, Obsidian o cualquier editor de texto. Obsidian guarda sus notas precisamente como archivos de texto plano con formato Markdown dentro de una carpeta que llama vault.[3]

Títulos

Se escriben con almohadillas. Una almohadilla crea el título principal; dos, una sección; tres, una subsección.

# Título del documento

## Una sección

### Una subsección

Negrita y cursiva

**texto en negrita**
*texto en cursiva*

El resultado se verá como texto en negrita y texto en cursiva.

Listas

Una lista sin ordenar usa guiones:

- Primer elemento
- Segundo elemento
- Tercer elemento

Una lista numerada usa números:

1. Revisar la documentación.
2. Tomar una decisión.
3. Registrar el motivo.

Enlaces

El texto visible va entre corchetes y la dirección entre paréntesis:

[Documentación de Obsidian](https://help.obsidian.md/)

También puedes enlazar otro archivo de la misma carpeta:

[Ver la decisión](decisiones/aislamiento-fachada.md)

Código

Para una palabra o una instrucción breve se usan comillas invertidas:

El campo obligatorio es `type`.

Para un bloque completo se usan tres comillas invertidas al principio y al final:

```yaml
type: Decision
title: Sistema de aislamiento
```

Citas

El signo > crea una cita o un bloque destacado:

> El mismo archivo puede ser leído por una persona y por un agente.

Tablas

Markdown también permite escribir tablas sencillas:

| Campo | Función |
|---|---|
| type | Tipo de concepto |
| title | Título legible |
| tags | Etiquetas |

No hace falta memorizar toda la sintaxis. Con títulos, listas, enlaces, negrita y bloques de código se puede escribir la mayoría de las notas de trabajo.

YAML no es Markdown, aunque convivan en el mismo archivo

El bloque situado entre --- se llama frontmatter. Su contenido suele escribirse en YAML, otro formato de texto pensado para representar datos estructurados.

---
type: Decision
title: Sistema de aislamiento
tags:
  - rehabilitacion
  - energia
---

En este ejemplo, type y title tienen un valor, mientras que tags contiene una lista. Hay que respetar la sangría porque YAML la utiliza para expresar la estructura.

El frontmatter no forma parte del Markdown estándar. Es una convención ampliamente aceptada por herramientas como Obsidian, Hugo o Jekyll. OKF la adopta porque permite combinar datos fáciles de consultar con un cuerpo de texto cómodo de leer.

Qué relación tiene todo esto con Obsidian

Un vault de Obsidian ya tiene buena parte de la forma que propone OKF: es una carpeta local, contiene notas Markdown, admite propiedades en YAML y conecta documentos mediante enlaces. Además, al ser texto plano, las notas pueden editarse con otras aplicaciones y sincronizarse por distintos medios.[3]

Pero un vault no se convierte automáticamente en un paquete OKF. Para acercarlo a la especificación habría que:

Tratar cada nota como un concepto bien delimitado.
Añadir al menos el campo type en el frontmatter de cada concepto.
Preferir enlaces Markdown estándar frente a enlaces exclusivos de una aplicación.
Reservar index.md para describir el contenido de las carpetas.
Usar log.md cuando interese conservar un historial narrativo.
Añadir procedencia, verificación y vigencia cuando el conocimiento vaya a alimentar decisiones o respuestas de IA.

No todos los vaults necesitan ese grado de disciplina. Para unas notas personales puede ser excesivo. Empieza a tener sentido cuando el conocimiento debe sobrevivir al cambio de herramienta, compartirse entre equipos o utilizarse como contexto para varios agentes.

De RAG a una wiki que se mantiene

OKF reconoce la influencia del patrón LLM Wiki descrito por Andrej Karpathy. En lugar de recuperar fragmentos de documentos desde cero en cada consulta, un agente mantiene una wiki persistente: integra nuevas fuentes, actualiza resúmenes, crea referencias cruzadas y registra contradicciones.[1][4]

Karpathy propone tres capas: fuentes originales que no se modifican, una wiki de archivos Markdown mantenida por el agente y un documento de reglas que explica cómo debe trabajar. En su flujo, Obsidian funciona como entorno de lectura y navegación mientras el agente se ocupa del mantenimiento repetitivo.[4]

La idea ataca una debilidad muy humana. Crear una wiki es fácil; mantenerla durante años no lo es. Los agentes pueden ayudar con índices, enlaces, resúmenes y revisiones. Aun así, conviene separar las fuentes originales de la síntesis generada. Una carpeta ordenada no garantiza que su contenido sea cierto.

Las señales de procedencia, revisión y caducidad añadidas en OKF v0.2 apuntan precisamente a ese problema.

Lo que OKF no resuelve

OKF no es una base de datos, un buscador ni un sistema RAG. Tampoco decide qué modelo debe leer los documentos o cómo se controlan los permisos.

No sustituye a esquemas especializados como OpenAPI, Protobuf o los formatos propios de una base de datos. Puede enlazarlos y aportar contexto, pero no pretende reemplazarlos.[2]

Tampoco elimina el trabajo de gobernanza. Alguien debe decidir qué fuentes son fiables, quién puede modificar cada concepto, cuándo revisar una nota y qué hacer con información sensible. Guardar conocimiento en texto plano mejora la portabilidad; no resuelve por sí solo la seguridad.

Markdown también tiene límites. Es excelente para documentación, decisiones, procedimientos y conocimiento narrativo. Para millones de registros, consultas transaccionales o relaciones muy complejas seguiremos necesitando bases de datos y herramientas específicas.

Una base sencilla para que personas y agentes trabajen juntos

Lo interesante de OKF no es que Google haya inventado otra extensión de archivo. No lo ha hecho. Su aportación consiste en poner reglas comunes alrededor de tecnologías antiguas y conocidas: carpetas, texto plano, Markdown, YAML y enlaces.

Ese planteamiento encaja bien con Obsidian. El conocimiento permanece visible y editable, incluso si mañana dejamos de usar la aplicación. También permite que un agente lea y actualice los mismos documentos que revisa una persona, con Git como historial y con campos que indiquen procedencia, revisión y vigencia.

No hace falta convertir hoy toda una bóveda personal a OKF. Sí merece la pena adoptar algunas de sus preguntas:

¿Cada nota explica una sola cosa?
¿Puedo saber de dónde salió la información?
¿Está revisada o solo generada?
¿Sigue vigente?
¿Sus enlaces funcionan fuera de una aplicación concreta?

Si las respuestas están dentro de los propios archivos, el conocimiento será más útil para una persona y bastante más seguro para una IA.