Glosario de Puerta de Decisión

Definiciones cortas y canónicas para los términos de Decision Gate.

Condición

Un nodo hoja en un árbol de Requisitos que hace referencia a un condition_id definido en el ScenarioSpec. Al evaluarse, busca el ConditionSpec, consulta al proveedor de evidencia, aplica el comparador y devuelve un resultado de tres estados. Los IDs de condición deben ser estables y descriptivos (por ejemplo, ‘env_is_prod’, ‘after_freeze’).

ConditionSpec

Vincula un condition_id a una consulta de evidencia, un comparador y un valor esperado. El condition_id es referenciado por las hojas de Requisitos. Al evaluarse, el tiempo de ejecución consulta al proveedor utilizando EvidenceQuery (provider_id + check_id + params), aplica el comparador a la evidencia y devuelve verdadero/falso/desconocido. La falta de un valor esperado (excepto para exists/not_exists) produce desconocido.

EvidenceAnchor

Metadata que vincula la evidencia a su fuente para verificación fuera de línea. Contiene anchor_type y anchor_value establecidos por el proveedor (por ejemplo, ‘receipt_id’, ‘log_offset’). Los anclajes permiten auditorías: dado un anclaje, puedes volver a consultar al proveedor (si aún está disponible) o verificar contra instantáneas archivadas. Los anclajes se incluyen en los runpacks.

EvidenceContext

Contexto de ejecución pasado a los proveedores de evidencia durante las consultas. Incluye tenant_id, run_id, scenario_id, stage_id, trigger_id, trigger_time y un optional correlation_id para la correlación de auditoría. El contexto es solo metadatos y no cambia la lógica de condición.

EvidenceQuery

La solicitud se envió a un proveedor de evidencia. Contiene provider_id (qué proveedor consultar), check_id (qué verificación del proveedor ejecutar) y params (argumentos específicos del proveedor). La consulta es determinista: la misma consulta siempre devuelve el mismo resultado dado el mismo estado externo. Las consultas se registran para auditoría.

EvidenceRef

Una referencia URI opaca que apunta a contenido de evidencia almacenado fuera del tiempo de ejecución. El tiempo de ejecución registra la referencia pero no la recupera ni la resuelve; los auditores externos pueden utilizar la URI para recuperar la evidencia según sea necesario.

EvidenceResult

La respuesta de un proveedor de evidencia. Contiene el valor de la evidencia (o su hash si la divulgación en bruto está bloqueada), el evidence_hash para la integridad, un ancla que vincula a la fuente y metadatos de firma opcionales. Los comparadores evalúan contra el campo de valor. Los resultados se capturan en runpacks para su reproducción.

EvidenceValue

La carga útil de evidencia real devuelta por un proveedor. Puede ser JSON (objetos, arreglos, cadenas, números, booleanos, nulo) o bytes sin procesar. El comparador interpreta el tipo de valor: las comparaciones numéricas requieren números, in_set requiere que el esperado sea un arreglo. Las incompatibilidades de tipo producen resultados desconocidos.

GateOutcome

El resultado de tres estados de la evaluación de una puerta: verdadero, falso o unknown. Verdadero significa que se satisface el requisito. Falso significa que la evidencia contradice el requisito. Unknown significa que falta evidencia, el comparador no puede evaluar (incompatibilidad de tipos) o el proveedor falló. El ramificado puede enrutar en cualquier resultado; solo verdadero avanza etapas lineales/fijas.

GateSpec

Define una única puerta dentro de una etapa. Cada puerta tiene un gate_id y un árbol de requisitos (expresión RET). Una puerta se activa solo cuando su requisito se evalúa como verdadero bajo la lógica tri-estado de Kleene. Las puertas fallan en cerrado: falso o desconocido bloquea el avance. Múltiples puertas en una etapa se evalúan juntas.

Proveedor

Una fuente de evidencia (servidor MCP interno o externo) que responde a las verificaciones de EvidenceQuery. Los proveedores están configurados en decision-gate.toml y se descubren a través de contratos MCP.

RET

Árbol de Evaluación de Requisitos. Un álgebra booleana sobre resultados de tres estados que compone nodos And, Or, Not, RequireGroup y Condition. Los RETs hacen que la lógica de compuerta sea explícita y auditable.

RequireGroup

Un operador de quórum N-de-M en un árbol de Requisitos. Especifica un conteo mínimo (min) de requisitos hijos que deben aprobar. Utiliza lógica de tres estados: devuelve verdadero cuando al menos min hijos son verdaderos; devuelve falso cuando incluso todos los desconocidos que se vuelven verdaderos no pueden alcanzar min; de lo contrario, devuelve desconocido. Utilizar para aprobación de múltiples partes, firmas de umbral o verificaciones redundantes.

Requisito

Un Árbol de Evaluación de Requisitos (RET) es un álgebra booleana sobre resultados de tres estados. Compuesto por nodos And, Or, Not, RequireGroup y Condition en un árbol. La evaluación utiliza lógica de Kleene fuerte: falso domina And, verdadero domina Or y desconocido se propaga. Las puertas solo pasan cuando la raíz evalúa a verdadero. Los RET hacen que la lógica de puertas sea explícita, auditable y reproducible.

EscenarioEspecificación

