Entrevista de ingeniería de datos: ¿Cómo gestionarías la confianza en el conocimiento generado por agentes con OKF v0.2?

Consigna y alcance

Varios agentes generan continuamente definiciones de métricas, runbooks y esquemas de tablas. Diseña un catálogo de conocimiento en OKF v0.2 que registre fuentes, generadores, verificadores, expiración y evidencia de cómputo, manteniéndose legible para consumidores de v0.1.

Google Cloud introdujo OKF v0.2 en julio de 2026. Open Knowledge Format utiliza archivos Markdown y frontmatter YAML para el conocimiento mantenido por personas y agentes. La versión 0.2 hace que la procedencia, la confianza, el ciclo de vida y la atestación sean consultables, manteniéndose aditiva y retrocompatible. Es un formato de datos y una convención de gobernanza, no un entorno de ejecución centralizado ni un sistema de control de acceso.

Qué evalúa el entrevistador

El entrevistador busca una separación clara entre quién generó y quién verificó el contenido, atribución por afirmación mediante IDs de fuente estables, filtrado ejecutable por frescura y ciclo de vida, y la comprensión de que los niveles de confianza son señales consultivas derivadas por el consumidor y no mecanismos de autorización. También debes cubrir el fallback a v0.1, escrituras idempotentes, migración, contenido hostil y el límite de verificación de las atestaciones de cómputo.

Preguntas aclaratorias antes de responder

• ¿Qué productores escriben el bundle y quién es el dueño de la revisión humana final?
• ¿Los consumidores deben filtrar lo no verificado, lo obsoleto, lo deprecado o solo ciertos niveles de confianza seleccionados?
• ¿Debería sources admitir URLs externas, rutas relativas al bundle y descriptores de alcance?
• ¿Qué entorno de ejecución, versión de entrada y recursos de recómputo respaldan un cómputo atestado?
• ¿Los consumidores de v0.1 solo pueden leer campos antiguos o deben recibir advertencias de migración?

Estructura de respuesta en 30 segundos

“Trataría los archivos OKF como hechos de conocimiento versionados y separaría la producción, verificación, indexación y consumo. Cada concepto registra fuentes, generador y fecha, registros de verificación independientes, estado y expiración; las afirmaciones utilizan una atribución estable con sources[].id. Los consumidores filtran el frontmatter por estado, nivel de confianza y frescura antes de leer el cuerpo. Todas las adiciones de v0.2 son opcionales, los lectores conservan claves desconocidas y recurren a fallback de timestamp a generated.at y de convenciones de citas antiguas a sources. Los niveles de confianza son derivados por los consumidores, no utilizados como autorización; la evidencia de cómputo vincula entradas, código y pruebas reproducibles”.

Análisis detallado paso a paso

1. Diseñar el archivo de concepto más pequeño

Mantén un concepto mantenible por archivo con campos base como type, título, descripción, recurso y etiquetas. Coloca metadatos indexables y filtrables en el frontmatter y explicaciones, esquemas y consultas de ejemplo en el cuerpo. Un directorio en Git proporciona revisión de cambios y rollback sin requerir un registro central en tiempo de ejecución.

2. Establecer fuentes y atribución por afirmación

sources registra documentos externos, rutas relativas al bundle o descriptores de alcance de los que deriva un concepto, con señales objetivas como autor, recuento de uso y fecha de última modificación. Las afirmaciones del cuerpo usan notas al pie asociadas a IDs de fuentes estables en lugar de sources[0] posicionales; reordenar el contenido no puede atribuir erróneamente una afirmación de forma silenciosa, y los consumidores pueden calcular la credibilidad localmente.

3. Separar lo generado de lo verificado

generated indica quién produjo el contenido actual y cuándo; verified indica quién lo confirmó contra las fuentes o un recurso y cuándo. La ausencia de verified significa no verificado; una confirmación exclusiva por máquinas puede resultar en machine-confirmed; un verificador humano puede resultar en human-reviewed. Estos niveles son señales consultivas derivadas por el consumidor, no decisiones directas de autorización o cumplimiento.

4. Gestionar frescura y ciclo de vida

Usa status para estados del ciclo de vida como stable, draft o deprecated, y stale_after o una fecha equivalente para plazos de revisión. Un indexador combina la hora actual, las actualizaciones de fuentes y las políticas de negocio para computar la frescura. Que esté obsoleto no significa que sea falso: el consumidor decide si ocultarlo, degradar su ranking o volver a verificarlo, registrando el motivo.

source -> generated -> verified -> trust tier
      -> status/stale_after -> consumer filter -> body read

5. Manejar cómputos atestados

