Documentación

Buscar en Arxiu

Escriba para buscar en Arxiu.

Cómo Funciona

Decision Gate es un mecanismo formalmente especificado que convierte las afirmaciones de agentes seleccionados y las transiciones de flujo de trabajo en reclamaciones aceptadas respaldadas por evidencia. Esta página explica cómo: en qué debe convertirse una reclamación antes de que pueda ser verificada, qué evidencia debe establecerse antes de que pueda ser utilizada, y qué significa "aceptado" con suficiente precisión para construir sobre ello. No afirma resolver la alucinación. Afirmar algo más estrecho y útil: que las reclamaciones que un flujo de trabajo elige considerar pueden hacerse para producir prueba antes de que produzcan consecuencias.

Modo de lectura

En esta página Sección actual: La tesis

La tesis

Los programas son deterministas pero rígidos. Los humanos son flexibles pero poco fiables. Los agentes heredan la flexibilidad sin heredar las garantías formales, y los sistemas modernos cada vez les permiten actuar de todos modos.

El fallo es estructural. Un flujo de trabajo agente mezcla dos modos que no pertenecen al mismo actor: el razonamiento generativo, que propone planes, explicaciones, código y afirmaciones de manera probabilística; y el compromiso operativo, donde el sistema circundante debe decidir si el trabajo está completo, si una transición es válida, si se puede intentar un efecto. Sin un límite externo, el mismo actor estocástico que realizó el trabajo también declara que el trabajo tuvo éxito.

Decision Gate establece un límite determinista entre la propuesta y la aceptación. Un flujo de trabajo declara lo que debe establecerse. Se presenta o adquiere evidencia, admitida bajo una política explícita, y se evalúa en función de condiciones tipificadas. Una reclamación o transición avanza solo cuando se satisface la relación de prueba declarada. Si la obligación es falsa, no resuelta, mal formada, no disponible o obsoleta, la reclamación no se convierte en un progreso aceptado.

El actor puede permanecer estocástico. La aceptación no tiene que serlo.

La alucinación es solo parte del problema

“Alucinación” generalmente se refiere a una salida de modelo que es falsa o fabricada. En sistemas agentivos, el fallo comercialmente importante es más amplio: el agente afirma que una condición se cumple, y el sistema anfitrión procede como si la afirmación fuera un hecho operativo. “Todas las pruebas pasan.” “El caso citado existe.” “La migración se completó.” “El cliente es elegible.”

Estos fallos no son una sola cosa, y colapsarlos destruye la información necesaria para recuperarse correctamente. Una reclamación puede ser semánticamente falsa: el informe de prueba muestra una prueba fallida. Puede estar sin resolver: nadie presentó nunca el informe. La evidencia puede estar presente pero ser insuficiente: el informe provino del actor que se está verificando cuando la política exige una fuente independiente. La ausencia puede observarse positivamente: una consulta de registro completa prueba que no existe ningún registro. Y una verificación puede fallar operativamente: el archivo no se pudo analizar, la fuente se agotó. Cada uno de estos merece una respuesta diferente, y solo algunos de ellos son culpa del modelo.

Decision Gate comienza al rechazar el atajo que causa el daño: tratar la declaración fluida del actor como la autoridad de aceptación.

Lo que significa saber algo

Antes de cualquier maquinaria, una pregunta: ¿qué se necesitaría para saber que “las pruebas pasan” es cierto?

No hay certeza en el sentido filosófico. La verificación siempre es relativa a un procedimiento: algún proceso nombrado, utilizando evidencia nombrada de fuentes nombradas, bajo supuestos establecidos, estableció una proposición declarada en un momento determinado. Esa oración tiene partes que soportan carga. Cambia la fuente y tendrás un hecho diferente. Cambia el alcance, qué compromiso, qué cuenta, qué registro, y tendrás un hecho diferente. Cambia cuándo, y es posible que ya no tengas un hecho en absoluto.

La mayoría de los sistemas aplanan esto en un booleano y pierden todo lo que hacía que el booleano fuera significativo. Decision Gate mantiene la estructura. Su afirmación está deliberadamente limitada: puede determinar si un procedimiento nombrado, utilizando evidencia nombrada bajo una política nombrada, estableció una proposición nombrada. La credibilidad del resultado depende de la ley, la evidencia y las autoridades que la produjeron, y el sistema es honesto acerca de esa dependencia en lugar de ocultarla detrás de un puntaje de confianza.