La especificación completa para un flujo de trabajo de decisión determinista. Contiene una lista ordenada de etapas, definiciones de condiciones y políticas/esquemas opcionales. Un ScenarioSpec es inmutable una vez registrado: su forma JSON canónica se hash para producir el spec_hash. Mismo spec + misma evidencia = mismas decisiones, siempre.

TimeoutPolicy

Política que controla lo que sucede cuando un escenario se agota. Opciones: ‘fail’ marca la ejecución como fallida con un motivo de tiempo de espera; ‘advance_with_flag’ avanza y establece la bandera de tiempo de espera de decisión; ‘alternate_branch’ enruta utilizando resultados desconocidos en las reglas de ramificación. Elija en función de la criticidad del flujo de trabajo y las necesidades de enrutamiento.

TriState

Resultado de la evaluación de tres estados: verdadero, falso o desconocido. Utilizado por comparadores y la evaluación RET para representar evidencia faltante o desajuste de tipo sin falsos positivos.

advance_to

La política que controla cómo avanza una ejecución desde la etapa actual. Cuatro modos: ‘lineal’ avanza a la siguiente etapa en orden; ‘fijo’ salta a una etapa nombrada; ‘rama’ enruta según los resultados de las puertas (verdadero/falso/desconocido cada uno mapea a un next_stage_id); ‘terminal’ finaliza la ejecución. El modo rama permite flujos de trabajo condicionales.

allow_default

Permitir el espacio de nombres ‘default’ literal (opción de activación). Requiere namespace.default_tenants. Las implementaciones en producción deben utilizar espacios de nombres explícitos para evitar colisiones entre inquilinos.

allow_http

Configuración por proveedor que permite URLs http:// para el proveedor de evidencia HTTP. Por defecto es falso (solo HTTPS). Habilitar para puntos finales de salud internos que carecen de TLS. Preferir HTTPS para cualquier servicio accesible a través de la red.

allowinsecurehttp

Permite URLs http:// (no TLS) para proveedores de MCP a nivel global. Deshabilitar en producción. Usar solo para desarrollo local o redes aisladas. El tráfico HTTP no está cifrado y es vulnerable a la interceptación.

allow_logical

Permite marcas de tiempo lógicas en las verificaciones de tiempo en lugar de requerir unix_millis real. Habilitar para pruebas y simulaciones donde se necesita un control de tiempo determinista. Deshabilitar en producción para restricciones de tiempo real.

allow_raw

Configuración por proveedor que permite la divulgación de evidencia en bruto. Requiere que allow_raw_values sea verdadero a nivel global. Establecer en proveedores cuya evidencia sea segura para exponer (por ejemplo, marcas de tiempo, estado de salud). Omitir para proveedores sensibles (secretos, credenciales).

allowrawvalues

Configuración global que permite valores de evidencia en bruto en los resultados. Cuando es falso, los proveedores devuelven hashes en lugar de valores. Habilitar solo cuando los sistemas consumidores necesiten contenido de evidencia real. Combinar con require_provider_opt_in para un control por capas.

allow_yaml

Permite el análisis de YAML en el proveedor de evidencia JSON. YAML es un superconjunto de JSON con una sintaxis adicional. Habilitar cuando los archivos de configuración utilicen el formato YAML. Deshabilitar para restringir a JSON puro para una validación más estricta.

allowed_comparators

Lista de permitidos de comparadores válidos para esta salida de verificación.

allowed_hosts

Lista de permitidos de nombres de host para solicitudes salientes del proveedor HTTP. Solo se permiten URLs que coincidan con estos hosts. Previene SSRF: las consultas a hosts no aprobados fallan con un error de seguridad. Requerido para proveedores HTTP en producción.

lista permitida

Lista de claves de variables de entorno que el proveedor de entorno puede leer. Las consultas para claves que no están en la lista de permitidos fallan con un error de política. Utilice listas de permitidos para limitar la exposición: solo permita las variables específicas que sus verificaciones necesitan.

tiposdeanclaje

Cadenas de tipo de ancla que la verificación del proveedor puede emitir.

auditoría_habilitada

Habilitar el registro de auditoría estructurado de MCP. Cuando es falso, los eventos de auditoría se descartan. El valor predeterminado es verdadero para preservar la evidencia de seguridad y cumplimiento.

audit_path

Ruta del sistema de archivos para los registros de auditoría de MCP (líneas JSON). Cuando no está configurado, los eventos de auditoría se escriben en stderr.

bind

Dirección a la que se vincula el servidor MCP para transportes HTTP o SSE. Formato: ‘host:port’ (por ejemplo, ‘127.0.0.1:8080’, ‘0.0.0.0:9000’). Requerido cuando el transporte del servidor es http/sse. Omitir para stdio.

capabilities_path

Ruta del sistema de archivos a un contrato JSON de proveedor (contrato de capacidad). El contrato declara las verificaciones soportadas, los esquemas de parámetros y la compatibilidad de comparadores. El tiempo de ejecución valida las consultas contra el contrato antes del despacho. Distribuya los contratos junto con los binarios del proveedor.

check_id

El identificador de verificación del proveedor para evaluar dentro de un proveedor. Cada proveedor expone verificaciones nombradas (por ejemplo, ‘get’ para env, ‘after’ para tiempo, ‘status’ para http). El check_id determina lo que el proveedor devuelve y qué parámetros acepta. Consulte providers.json para el catálogo completo de verificaciones por proveedor.

