Aplicaciones

Tres formas en que Decision Gate se integra en un producto LLM: respuestas verificadas antes de que se muestren, afirmaciones comprobadas bajo demanda y planes que llevan sus propias condiciones de finalización.

La respuesta llega ya verificada

Usuario

¿Cuánto gastamos con Acme en el segundo trimestre?

Borrador de respuesta, retenido para verificación

Gastaste $12,480 con Acme en el segundo trimestre, a través de 3 facturas.

Decision Gate Definir

El borrador contiene dos afirmaciones fácticas. Decision Gate retiene la respuesta mientras convierte el total y el recuento de facturas indicados en condiciones vinculadas a los registros de facturación.

billing.total('acme', 'Q2') == 12480 Observado 12480 PASS

billing.invoices('acme', 'Q2').count == 3 Observado 3 PASS

Decision Gate Evaluar

Ambas condiciones se resuelven como True frente a los registros admitidos, por lo que esta respuesta exacta ya se puede presentar.

Asistente

Gastaste $12,480 con Acme en el segundo trimestre, a través de 3 facturas.

Verificado 2 reclamaciones verificadas contra los registros de facturación

Decision Gate Resultado

El lector recibe una respuesta con una cadena comprobable desde cada cifra hasta la evidencia que la respalda, no solo una cita cercana.

Las pruebas: las cifras declaradas coincidían con los registros de facturación declarados en el momento de la evaluación.

No prueba: la prosa está completa, o los registros de facturación en sí son libres de errores.

El lector se opone

Asistente

Todos los datos de los clientes se almacenan en regiones de la UE.

Usuario

No te creo.

Decision Gate Definir

Decision Gate no le pide al modelo que reconsidere su redacción. Convierte «todos los datos de los clientes se almacenan en regiones de la UE» en las obligaciones que deben ser todas ciertas.

El almacenamiento de objetos vive en regiones de la UE
Las bases de datos viven en regiones de la UE
Las copias de seguridad viven en regiones de la UE

Decision Gate Evaluar

Para las copias de seguridad, la afirmación amplia se vuelve exacta: cada bóveda debe estar en una región permitida de la UE. La puerta comprueba ese predicado frente al inventario admitido de copias de seguridad.

Recuperar el inventario de respaldo
Construir la puerta vaults.all(region in ['eu-central-1', 'eu-west-1'])
Evalúe contra el inventario observado

Observado vault 'archive-7': us-east-1 FALLAR

FALLAR

Una bóveda está fuera de la UE. La afirmación es falsa tal como se indica, y ahora hay un registro de por qué.

Decision Gate Resultado

Una sola bóveda en EE. UU. basta para que la afirmación universal sea False. La respuesta se rechaza y se conserva la contraevidencia, en lugar de invitar otra respuesta sin fundamento.

Pruebas: el inventario declarado mostró una bóveda fuera de la UE en el momento de la evaluación.

No prueba: el inventario en sí es completo. Ese es un hecho de alcance de evidencia que la política tiene que nombrar.

El plan lleva sus propias condiciones de finalización

plan.md

Reproduce el error reportado
Repara eso y añade cinco pruebas
Prepare el cambio probado para la entrega

Condiciones de finalización del Decision Gate

new_test_count == 5
required_tests.all(status == 'PASSED')
tested_commit == delivery_commit

Agente

Todo listo. Se añadieron cinco pruebas, todo pasa.

Decision Gate Definir

«Hecho» se definió antes de comenzar el trabajo: cinco pruebas nuevas, todas las pruebas requeridas aprobadas y el commit probado igual al commit de entrega. Decision Gate evalúa ahora la afirmación del agente frente a esas condiciones.

new_test_count == 5 Observado 5 PASS

required_tests.all(status == 'PASSED') Observado todo APROBADO PASS

tested_commit == delivery_commit Observado desajuste de digestión FALLAR

Decision Gate Evaluar

El recuento y los estados de las pruebas pasan, pero falla la vinculación del artefacto: la evidencia pertenece a un commit diferente. Los buenos resultados de un artefacto no prueban otro.

HECHO

Las pruebas se pasaron en un commit diferente al que se está entregando. La finalización no es aceptada.

El agente vuelve a ejecutar la suite en el commit de entrega y la vuelve a enviar.

tested_commit == delivery_commit Observado coincidencias de resúmenes PASS

ACEPTADO

La finalización se registra con su evidencia. El bucle se cierra en la prueba, no en la prosa.

Decision Gate Resultado

Después de volver a ejecutar el conjunto de pruebas sobre el commit de entrega, todas las condiciones de finalización pasan y la finalización se acepta. El plan se cierra con evidencia, no con la confianza del agente.

Pruebas: las condiciones declaradas se mantuvieron para el compromiso de entrega exacto.

No prueba: las cinco pruebas son buenas pruebas. La calidad de la prueba es una afirmación diferente que necesita evidencia diferente.

En esta página La forma que comparten

En cada patrón sucede lo mismo en un momento diferente. Un actor propone algo: una respuesta, un hecho, una tarea terminada. La afirmación que importa se expresa como condiciones tipificadas. Se admite evidencia bajo una política explícita, se evalúan las condiciones y se registra el resultado con la evidencia que lo produjo.

Lo que cambia es dónde se sitúa el límite. Puede ejecutarse antes de que un lector vea la salida, por lo que la verificación es una infraestructura invisible. Puede ejecutarse bajo demanda, cuando alguien formula la pregunta que cada respuesta fluida debería poder soportar. O puede estar escrita en el trabajo mismo, de modo que “hecho” sea un conjunto de condiciones que el flujo de trabajo debe satisfacer en lugar de una frase que el flujo de trabajo puede decir.

Ninguno de estos patrones hace que el modelo sea más cuidadoso. Hacen que el producto deje de aceptar la palabra del modelo.

Sigue adelante

Cómo Funciona explica la maquinaria en la que se basan estos guiones gráficos: condiciones tipificadas, garantía de evidencia, resultados de tres valores y progreso aceptado. Documentación tiene la referencia completa.