Esa reclamación limitada resulta ser exactamente lo que un flujo de trabajo agente necesita, porque un flujo de trabajo no necesita verdad metafísica. Necesita saber si puede proceder.

Condiciones tipadas

Una instrucción ambigua no puede ser verificada, por lo que la primera transformación es de prosa a obligaciones de prueba tipificadas. “Agrega cinco pruebas y asegúrate de que pasen” se convierte en un conjunto cerrado de proposiciones:

P1: new_test_count == 5
P2: required_test_result_count == 5
P3: all(required_test_status == PASSED)
P4: tested_commit_digest == proposed_delivery_commit_digest

Completion law: P1 AND P2 AND P3 AND P4

El movimiento importante no es que el lenguaje se convirtiera en verdad. Es que una oración ambigua se convirtió en un conjunto cerrado y verificable de obligaciones que o se cumplen o no.

Cada condición declara un dominio de observación y un predicado tipado sobre él, y los dominios están cerrados a propósito: enteros, decimales exactos, booleanos, cadenas acotadas, fechas, instantes, registros cerrados. Comparaciones aparentemente triviales ocultan una semántica real. ¿Es 1 igual a 1.0? ¿Significa “contains” subcadena o pertenencia a un conjunto? ¿Es un campo ausente diferente de uno nulo? ¿Es una fecha un instante UTC o un día local? Decision Gate requiere que la ley responda a estas preguntas antes de la evaluación. Los operandos inválidos o incompatibles son rechazados cuando se construye la condición; no se desvían hacia el tiempo de ejecución y no resurgen como un falso conveniente.

Significado, separado de la recuperación

Una condición define lo que significa una proposición: su dominio, su predicado y qué evidencia es suficiente para ella. Deliberadamente no define qué API llamar, qué archivo leer o en qué proveedor confiar. Esa es una vinculación separada y explícita: un camino de adquisición que describe cómo se puede producir una observación para una condición.

La separación importa más de lo que parece a primera vista. “El commit probado coincide con el commit de entrega” es una condición con un significado. Los resúmenes pueden llegar de un recibo de CI presentado por el arnés que llama, de un manifiesto de construcción firmado en un documento local, o de una futura integración registrada que los recupera directamente. La condición no cambia cuando la infraestructura cambia. La ley semántica se mantiene estable mientras que la adquisición varía según el despliegue, el límite de privacidad, el entorno del cliente.

Los sistemas que fusionan los dos — donde una condición simplemente es una consulta de proveedor — no pueden hacer esta distinción, y eso les cuesta: cada cambio de fuente de datos se convierte silenciosamente en un cambio de significado.

La evidencia es un producto, no una puntuación

El atajo común es clasificar la evidencia en una única escalera de confianza. Decision Gate rechaza el escalar. La evidencia lleva un conjunto de hechos independientes: cómo ingresó al sistema, qué forma toma su contenido, quién o qué lo produjo, de qué se derivó, qué alcance exacto concierne, cuándo fue observado, qué protecciones de integridad lo cubren y cuán independiente es su fuente del actor que se está verificando.

Estos ejes no se reducen a un solo número. Un valor puede tener una fuerte integridad y una mala frescura. Una fuente puede ser autoritaria pero estar fuera de alcance. Una observación local puede ser fresca y exacta, pero controlada por el mismo agente cuya afirmación apoya. Una firma puede probar quién firmó los bytes sin probar que la afirmación es verdadera. La política de uso de evidencia para cada condición nombra la combinación que es suficiente para esa afirmación en ese contexto: un escenario de desarrollo puede aceptar el propio informe de prueba del agente de codificación, mientras que un escenario de lanzamiento exige un recibo independiente vinculado al commit exacto. El mismo boolean no lleva la misma prueba.

La admisión tampoco es suficiencia. El material primero pasa un límite de admisión — delimitado, validado, hostil por defecto. La evidencia admitida se evalúa luego en función de la política de la condición, y cada condición requerida por una evaluación se resuelve de exactamente una manera:

ResoluciónSignificado
PresenteUn valor tipado que satisface la política está disponible.
ObservadoAusenteUna observación admitida completa prueba la ausencia en un universo declarado.
FaltaLa evaluación no tiene candidato para este objetivo en absoluto.
InsuficienteExisten candidatos, pero ninguno satisface la política de uso.

