Arxi Puerta de Decisión Asset Core
Docs
Documentos de Decision Gate

Evaluación de puertas determinista, reproducible con decisiones auditables.

Documentación de Asset Core

Flujo de Evidencia + Modelo de Ejecución

A primera vista

Qué: Cómo Decision Gate evalúa la evidencia y produce decisiones Por qué: Entender exactamente qué se obtiene, valida y compara Quién: Desarrolladores, equipos de seguridad y arquitectos que integran Decision Gate Requisitos previos: getting_started.md

Una frase que debes recordar

Decision Gate evalúa la evidencia; no ejecuta tareas.

Flujo de Datos Principal

Trigger (scenario_next / scenario_trigger / precheck)
  |
  +-> Collect or accept evidence
  |     - Live run: call providers
  |     - Precheck: accept asserted payload
  |
  +-> Trust enforcement
  |     - Trust lane minimum (min_lane)
  |     - Signature policy (if required)
  |     - Anchor validation (if configured)
  |
  +-> Comparator evaluation -> TriState
  +-> RET evaluation -> Gate outcomes
  |
  +-> Decision
        - Live run: state mutation + runpack storage
        - Precheck: no state mutation

Fuentes de Evidencia

1) Proveedores (Ejecutar en Vivo)

Los proveedores obtienen o calculan evidencia y devuelven un EvidenceResult.

Proveedores integrados: time, env, json, http

Proveedores externos: servidores MCP llamados a través de tools/call con evidence_query.

2) Evidencia Afirmada (Prechequeo)

Precheck no llama a los proveedores. El cliente proporciona una carga útil que es:

  1. Validado contra una forma de datos registrada (JSON Schema).
  2. Convertido en valores EvidenceResult afirmados.

El mapeo de carga útil es exacto:

  • Si el payload es un objeto: las claves son IDs de condición.
  • Si el payload no es un objeto: solo se acepta cuando el escenario tiene exactamente una condición.

Cumplimiento de Confianza

Lanes de Confianza

  • Verificado: evidencia devuelta por los proveedores.
  • Afirmado: evidencia suministrada a través de la carga de prechequeo.

Carril Mínimo (min_lane)

Configurado en decision-gate.toml:

[trust]
min_lane = "verified"   # or "asserted"

Cuando min_lane = "verified", la evidencia afirmada es rechazada (la condición se convierte en unknown).

Dev-permissive: min_lane se convierte en asserted automáticamente, excepto para los proveedores listados en dev.permissive_exempt_providers (esos permanecen estrictos).

Anulaciones por Condición y por Puerta

Puedes aumentar el carril mínimo en la especificación del escenario:

{
  "condition_id": "tests_ok",
  "trust": { "min_lane": "verified" }
}

El trust a nivel de puerta también puede aumentar los requisitos. El requisito efectivo es el más estricto de la base y las sobrecargas.

Verificación de Firma

Configurado a través de trust.default_policy:

[trust]
# Audit mode accepts unsigned evidence.
default_policy = "audit"

# Require signatures from key files:
# default_policy = { require_signature = { keys = ["/etc/decision-gate/keys/provider.pub"] } }

Cuando require_signature está activo:

  • EvidenceResult.signature.scheme debe ser "ed25519".
  • signature.key_id debe coincidir con una entrada de clave configurada.
  • La firma se verifica sobre JSON canónico de evidence_hash.

Si evidence_hash falta, Decision Gate lo calcula a partir del valor de evidencia. Si evidence_hash está presente, debe coincidir con el hash canónico del valor de evidencia o la respuesta del proveedor será rechazada.

Validación de Anclaje

Los anclajes se aplican a través de la configuración (no la especificación del escenario):

[anchors]
[[anchors.providers]]
provider_id = "json"
anchor_type = "file_path_rooted"
required_fields = ["root_id", "path"]

EvidenceResult.evidence_anchor.anchor_value debe ser una cadena que contenga JSON canónico que se analice como un objeto. Los campos requeridos deben existir y deben ser escalares (cadena/número). Las violaciones producen error.code = "anchor_invalid" y la condición se convierte en unknown. Para file_path_rooted, path es relativo a la raíz del proveedor configurado.

Evaluación del Comparador

Los comparadores producen resultados TriState:

  • verdadero
  • falso
  • desconocido

Comportamientos exactos importantes (ver condition_authoring.md):

  • equals/not_equals devuelve false/true en caso de desajuste de tipo (no unknown).
  • Los comparadores de orden (greater_than, etc.) devuelven unknown a menos que ambos lados sean números o cadenas de fecha/hora RFC3339.
  • exists/not_exists prueba presencia de EvidenceResult.value; JSON null aún cuenta como exists.

Flujo de Ejecución en Vivo (scenario_next)

  1. Existe una ejecución (scenario_start).
  2. scenario_next se llama con run_id, tenant_id, namespace_id, trigger_id, agent_id y time.
  3. Decision Gate llama a los proveedores para cada condición.
  4. Se aplican los requisitos de confianza.
  5. Los comparadores y RET producen resultados de puerta.
  6. Se devuelve un DecisionRecord y se actualiza el estado de ejecución.

Salida: NextResult { decision, packets, status } (sin valores de evidencia).

Para inspeccionar evidencia y detalles de la puerta, utiliza runpack_export.

Flujo de Preverificación (precheck)

  1. El cliente llama a schemas_register para registrar una forma de datos.
  2. Client calls precheck with:
    • tenant_id, namespace_id
    • scenario_id o inline spec
    • data_shape (id de esquema + versión)
    • carga útil
  3. La carga útil se valida contra el esquema.
  4. La carga útil se convierte en evidencia afirmada.
  5. Las puertas se evalúan sin mutar el estado de ejecución.

Salida: PrecheckToolResponse { decision, gate_evaluations }.

gate_evaluations incluye solo el estado de la puerta y el rastro de condiciones (sin valores de evidencia).

Audit Submissions (scenario_submit)

scenario_submit añade un registro de envío al estado de ejecución sin afectar la evaluación de la puerta. Cada envío almacena un hash de contenido y metadatos para auditoría.

Interacción con el Proveedor (MCP Externo)

Decision Gate llama a proveedores externos de MCP con tools/call y una única herramienta: evidence_query. No depende de tools/list en tiempo de ejecución; las capacidades del proveedor se cargan desde capabilities_path en la configuración.

Conceptos Erróneos Comunes (Corregidos)

  • “DG ejecuta las herramientas.” -> Falso. DG evalúa la evidencia; las herramientas se ejecutan en otro lugar.
  • “Precheck devuelve errores de evidencia.” -> Falso. Solo devuelve decision + gate_evaluations.
  • “scenario_next response includes evidence.” -> Falso por defecto. Las solicitudes solo locales tienen como valor predeterminado la retroalimentación trace, pero los valores de evidencia aún requieren feedback: "evidence" (si está permitido) o runpack_export/evidence_query.
  • “La política de anclaje está en el escenario.” -> Falso. Está configurada bajo [anchors].

Glosario

EvidenceQuery: { provider_id, check_id, params }. EvidenceResult: { value, lane, error, evidence_hash, evidence_ref, evidence_anchor, signature, content_type }. Trust Lane: verified o asserted. Runpack: Paquete de artefactos de auditoría escrito para ejecuciones en vivo.