ormuz
Decisions/Construire et tester

Construire, tester et observer une Decision

Decision Studio réunit la conception, la validation, l’exécution sur des jeux de données explicites et la lecture de trace. Une exécution utilisateur porte toujours l’identité d’une révision immuable.

Construire avec un contrat Ormuz

Commencez par définir les inputs et outputs. Ces contrats alimentent l’éditeur et son aide au typage, afin que les règles puissent référencer des champs métier connus plutôt que manipuler un JSON sans structure.

Le Studio limite également la palette aux primitives de décision prises en charge par Ormuz. Le JSON interne reste un format d’import, d’export et de diagnostic, pas la surface normale de conception.

Assistant IA de conception

L’assistant de Decision Studio peut expliquer la logique existante, proposer une modification, construire un candidat et vérifier son comportement avant de l’appliquer au brouillon visible.

Simulation de candidat ≠ Decision Run Les essais internes de l’assistant servent uniquement à valider son candidat. Ils ne créent ni révision persistée ni Run et ne disposent d’aucun droit implicite de résolution de ressources.

Tester une révision réelle

Une exécution utilisateur n’évalue pas directement un brouillon non persisté. Si le Working contient des changements, Decision Studio valide d’abord la définition et enregistre un nouveau snapshot immuable ; le Decision Run référence ensuite cette révision exacte.

Brouillon Working
Snapshot immuable après validation
Decision Run
Résultat + trace

Le brouillon est validé et figé avant l’exécution. Le Run possède donc toujours une identité de révision reproductible.

Pas d’exécution autoritative d’un brouillon non persisté La simulation interne de l’assistant est un outil de conception. Le bouton de test utilisateur suit, lui, le cycle de vie normal des révisions avant de créer un Run.

Données synthétiques ou objet existant

Une Decision évalue le snapshot JSON qui lui est fourni. Le moteur ne transforme pas un identifiant en droit de lecture et ne recharge pas implicitement les ressources référencées.

Source de testComportement
Données synthétiquesVous pouvez saisir ou générer des valeurs fictives conformes au contrat, y compris des objets plateforme ou d’extension structurellement valides.
Objet existantLa Console lit d’abord l’objet par son API normale, avec les droits du lecteur, puis injecte le snapshot retourné comme simple valeur d’entrée du Run.
La Decision n’acquiert pas un droit de lecture Posséder le droit d’exécuter une Decision ne donne aucun accès supplémentaire aux objets plateforme ou provider. La lecture d’un objet réel reste une opération séparée et autorisée par ses propres permissions.

Lire la trace

Une exécution peut demander une trace détaillée. Decision Studio projette alors le chemin évalué, les règles correspondantes ainsi que les inputs et outputs des éléments concernés dans l’éditeur afin de relier directement le résultat à la logique qui l’a produit.

Utilisez la trace pour expliquer une issue inattendue ou vérifier un cas limite. Pour une validation rapide du résultat final, une exécution sans trace évite le bruit supplémentaire.

Pour l’entrée synthétique 75 000, le test retourne standard et met en évidence la deuxième règle de la table.
Pour l’entrée synthétique 75 000, le test retourne standard et met en évidence la deuxième règle de la table. Agrandir

Decision Runs

Chaque Run conserve l’identité exacte de la révision évaluée, le snapshot d’input, le résultat, la durée et les informations de trace demandées. Une exécution peut répondre rapidement tout en restant identifiable comme un Run distinct.

Lorsqu’un processus évalue la même Decision, sa révision reste elle aussi explicite afin de conserver la reproductibilité de l’orchestration. Revenir au modèle général : Comprendre les Decisions.