checks

Lista de verificaciones de proveedores expuestas por el contrato del proveedor.

comparator

El operador de comparación aplicado a la evidencia. Comparadores soportados: equals, not_equals, greater_than, greater_than_or_equal, less_than, less_than_or_equal, contains, in_set, exists, not_exists. Todos los comparadores excepto exists/not_exists requieren un valor esperado y devuelven unknown en caso de desajuste de tipo. Los comparadores numéricos devuelven unknown para no números. exists/not_exists ignoran el esperado.

condition_id

Identificador estable para una condición dentro de un ScenarioSpec. Los IDs de condición son referenciados por las hojas de requisitos y deben ser descriptivos y estables (por ejemplo, ‘env_is_prod’).

condiciones

Lista de entradas ConditionSpec en un ScenarioSpec. Cada condición vincula una verificación de proveedor a reglas de comparador y valores esperados para la evaluación de puertas.

config_schema

Esquema JSON que valida las entradas de configuración del proveedor.

contiene

Verdadero cuando la evidencia (array o string) contiene el valor esperado.

content_hash

Hash metadata para cualquier contenido de carga. Incluye el algoritmo de hash y el valor de hash. Permite la verificación de integridad de paquetes, envíos y evidencia sin requerir acceso al contenido en bruto. Se utiliza en todo runpacks.

tipodecontenido

Tipo de contenido MIME asociado con un valor de evidencia o carga útil de paquete (por ejemplo, application/json). Se utiliza para verificaciones de divulgación y compatibilidad.

tiposdecontenido

Tipos de contenido MIME permitidos para valores de evidencia o verificaciones de reglas de políticas. Utilizados en contratos de proveedores y reglas de políticas para restringir los formatos de carga útil.

correlation_id

Identificador que vincula solicitudes y decisiones relacionadas a través de sistemas. Pase un correlation_id con los desencadenantes para rastrear los flujos de decisiones a través de registros, métricas y servicios externos. Propagado en EvidenceContext para el registro del proveedor.

decisiongatedocs_search

Busca la documentación de Decision Gate para obtener orientación y mejores prácticas. Devuelve secciones clasificadas con encabezados, metadatos de rol y seguimientos sugeridos. Utiliza esto para responder preguntas sobre productos o políticas sin salir de la sesión MCP.

decision_id

Identificador único para una decisión registrada. Se genera cuando una evaluación de activación produce un resultado y se vincula a la secuencia de decisiones, trigger_id y stage_id. Los IDs de decisión permiten auditorías y depuración.

deep_equals

Igualdad estructural profunda para objetos y arreglos JSON.

deepnotequals

Desigualdad estructural profunda para objetos y arreglos JSON.

predeterminado

Efecto de política predeterminada aplicado cuando no coinciden reglas. Por defecto, se establece en ‘denegar’ para un comportamiento de cierre por fallo.

default_policy

Política de confianza predeterminada para proveedores de evidencia. Opciones: ‘audit’ o ‘require_signature’ (con lista de claves). Los proveedores individuales pueden anular. Comience con ‘audit’ y ajuste por proveedor según sea necesario.

default_tenants

Lista blanca de identificadores de inquilinos permitidos para usar el espacio de nombres literal ‘default’. Requerido cuando allow_default es verdadero; se rechaza la lista vacía.

denylist

Lista de claves de variables de entorno que el proveedor de env nunca debe leer. Las consultas para claves denegadas fallan inmediatamente. Utilice listas de denegación para una defensa en profundidad: bloquee claves conocidas como sensibles (API_KEY, SECRET_*, etc.) incluso si se consultan accidentalmente.

descripción

Resumen breve que describe el comportamiento e intención del proveedor.

determinismo

Salida de verificación del proveedor: determinista, dependiente del tiempo o externo.

dispatch_targets

Destinos donde se entregan los paquetes emitidos. Configure los objetivos en run_config: agent, session, external o channel. Múltiples objetivos permiten la distribución a diferentes sistemas.

efecto

Efecto de la regla de política: ‘permitir’, ‘denegar’ o ‘error’ (fallar cerrado con un error de política).

motor

Selección del motor de política de despacho. Opciones: ‘permit_all’, ‘deny_all’ o ‘static’. Utilice ‘static’ para aplicar la autorización basada en reglas. Se pueden agregar motores adicionales a través de adaptadores sin cambiar el núcleo.

entry_packets

Paquetes de divulgación emitidos cuando una ejecución entra en una etapa. Utilice entry_packets para liberar información en puntos específicos del flujo de trabajo: por ejemplo, revelar la configuración después de la aprobación, emitir eventos de auditoría o activar sistemas posteriores. Los paquetes incluyen payload, schema_id y visibility_labels para el control de acceso.

iguales

Verdadero cuando la evidencia es igual a lo esperado (números, cadenas, booleanos o valores JSON).

mensajedeerror

Mensaje de error a reportar cuando el efecto es ‘error’. Requerido para las reglas de error.

evidence_anchor

Campo EvidenceResult que contiene metadatos de anclaje (anchor_type + anchor_value) utilizados para vincular la evidencia a su fuente para verificación fuera de línea.

evidence_hash

