Crear un Open Knowledge Format con Draft_: la guía práctica
Un bundle OKF no es más que un directorio de archivos Markdown bien ordenados: exactamente lo que Draft_ produce, sin configurar nada. Por qué escribir tu base de conocimiento en un procesador de texto Markdown y luego entregarla tal cual a un agente de IA. Tres casos donde lo cambia todo.
El Open Knowledge Format de Google (OKF) no exige ninguna herramienta propietaria. Un bundle es un directorio de archivos Markdown, un poco de frontmatter YAML, enlaces entre los conceptos, y nada más. Dicho de otro modo, el formato ya es tu editor de texto.
Ahora bien, «poder» y «con comodidad» no son sinónimos. Escribir una base de conocimiento es un trabajo de escritura: quieres un lugar tranquilo para hacerlo, no una terminal. Ahí es donde Draft_ encaja, no gracias a una función «OKF» dedicada, sino porque su formato nativo ya es el del OKF. Veamos por qué, y luego tres casos concretos donde cuenta.
¿Por qué un procesador de texto Markdown para el OKF?
El OKF separa dos roles: quien produce el conocimiento y quien lo consume. El consumidor es un agente de IA. El productor es un humano que escribe, y que merece algo mejor que un campo de entrada para hacerlo.
Este giro es la línea de Draft_: eres tú quien alimenta a la IA, no la IA la que crea en tu lugar. Aunque el OKF se dirija a las máquinas, todo lo que contiene nace de un pensamiento humano: escrito, estructurado, asumido. Y quién sostiene el teclado no es una elección neutra: delegar la escritura en un asistente tiene un coste cognitivo ya medido, desde la sobrecarga mental hasta la dependencia de la IA, mientras que la jerarquía neurocientífica mano > teclado > IA muestra que es la implicación de quien escribe la que da valor a lo que se produce. Una base de conocimiento solo vale por lo que pones en ella. Mejor escribirla tú mismo, en una herramienta construida para eso.
Y es que las piezas del OKF son, una a una, las de Draft_:
| Convención OKF | Draft_, tal como está |
|---|---|
| Directorio de archivos Markdown | Formato de almacenamiento nativo |
| Frontmatter YAML | Zona de metadatos en la cabecera del documento |
| Enlaces cruzados entre conceptos | Enlaces internos relativos ([texto](../carpeta/doc.md)) |
| Árbol de conceptos | Espacios y carpetas |
| Bundle versionado | Sincronización con GitHub integrada |
| Legible por un humano | Editor Markdown sin distracciones |
Nada que instalar, nada que conectar. La correspondencia no es casualidad: el OKF simplemente formalizó lo que los buenos editores Markdown hacen desde hace tiempo.
El flujo de trabajo concreto
Creas un espacio: es la raíz de tu bundle. Dentro organizas carpetas (personajes/, tablas/, lugares/…) que se convierten en las familias de conceptos. Cada documento se abre con una zona de metadatos donde escribes el frontmatter en claro (type: Personaje, title, tags), sin siquiera los delimitadores ---, que Draft_ añade al exportar. El nombre del documento se convierte en el nombre del archivo (orders → orders.md), así que controlas la ruta de cada concepto; tus enlaces internos se convierten en las aristas del grafo que el agente seguirá; y la sincronización con GitHub transforma el conjunto en un repositorio versionado. Un bundle OKF válido, salido de un editor donde sobre todo has escrito.
Tres casos concretos
Caso 1: la biblia de un universo de ficción
Escribes una novela, una serie, un juego. Mantienes un espacio biblia/:
personajes/
└── elena.md (type: Personaje)
lugares/
└── valdris.md (type: Lugar)
facciones/
└── pacto-de-hierro.md (type: Facción)La ficha de Elena cita a Valdris y al Pacto de Hierro mediante simples enlaces. Más tarde, entregas el repositorio a un LLM: «Aquí está mi biblia. Escribe una escena donde Elena regresa a Valdris, fiel a su historia y a la atmósfera del lugar.» El agente recupera las fichas pertinentes siguiendo los enlaces y escribe dentro de tu universo, sin que tengas que reexplicarlo en cada sesión. Tu coherencia se convierte en un activo, no en una carga mental.
Caso 2: una documentación técnica viva
Documentas una API o un producto, por tipo: endpoints/, conceptos/, runbooks/, cada uno con su type. El repositorio vive junto al código, en el mismo GitHub, versionado por los mismos commits. La documentación deja de ser un wiki paralelo que se enrancia: es legible por un agente de CI, por el asistente que responde a las preguntas del equipo, o por la desarrolladora que llega el lunes. Una sola fuente, y todos, humanos y máquinas por igual, beben de ella.
Caso 3: notas de investigación consultables
Acumulas notas sobre un tema: competidores, lecturas, ideas. Cada nota es un concepto, enlazado a los demás. El bundle sincronizado se convierte en una memoria externa que consultas: «¿Qué tensiones recorren estos dos enfoques en mis notas?» El LLM recorre el grafo de tu pensamiento para responder: no Wikipedia, tu propio razonamiento, estructurado y citado.
El alcance, en una línea
Draft_ cubre el eslabón humano de la cadena OKF: escribir, nombrar, enlazar, versionar. El consumo se hace después con cualquier LLM, y ese es todo el interés de un formato portátil. Escribes el frontmatter y mantienes el control de la coherencia, exactamente el nivel de control que se espera de un trabajo de escritura cuidado.
En resumen
- Un bundle OKF es un directorio de Markdown + frontmatter YAML; Draft_ lo produce de forma nativa.
- Espacio = raíz, carpetas = conceptos, zona de metadatos = frontmatter, nombre del documento = nombre del archivo, enlaces internos = grafo, sincronización con GitHub = bundle versionado.
- Escribes en un procesador de texto de verdad y luego entregas el conocimiento tal cual a un agente.
- Tres terrenos de juego: biblia de ficción, documentación técnica viva, notas de investigación consultables.
Para empezar a construir tu base de conocimiento OKF, ya tienes todo lo que necesitas en Draft_: escribes, nombras, sincronizas. El resto es Markdown, y ya está en tus manos.