Exemple simulé · Exemple rempli · pas une référence client
Simulation locale — issue inconnue
La forme d’une fiche de diagnostic, remplie sur un dossier simulé. Aucun client n’est représenté.
Sources et contexte de lecture
dossier local du démonstrateur TENIR/REG, figé ; preuves #5 et #6 ; préparé le 20 octobre 2026
Rendu public simplifié, lecture du 19 octobre 2026. KB3 : ligne de rendu doctrinale instituée et active. Elle rend le sens ; elle n’est pas le code, ni une constitution. KB2 : ligne antérieure. Ce site ne certifie aucune implémentation. Lire le statut détaillé →
Sur cette page
Exemple simulé — données fictives. Fiche illustrative préparée le 20 octobre 2026 à partir du dossier du démonstrateur TENIR/REG. Aucun client, entretien, incident réel ou gain commercial n’est représenté. La fiche est rédigée à la main. Les recommandations ne sont pas des résultats signés du moteur. Un essai de ce démonstrateur ne démontre pas le système d’un client.
La synthèse illustre la fiche remise à l’issue du service décrit sur l’offre. Les annexes explicitent ses sources et les limites de l’exemple. PASS, ici, est un verdict d’exécution. Ce n’est pas une posture. Ce cas montre une issue UNKNOWN après un PASS. Il ne montre pas un nouveau verdict HOLD.
Fiche de synthèse
| Rubrique | Fiche remplie |
|---|---|
| Action examinée | L’opération issue-inconnue demande au fournisseur simulé une action de 10 000 demo-unit. Cette unité représente un budget de démonstration. |
| Question | Les traces confirment-elles le résultat de l’action ? Quelle information faudrait-il obtenir avant d’envisager une nouvelle tentative dans un système intégré ? |
| Périmètre | Une opération du profil tenir-reg-local-demo/0.1.0, en mémoire et dans un seul processus. Lecture des preuves #5 et #6 et du journal simulé. |
| Décision initiale | PASS à la preuve #5 : budget et observation jugés valides par le profil local. L’état enregistré est alors DISPATCHING. |
| Envoi enregistré | La preuve #6 contient un appel du fournisseur simulé pour cette opération : call_id=2. C’est un appel pour cette opération, dans un journal de deux appels cumulés. |
| Résultat enregistré | UNKNOWN à la preuve #6. Le PASS initial demeure une décision historique. Il ne confirme pas l’effet. La branche UNKNOWN est imposée par le scénario simulé. |
| Ressource | 10 000 réservés, 20 000 consommés, 40 000 disponibles, pour un plafond de 70 000 demo-unit. Les 20 000 consommés proviennent d’une opération antérieure confirmée. |
| Observation | Signal demo-observation-1, statut VERIFIED, émis par demo-assure pour demo-budget. Il est valide au temps figé de ce scénario. |
| Conclusion | Le dossier établit ce que le simulateur a enregistré : autorisation, appel et issue inconnue, avec maintien de la réservation. Il ne permet pas de conclure à un effet externe confirmé. |
| Information manquante | Dans un système intégré : un état faisant autorité sur l’effet attendu, relié sans ambiguïté à l’identité de l’opération. Aucun service externe de ce type n’est interrogé dans cet exemple. |
| Prochain contrôle proposé | Définir puis éprouver, dans un environnement d’essai, la recherche de l’effet par identifiant stable. Conserver l’incertitude tant que le résultat obtenu ne suffit pas à conclure. |
| Responsabilité et échéance | Rôle proposé : responsable de l’intégration du système destinataire, avec validation du propriétaire métier. Nom et date à convenir pour une mission réelle. Aucun engagement client n’existe dans cet exemple. |
| Critère observable du prochain essai | Une réponse positive, une absence d’enregistrement et une réponse indisponible sont distinguées. La règle précise, pour chacune, la conclusion permise, le traitement de la réservation et l’autorité de reprise. Une simple absence d’enregistrement ne vaut pas échec définitif sans contrat qui le garantit. |
Entrées utilisées
- Le dossier de preuves figé, son reçu signé, les clés publiques de preuve et de signal, le résumé de vérification et les résultats d’essais du démonstrateur.
- Les preuves #5 et #6, le profil local, les budgets avant et après, et le journal du fournisseur simulé.
- La recette déjà enregistrée dans les résultats d’essais. Son existence est contrôlée avec le dossier. Elle n’est pas une campagne d’essais réalisée chez un client.
Le reçu liste huit fichiers et porte go_local=true, production=false. Le résumé de vérification porte valid=true, 6 enregistrements, 4 opérations, 2 appels. Les clés fournies permettent de vérifier la cohérence cryptographique du dossier local. Elles n’établissent pas à elles seules une autorité externe.
Trois fichiers nommés par le reçu ne sont pas republiés ici : le catalogue de configuration, le configurateur et le rapport HTML. Leur volume est celui d’un outil de démonstration, et leurs empreintes restent dans le reçu. Le chemin local d’où le dossier a été copié n’est pas publié. Cette page ne rejoue pas le vérificateur.
Le temps 1792404000, soit le 19 octobre 2026 à 10:00:00 UTC, est l’horloge figée du scénario. Il ne décrit pas une date réelle d’incident ou de génération du dossier.
Sources des constats
Les chemins ci-dessous sont des JSON Pointers à partir de la racine de evidence.json. L’index 4 correspond à la preuve #5. L’index 5 correspond à la preuve #6.
| Réf. | Constat | Source exacte | Nature |
|---|---|---|---|
| S1 | Autorisation PASS avant envoi | /records/4/payload/decision/verdict | Payload signé, #5 |
| S2 | Motif BUDGET_AND_OBSERVATION_VALID | /records/4/payload/decision/reasons/0 | Payload signé, #5 |
| S3 | Observation VERIFIED | /records/4/payload/request/signal/payload/status | Payload signé, #5 |
| S4 | Budget avant et après réservation | /records/4/payload/budget_before et /records/4/payload/budget_after | Payload signé, #5 |
| S5 | Résultat UNKNOWN | /records/5/payload/operation_state | Payload signé, #6 |
| S6 | Appel call_id=2, opération issue-inconnue | /records/5/payload/provider_journal/1 | Payload signé, #6 |
| S7 | Réservation conservée à 10 000 | /records/5/payload/budget_after/reserved | Payload signé, #6 |
| S8 | Verdict historique PASS conservé | /records/5/payload/decision/verdict | Payload signé, #6 |
| S9 | Scénario explicitement simulé | /records/5/payload/simulation_only et /records/5/payload/request/simulated_outcome | Payload signé, #6 |
Les nombres d’appels sont des calculs de lecture du journal de la preuve #6 : sa longueur vaut 2 ; le filtrage par operation_id=issue-inconnue donne 1. Ils ne sont pas présentés comme des champs de compteur distincts du payload.
Contrôles observés, questions ouvertes
| Axe | Configuration et portée observées | Ce qui reste à instruire pour un autre système |
|---|---|---|
| Périmètre d’exécution | mono-process | Comportement après interruption et entre plusieurs processus. |
| Prévention des doublons | local-registry, registre local en mémoire | Identité stable, persistance et contrat du destinataire. Les deux preuves ne démontrent pas une idempotence générale. |
| Coordination | thread-lock | Coordination entre instances si le déploiement en utilise plusieurs. |
| Observation insuffisante | fail-closed pour le profil local | Sources, fraîcheur et traitement d’une observation indisponible dans le système cible. |
| Issue après envoi | UNKNOWN avec réservation conservée | Source faisant autorité, règles de rapprochement, et décision humaine ou technique de reprise. |
L’arrêt avant envoi et l’incertitude après envoi doivent rester distingués.
Plan de suite illustratif
| Priorité | Action proposée | Preuve attendue | Condition de clôture |
|---|---|---|---|
| 1 | Définir la source faisant autorité sur l’effet et son lien avec l’identité de l’opération. | Contrat de recherche et exemples de réponses positive, absente et indisponible. | L’équipe sait dire quelle réponse permet quelle conclusion, et quand l’état doit rester inconnu. |
| 2 | Définir le traitement de la réservation et l’autorité de reprise. | Tableau des transitions, responsabilités et critères d’essai. | Chaque transition est justifiée. Aucune libération de réservation ou nouvelle tentative ne découle d’une simple supposition de résultat. |
| 3, si une mission exige la reprise après arrêt | Concevoir la persistance et la prévention des doublons aux frontières du système. | Essais d’interruption et de reprise convenus dans un environnement borné. | Le dossier d’essai décrit les états retrouvés et les appels observés aux points d’interruption choisis. |
Ce plan est une interprétation documentaire. Aucune réconciliation, relance, modification du moteur ou intégration n’a été exécutée pour le produire.
Réception de l’exemple
| Critère | État de cette illustration |
|---|---|
| Périmètre et question explicites | Renseignés dans la fiche. |
| Constats traçables | Sources S1 à S9 et dossier figé consultables. |
| Autorisation, appel, résultat et budget séparés | Présentés distinctement. Unités et portée des compteurs précisées. |
| Inconnues et conséquences explicites | Effet externe non établi. Information à rechercher nommée. |
| Prochain contrôle observable | Critère proposé dans la fiche et détaillé dans le plan. |
| Responsable, date et validation par le client | À convenir lors d’une mission réelle. L’exemple ne simule pas une réception ou une approbation client. |
Empreintes
Les empreintes ci-dessous sont des métadonnées d’intégrité. Elles sont distinctes des constats et des recommandations. Les signatures et le reçu ne certifient pas cette fiche éditoriale.
evidence.json — SHA-256 du fichier
af9bae4c89f994b83fc2a8aa965a862afaea0035b4e777979537f1c035bdaa54
receipt.json — SHA-256 du fichier
c8b022b1211596ea120199afba28bb80b0ea155cfeac2cb7eca407602f4cc441
source_sha256 enregistré dans le dossier
06bb6718ea2f760ba0693238588c68ee62d6c67b6943825b46235d99bd623cf5
Preuve #5 — integrity/payload_sha256
283bca6f32971371b89196b853042ada518e83297c3ad6f701516b7291d9c948
Preuve #6 — integrity/payload_sha256
86bdf58f70d091bcbe3e69f73c9cac3fafdeab8ded440dd04221cf78d2a8471b