Las distinciones previenen errores específicos y familiares. Un tiempo de espera de la API de registros judiciales no es evidencia de que el caso no exista. Una búsqueda cuya paginación nunca se completó no puede probar la ausencia. “No encontrado” y “nadie miró” son estados diferentes, y un sistema que los confunde eventualmente hará reclamaciones excesivas.

Verdadero, Falso, Desconocido

Un predicado tipado sobre una resolución de evidencia válida produce uno de tres resultados semánticos. Verdadero: la evidencia admitida satisface el predicado. Falso: contradice el predicado. Desconocido: la evidencia admisible no determina el predicado bajo la política declarada.

Los sistemas binarios imponen uno de dos errores. Tratar el trabajo no resuelto como falso, y se pierde la distinción entre “contradicho” y “no probado aún” — el flujo de trabajo castiga la falta de datos como si fuera un fracaso. Tratar el trabajo no resuelto como verdadero o “mejor esfuerzo”, y el progreso no respaldado atraviesa el límite. La semántica de tres valores permite que el flujo de trabajo se mantenga de manera segura sin pretender en ninguna dirección. El agente puede adquirir más evidencia, reparar el trabajo o escalar, sabiendo exactamente qué obligación está sin resolver.

Unknown tiene un significado preciso, y no es un cubo de basura. Es un resultado semántico derivado de evidencia válidamente admitida. Un fallo de análisis no es Unknown. Un tiempo de espera no es Unknown. Un testigo falsificado, una denegación de autorización, una carga útil malformada — estos son fallos operativos e de integridad, mantenidos en sus propias familias tipadas, porque requieren un manejo diferente: reintento, alarma, auditoría, rechazo. Un sistema que blanquea sus fallos en Unknown ha destruido silenciosamente su propia taxonomía de fallos.

Álgebra de requisitos

Las condiciones únicas rara vez deciden algo interesante. Los requisitos las componen:

ALL(tests_passed, coverage_met, NOT critical_vulnerability_present)

ANY(primary_registry_match, two_independent_attestations)

QUORUM(2 of: ci_passed, security_scan_passed, reviewer_approved)

La evaluación de requisitos es composicional y determinista, y preserva resultados no resueltos: un requisito sobre entradas Verdadero, Falso y Desconocido permanece Desconocido cuando las entradas aún no pueden decidirlo, en lugar de predeterminarse en ninguna dirección.

Una distinción estructural realiza un trabajo real aquí. La finalización de la etapa — ¿se ha completado esta unidad de trabajo? — puede utilizar lógica rica sobre los resultados de las condiciones, incluida la negación legal, porque la verdad de la evidencia no es monótona: se puede descubrir una vulnerabilidad. La topología del flujo de trabajo — ¿qué etapas pueden abrirse a continuación? — está restringida a requisitos monótonos sobre el progreso completado, porque el progreso no debe parpadear: una vez que una etapa está lista porque se completaron sus prerrequisitos, un progreso adicional no relacionado no puede hacer que esté no lista. Lógica rica dentro de una etapa; movimiento solo hacia adelante a través del flujo de trabajo.

El progreso es un gráfico

Los flujos de trabajo reales no son listas. Las tareas se bifurcan y se reúnen; una versión requiere dos de tres revisiones; los componentes no relacionados avanzan en paralelo. Decision Gate modela la topología de un escenario como un gráfico de dependencia finito — cadenas, bifurcaciones, diamantes, múltiples raíces, componentes desconectados — con la preparación de una etapa derivada del progreso completado aceptado bajo su ley de prerrequisitos monótona.

Cada etapa está en exactamente uno de cuatro estados: no lista, sus requisitos previos aún no se cumplen; lista pero no abierta; abierta e incompleta; o completada, lo que significa que su ley de finalización evaluó como Verdadero en una mutación aceptada. Abrir una etapa no asigna ningún agente, no reserva nada y no cancela nada: la programación del trabajo permanece fuera, donde pertenece. Y un escenario finaliza solo por su propia ley de finalización explícitamente declarada sobre etapas completadas, nunca por un accidente estructural como “se alcanzó el último nodo en el diagrama”.

El gráfico es lo que impide que una narrativa fluida de progreso se convierta en un cursor de flujo de trabajo implícito. El sistema siempre puede responder, a partir de hechos aceptados en lugar de la transcripción: ¿qué etapas son demostrablemente elegibles en este momento?

Evalúa primero, acepta después