SHA-256 hash de un valor de evidencia para la verificación de integridad. Calculado sobre la forma canónica de EvidenceValue. Los hashes de evidencia permiten la verificación sin exponer valores en bruto: los auditores pueden confirmar que la evidencia coincide con las expectativas incluso cuando la divulgación en bruto está bloqueada.

consultadeevidencia

Consulta a un proveedor de evidencia con la política de divulgación configurada aplicada. Devuelve el EvidenceResult que contiene el valor (o hash), los metadatos de anclaje y una firma opcional. Utiliza esto para depurar condiciones o construir puertas personalizadas fuera del flujo de escenario estándar.

evidence_ref

Campo EvidenceResult que contiene una referencia URI externa al contenido de evidencia almacenado fuera del tiempo de ejecución.

ejemplos

Ejemplos de invocaciones de verificación con parámetros y resultados.

existe

Verdadero cuando el valor de evidencia está presente. Se ignora lo esperado.

expected

El valor objetivo se compara con la salida de evidencia. El tipo debe coincidir con el tipo de evidencia: valores JSON para equals/in_set, números para greater_than, arreglos para in_set (la evidencia coincide con cualquier elemento). Si falta o no coincide el esperado, el comparador devuelve desconocido (fail-closed). No es necesario para exists/not_exists.

forbid_labels

Etiquetas de visibilidad que no deben estar presentes para que la regla coincida.

forbidpolicytags

Etiquetas de política que no deben estar presentes para que la regla coincida.

resultado de la puerta

El resultado de tres estados de la evaluación de una puerta: verdadero, falso o unknown. Verdadero significa que se satisface el requisito. Falso significa que la evidencia contradice el requisito. Unknown significa que falta evidencia, el comparador no puede evaluar (incompatibilidad de tipos) o el proveedor falló. El ramificado puede enrutar en cualquier resultado; solo verdadero avanza etapas lineales/fijas.

gate_id

Identificador para una puerta dentro de una etapa. Debe ser único dentro de la etapa. Aparece en los registros de ejecución, decisiones y en el enrutamiento de ramas. Utilice nombres descriptivos que reflejen lo que verifica la puerta: ‘env_gate’, ‘time_gate’, ‘approval_gate’.

gates

La lista de GateSpecs evaluados cuando una ejecución entra en una etapa. Todas las puertas se evalúan juntas (no se interrumpen). La política advance_to de la etapa determina cómo los resultados de las puertas afectan la progresión. Múltiples puertas permiten verificaciones paralelas: por ejemplo, verificar tanto las restricciones de tiempo como las aprobaciones antes de avanzar.

generated_at

Marca de tiempo registrada en el manifiesto de runpack que indica cuándo se creó la exportación. Expresada como ISO 8601. Útil para registros de auditoría y verificaciones de frescura. No afecta el resultado de la verificación.

mayor_que

Verdadero cuando la evidencia numérica es mayor de lo esperado.

mayorqueo_igual

Verdadero cuando la evidencia numérica es mayor o igual a la esperada.

hash_algorithm

Algoritmo utilizado para el hashing de evidencia y artefactos de runpack. Actualmente, exclusivamente SHA-256. Registrado en manifiestos para compatibilidad futura. No asuma otros algoritmos sin verificar este campo.

in_set

Verdadero cuando la evidencia está contenida en el array esperado.

include_verification

Indicador que determina si se debe emitir un informe de verificación junto con la exportación de runpack. Cuando es verdadero, runpack_export también ejecuta la verificación e incluye el informe. Útil para la validación inmediata después de la exportación.

issueentrypackets

Bandera que controla si scenario_start emite entry_packets para la etapa inicial. Establecer en falso para diferir la emisión de paquetes hasta el primer desencadenador o el siguiente. Útil cuando las ejecuciones necesitan configuración antes de que comiencen las divulgaciones.

jsonpath

Selector JSONPath utilizado por el proveedor JSON para extraer valores de documentos. La sintaxis sigue la RFC 9535. Ejemplos: ‘$.version’, ‘$.config.features[*].name’. El valor extraído se convierte en la evidencia para la evaluación del comparador.

menos_que

Verdadero cuando la evidencia numérica es menor de lo esperado.

lessthanor_equal

Verdadero cuando la evidencia numérica es menor o igual a la esperada.

lexmayorque

Comparación de cadenas lexicográficas: verdadero cuando la evidencia se ordena después de lo esperado.

lexmayorqueoigual

Comparación de cadenas lexicográficas: verdadero cuando la evidencia se ordena después o es igual a lo esperado.

lexmenosque

Comparación de cadenas lexicográficas: verdadero cuando la evidencia se ordena antes de lo esperado.

lexmenorqueoigual

Comparación de cadenas lexicográficas: verdadero cuando la evidencia se ordena antes o es igual a lo esperado.

logprecheckpayloads

Consentimiento explícito para registrar las cargas útiles de solicitud/respuesta de prechequeo en bruto. Por defecto, falso; la auditoría solo de hash siempre se emite cuando la auditoría está habilitada.

lógico

Un valor de marca de tiempo lógico utilizado para el ordenamiento determinista cuando el tiempo del reloj de pared no está disponible. Se aceptan enteros proporcionados por el llamador (>= 0) solo cuando allow_logical está habilitado. Útil para pruebas y simulación.

manifiesto

