El formato Open Knowledge v0.2 aborda la confianza activa

Cuando presentamos el Formato de Conocimiento Abierto (OKF) en junio de 2026, afirmamos que el contexto que necesitan los agentes (esquemas de tablas, definiciones de métricas, manuales de operación) debería residir en un formato, no en un servicio propietario, y no disperso en bloques de texto no estructurado. Por lo tanto, OKF v0.1 comenzó de manera simple: solo markdown, frontmatter YAML y un puñado de convenciones. La fuerte respuesta y las contribuciones de la comunidad de desarrolladores informaron nuestro enfoque para la siguiente versión. Desde su lanzamiento, los contribuyentes abrieron propuestas de extensión (bordes de relación tipados, campos de sugerencias de enrutamiento de agentes, un perfil de conformidad opcional de borrado, una convención .okfignore y más), enviaron nuevos paquetes de muestra y comenzaron a catalogar herramientas del ecosistema OKF construidas fuera de Google. Muchas de estas contribuciones y comentarios de los contribuyentes reflejaron una preocupación mayor sobre OKF: una vez que los agentes están escribiendo en el corpus, ¿realmente se puede confiar en él? Los paquetes de OKF más valiosos no se escribirán a mano una vez y luego se leerán para siempre. Se escriben continuamente, por agentes, y son consumidos por un conjunto diferente de agentes. Una página de wiki redactada por un humano viene con una garantía implícita: una persona la escribió, y puedes hacerla responsable si está equivocada. Cuando un agente genera diez mil conceptos de la noche a la mañana, esa garantía desaparece. Para proporcionar responsabilidad, un consumidor (a menudo otro agente) tiene que juzgar cada concepto basado en señales explícitas, y necesita responder cinco preguntas: ¿De qué se creó esto? (procedencia) ¿Cuánto debo confiar en él? (confianza) ¿Sigue siendo cierto? (frescura) ¿Es la versión actual? (ciclo de vida) ¿Se produjo este número de la manera que dijimos que debía ser? (atestación) En OKF v0.2, ahora es posible responder todas esas cinco preguntas desde el frontmatter, mientras que el formato sigue siendo tan mínimamente opinioso como v0.1. Añade vocabulario, no reglas: el tipo sigue siendo el único campo siempre requerido, cada nuevo campo es opcional, las claves personalizadas se siguen preservando en lugar de ser rechazadas, y un paquete que no adopta ninguna de las adiciones es exactamente tan válido como lo fue bajo v0.1. Todo lo nuevo a continuación es opcional, pero su ausencia ahora tiene significado: un concepto no verificado es distinguible de uno verificado (aunque nunca se rechaza por la diferencia). Desde describir hasta decidir, v0.1 ya mantenía metadatos en el frontmatter: tipo, título, descripción, recurso, etiquetas. Esos campos describen un concepto: qué es y a qué apunta. v0.2 añade un segundo tipo de campo de frontmatter, el tipo que usas para decidir algo sobre un concepto antes de leerlo: quién lo produjo, si ha sido verificado, si sigue siendo actual y cómo se debe calcular un valor que reporta. La razón por la que estos campos pertenecen al frontmatter es que la mayoría de las interacciones con un concepto nunca avanzan realmente hasta acceder a la información en el cuerpo del archivo. Un consumidor, ya sea una persona, un código determinista o un agente escaneando durante la búsqueda y el descubrimiento, primero tiene que decidir si un concepto es relevante en absoluto. Todo en un concepto debería ser conciso, pero el frontmatter tiene la tarea más estrecha de elevar exactamente las señales necesarias para tomar decisiones sobre relevancia y confiabilidad, para que pueda hacerse de manera económica y frecuente, sin gastar tokens en prosa. El contenido que debe ser leído en su totalidad permanece en el cuerpo, accesible solo una vez que se elige un concepto. La confianza se convierte en algo sobre lo que puedes filtrar antes de comprometerte a leer. Para hacer que las secciones que siguen sean concretas, cada ejemplo a continuación se basa en un pequeño paquete de OKF v0.2 que hemos preparado como un complemento a este post: acme_retail, el conocimiento compartido de una empresa minorista ficticia de EE. UU. para análisis asistidos por IA sobre BigQuery: Cada sección que sigue muestra el archivo correspondiente. Aquí está tables/orders.md, un concepto que lleva las nuevas señales: Cada una de esas familias responde a una de las cinco preguntas. Procedencia: fuentes, no una puntuación El nuevo campo de fuentes registra los materiales de los que deriva un concepto: un documento externo, una ruta relativa al paquete o incluso un descriptor de alcance como todas las consultas en el proyecto X. Al mismo tiempo, una entrada puede llevar señales de credibilidad objetivas: autor, cuenta_de_uso, última_modificación. La elección deliberada aquí es lo que no añadimos. OKF registra las señales, no una puntuación de credibilidad. Una puntuación es subjetiva, no se transporta entre los consumidores y se vuelve obsoleta en el momento en que se escribe. En su lugar, la credibilidad se infiere de las señales por quien consume (y puede ser puntuado dinámicamente por el consumidor, si se desea), de la misma manera que confiarías en una fuente muy utilizada, recientemente actualizada y con autoría acreditada más que en una anónima. Y cuando el cuerpo cita una fuente específica, lo hace con una nota a pie de página en markdown común vinculada al id de la fuente, así que la atribución es por reclamación en lugar de una lista colgante en la parte inferior. Confianza: generada, verificada La confianza se establece utilizando dos campos, mantenidos deliberadamente distintos, porque quien escribió algo no necesariamente es quien lo confirmó: generado: { por, en }: cómo se produjo el contenido actual y cuándo cambió por última vez de manera significativa. verificado: [ { por, en } ]: una lista de confirmaciones independientes contra las fuentes o el recurso subyacente; una aprobación humana, un proceso financiero nocturno o ambos. A partir de verificado, un consumidor deriva un nivel de confianza: ninguna clave verificada es no verificada; la confirmación solo por actores de máquina es confirmada por máquina; confirmación por un humano: el actor es revisado por un humano. Los niveles son señales asesoras, no de control de acceso, pero permiten a un consumidor mostrar solo métricas revisadas por humanos en el tablero ejecutivo como un filtro de frontmatter. En acme_retail: metrics/revenue.md es redactado por el agente de referencia y verificado por el VP de Finanzas, lo que lo coloca en el nivel revisado por humanos. Un consumidor del tablero ejecutivo configurado con un filtro de nivel de confianza lo muestra; un entorno de prueba desechable puede aceptar conceptos de niveles inferiores: Frescura y ciclo de vida: stale_after, estado OKF v0.2 establece frescura y ciclo de vida con los campos stale_after y estado. El estado mueve un concepto a través de borrador → estable → obsoleto (ausente significa estable). stale_after es una única fecha absoluta. Elegimos una fecha absoluta sobre un TTL relativo a propósito: la obsolescencia se convierte en una comparación de fechas simple sin referencia a cuándo se leyó el concepto, que es exactamente el tipo de determinismo que un consumidor que no es LLM quiere. En acme_retail: metrics/revenue.md y metrics/gross-margin.md llevan ambos stale_after: 2026-12-31 porque el equipo financiero de Acme vuelve a aprobar las políticas subyacentes cada enero. El 2027-01-01 ambos conceptos requieren volver a verificar contra la política FY2027 antes de servir. Y metrics/gross-margin-legacy.md tiene estado: obsoleto. Acme cambió su estándar de asignación de costos en febrero de 2026 (la fórmula antigua excluía el envío y el cumplimiento de su costo de bienes vendidos). La definición legada se conserva para la reproducibilidad histórica de consultas pero no se muestra para nuevos trabajos: Atestación: ¿Se computó este número de la manera sancionada? La procedencia responde de dónde proviene una reclamación. La atestación responde a una pregunta más difícil que importa en el momento en que un agente informa una cifra en dólares: ¿se produjo este número de la manera que dijimos que debía ser, o el agente improvisó su propia SQL? OKF v0.2 introduce un nuevo tipo de concepto, Cálculo Atestado. Este no solo lleva el significado de un valor, sino una manera sancionada de calcularlo y la forma de verificar que el asunto sancionado realmente se ejecutó. Aquí está acme_retail/computations/revenue-ytd.md: El agente solo puede llenar los parámetros declarados; nunca debe autorizar o editar el cálculo. Un consumidor ejecuta el cálculo a través del ejecutor, que devuelve un recibo (aquí: un job_id de BigQuery, la SQL que fue realmente ejecutada y el resultado). Luego, un atestador determinista, no LLM, inspecciona ese recibo y devuelve un veredicto: ¿la consulta que se ejecutó es igual al cálculo sancionado limitado por los parámetros reclamados, y coincide el valor mostrado con la fuente autoritativa del recibo? Debido a que la comparación es mecánica, una consulta reescrita, un archivo de cálculo intercambiado o una dependencia mutada fallan la verificación. En acme_retail: el atestador en attesters/sql_equality.py canoniza ambas SQL (elimina comentarios, colapsa espacios en blanco, convierte a mayúsculas palabras clave conocidas) y se niega a devolver ok si las formas canónicas difieren. Un nombre de tabla intercambiado, un filtro añadido, un JOIN eliminado, todos fallan la atestación. El consumidor se niega a mostrar el valor cuando el veredicto vuelve falso. Si bien utilizamos BigQuery (y SQL) en este ejemplo, la abstracción es deliberadamente flexible. Los cálculos atestados pueden corresponder a invocaciones de modelos semánticos (en Looker, AtScale u otros sistemas), consultas de grafos de conocimiento estructurado o incluso realizar llamadas a API arbitrarias. Crucialmente, OKF registra el cálculo y cómo verificarlo; nunca ejecuta nada por sí mismo. Y la atestación se distingue de la verificación: verificado confirma que la definición aún coincide con la política (lento, a nivel de documento, almacenado en el paquete); la atestación confirma que una única ejecución produjo correctamente el valor (por llamada, en tiempo de ejecución, nunca almacenada en el paquete). Una definición obsoleta aún puede atestarse de manera clara; una definición recién verificada aún necesita atestación en cada ejecución. Esa es la razón por la que ambas existen. Lo que estamos lanzando con v0.2 Al igual que con v0.1, las implementaciones de referencia son deliberadamente pruebas de concepto; nada de OKF las requiere. Aquí está lo que está cambiando en el repositorio de Github: reference_agent ahora emite las familias de procedencia y confianza a medida que genera, por lo que un paquete recién acuñado llega con fuentes generadas y citas ya en su lugar. El visualizador estático muestra el nivel de confianza, estado y obsolescencia junto con el gráfico del concepto, de modo que estas señales son visibles, no solo parseables. Los paquetes de muestra actualizados (GA4 comercio electrónico, Stack Overflow, Bitcoin y el ejemplo de acme retail utilizado en este blog) llevan los campos de v0.2. Una demostración del Catálogo del Conocimiento muestra un paquete que circula a través del Catálogo de Conocimiento de Google Cloud (anteriormente Dataplex): OKF limpio en disco, señales de confianza y procedencia preservadas a través del catálogo y de regreso. Compatibilidad v0.2 es un aumento menor de versión que es aditivo, compatible hacia atrás, con dos cambios de nombre deliberados: timestamp es reemplazado por generated.at, y la lista # Citations del cuerpo es reemplazada por sources; en ambos casos, un consumidor de v0.2 puede revertir a la forma de v0.1. Un paquete de v0.1 se introduce sin cambios. Adónde vamos desde aquí Lee la especificación (todavía es corta). Escribe un productor que emita señales de confianza para tu sistema fuente. Escribe un consumidor que filtre en ellas. Prueba un Cálculo Atestado contra tus propias definiciones financieras. Reporta problemas, envía PRs, propone extensiones. Una lengua franca solo es tan buena como el número de partes que la hablan, y ahora también pueden verificar el trabajo de los demás. Especificación de OKF v0.2, muestras e implementaciones de referencia: github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/okf