Coroid utilise un moteur dédié Moteur de décision pour les questions ayant un ensemble connu de réponses. Le modèle initial est Jev 1.13, servi via OpenRouter. Il cohabite avec les modèles d'architecte, de développeur, de QA et de réviseur dans votre profil AI ; ce n'est pas un autre agent qui écrit du code ou appelle des outils.
Fonctionnement d'une décision
Coroid envoie l'état pertinent et un contrat de question versionné. Au lieu de demander à un modèle de chat d'inventer et de formater une réponse JSON, il fournit les choix autorisés. Jev renvoie alors une réponse structurée ainsi que des informations sur la probabilité.
- Choix sélectionne une option fournie, avec une distribution de probabilités et un niveau de confiance.
- Score évalue les critères ordonnés fournis, avec des probabilités et un niveau de confiance.
- Noul exprime un jugement oui/non sous forme de probabilité entre zéro et un.
Coroid valide la réponse par rapport au contrat exact, vérifie le niveau de confiance et les règles de flux de travail avant de l'utiliser. Si la réponse est incertaine, invalide ou indisponible, c'est l'évaluateur de flux de travail existant qui gère la décision.
Contrat de question
État pertinent ainsi que les réponses autorisées
Comment ce critère d'acceptation peut-il être vérifié ?
Réponse structurée
Une probabilité pour chaque choix autorisé
Validation
Contrat, confiance et règles de workflow
Où il est utilisé
| Flux de travail | Décision | Ce qui reste inchangé |
|---|---|---|
| Preuves d'acceptation | Classer un critère comme visuel, commande, statique ou non vérifiable | La vérification doit toujours s'exécuter et produire des preuves. |
| Pré-vérification QA | Classer une défaillance, évaluer sa réparabilité et identifier les chemins pertinents à partir des journaux fournis | Les correctifs, tests et approbation QA restent distincts. |
| Qualification du travail | Évaluer la pertinence pour la version actuelle, les doublons, la reproductibilité et le routage | Un doublon doit faire référence à un candidat fourni ; un élément déjà corrigé nécessite des preuves fournies. |
| Routage des tâches | Classer le type et la complexité du travail, puis sélectionner parmi les compétences compatibles | Le type de travail explicite, les surcharges de modèle, les budgets et la sélection de profil sont préservés. |
Le moteur ne génère pas de plans d'implémentation, de correctifs, de preuves arbitraires, de nouveaux chemins de fichiers ou d'explications pour les réviseurs. Les nœuds de qualification avec une sélection de modèle explicite conservent cette sélection au lieu d'utiliser Jev.
Configurer votre profil
- Ouvrir Paramètres → AI profile et sélectionnez un profil adapté pour les nouveaux travaux.
- Budget, Smartest, Quick et Ludicrous incluent une affectation du moteur de décision Jev.
- Dans un profil personnalisé modifiable, affectez Jev 1.13 à moteur de décision. Les modèles de Chat sont exclus de ce rôle, et Jev est exclu des rôles d'agents de Chat.
- Assurez-vous qu'OpenRouter est activé et qu'une clé de fournisseur d'organisation éligible est disponible. Les politiques de modèle d'organisation et de projet restent applicables.
Il n'existe aucun réglage de température, de raisonnement ou de fallback de Chat pour ce rôle. Le fallback consiste à revenir à l'évaluateur existant du workflow, et non à envoyer une demande de décision à un modèle de Chat arbitraire.
Les profils gratuits et soumis à des restrictions de résidence ne se voient pas automatiquement attribuer un modèle OpenRouter payant. Les profils personnalisés existants ne sont pas modifiés silencieusement. Les instantanés d'exécution conservent leurs affectations d'origine ; commencez donc de nouveaux travaux après avoir modifié un profil pour tester la nouvelle affectation. Consultez Profils AI.
Activation et fallback sécurisé
L'activation à l'exécution est contrôlée par la base de données, séparément pour chaque workflow. La classification d'acceptation, le pré-lancement QA, la qualification et le routage de tâches utilisent par défaut les décisions de Jev. Les sept contrats de la version 1 actuelle sont approuvés.
Même lorsqu'il est activé, Coroid bascule sur le fallback si le profil ne dispose pas de modèle de décision éligible, si les identifiants ou la politique bloquent l'accès, si la demande dépasse la taille prise en charge, si le fournisseur rencontre un timeout ou si une réponse échoue aux vérifications de validation ou de confiance. Une décision non prise en charge ou ambiguë ne doit pas être considérée comme une validation réussie sans notification.
Les opérateurs peuvent utiliser désactivé, en mode ombrage ou appliqué les modes. Le mode ombrage enregistre une comparaison tout en conservant le résultat de l'évaluateur existant ; le mode appliqué utilise une décision validée issue d'un contrat approuvé. Une nouvelle version de contrat nécessite toujours une approbation avant de pouvoir contrôler un workflow. Ces contrôles d'exécution ne masquent ni ce guide ni la description publique du produit.
Utilisation et journaux d'audit
Les appels utilisent la même sélection de clé de fournisseur, les mêmes vérifications de politique d'organisation et la même comptabilisation de l'utilisation que les autres traitements de modèles, attribués au rôle de moteur de décision. Les réponses facturées sont enregistrées même si leurs réponses sont rejetées. BYOK suit les conditions de facturation du fournisseur ; aucune clé Typesafe distincte n'est requise.
L'enregistrement de la décision opérationnelle comprend le workflow, la version du contrat, la révision du modèle réel, les probabilités, le fait que le résultat ait été appliqué, la raison du fallback, la latence de la décision et la corrélation d'utilisation. Il stocke un résumé de l'état d'entrée, et non la demande brute ou les identifiants. La rétention suit la politique de journal d'agent de l'organisation. Cet enregistrement d'audit est distinct d'une explication générée ou d'un rapport de test.
Tester en local
Utilisez une nouvelle tâche avec un profil incluant Jev. Exercez la planification d'acceptation, le pré-lancement QA avec un échec connu, la qualification du travail et le routage normal de tâches. Vérifiez dans l'audit de décision s'il y a un mode appliqué et un résultat appliqué. Une entrée de fallback explique pourquoi Jev n'a pas contrôlé cette décision en particulier ; ce n'est pas la preuve que le workflow a échoué. Les tâches existantes peuvent avoir un instantané de profil sans Jev.