La evaluación es pura. El evaluador consume leyes validadas, avances aceptados y una instantánea de evidencia admitida, y no realiza ninguna entrada/salida: no lee archivos, no tiene reloj, no se conecta a la red, no utiliza almacenamiento. A partir de esas entradas, deriva un candidato: quizás un delta de finalización y una nueva frontera, quizás un intento Falso o Desconocido que no cambia nada.

Un candidato aún no está en progreso. Cada ejecución tiene una única historia aceptada con una cabeza actual exacta, y un candidato se compromete solo si la cabeza de la que se derivó sigue siendo la cabeza. Dos trabajadores pueden competir para extender la misma ejecución; uno se compromete, y el candidato del otro está obsoleto — no corrupto, no parcialmente aplicado, solo derivado de un estado sustituido y re-derivable. Las presentaciones repetidas de la misma operación reproducen el resultado original en lugar de aplicar doblemente. Cuando el resultado de un compromiso es genuinamente incognoscible — el almacenamiento puede haberse comprometido mientras la respuesta se perdió — el protocolo informa ese estado honestamente en lugar de adivinar.

La separación es lo que hace que todo el sistema sea auditable: la evaluación es una función determinista que puedes reproducir, y la aceptación es un punto de serialización que puedes inspeccionar.

La aceptación no es efecto

Una mutación aceptada puede llevar una intención: enviar el reembolso, publicar el artefacto, desplegar la versión. La aceptación prueba que la intención pertenece a una revisión aceptada de la ejecución y es elegible para el despacho. No prueba que el sistema externo lo haya recibido, lo haya realizado o lo haya realizado exactamente una vez. Los efectos viven fuera del límite, en sistemas con sus propios modos de fallo, y pretender lo contrario es cómo los flujos de trabajo llegan a creer en reembolsos que nunca ocurrieron.

La misma honestidad se aplica al registro en sí. El estado duradero se revalida al cargarlo en lugar de confiar en que el sistema lo escribió anteriormente. Un historial de ejecución exportado puede ser verificado de forma independiente: sus artefactos rehashados, sus evaluaciones reproducidas contra evidencia registrada. Y las afirmaciones de verificación permanecen separadas a propósito: la integridad del registro, la autenticidad de la fuente, la actualidad del paquete y la veracidad de la evidencia original son propiedades diferentes, establecidas por diferentes medios. Un cheque verde que las colapsa es un cheque verde en el que no se puede confiar.

Lo que esto no resuelve

Decision Gate endurece los flujos de trabajo contra reclamaciones no soportadas y falsas que pueden expresarse como obligaciones de prueba explícitas. Esa oración tiene bordes, y son portantes.

No descompone automáticamente la prosa arbitraria en las proposiciones correctas; el autor del flujo de trabajo, o una herramienta anterior, declara lo que importa. No hace que la evidencia débil sea fuerte: un predicado escrito de manera perezosa o una política de evidencia permisiva produce exactamente la relación de prueba que declara, verificada exactamente. No ve razonamientos ocultos, no adjudica interpretaciones disputadas ni detecta engaños fuera de los hechos de garantía que la política nombra. Una fuente puede ser consultada honestamente y aún así estar equivocada; la política decide cuánta independencia e integridad requiere una clase de reclamos.

Lo que elimina es más estrecho y estructural: la propia fluidez del actor como la autoridad decisiva. Cada reclamación que el flujo de trabajo elige restringir debe producir evidencia que sobreviva a una política declarada, y cada aceptación deja un registro de exactamente lo que se estableció, de qué, bajo qué ley.

Donde nos deja esto

El mecanismo está formalmente especificado; sus propiedades semánticas y de protocolo están establecidas; existe una implementación funcional, y sus modelos formales y sus límites están documentados en lugar de ser mencionados de manera superficial. Lo que su adopción cambia sobre el comportamiento de los agentes a través de modelos, harnesses y dominios es un programa empírico abierto: este sistema es el instrumento que hace que la pregunta sea comprobable, no una afirmación de que la respuesta ya está disponible.

Los agentes seguirán proponiendo la realidad de manera fluida. Los sistemas a su alrededor deciden si las propuestas se convierten en hechos. Basics enseña el vocabulario de trabajo, Applications muestra el límite dentro de productos reales, y la Documentación contiene el tratamiento formal completo: el álgebra de requisitos, el modelo gráfico, los estándares de evidencia y sus pruebas.