El manifiesto de runpack que contiene metadatos y hashes para todos los artefactos. Enumera cada archivo en el runpack con su hash SHA-256, además de la marca de tiempo de generación y la referencia spec_hash. La verificación compara los hashes calculados con el manifiesto para detectar manipulaciones o archivos faltantes.

manifest_name

Sobrescribir el nombre del archivo para el manifiesto de runpack. Por defecto es ‘manifest.json’. Personalizar al exportar múltiples runpacks al mismo directorio o al integrarse con sistemas que esperan nombres de archivos específicos.

manifest_path

Ruta al archivo de manifiesto dentro del directorio runpack. Utilizado por runpack_verify para localizar el manifiesto. Típicamente ‘manifest.json’ en la raíz de runpack. El verificador lee este archivo primero para descubrir todos los demás artefactos.

maxbodybytes

Tamaño máximo del cuerpo de la solicitud en bytes para solicitudes JSON-RPC. Previene que cargas útiles excesivas agoten los recursos del servidor. Las solicitudes que superen esto son rechazadas antes del procesamiento. Configurar según los tamaños de carga útil esperados.

max_bytes

Tamaño máximo de archivo en bytes que el proveedor JSON leerá. Previene el agotamiento de recursos por archivos de gran tamaño. Las consultas para archivos que superen este límite fallan con un error de validación. Ajuste el tamaño de manera apropiada para sus archivos de configuración.

maxkeybytes

Longitud máxima de bytes para las claves de variables de entorno consultadas por el proveedor de env. Previene el agotamiento de recursos por nombres de claves patológicos. Por defecto, se establece un límite razonable. Las consultas que superen este límite fallan con un error de validación.

maxresponsebytes

Tamaño máximo del cuerpo de respuesta HTTP que el proveedor HTTP leerá. Previene el agotamiento de memoria por respuestas sin límites. Las respuestas que superen este tamaño son truncadas o rechazadas. Tamaño para chequeos de salud típicos o respuestas de API.

maxvaluebytes

Longitud máxima de bytes para los valores de las variables de entorno devueltos por el proveedor env. Previene que los valores excesivos inflen los resultados de evidencia. Los valores que superen esto son truncados o rechazados según la configuración del proveedor.

modo

Modo de operación del servidor: ‘estricto’ (predeterminado) o ‘dev_permissive’ heredado. Prefiera el conmutador explícito dev.permissive. Dev-permissive relaja solo la evidencia afirmada y no permite automáticamente el espacio de nombres predeterminado.

nombre

Nombre del proveedor legible por humanos que se muestra en la documentación y en las interfaces de usuario.

no_iguales

Verdadero cuando la evidencia no es igual a la esperada.

not_exists

Verdadero cuando falta el valor de evidencia. Se ignora lo esperado.

notas

Notas opcionales sobre el comportamiento del proveedor o el determinismo.

on_timeout

Política de tiempo de espera de etapa (TimeoutPolicy). Siempre presente en StageSpec y utilizada solo cuando se establece un tiempo de espera; ignorada cuando el tiempo de espera es nulo. Soporta comportamientos de ‘fail’, ‘advance_with_flag’ o ‘alternate_branch’.

output_dir

Directorio donde runpack_export escribe el paquete de auditoría para el almacenamiento en el sistema de archivos. Opcional cuando se configura el almacenamiento gestionado de runpack. Asegúrese de tener permisos de escritura y suficiente espacio en disco. Los archivos existentes pueden ser sobrescritos.

overrides

Mapa de anulación determinista para valores de entorno durante las pruebas. Las claves en las anulaciones reemplazan las búsquedas reales del entorno, asegurando evidencia reproducible. Utilizar para CI/CD donde el entorno varía entre los ejecutores.

packet_id

Identificador para un paquete de divulgación. Debe ser único dentro del escenario. Se utiliza para rastrear emisiones, filtrar por tipo de paquete y correlacionar con dispatch_targets. Se hace referencia en entry_packets y registros de divulgación.

packet_ids

Identificadores de paquetes permitidos por la regla.

params

Parámetros específicos del proveedor pasados a una verificación. La estructura varía según el proveedor: env.get necesita {key}, time.after necesita {timestamp}, http.status necesita {url}. Los parámetros requeridos inválidos o faltantes hacen que el proveedor falle, lo que produce un resultado desconocido.

params_required

Si se deben proporcionar EvidenceQuery.params para esta verificación.

params_schema

JSON Schema para los parámetros de carga útil de verificación del proveedor.

carga útil

El cuerpo de contenido de un paquete, envío o carga útil de activación. Codificado como PacketPayload: json, bytes o external content_ref (uri + content_hash, cifrado opcional). Las cargas útiles se hash para integridad y pueden ser validadas por esquema antes de la emisión.

permissive

Interruptor explícito solo para desarrolladores que permite evidencia afirmada. Utilizar únicamente en entornos de desarrollo local o pruebas controladas; emite advertencias y metadatos de auditoría.

permissiveexemptproviders

IDs de proveedores exentos de relajaciones permisivas para desarrolladores (por ejemplo, proveedores de Asset Core).

permissive_scope

Selector de ámbito permisivo para desarrolladores. Actualmente fijado a asserted_evidence_only para v1.

permissivettldays

TTL opcional (días) para advertencias de permisos de desarrollo. Utiliza la configuración mtime para emitir advertencias de expiración cuando se excede el TTL.

permissive_warn

