Une trace que vous pouvez utiliser
L’étape, la version, le résultat et la catégorie d’échec sont enregistrés. Décidez quelles données utiles sont nécessaires au diagnostic, et comment elles sont protégées et conservées.
ENGINEERING / DESIGN NOTE 001
Une IA utile. Un contrôle explicite.
Des règles pour tout ce qui peut être spécifié. L’IA pour le travail linguistique qui bénéficie de l’interprétation. Et une limite visible entre préparation et action.
01 / ARCHITECTURE DE RÉFÉRENCE
Un workflow devant un agent autonome.
- 01Valider l’entrée
- 02Récupérer le contexte approuvé
- 03Interpréter ou préparer
- 04Vérifier la sortie
- 05Demander à la personne autorisée
- 06Agir et enregistrer
ENTRÉE → PRÉPARATION → AUTORITÉ → ACTION
- 01 / RÈGLES
Valider l’entrée
Vérifier les champs obligatoires, les types autorisés et les autorisations des sources. Rejeter ou retenir le travail incomplet.
- 02 / SOURCES
Récupérer le contexte approuvé
Utiliser un ensemble de sources délimité. Garder les versions des documents et les références attachées au résultat.
- 03 / AI-ASSISTED
Interpréter ou préparer
Extraire, classer, résumer ou rédiger là où le travail linguistique apporte de la valeur. Ne pas inventer les faits manquants.
- 04 / RÈGLES
Vérifier la sortie
Valider le schéma et les contraintes métier. Calculer les chiffres avec une logique déterministe.
- 05 / HUMAIN
Demander à la personne autorisée
Montrer ce qui a changé, les preuves à l’appui et l’action que la validation autorisera.
- 06 / CONTROLLED ACTION
Agir et enregistrer
N’exécuter que l’action validée. Enregistrer le résultat et gérer l’échec sans effets en double.
Architecture de référence pour une implémentation délimitée. Chaque étape a un parcours d’échec ; un prérequis manquant retient l’élément pour son responsable au lieu de continuer sur une hypothèse.
02 / INTERFACES STRUCTURÉES
Une réponse utile a un contrat.
Interface illustrative, pas une API en production. Les références de sources, la sortie proposée et l’autorisation d’agir circulent séparément. Une réponse de modèle ne peut pas s’accorder elle-même une validation.
Préparer n’est pas autoriser
Une ébauche reliée aux sources peut encore être erronée. La validation, la revue et l’autorité d’agir restent des étapes distinctes.
{
"request_id": "SYN-EXAMPLE-01",
"source_refs": [
"approved-source:v3:section-2"
],
"proposed_action": "prepare_draft",
"result_status": "needs_review",
"approval": {
"required": true,
"granted": false
},
"external_action_allowed": false
}03 / CAS D’ACCEPTATION
Tester plus que le cas idéal.
- Entrée attendue
La sortie convenue est produite et peut être retracée jusqu’à ses entrées.
- Résultat ambigu
Retenir pour revue ; l’incertitude ne devient pas silencieusement une validation.
- Informations manquantes
Demandez la source ou le champ manquant et conservez l'état incomplet.
- Entrée incorrecte
Rejeter les types, valeurs ou formats invalides avant une action en aval.
- Intégration non disponible
Enregistrer l’échec et utiliser un parcours convenu de nouvelle tentative ou d’escalade.
- Demande non sûre
Refuser les actions hors du workflow et du périmètre de données autorisés.
- Événement en double
Empêcher une nouvelle tentative de répéter une action externe à conséquences.
- Changement de source ou d'instruction
Réexécuter les cas de réception pertinents avant de publier la nouvelle version.
Cas de référence pour un plan de réception client. Les tests et preuves exacts sont convenus pour chaque implémentation.
04 / CONCEPTION OPÉRATIONNELLE
Quelqu’un doit l’exploiter demain.
Un responsable nommé
Quelqu’un doit porter les cas particuliers, les changements d’accès et la décision de reprendre. Une file d’attente sans personne responsable n’est pas un plan de reprise.
Un changement contrôlé
Les cas concernés sont retestés lorsqu’un modèle, une instruction, une source ou une intégration change. Une version précédente qui fonctionne et une procédure de reprise explicite restent disponibles.
05 / ÉLÉMENTS DE PREUVE À EXAMINER
Testez les limites vous-même.
Le Workflow Studio montre des arrêts de validation locaux, des réinitialisations, des cas particuliers, des données structurées et des traces d’événements. Les intégrations client, les nouvelles tentatives et la surveillance opérationnelle exigent leurs propres preuves d’implémentation et de réception.