Decision Desk | Developer Docs

Le Decision Desk (/approvals-inbox) est l'endroit où les personnes prennent les décisions que les machines ne devraient pas prendre seules. Lorsque le KLA Policy Engine renvoie une décision require_approval, l'action de l'agent ne se poursuit pas. L'exécution se met en pause et KLA ouvre une Escalation, un objet d'intervention manuelle qui réunit tout ce dont un relecteur a besoin pour agir. L'élément de travail que le relecteur finit par traiter est une Decision Request. Le Decision Desk est à la fois la file d'attente, la surface de relecture et l'enregistrement d'audit pour chacun de ces moments.

Cela compte parce que require_approval est l'un des quatre résultats de politique de KLA, par ordre de priorité : allow, warn, require_approval, block. Les deux premiers laissent le travail se poursuivre ; block l'arrête net. Seul require_approval confie la décision à un humain, et le Decision Desk est l'endroit où cet humain se trouve.

ℹ️ Note

Le Decision Desk ne crée pas les règles ; celles-ci résident dans **Policy Builder**. C'est la destination d'exécution des actions qu'une politique a délibérément acheminées vers des personnes au lieu de les résoudre automatiquement.

Comment une Escalation parvient au Decision Desk

flowchart LR
  A["Action d'agent"] --> B{"Décision de politique"}
  B -->|allow / warn| C["Continuer"]
  B -->|block| D["Arrêter"]
  B -->|require_approval| E["Ouvrir une Escalation"]
  E --> F["File du Decision Desk"]
  F --> G{"Le relecteur agit"}
  G -->|approve| H["Reprendre l'exécution"]
  G -->|deny| I["Terminer l'exécution"]
  G -->|re-route| J["Relecteur senior"]
  J --> G

L'exécution de l'agent est suspendue, et non échouée, pendant que l'Escalation attend. L'agent instrumenté (via le Govern in Place SDK) ou le proxy géré (Run through KLA) se bloque sur la décision en attente, de sorte qu'aucun effet de bord ne se produit tant qu'une personne ne l'a pas résolue.

Traiter la file d'attente

La boîte de réception est conçue pour le tri à grand volume. Les relecteurs filtrent et trient selon quatre dimensions :

Dimension	Ce qu'elle fait
Priorité	Fait remonter les Escalations critiques avant les relectures de routine proches de `warn`.
Équipe	Achemine les éléments vers la bonne file (tri des sinistres, approbation des remboursements, relecture de documents) pour que la finance ne voie jamais le travail du juridique.
Agent	Isole chaque action en attente provenant d'un même agent, utile lorsqu'un agent se comporte de façon inattendue.
État	Sépare les Decision Requests ouvertes de l'historique résolu pour l'audit et l'analyse des tendances.

Les règles d'acheminement sont déclarées dans la politique, de sorte qu'une Escalation atterrit par défaut devant l'équipe qui détient ce risque plutôt que dans une pile partagée.

Relire une Decision Request

L'ouverture d'un élément donne aux relecteurs tout le contexte derrière l'action mise en pause, sans changer d'outil ni deviner :

Prompt et instructions : l'entrée qui a déclenché l'action, y compris genai.system.instructions, de sorte que le relecteur voit ce que l'agent était censé faire.
Charge utile de l'outil : le genai.tool.name et les genai.tool.parameters exacts que l'agent comptait invoquer (le montant du remboursement, l'enregistrement à écrire, le document à envoyer).
Règle déclenchante : la politique précise qui a renvoyé require_approval, avec ses codes de raison, de sorte que la décision repose sur un contrôle nommé et non sur une intuition.
Lien de traçabilité : un accès direct vers Lineage Explorer pour rejouer le Lineage Record complet menant à cette étape.

À partir de là, le relecteur effectue l'une des trois actions suivantes :

Approuver : lève la suspension ; l'agent reprend exactement là où il s'était mis en pause.
Refuser : termine l'exécution ; l'action ne s'exécute jamais.
Réacheminer / escalader : confie la Decision Request à un relecteur plus senior ou à une autre équipe sans perdre le contexte.

SLA et l'angle de l'audit

Chaque Decision Request comporte une dimension temporelle. Les relecteurs voient depuis combien de temps un élément attend, et les Escalations en retard ressortent par rapport à leur objectif de niveau de service, de sorte que rien ne pourrit dans la file. Ce suivi du temps fait partie de l'enregistrement, et n'est pas qu'une commodité opérationnelle.

🛡️ Important

Chaque décision est une preuve. Chaque approbation, refus et réacheminement est capturé sous forme de span OpenTelemetry, expurgé par le KLA Collector et écrit dans le registre cryptographique ImmuDB. Le relecteur, l'action, la règle déclenchante et l'horodatage alimentent tous les **Sealed Evidence Bundles** et les **Control Packs**.

Le résultat est une réponse défendable à la question la plus difficile de l'auditeur, qui a approuvé ceci, sur quelle base et quand, sans que personne n'ait à la reconstituer après coup. Le jugement humain devient une partie inviolable et de premier ordre de l'enregistrement de gouvernance.

💡 Tip

Associez le Decision Desk à l'**Assurance Center**. Un taux croissant d'Escalations `require_approval` sur un même agent est souvent une **Assurance Alert** précoce, un signal pour revoir la politique ou l'agent avant que les relecteurs ne soient submergés.