Emitir advertencias y eventos de auditoría de seguridad cuando dev-permissive esté habilitado o haya expirado.

policy_tags

Etiquetas aplicadas a ejecuciones, condiciones o divulgaciones para el enrutamiento de políticas. Las etiquetas permiten un comportamiento condicional: diferentes reglas de divulgación por entorno, límites de tasa específicos del inquilino o categorías de auditoría. Define etiquetas en el ScenarioSpec y aplícalas a ejecuciones, condiciones, paquetes o tiempos de espera según sea necesario.

preverificación

Evalúa un escenario contra datos afirmados sin mutar el estado de ejecución. Valida los datos afirmados contra una forma registrada y devuelve el resultado de la decisión para la simulación. Utiliza esto como el bucle de iteración rápida para los agentes antes de ejecutar el escenario_auditoría_siguiente.

providercheckschema_get

Obtiene detalles del esquema a nivel de verificación para un proveedor (esquema de parámetros, esquema de resultados, listas de permitidos de comparadores y ejemplos). Utiliza esto para redactar formularios o guías de LLM sin cargar el contrato completo del proveedor.

providercontractget

Obtiene el JSON del contrato del proveedor canónico y su hash para un proveedor. Utiliza esto para descubrir esquemas de verificación, listas de permitidos de comparadores y ejemplos. La divulgación está controlada por la autorización y la política de visibilidad del contrato del proveedor.

provider_id

Identificador para un proveedor de evidencia registrado en decision-gate.toml. Los proveedores suministran verificaciones: ‘time’ para marcas de tiempo, ‘env’ para variables de entorno, ‘http’ para verificaciones de salud, ‘json’ para consultas de archivos. Los proveedores personalizados se pueden registrar a través de la configuración de MCP.

providers_list

Lista de proveedores de evidencia registrados y su resumen de capacidades. Devuelve identificadores de proveedores, metadatos de transporte y visibilidad con alcance de políticas. Utilice esto para descubrir proveedores disponibles y verificaciones soportadas.

registro

Wrapper para respuestas de envío. Contiene submission_id, run_id, payload, content_type, content_hash, submitted_at y correlation_id. Los registros demuestran que los artefactos fueron enviados y hashados para auditoría.

request

Envoltorio para cargas útiles de solicitudes de herramientas. Utilizado en mensajes del protocolo MCP. Contiene el nombre de la herramienta, parámetros y metadatos de la solicitud. Estructura interna; la mayoría de los usuarios interactúan a través de herramientas de nivel superior scenario_*.

require_labels

Etiquetas de visibilidad que deben estar presentes para que la regla coincida.

requirepolicytags

Etiquetas de política que deben estar presentes para que la regla coincida.

requireprovideropt_in

Requiere que los proveedores opten explícitamente por la divulgación en bruto a través de allow_raw en su configuración. Incluso si allow_raw_values es verdadero a nivel global, los proveedores sin opt-in devuelven hashes. Defensa en profundidad para evidencia sensible.

requisito

La expresión RET que debe satisfacer una puerta. Este campo contiene la raíz de un árbol de Requisitos (And/Or/Not/RequireGroup/Condition). La puerta solo se activa cuando todo el árbol evalúa como verdadero. Diseñe requisitos para manejar resultados desconocidos de manera explícita a través de ramificaciones o umbrales de RequireGroup.

resultado

Ejemplo de valor de salida para una invocación de verificación.

result_schema

JSON Schema para los valores de salida de verificación del proveedor.

root

Directorio base para la resolución de archivos del proveedor JSON. Las rutas de archivo en las consultas se resuelven en relación con la raíz. Previene la navegación por directorios: las rutas que escapan de la raíz fallan con un error de seguridad. Establecer en el directorio de configuración o en una carpeta de datos dedicada.

reglas

Lista ordenada de reglas de política. La primera regla que coincida con la solicitud de despacho gana.

run_config

Configuración proporcionada al iniciar una ejecución a través de scenario_start. Incluye tenant_id, run_id, scenario_id, dispatch_targets y policy_tags. La configuración de ejecución es inmutable después de iniciar y se registra en runpacks para reproducibilidad.

run_id

Identificador único que delimita una única ejecución de un escenario. Generado en scenario_start y utilizado para todas las operaciones subsiguientes. Los IDs de ejecución aparecen en runpacks, decisiones y registros de auditoría. Mantenga los run_ids para correlación y respuesta a incidentes.

runstatestore

Configuración del backend para la persistencia del estado de ejecución. Las opciones incluyen en memoria (para pruebas) o SQLite. El almacén mantiene el progreso de ejecución, el historial de decisiones y los desencadenadores pendientes. Configure la durabilidad y la retención según las necesidades de cumplimiento.

runpack_dir

Directorio raíz de un runpack para verificación. runpack_verify lee el manifiesto desde esta ubicación y verifica todos los artefactos referenciados. Apunte al directorio que contiene manifest.json.

runpack_export

Exporta un paquete de auditoría determinista (runpack) que contiene la especificación del escenario, todos los disparadores, evaluaciones de puertas, decisiones y paquetes de divulgación. El manifiesto incluye hashes SHA-256 de cada artefacto. Los runpacks permiten la verificación offline: cualquier persona puede reproducir la lógica de decisión y confirmar los mismos resultados.

runpack_verify