Para métricas y afirmaciones computadas, registra la definición, versión del recurso de entrada, ejecutor, tiempo de ejecución y resultado de la verificación. Una atestación demuestra que un valor fue producido mediante el método declarado; no demuestra que las entradas o la interpretación del negocio sean correctas. OKF no prescribe un ejecutor ni empaquetado, por lo que la gobernanza debe fijar el entorno, las dependencias y la evidencia de reproducción.

6. Preservar la compatibilidad con v0.1

La versión 0.2 es una versión menor aditiva y retrocompatible; un bundle v0.1 que no adopta campos nuevos sigue siendo válido. Los lectores conservan claves personalizadas y desconocidas, prefieren generated.at, recurren al antiguo timestamp y pueden leer la convención antigua de # Citations cuando sources está ausente, emitiendo una advertencia de migración. Los escritores deben proporcionar una migración versionada en lugar de reescribir la historia silenciosamente.

7. Construir un pipeline de consumo confiable

Los productores confirman archivos, los validadores verifican el frontmatter, los IDs de fuente y las marcas de tiempo, los verificadores escriben confirmaciones independientes, los indexadores materializan campos de filtrado y los consumidores filtran antes de cargar los cuerpos. Utiliza IDs de concepto y hashes de contenido para la idempotencia, junto con una cola de revisión para la generación repetida. Escapa y define listas permitidas para enlaces remotos, Markdown, notas al pie y contenido generado por agentes, con pistas de auditoría.

Ejemplo de respuesta de alta calidad

Trataría un bundle OKF como hechos de conocimiento revisables en Git. Cada archivo contiene un concepto, con metadatos filtrables en el frontmatter y explicaciones en el cuerpo. sources cuenta con IDs estables y las notas al pie del cuerpo atribuyen afirmaciones individuales. generated y verified registran por separado al productor y al confirmador; los consumidores derivan niveles unverified, machine-confirmed o human-reviewed sin tratarlos como autorización. status y stale_after impulsan el filtrado por ciclo de vida y frescura, mientras que los conceptos obsoletos pueden degradarse de rango o enviarse a revisión. Las afirmaciones computadas llevan versiones de entrada, entorno de ejecución, método y evidencia, con el límite explícito de que la atestación no prueba la corrección de las entradas. Un lector v0.2 conserva claves desconocidas, admite fallback de generated.at a timestamp y de sources a convenciones de citas antiguas, y emite advertencias de migración para compatibilidad con v0.1. Commits idempotentes, hashes, colas de revisión y renderizado seguro separan la producción, verificación, indexación y consumo.

Errores comunes

• Combinar generador y verificador → desaparece la confirmación independiente → registra generated y verified por separado.
• Usar un nivel de confianza como permiso → una señal consultiva se convierte en un control de seguridad → mantén la autorización en sistemas de identidad, políticas y recursos.
• Usar sources[0] para atribución → reordenar listas atribuye afirmaciones incorrectamente → utiliza IDs de fuente estables y claves de notas al pie.
• Tratar lo obsoleto como falso → la política del consumidor se vuelve demasiado estricta e imprecisa → permite a los consumidores ocultar, degradar el rango o volver a verificar.
• Afirmar que la atestación prueba la verdad → se ignoran las entradas y la semántica → vincula versiones de entrada, método y alcance de verificación.
• Eliminar campos antiguos silenciosamente durante la migración → rompe a los consumidores de v0.1 → utiliza fallback, advertencias y escrituras versionadas.

Preguntas de seguimiento y respuestas

¿Por qué no definir un puntaje de confianza universal en el formato?

Los puntajes dependen del dominio, del consumidor y del tiempo; almacenar uno hace que quede obsoleto y no sea portable. El formato registra señales verificables y cada consumidor deriva una política local a partir de autoría, frescura, verificación y uso.

¿Qué pasa si dos verificadores independientes confirman un concepto?

Mantén múltiples registros verified con sujeto y fecha. Un consumidor puede combinar políticas humanas, de máquinas, de dominio o de antigüedad sin sobrescribir evidencia previa.

¿Cómo evitas la extensión arbitraria de stale_after?

Restringe quién puede cambiarlo, exige aprobación de la fuente o del dueño del negocio y audita el valor anterior, el nuevo valor, el motivo y la evidencia de verificación. Renovar un plazo no equivale a una revisión de contenido.

¿Qué ocurre si un consumidor de v0.1 no comprende los nuevos campos?

Debería ignorar los campos desconocidos y continuar leyendo los campos base. Proporciona escrituras de compatibilidad, fallback para campos antiguos y advertencias de migración; no hagas obligatorias las extensiones de v0.2 en cada bundle antiguo.

¿Cómo alcanza una métrica generada por agentes un nivel de alta confianza?

Registra su fuente de generación y evidencia de cómputo, y luego verifica de forma independiente las entradas, el método y el resultado. Solo después de que la revisión humana o el proceso de negocio tenga éxito, el consumidor debe derivar un nivel de confianza superior.