Un mandato es un artefacto, no una opción de configuración.
La delegación acotada es una capacidad dentro de Execution Authorization, no una categoría propia. Un Task Contract enmarca la cadena; no reemplaza ninguna de sus piezas. Cada paso sigue produciendo su propio Execution Grant de un solo uso y su propio Action Receipt.
Diseño
TaskContractV1
El contrato vincula, en un único objeto firmado: el tenant, los actores habilitados a actuar bajo él, el Guardian y la audiencia a la que está dirigido, la revisión, los pasos, sus restricciones, el presupuesto y sus unidades, la ventana de vigencia, la política y el manifiesto en vigor, y el contador de revocación.
taskId · revisionIdentidad y versión. Un contrato aprobado no se edita en el lugar: cualquier cambio en un paso produce una revisión nueva que hay que volver a revisar.
tenant · guardianId · audienceDe quién es y qué único punto de ejecución puede consumirlo. Un mandato se dirige a un Guardian.
actors[]Cada actor vincula un identificador con una clave y su thumbprint. Un paso se reclama probando posesión de esa clave contra un desafío fresco, consumido de forma atómica.
authorityLa fija el protocolo por operación. Quien llama no la elige ni puede degradarla dentro del mismo pedido, y un mandato aprobado nunca baja el umbral de un paso.
steps[]Cada paso nombra su operación canónica, su proveedor, su lista de recursos, el digest de sus parámetros exactos, y lleva maxUses fijado en uno.
budgetDurable y atómico por tenant, tarea, revisión y paso. Comprometido significa consumido más lo reservado cuyo resultado está pendiente o es incierto, así un grant no puede reservar dos veces.
issuedAt · expiresAtLa ventana. Después no se envía ningún paso nuevo; no hay período de gracia ni renovación desde adentro de la tarea.
policyVersion · revocationVersionLa política local firmada en vigor y el contador de revocación. Si el almacenamiento o la revocación no están disponibles, no salen efectos nuevos.
La intersección sigue rigiendo
permiso efectivo = mandato ∩ grant ∩ política local firmada ∩ restricciones del adaptador ∩ presupuesto ∩ identidad ∩ vigencia y revocación
La nube nunca amplía el techo local. Un mandato es un término más de la intersección, jamás una forma de esquivarla, y el Guardian los aplica todos antes de contactar a un proveedor.
Máquina de estados
Una tarea ocupa exactamente un estado, y el ledger registra la transición, no la intención.
- draft
- approved
- running
- paused
- completed
- revoked
- expired
Exclusiones deliberadas
- Sin subdelegación. Un mandato, un Guardian, un presupuesto; una tarea no puede ceder una parte de sí a otro actor ni levantar un segundo punto de ejecución.
- Sin efectos abiertos. Un paso sin operación canónica y sin digest de parámetros no es un paso.
- Sin autorización permanente. Todo mandato vence, y el vencimiento no se renueva desde adentro de la tarea.
- Lo que el actor lee — documentos, salida de herramientas, contenido web, memoria — es entrada, nunca autoridad. No puede extender el contrato.
- El adaptador determina el efecto canónico y el preestado. No se acepta como verdad el resumen de un agente, un schema de sólo lectura ni un destino tomado del contenido.
El rol del lector
El lector local es explicativo. En este perfil un hallazgo aislado, una abstención, una no evaluación o una lectura parcial no bloquean, revocan ni fuerzan aprobaciones adicionales sobre un efecto exacto ya aprobado y permitido. La autoridad nunca se eleva para compensar una alerta, y nunca se baja porque no haya aparecido ninguna. Identidad, firma, presupuesto, precondición y revocación siguen fallando cerrado: esto no es permiso para ejecutar sin controles.
Estado
Diseño. El esquema y sus invariantes existen y están cubiertos por tests. Ningún mandato delegado se ejecutó contra un proveedor real, así que este perfil queda etiquetado como simulado. Un resultado nunca se extrapola desde un mock ni desde otro conector, y un conector heredado probado con MFA o quórum no acredita la delegación de varios pasos.
Preguntas abiertas
Los detalles de canonicalización, los límites de tamaño y cantidad, el manejo del reloj y el rechazo de campos desconocidos se fijan antes de construir cualquier runtime, y se publican como vectores de prueba versionados junto al verificador. El verificador sale antes que el perfil: no se emite nada que todavía no se pueda verificar de forma independiente.