Verifica el manifiesto y los artefactos de un runpack sin conexión. Comprueba que todos los hashes coincidan, que la secuencia de decisiones sea internamente consistente y que no falten ni se hayan manipulado artefactos. Devuelve un informe de verificación. Utiliza esto para auditorías de cumplimiento, revisión de incidentes o validación de puertas de CI/CD.

escenario_definir

Registra un ScenarioSpec con el runtime y devuelve su spec_hash canónico. El runtime valida la estructura del spec, verifica que todas las condiciones y proveedores referenciados existan, y calcula un hash SHA-256 de la forma JSON canónica. Almacena el spec_hash para auditoría: prueba qué spec exacto gobernó una ejecución.

scenario_id

Identificador estable para un escenario a lo largo de su ciclo de vida: registro, ejecuciones y auditorías. Elija identificadores descriptivos y versionados (por ejemplo, ‘deployment-gate-v2’). El scenario_id más spec_hash identifican exactamente qué definición de flujo de trabajo se utilizó.

scenario_ids

Identificadores de escenario permitidos por la regla.

escenario_siguiente

Evalúa las puertas para la etapa actual y avanza o mantiene la ejecución. Este es el principal impulsor de los flujos de trabajo controlados por el agente. Todas las puertas deben ser verdaderas para avanzar; de lo contrario, la ejecución se mantiene. Las etapas de ramificación utilizan los resultados de las puertas para seleccionar el next_stage_id una vez que las puertas pasan. Las políticas de tiempo de espera pueden sintetizar resultados para el enrutamiento de ramas alternas. Devuelve la decisión y la nueva etapa, con niveles de retroalimentación opcionales (resumen, traza, evidencia) cuando lo permite la política de retroalimentación del servidor.

iniciodelescenario

Crea un nuevo estado de ejecución para un escenario registrado. Inicializa la ejecución en la primera etapa y, opcionalmente, emite entry_packets como divulgaciones. Devuelve un run_id que delimita todas las operaciones subsecuentes. La ejecución comienza en el estado activo con stage_entered_at establecido a partir de started_at.

estadodelescenario

Obtiene una instantánea de solo lectura de una ejecución sin modificarla. Devuelve current_stage_id, status, last_decision, issued_packet_ids y un safe_summary opcional para las visualizaciones de la interfaz de usuario. Utiliza esto para paneles, sondeos y depuración. La respuesta omite los valores de evidencia en bruto.

escenario_enviar

Envía artefactos externos al registro de auditoría de una ejecución para su revisión posterior. Utiliza esto para adjuntar documentos, firmas o recibos para auditoría y exportación de runpack. Las cargas útiles se hash en content_hash y se registran en el registro de envíos. Los envíos son idempotentes por submission_id; las cargas útiles en conflicto devuelven un error de conflicto.

escenario_disparador

Envía un evento de activación con una marca de tiempo explícita y evalúa la ejecución. A diferencia de scenario_next, los activadores llevan metadatos de tipo, source_id y una carga útil opcional para verificaciones basadas en el tiempo y auditoría. El trigger_id asegura un procesamiento idempotente: las llamadas repetidas con el mismo trigger_id devuelven la decisión almacenada en caché.

listadeescenarios

Lista los escenarios registrados para un inquilino y un espacio de nombres. Devuelve identificadores de escenario y hashes de especificación para apoyar el inventario y la auditoría.

schema_id

Identificador para un esquema adjunto a paquetes. Los esquemas validan la estructura de la carga útil antes de la emisión. Registre los esquemas en el array de esquemas de ScenarioSpec. Los paquetes hacen referencia a los esquemas por schema_id para garantizar la seguridad de tipo y la documentación.

schema_ids

Identificadores de esquema permitidos por la regla.

schemas_get

Obtiene una forma de datos específica por schema_id y versión para un inquilino y un espacio de nombres. Falla de manera cerrada cuando falta el esquema.

listasdeesquemas

Lista los formatos de datos registrados para un inquilino y un espacio de nombres. Soporta paginación a través de cursor y límite. Utiliza esto para descubrir las versiones de esquema disponibles.

schemas_register

Registra un esquema de forma de datos para un inquilino y un espacio de nombres. Los esquemas son inmutables; volver a registrar la misma versión falla. Incluye created_at para capturar cuándo se creó el esquema.

firma

Metadatos de la firma criptográfica adjuntos a la evidencia. Contiene el esquema de firma (por ejemplo, ed25519), el identificador de la clave pública y los bytes de la firma. Permite a los proveedores probar la autenticidad de la evidencia. Los verificadores pueden comprobar las firmas sin conexión utilizando la referencia de clave anclada.

spec_hash

Un hash SHA-256 canónico del ScenarioSpec en forma JSON determinista. Dos specs con contenido idéntico siempre producen el mismo hash independientemente del orden de los campos. Almacene el spec_hash al iniciar una ejecución: prueba exactamente qué versión del spec gobernó las decisiones. Es esencial para auditoría y cumplimiento.

stageenteredat

Marca de tiempo registrada cuando la ejecución ingresó a la etapa actual. Se utiliza para evaluar los tiempos de espera de la etapa y para la reproducción de auditoría. Se establece en scenario_start y se actualiza en los avances.

stage_id

