Modèles de décision

A decision model answers typed questions about an event instead of generating text. An SOP can ask one, after its trigger matches and before a run starts:

Un modèle de décision répond à des questions typées sur un événement au lieu de générer du texte. Une SOP peut en poser une, après que son déclencheur a correspondu et avant le démarrage d’une exécution :

• Porte : cet événement doit-il déclencher cette SOP ?
• Mode : lequel des modes d’exécution listés par l’auteur correspond à cette exécution ?

Cela permet à un même déclencheur (un chemin de webhook, un canal, un sujet MQTT) d’alimenter plusieurs SOP, le modèle décidant à laquelle d’entre elles l’événement est réellement destiné et le niveau de supervision humaine accordé à chaque exécution.

ZeroClaw parle l’API de décision typée « System One » (POST <base_url>/v1/systemone). Deux modèles l’implémentent :

Configurer les modèles

Déclarez chaque modèle sous un alias dans config.toml et choisissez son provider :

[decision_models.jev]
provider = "jev"
# api_key est un secret ; définissez-le avec `zeroclaw config` ou
# ZEROCLAW_decision_models__jev__api_key.

[decision_models.laya]
provider = "laya"

[decision_models.gpu_box]
provider = "custom"
base_url = "http://10.0.0.5:8000"
model = "laya"

base_url et model remplacent les valeurs par défaut du fournisseur. Une entrée custom sans base_url est ignorée, et les SOP qui la sélectionnent reviennent à leur mode le plus strict. Les alias peuvent également être gérés depuis la page Config du tableau de bord.

Sélectionner un modèle dans une SOP

Dans l’éditeur de SOP du tableau de bord web, cochez Modèle de décision sous Mode d’exécution, puis choisissez un modèle configuré dans la liste déroulante ; la barrière, les modes et les seuils se modifient dans le même panneau. L’enregistrement refuse une table [decision] invalide et indique la raison.

Dans un SOP adossé à un fichier, ajoutez une table [decision] à SOP.toml et nommez l’alias :

[decision]
model = "jev"
gate = "Le client demande-t-il un remboursement ?"
gate_threshold = 0.7
modes = ["auto", "supervised", "step_by_step"]
mode_instructions = "auto : moins de 50 $ et routinier. step_by_step : plus de 500 $, menaces juridiques, ou tout cas inhabituel."
min_confidence = 0.7

Un tableau [decision] nécessite un gate, modes, ou une étape avec decide. modes ne peut pas être utilisé avec une SOP déterministe.

Étapes conditionnelles

Une étape peut porter sa propre question oui/non. Le modèle y répond dans la même requête que la porte et le mode, si bien qu’un seul appel détermine quelles étapes un run inclut. Cela permet de composer une SOP à partir de pièces distinctes, au lieu de la découper en plusieurs SOP qui demandent chacune au modèle s’il faut démarrer.

## Steps

1. **Hold for a maintainer** - Draft a comment that tags a maintainer to decide on scope.
   - decide: Does this PR add a new feature outside the roadmap and existing features?

2. **Security review** - Review the auth, secret, and sandbox changes.
   - decide: Does this PR touch authentication, secrets, or sandboxing?
   - unless_decided: 1

3. **Test review** - Check that the changed behavior is tested.
   - decide: Does this PR change runtime behavior?
   - unless_decided: 1

4. **Compose the review** - Combine the findings into one review comment.
   - unless_decided: 1

• - decide: <question> exécute l’étape uniquement lorsque la probabilité de réponse « oui » atteint part_threshold.
• - unless_decided: N ignore l’étape lorsque la question de l’étape N a reçu la réponse oui. L’étape N doit comporter une question decide.
• Une étape ignorée est enregistrée avec le statut skipped ainsi que la raison, et l’exécution se poursuit avec l’étape suivante dans l’ordre. L’étape suivante reçoit l’entrée que l’étape ignorée aurait reçue.
• Lorsque le modèle ne peut pas répondre, ou répond à la question d’une étape par une valeur mal formée, cette étape est exécutée. Ignorer l’étape n’est jamais la solution de repli sûre.
• Les gardes de routage peuvent lire les réponses : $.decisions.2 correspond à la probabilité « oui » de l’étape 2 dans une condition when:.
• Une autre étape ne peut pas utiliser depends_on sur une étape conditionnelle, car une étape ignorée ne produit aucune sortie. Lisez plutôt $.steps.N dans une condition when:.
• Une étape ignorée avant sa barrière d’approbation ne demande jamais d’approbation.

Sécurité

• Le modèle ne choisit que parmi ce que l’auteur a écrit. Il ne peut pas ajouter de déclencheurs, choisir un mode non listé, ni sélectionner priority_based ou deterministic.
• A mode choisi s’applique uniquement à cette exécution et est enregistré avec celle-ci, de sorte qu’il est conservé après un redémarrage. Le requires_confirmation au niveau des étapes et les points de contrôle continuent de bloquer l’exécution quel que soit le mode choisi.
• Échec fermé : un alias non configuré, une erreur réseau ou HTTP, une réponse malformée ou une réponse à faible confiance ne réduit jamais la supervision. L’exécution utilise le mode le plus strict parmi ses modes listés, son execution_mode rédigé et supervised.
• Les charges utiles des événements sont envoyées au modèle en tant que contenu non fiable, limitées à 8 000 caractères. Choisissez un modèle auto-hébergé lorsque le contenu des événements ne doit pas quitter l’hôte.

Chaque décision est enregistrée avec le nom de la SOP, le résultat, le mode choisi, la réponse à chaque étape conditionnelle et le nombre de jetons d’entrée.