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

Patrones de Integración

A primera vista

Qué: Patrones de implementación comunes para CI/CD, bucles de agentes y flujos de trabajo de cumplimiento Por qué: Elegir la estrategia de integración adecuada para las necesidades de confianza y auditoría Quién: Arquitectos y desarrolladores que planifican implementaciones de Decision Gate Requisitos previos: getting_started.md

Resumen del Patrón

PatrónCarril de ConfianzaVelocidadRegistro de AuditoríaCaso de Uso
CI/CD GateVerificadoMás LentoEjecución completaDespliegues en producción
Agent LoopAfirmado -> VerificadoRápido -> LentoOpcional -> CompletoPlanificación de LLM hacia puertas
Controlled DisclosureVerificadoLentoCompletoLiberación de datos con auditoría
Compliance WorkflowVerificadoLentoCompletoPuertas de múltiples etapas
MCP FederationVerificadoVaríaCompletoFuentes de evidencia externas

Patrón 1: Puerta CI/CD

Cuándo usar: Puertas de calidad automatizadas en pipelines de CI/CD

Flujo:

  1. Ejecutar herramientas -> emitir JSON
  2. scenario_start -> crear ejecución
  3. scenario_next -> DG lee JSON a través del proveedor json
  4. El resultado de la decisión impulsa el despliegue

Configura el proveedor json con una raíz que apunte a tu espacio de trabajo de evidencia, y mantiene las rutas de archivo relativas a esa raíz.

Escenario (mínimo, campos precisos):

{
  "scenario_id": "ci-gate",
  "namespace_id": 1,
  "spec_version": "v1",
  "stages": [
    {
      "stage_id": "quality",
      "entry_packets": [],
      "gates": [
        {
          "gate_id": "quality-checks",
          "requirement": {
            "And": [
              { "Condition": "tests_ok" },
              { "Condition": "coverage_ok" },
              { "Condition": "scan_ok" }
            ]
          }
        }
      ],
      "advance_to": { "kind": "terminal" },
      "timeout": null,
      "on_timeout": "fail"
    }
  ],
  "conditions": [
    {
      "condition_id": "tests_ok",
      "query": {
        "provider_id": "json",
        "check_id": "path",
        "params": {
          "file": "test-results.json",
          "jsonpath": "$.summary.failed"
        }
      },
      "comparator": "equals",
      "expected": 0,
      "policy_tags": []
    },
    {
      "condition_id": "coverage_ok",
      "query": {
        "provider_id": "json",
        "check_id": "path",
        "params": {
          "file": "coverage.json",
          "jsonpath": "$.total.lines.percent"
        }
      },
      "comparator": "greater_than_or_equal",
      "expected": 85,
      "policy_tags": []
    },
    {
      "condition_id": "scan_ok",
      "query": {
        "provider_id": "json",
        "check_id": "path",
        "params": {
          "file": "scan.json",
          "jsonpath": "$.summary.critical"
        }
      },
      "comparator": "equals",
      "expected": 0,
      "policy_tags": []
    }
  ],
  "policies": [],
  "schemas": [],
  "default_tenant_id": 1
}

Interpretación del resultado de scenario_next:

  • Look at result.decision.outcome.kind:
    • avance / completo -> puertas pasadas
    • hold -> puertas no satisfechas
    • fail -> ejecución fallida
  • Opcional: feedback: "trace" puede devolver el estado de la puerta + condición (si lo permite la política de retroalimentación del servidor).

Patrón 2: Bucle de Agente

Cuándo usar: Agentes LLM iterando hacia la satisfacción de la puerta de decisión

Flujo:

  1. El agente ejecuta herramientas -> extrae valores
  2. precheck -> evaluación rápida (evidencia afirmada)
  3. Si las puertas pasan -> ejecutar en vivo scenario_next

La salida de precheck está limitada:

  • Devuelve { decision, gate_evaluations }.
  • gate_evaluations contiene gate_id, status y solo el rastro de condiciones.
  • No incluye valores de evidencia ni errores.

Si necesita errores de evidencia, use evidence_query o runpack_export en una ejecución en vivo.

Patrón 3: Divulgación Controlada

Cuándo usar: Publicación de datos con historial de auditoría

Flujo típico:

  1. Aprobaciones de puerta utilizando RequireGroup.
  2. Al pasar, utiliza scenario_submit para registrar metadatos.
  3. Enviar paquetes de datos (controlados por políticas).

scenario_submit es solo para auditoría y requiere:

  • run_id, tenant_id, namespace_id, submission_id
  • payload, content_type, submitted_at

Patrón 4: Flujo de Trabajo de Cumplimiento (Multi-etapa)

Utilice el orden de etapas más advance_to.kind = "linear" para pasar a la siguiente etapa en el orden especificado:

{
  "stage_id": "dev",
  "advance_to": { "kind": "linear" }
}

Utiliza branch cuando necesites diferentes destinos basados en el resultado de la puerta de enlace.

Patrón 5: Federación MCP (Proveedores Externos)

Cuándo usar: Fuentes de evidencia fuera de las integradas

Configuración (exacta):

[[providers]]
name = "git"
type = "mcp"
command = ["/usr/local/bin/git-provider"]
capabilities_path = "contracts/git.json"

[[providers]]
name = "cloud"
type = "mcp"
url = "https://cloud.example.com/rpc"
capabilities_path = "contracts/cloud.json"
allow_insecure_http = false
timeouts = { connect_timeout_ms = 2000, request_timeout_ms = 10000 }

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

Notas de Interoperabilidad (Runpack + Transcripciones)

checkedfiles en runpackexport vs runpack_verify

Cuando se llama a runpack_export con include_verification = true, el valor devuelto de report.checked_files refleja la verificación ejecutada antes de que artifacts/verifier_report.json se agregue al manifiesto. Para el mismo runpack, se espera que runpack_verify.report.checked_files sea exactamente +1 porque valida el manifiesto finalizado (incluyendo verifier_report.json).

Artefactos de Transcripción: Contrato vs Banco de Pruebas

  • DG runpack artifact artifacts/tool_calls.json is the canonical contract El artefacto de ejecución de DG artifacts/tool_calls.json es la superficie de contrato canónica y contiene registros de llamadas a herramientas de estado de ejecución solo con hash.
  • System-test artifact tool_transcript.json is raw client-side capture used El artefacto de prueba del sistema tool_transcript.json es una captura en el lado del cliente utilizada para diagnósticos y no es un artefacto de contrato de ejecución de DG.

Advertencia de Carga Sensible

scenario_submit.payload y scenario_trigger.payload se persisten en los registros de estado de ejecución y se exportan a runpacks por diseño. No coloque secretos en bruto en estos campos de carga útil.

Lista de verificación de implementación

  • La configuración valida (decision-gate config validate)
  • Los proveedores tienen archivos capabilities_path válidos
  • namespace.allow_default configurado correctamente para uso local únicamente
  • Autenticación + TLS (o tls_termination = "upstream") configurado para enlaces no loopback
  • trust.default_policy y min_lane configurados para producción
  • Política de divulgación de evidencia establecida (allow_raw_values, require_provider_opt_in)

Referencias cruzadas