Identificador para una etapa dentro de un escenario. Debe ser único dentro del ScenarioSpec. Referenciado por políticas advance_to y objetivos de ramificación. Los IDs de etapa aparecen en el estado de ejecución, decisiones y emisiones de entry_packet. Utilice nombres descriptivos: ‘aprobación’, ‘verificación’, ‘liberación’.

stage_ids

Identificadores de etapa permitidos por la regla.

etapas

Una lista ordenada de fases de decisión en un ScenarioSpec. Cada etapa contiene puertas para evaluar y una política advance_to. Las ejecuciones progresan a través de las etapas secuencialmente a menos que una bifurcación las redirija. Las etapas aíslan preocupaciones: las etapas iniciales pueden verificar requisitos previos, las etapas intermedias verifican condiciones, y las etapas finales autorizan acciones.

started_at

Marca de tiempo proporcionada por el llamador que indica cuándo comenzó la ejecución. Requerida en scenario_start y utilizada para cálculos de tiempo, stage_entered_at y registros de auditoría. Se prefieren marcas de tiempo explícitas para una reproducción determinista.

static

Configuración de la política de despacho estático. Se aplica cuando policy.engine = ‘static’.

estado

Indicador del estado actual para una ejecución o verificación. Estados de ejecución: ‘activo’, ‘completado’, ‘fallido’. Estados de verificación: ‘aprobado’, ‘fallido’. Verifique el estado para determinar las próximas acciones o identificar problemas.

storage_uri

Ubicación de almacenamiento opcional devuelta por los backends de almacenamiento de runpack gestionados (por ejemplo, s3://bucket/tenant/namespace/run/runpack.tar). Presente solo cuando el servidor está configurado para exportar runpacks a almacenamiento de objetos.

submission_id

Identificador para un artefacto externo enviado a través de scenario_submit. Debe ser único dentro de la ejecución. Permite envíos idempotentes: las llamadas repetidas con la misma carga útil devuelven el registro existente, mientras que las cargas útiles en conflicto devuelven un error.

sistema

Nombre del sistema externo para los objetivos de despacho.

target

Identificador externo de destino para objetivos de despacho.

target_id

Identificador de destino para selectores de agente/sesión/canal.

target_kind

Tipo de objetivo para un selector explícito. Opciones: ‘agente’, ‘sesión’, ‘externo’, ‘canal’.

target_kinds

Tipos de destino permitidos por la regla. Opciones: ‘agent’, ‘session’, ‘external’, ‘channel’.

targets

Selectores de destino explícitos para la autorización de despacho.

tenant_id

Identificador para la aislamiento de inquilinos en implementaciones multi-inquilino. Ejecuta ámbitos, almacenes de estado y políticas. Los datos de cada inquilino están lógicamente separados. Por defecto, se establece en un solo inquilino si no se especifica. Requerido para patrones de SaaS e infraestructura compartida.

timeout

Configuración del tiempo de espera de la etapa. Establecer en un TimeoutSpec que contenga timeout_ms y policy_tags, o nulo para no tener tiempo de espera. Los tiempos de espera evitan que las ejecuciones se detengan indefinidamente y son gestionados por on_timeout.

timeout_ms

Tiempo de espera en milisegundos. Utilizado para los tiempos de espera de etapa (TimeoutSpec) y para las solicitudes del proveedor HTTP. Las operaciones que superen esta duración fallan según la política.

transporte

Protocolo de transporte MCP para la comunicación con proveedores: ‘stdio’ para tuberías de subprocesos, ‘http’ para JSON-RPC sobre HTTP, ‘sse’ para eventos enviados por el servidor. Elegir según el despliegue: stdio para proveedores locales, http/sse para servicios remotos. Configurar en decision-gate.toml [[providers]].

trigger

Carga útil del evento enviada a través de scenario_trigger para avanzar una ejecución. Contiene trigger_id, run_id, kind, time, source_id, carga útil opcional y correlation_id. Los triggers se registran para la reproducción de auditoría.

trigger_id

Identificador que garantiza el procesamiento idempotente de los disparadores. Las llamadas repetidas con el mismo trigger_id devuelven la decisión almacenada en caché sin re-evaluación. Utilice UUIDs o IDs derivados de eventos. Crítico para reintentos seguros en sistemas distribuidos.

trigger_time

Marca de tiempo proporcionada por el llamador del evento de activación utilizada por las verificaciones de tiempo y EvidenceContext. Utiliza el tipo Timestamp (unix_millis o lógico cuando se permite) para evitar lecturas de reloj de pared. Los auditores pueden reproducir ejecuciones con el trigger_time registrado.

unix_millis

Marca de tiempo Unix expresada en milisegundos desde la época (1970-01-01 UTC). Formato estándar para trigger_time y verificaciones de tiempo. La precisión en milisegundos permite la programación en sub-segundos. Convertir desde ISO 8601: analizar a Date, llamar a getTime().

user_agent

Cadena de encabezado User-Agent para solicitudes de proveedores HTTP. Por defecto, se utiliza un identificador de Decision Gate. Personalícelo para los requisitos de la API, identificación de límites de tasa o depuración. Aparece en los registros de servicios externos.

visibility_labels

Etiquetas de control de acceso adjuntas a los paquetes emitidos. Las etiquetas están disponibles para los decisores de políticas y los consumidores posteriores para implementar reglas de divulgación. Utilizar para divulgación graduada: algunos sistemas ven resúmenes, otros ven detalles completos.