Contrato de Integración de Decision Gate + Asset Core

Resumen

Este documento es el contrato canónico, listo para implementación, para integrar Decision Gate (DG) con Asset Core (ASC). Define los límites, la autoridad y la semántica de evidencia necesarias para preservar la independencia mientras se permite una superposición de alta confianza.

Intención de diseño: DG sigue siendo un plano de control independiente. ASC sigue siendo un sustrato de estado mundial independiente. La integración es opcional y explícita.

Límites No Negociables

• Sin acoplamiento de código: DG no se vincula con crates de Asset Core ni comparte APIs internas.
• Sin control de ruta de escritura (v1): DG no debe estar en las rutas de escritura de ASC.
• Fronteras de confianza que fallan cerradas: Los espacios de nombres faltantes o no autorizados deben denegar.
• Determinismo primero: Las mismas entradas producen salidas idénticas y paquetes de ejecución.

Autoridad de Espacio de Nombres

Fuente de Verdad

• Despliegues integrados: el catálogo del espacio de nombres ASC es autoritativo.
• Standalone DG deployments: DG registry is authoritative. Despliegues independientes de DG: El registro de DG es autoritativo. Dev-permissive está prohibido cuando namespace.authority.mode = "assetcore_http".

Reglas de Validación

• DG must validate namespace_id for every namespace-scoped tool call, DG debe validar namespace_id para cada llamada de herramienta con ámbito de espacio de nombres, incluyendo consultas de evidencia.
• Espacio de nombres desconocido -> fallo cerrado.
• Catálogo inalcanzable -> fallo cerrado.

Reglas de ID de Namespace

• DG acepta solo identificadores de espacio de nombres numéricos (>= 1).
• La validación de la autoridad de Asset Core es directa; no hay tabla de mapeo ni traducción.

Mapeo de Autenticación/RBAC

Capa de Integración

DG no debe analizar los tokens ASC ni compartir los detalles internos de autenticación ASC. Una capa de integración estrecha verifica la autenticación ASC y reenvía un PrincipalContext mínimo:

• id_de_inquilino
• principal_id
• roles
• policy_class
• grupos

Postura Predeterminada

Los valores predeterminados de autenticación son conservadores: no se permite la creación de escenarios ni la escritura en el registro a menos que se otorgue explícitamente en la matriz de mapeo.

Matriz de Mapeo (Predeterminada)

La capa de integración mapea los roles de ASC + la clase de política en una lista blanca de herramientas DG. Este mapeo es fail-closed: los roles faltantes o desconocidos no otorgan acceso.

Grupos de herramientas DG (referencia):

• Autorización: scenario_define, schemas_register
• Run operations: scenario_start, scenario_trigger, scenario_next, Ejecutar operaciones: scenario_start, scenario_trigger, scenario_next, scenario_submit, precheck
• Read-only: scenario_status, scenarios_list, schemas_list, schemas_get, providers_list, provider_contract_get, Solo lectura: scenario_status, scenarios_list, schemas_list, schemas_get, providers_list, provider_contract_get, provider_check_schema_get, evidence_query, decision_gate_docs_search
• Auditoría: runpack_export, runpack_verify

Asignación predeterminada (recomendada):

Rol ASC	Restricción de Clase de Política	Grupos de Herramientas DG
TenantAdmin	Ninguna	Autorización + Operaciones de ejecución + Solo lectura + Auditoría
NamespaceOwner	Ninguna	Autorización + Operaciones de ejecución + Solo lectura + Auditoría
NamespaceAdmin	Ninguna	Autorización + Operaciones de ejecución + Solo lectura + Auditoría
NamespaceWriter	Ninguna	Operaciones de ejecución + Solo lectura + Auditoría (solo verificación)
NamespaceReader	Ninguna	Solo lectura + Auditoría (solo verificación)
SchemaManager	Solo Scratch, Proyecto	Autorización (solo esquemas) + Solo lectura
AgentSandbox	Solo Scratch	Operaciones de ejecución + Solo lectura
NamespaceDeleteAdmin	Ninguna	Solo lectura

Aplicación de la clase de política:

• If policy_class is prod, SchemaManager and AgentSandbox do not Si policy_class es prod, SchemaManager y AgentSandbox no otorgan ningún permiso DG (ASC ya restringe estos roles).
• policy_class desconocido o faltante -> denegar.

Nota de auditoría: runpack_verify es seguro permitirlo de manera amplia; runpack_export debe estar restringido a roles de administrador/propietario a menos que se otorgue explícitamente.

Registro ACL (DG Interno)

El acceso al registro de esquemas se aplica mediante una capa de ACL interna de DG que se ejecuta después de la lista blanca de herramientas de la capa de integración. Esto está intencionadamente separado:

• El mapeo RBAC (integración) decide qué herramientas son invocables.
• Registry ACL (DG) decides who may schemas_register/list/get per Registro ACL (DG) decide quién puede schemas_register/list/get por inquilino/nombre de espacio, utilizando principios y metadatos de clase de política.

Valores predeterminados de ACL integrados:

• Leer: NamespaceReader+ dentro del espacio de nombres.
• Escribir: NamespaceAdmin/TenantAdmin únicamente.
• SchemaManager solo puede escribir cuando policy_class no es de producción.

Las implementaciones de integración no deben asumir que las listas de herramientas permitidas implican permiso de escritura en el registro; ambas capas deben permitir la operación.

Anclajes de Evidencia (Canon ASC)

Todo el respaldo de evidencia de ASC debe incluir los siguientes anclajes:

• assetcore.namespace_id
• assetcore.commit_id
• assetcore.world_seq

Ancla de actualización opcional:

• assetcore.chain_hash (cuando ASC habilita el hash de cadena)

Estos anclajes deben ser capturados en runpacks y utilizados por la verificación offline.

Contrato de Proveedor de Evidencia

Entradas Requeridas

• namespace_id (DG)
• Identificador de espacio de nombres ASC (mapeado o numérico)
• Verificar parámetros (container_id, class_id, etc.)

Salidas Requeridas

• Valor de evidencia o hash
• Hash de evidencia (JSON canónico)
• Ancla de evidencia (ancla ASC establecida arriba)
• Tipo de contenido
• Clase de determinismo (debe ser determinista para lecturas ASC)

Límites y Fallos

• Tiempos de espera estrictos; reintentar solo en errores de transporte.
• Tiempo de espera o error del proveedor -> Desconocido (fallo cerrado).

IDs de correlación

Requisitos de Extremo a Extremo

• DG debe propagar el ID de correlación del cliente a las consultas de evidencia de ASC.
• DG debe emitir identificadores de correlación del servidor en los registros de auditoría y en los runpacks.
• Los IDs de correlación se registran y capturan en las transcripciones de la herramienta.

Sanitización

Los IDs de correlación proporcionados por el cliente son inseguros y se validan estrictamente en la entrada. Los valores inválidos son rechazados; solo los IDs sanitizados se propagan a los proveedores de ASC. Los IDs de correlación emitidos por el servidor siempre están presentes para las auditorías.

Verificación de Runpack

La verificación de Runpack debe confirmar:

• Todas las entradas de evidencia ASC incluyen anclajes requeridos.
• Los valores de anclaje están bien formados y coinciden con el esquema esperado.
• El assetcore.chain_hash opcional está presente cuando se configura como requerido.

Fuera de Alcance (v1)

• Control de la ruta de escritura de ASC por DG.
• Creación de espacio de nombres ASC desde DG.
• Mutación de estado ASC a través de DG.