r-io suiter-io suiteuse case docs
← IMT Albi Crisis
IMT Albi Crisis / Guided scenario

Corrective procedures on an emerging risk

A complete walkthrough of the IMT Albi Crisis use case: trigger two very different detections, validate the inferred one, deduce a collaborative solution, then make the risk actually occur and watch the corrective procedure start on its own.

Packaged scenario changed

The Default_With10Steps game scenario used below is no longer packaged. IMT Albi Crisis now ships Default Game Scenario in game_scenarios/Default_Game_Scenario/ with its 22 sensor datasets: a one-hour timeline of four dated instants (the Energy company social media message, then the planned actualities Analyze the gas leak at Rapsodee, Presence detected at Iomega and Alert detected at Iomega) and a story narrated in French and English. Its datasets emit preparation/principal pairs: the Gas Sensor Rapsodee dataset holds eight emissions and crosses the 650 threshold at the fourth one (656.5), not at a sixth value of 1213.1. The steps and captures below remain a historical example; see the scenario migration notes.

What this scenario demonstrates

Two detection mechanisms coexist in r-io suite, and they are not trusted the same way. A CEP rule matches a measurement against a threshold: the result is a fact, and the alert is raised directly. An ML inference reads a sentence and proposes a problem: the result is a hypothesis, and a human validates it before it enters the model.

The scenario then goes one step further than a plain deduction. The deduced solution carries a corrective procedure that is deployed but idle, waiting on an Event_Flow. Raising the probability of the emerging risk to certainty makes its actuality appear, the condition becomes true, and the corrective sub-process starts by itself — in parallel, without interrupting the nominal flow.

01 · Step

Trigger the deterministic detection (CEP)

The gas sensor feeds a quantitative rule: as soon as a measurement crosses the threshold configured on the sensor, a CEP rule creates the alert directly. No human confirmation is needed, because a threshold match is a deterministic fact rather than an inference.

  1. Open r-iosemit and stay on the Sensors tab.
  2. Type Gas Sensor Rapsodee in Search sensor, then click the sensor card.
  3. Click Play selected dataset step by step (the swipe_right_alt icon) in the Selected dataset action row.
  4. The sensor is not started yet: answer Yes to the confirmation.
  5. Click the same button five more times, leaving a couple of seconds between clicks.
r-iosemit - the Gas Sensor Rapsodee controller, its 10-step dataset and the 650 threshold drawn on the chart.
r-iosemit - the Gas Sensor Rapsodee controller, its 10-step dataset and the 650 threshold drawn on the chart.
The sensor is still in CREATED state, so r-iosemit asks before starting it.
The sensor is still in CREATED state, so r-iosemit asks before starting it.
After six steps the sixth value (1213.1) has crossed the threshold and the CEP rule has fired.
After six steps the sixth value (1213.1) has crossed the threshold and the CEP rule has fired.

ResultThe sixth value of the dataset, 1213.1, crosses the 650 threshold declared on the sensor. The CEP rule fires immediately and produces a gas-leak alert together with the objective that treats it.

02 · Step

Trigger the inferred detection (ML)

The second sensor publishes natural-language messages. Its text is analysed by the gov.ai_chatbot module, which infers a problem from the sentence. Because this is an inference and not a measurement, its output is not trusted automatically: it needs a human decision in r-iota.

  1. Still in r-iosemit, search for Energy company social media and click the sensor card.
  2. Click Play selected dataset step by step once, and confirm the start if asked.
  3. Wait about ten seconds: the message is sent to the language model and the answer comes back asynchronously.
r-iosemit - the Energy company social media controller, a SOCIAL / MESSAGING sensor.
r-iosemit - the Energy company social media controller, a SOCIAL / MESSAGING sensor.
The first dataset entry is the only one carrying a real message; it is the one submitted to the language model.
The first dataset entry is the only one carrying a real message; it is the one submitted to the language model.

ResultThe published message is “Due to high electricity demand, there is a risk of power outages in your area.” The model returns a single problem, of type risk, named Power outages, with a certainty index of 0.95 and an occurrence probability of 0.7.

03 · Step

Read the two detections in r-iota

r-iota separates what it can trust from what it cannot. The two detection mechanisms you have just exercised land in two different counters.

  1. Open r-iota and let the dashboard finish loading (it fetches the field and expected models).
  2. Read the Incident detection panel on the right.
r-iota - one sure alert from the CEP rule, one alert awaiting validation from the ML inference.
r-iota - one sure alert from the CEP rule, one alert awaiting validation from the ML inference.

Result1 SURE ALERTS - the CEP gas alert, trusted on the spot. 1 ALERTS TO VALIDATE - the risk inferred by the language model. The status dot at the top left is red: problems are known and nothing takes care of them yet.

04 · Step

Validate the inferred risk

Validating turns an inference into a fact of the model. It also attaches the detected risk to the reference risk it resembles, through a core:Near edge - which is how the deduction later finds the corrective procedures already modelled for that family of risk.

  1. Click OPEN DETAILS under ALERTS TO VALIDATE.
  2. Read the row: the name found by the model, its type, the objective that treats, prevents or enables it, the nearest reference instance and the sentence that justifies the detection.
  3. Select Validate in the Actions column.
  4. Click Save.
The Problems found dialog: the inferred risk, its type, the nearest reference instance and the model's justification.
The Problems found dialog: the inferred risk, its type, the nearest reference instance and the model's justification.
Validate is selected for the detected risk; Delete would discard it instead.
Validate is selected for the detected risk; Delete would discard it instead.
After saving, both detections are sure alerts and the deduction can be launched.
After saving, both detections are sure alerts and the deduction can be launched.

ResultThe risk becomes an instance of the model, linked to the reference risk Risk of power outage. The panel now shows 2 SURE ALERTS and no alert left to validate.

05 · Step

Deduce, deploy and supervise a solution

The deduction builds a collaborative process that satisfies the objectives raised by the two alerts, assigns actors and resources to each task, then deploys it and starts supervising it.

  1. Click FIND SOLUTION(S).
  2. Keep the preselected Drools - Crisis Satisfaction Strategy; it is the one matching the project domain.
  3. Click Find.
  4. Wait: search, deployment and the start of supervision take one to three minutes on this use case.
The deduction dialog: the Crisis strategy is preselected because it matches the project domain.
The deduction dialog: the Crisis strategy is preselected because it matches the project domain.
The campaign runs in the background; r-iota reports its progress.
The campaign runs in the background; r-iota reports its progress.
Solution deployed and supervised: the cockpit switches to live telemetry and the status dot turns blue.
Solution deployed and supervised: the cockpit switches to live telemetry and the status dot turns blue.

ResultA solution is found, deployed and supervised. The header shows the supervision start and expected end, and the banner confirms Deduction, deployment and supervision completed.

06 · Step

Read the deployed process before anything happens

This is the key screen of the scenario. The corrective procedure is already deployed, side by side with the nominal flow, but it is not running. It hangs off the nominal sub-task through an Event_Flow edge - a non-interrupting link that fires on its own when its condition becomes true.

  1. In the right-hand panel, switch to the Execution graph tab (the second icon).
  2. Identify the three parts: Start → Nominal SubTask → End, and the corrective sub-process branching off.
The deployed process: the nominal sub-task is running (orange); the corrective sub-process is attached by an Event_Flow and stays neutral.
The deployed process: the nominal sub-task is running (orange); the corrective sub-process is attached by an Event_Flow and stays neutral.

ResultNominal SubTask is orange, meaning in progress. Circuit breaker for all circuits except IT and communications - the corrective - is still neutral: its Event_Flow condition is evaluated on every poll and is false, because the actuality it watches does not exist yet.

07 · Step

Make the emerging risk occur

A risk that stays a risk changes nothing. To exercise the corrective procedure you make the risk actually happen, by raising its probability to certainty. The platform then activates the actuality that this potentiality generates.

  1. Go back to r-iosemit and open the Potentialities Management tab.
  2. Click refresh if the list is empty: it only shows the emerging and intrinsic potentialities currently present in the model.
  3. Find Power outages - the risk you validated, shown as EMERGING at 70%.
  4. Drag the probability slider all the way to 1 (100%) and release it to commit.
r-iosemit - the emerging potentiality and the actualities it would activate, at its detected probability of 70%.
r-iosemit - the emerging potentiality and the actualities it would activate, at its detected probability of 70%.
Probability raised to 100%: the risk is now certain and its actuality is activated.
Probability raised to 100%: the risk is now certain and its actuality is activated.

ResultThe actuality Power outage becomes active and inherits the geolocation of the impacted asset. In the graph it is attached to the risk that generated it by a Generated_By edge.

08 · Step

Watch the corrective procedure start by itself

Nothing more is clicked here. The workflow engine polls the Event_Flow condition; as soon as the actuality exists, is active and was generated by that particular risk, the corrective sub-process is launched in parallel - the nominal flow is not interrupted.

  1. Go back to r-iota, on the Execution graph tab.
  2. Watch the corrective sub-process change colour, without reloading the page.
  3. Switch to the Dashboard tab to see the map.
The corrective sub-process has turned orange: its Event_Flow fired and it is now running.
The corrective sub-process has turned orange: its Event_Flow fired and it is now running.
Both problems are taken into account: blue pulsars on the map and a blue status dot.
Both problems are taken into account: blue pulsars on the map and a blue status dot.

ResultCircuit breaker for all circuits except IT and communications turns orange: it is running. On the map, the two problems now carry blue pulsars and the status dot is blue - every detected problem is taken into account by the deployed solution.

09 · Step

Find the work in the responders' to-do list

The corrective procedure is not only a drawing in a graph: its tasks are assigned to actors and land in their to-do list, where they are planned, started and completed.

  1. Open r-ioga and click the checklist icon in the toolbar to open the To Do List.
  2. Switch the calendar to the list view to read every task at once.
r-ioga - the deployed human tasks, nominal and corrective, on the shared timeline.
r-ioga - the deployed human tasks, nominal and corrective, on the shared timeline.

ResultThe tasks of both flows appear side by side - Cut off the local gas valve and Report the damage for the gas alert, Electric vehicle charging circuit breaker and its siblings for the corrective procedure - each with its planned window and its actual progress.

In depth

What actually fired it

The corrective is wired to the nominal flow by an Event_Flow edge whose condition is generated by the planner. It is written in the 2L language and evaluated on every poll of the workflow engine:

Node triggerActuality = findNodeInstance("Actuality", "Power outage");
boolean triggered = triggerActuality.isActive() && triggerActuality.Generated_By("Power outages") != null;
triggered;

The condition is deliberately qualified by the risk: an actuality name alone is not discriminating, because the same Power outage is described both by the reference model and by the risk the detection actually found. Requiring the actuality to be Generated_By that precise risk is what makes the corrective fire for this detection and not for a namesake.

Back to IMT Albi Crisis →r-iosemit →r-iota →r-ioga →
IMT Albi Crisis / Scénario guidé

Procédures correctives sur un risque émergent

Un parcours complet du cas d’usage IMT Albi Crisis : déclencher deux détections de natures très différentes, valider celle qui est inférée, déduire une solution collaborative, puis faire effectivement survenir le risque et voir la procédure corrective démarrer d’elle-même.

Scénario empaqueté modifié

Le scénario de jeu Default_With10Steps utilisé ci-dessous n’est plus empaqueté. IMT Albi Crisis fournit désormais Default Game Scenario dans game_scenarios/Default_Game_Scenario/ avec ses 22 jeux de données de capteurs : une chronologie d’une heure à quatre instants datés (le message d’Energy company social media, puis les actualités planifiées Analyze the gas leak at Rapsodee, Presence detected at Iomega et Alert detected at Iomega) et une histoire narrée en français et en anglais. Ses jeux de données émettent des paires préparation/principale : celui du Gas Sensor Rapsodee contient huit émissions et franchit le seuil 650 à la quatrième (656.5), et non à une sixième valeur de 1213.1. Les étapes et captures ci-dessous restent un exemple historique ; voir les notes de migration des scénarios.

Ce que ce scénario démontre

Deux mécanismes de détection coexistent dans r-io suite, et ils ne sont pas approuvés de la même façon. Une règle CEP confronte une mesure à un seuil : le résultat est un fait, et l’alerte est levée directement. Une inférence ML lit une phrase et propose un problème : le résultat est une hypothèse, et un humain la valide avant qu’elle n’entre dans le modèle.

Le scénario va ensuite un cran plus loin qu’une simple déduction. La solution déduite embarque une procédure corrective déployée mais inerte, en attente sur un Event_Flow. Porter la probabilité du risque émergent à la certitude fait apparaître son actualité, la condition devient vraie, et le sous-processus correctif démarre de lui-même — en parallèle, sans interrompre le flux nominal.

01 · Étape

Déclencher la détection déterministe (CEP)

Le capteur de gaz alimente une règle quantitative : dès qu'une mesure franchit le seuil configuré sur le capteur, une règle CEP crée l'alerte directement. Aucune confirmation humaine n'est requise, car un franchissement de seuil est un fait déterministe et non une inférence.

  1. Ouvrez r-iosemit et restez sur l'onglet Sensors.
  2. Saisissez Gas Sensor Rapsodee dans Search sensor, puis cliquez sur la carte du capteur.
  3. Cliquez sur Play selected dataset step by step (icône swipe_right_alt) dans la barre d'actions de Selected dataset.
  4. Le capteur n'est pas encore démarré : répondez Yes à la confirmation.
  5. Cliquez cinq fois de plus sur le même bouton, en laissant deux secondes entre chaque clic.
r-iosemit - le contrôleur Gas Sensor Rapsodee, son jeu de 10 pas et le seuil 650 tracé sur la courbe.
r-iosemit - le contrôleur Gas Sensor Rapsodee, son jeu de 10 pas et le seuil 650 tracé sur la courbe.
Le capteur est encore à l'état CREATED : r-iosemit demande confirmation avant de le démarrer.
Le capteur est encore à l'état CREATED : r-iosemit demande confirmation avant de le démarrer.
Après six pas, la sixième valeur (1213,1) a franchi le seuil et la règle CEP s'est déclenchée.
Après six pas, la sixième valeur (1213,1) a franchi le seuil et la règle CEP s'est déclenchée.

RésultatLa sixième valeur du jeu de données, 1213,1, franchit le seuil de 650 déclaré sur le capteur. La règle CEP se déclenche immédiatement et produit une alerte de fuite de gaz ainsi que l'objectif qui la traite.

02 · Étape

Déclencher la détection inférée (ML)

Le second capteur publie des messages en langage naturel. Leur texte est analysé par le module gov.ai_chatbot, qui infère un problème à partir de la phrase. Parce qu'il s'agit d'une inférence et non d'une mesure, sa sortie n'est pas approuvée automatiquement : elle demande une décision humaine dans r-iota.

  1. Toujours dans r-iosemit, recherchez Energy company social media et cliquez sur la carte du capteur.
  2. Cliquez une fois sur Play selected dataset step by step, et confirmez le démarrage si on vous le demande.
  3. Patientez une dizaine de secondes : le message part vers le modèle de langage et la réponse revient de façon asynchrone.
r-iosemit - le contrôleur Energy company social media, un capteur SOCIAL / MESSAGING.
r-iosemit - le contrôleur Energy company social media, un capteur SOCIAL / MESSAGING.
La première entrée du jeu de données est la seule à porter un vrai message ; c'est elle qui est soumise au modèle de langage.
La première entrée du jeu de données est la seule à porter un vrai message ; c'est elle qui est soumise au modèle de langage.

RésultatLe message publié est « Due to high electricity demand, there is a risk of power outages in your area. » Le modèle renvoie un seul problème, de type risk, nommé Power outages, avec un indice de certitude de 0,95 et une probabilité d'occurrence de 0,7.

03 · Étape

Lire les deux détections dans r-iota

r-iota sépare ce qu'il peut tenir pour acquis de ce qu'il ne peut pas. Les deux mécanismes de détection que vous venez d'exercer aboutissent dans deux compteurs distincts.

  1. Ouvrez r-iota et laissez le tableau de bord finir de charger (il récupère les modèles terrain et attendu).
  2. Lisez le panneau Incident detection à droite.
r-iota - une alerte sûre issue de la règle CEP, une alerte en attente de validation issue de l'inférence ML.
r-iota - une alerte sûre issue de la règle CEP, une alerte en attente de validation issue de l'inférence ML.

Résultat1 SURE ALERTS - l'alerte gaz issue du CEP, approuvée immédiatement. 1 ALERTS TO VALIDATE - le risque inféré par le modèle de langage. Le rond de statut en haut à gauche est rouge : des problèmes sont connus et rien ne les prend encore en charge.

04 · Étape

Valider le risque inféré

La validation transforme une inférence en fait du modèle. Elle rattache aussi le risque détecté au risque de référence dont il est proche, par une arête core:Near - c'est ainsi que la déduction retrouve ensuite les procédures correctives déjà modélisées pour cette famille de risque.

  1. Cliquez sur OPEN DETAILS sous ALERTS TO VALIDATE.
  2. Lisez la ligne : le nom trouvé par le modèle, son type, l’objectif qui le traite, le prévient ou le permet, l'instance de référence la plus proche et la phrase qui justifie la détection.
  3. Sélectionnez Validate dans la colonne Actions.
  4. Cliquez sur Save.
Le dialogue Problems found : le risque inféré, son type, l'instance de référence la plus proche et la justification du modèle.
Le dialogue Problems found : le risque inféré, son type, l'instance de référence la plus proche et la justification du modèle.
Validate est sélectionné pour le risque détecté ; Delete l'écarterait à la place.
Validate est sélectionné pour le risque détecté ; Delete l'écarterait à la place.
Après enregistrement, les deux détections sont des alertes sûres et la déduction peut être lancée.
Après enregistrement, les deux détections sont des alertes sûres et la déduction peut être lancée.

RésultatLe risque devient une instance du modèle, reliée au risque de référence Risk of power outage. Le panneau affiche désormais 2 SURE ALERTS et plus aucune alerte à valider.

05 · Étape

Déduire, déployer et superviser une solution

La déduction construit un processus collaboratif qui satisfait les objectifs soulevés par les deux alertes, affecte acteurs et ressources à chaque tâche, puis le déploie et démarre sa supervision.

  1. Cliquez sur FIND SOLUTION(S).
  2. Conservez la stratégie présélectionnée Drools - Crisis Satisfaction Strategy ; c'est celle qui correspond au domaine du projet.
  3. Cliquez sur Find.
  4. Patientez : la recherche, le déploiement et le démarrage de la supervision prennent une à trois minutes sur ce cas d'usage.
Le dialogue de deduction : la stratégie Crisis est présélectionnée car elle correspond au domaine du projet.
Le dialogue de deduction : la stratégie Crisis est présélectionnée car elle correspond au domaine du projet.
La campagne s'exécute en arrière-plan ; r-iota rend compte de sa progression.
La campagne s'exécute en arrière-plan ; r-iota rend compte de sa progression.
Solution déployée et supervisée : le cockpit bascule en télémétrie live et le rond de statut passe au bleu.
Solution déployée et supervisée : le cockpit bascule en télémétrie live et le rond de statut passe au bleu.

RésultatUne solution est trouvée, déployée et supervisée. L'en-tête affiche le début et la fin prévue de la supervision, et le bandeau confirme Deduction, deployment and supervision completed.

06 · Étape

Lire le processus déployé avant que rien n'arrive

C'est l'écran clé du scénario. La procédure corrective est déjà déployée, à côté du flux nominal, mais elle ne s'exécute pas. Elle est accrochée à la sous-tâche nominale par une arête Event_Flow - un lien non interruptif qui se déclenche de lui-même quand sa condition devient vraie.

  1. Dans le panneau de droite, basculez sur l'onglet Execution graph (la deuxieme icone).
  2. Repérez les trois parties : Start → Nominal SubTask → End, et le sous-processus correctif qui s'en détache.
Le processus déployé : la sous-tâche nominale est en cours (orange) ; le sous-processus correctif est rattaché par un Event_Flow et reste neutre.
Le processus déployé : la sous-tâche nominale est en cours (orange) ; le sous-processus correctif est rattaché par un Event_Flow et reste neutre.

RésultatNominal SubTask est orange, donc en cours. Circuit breaker for all circuits except IT and communications - le correctif - est encore neutre : sa condition d'Event_Flow est évaluée à chaque scrutation et vaut faux, car l'actualité qu'elle surveille n'existe pas encore.

07 · Étape

Faire survenir le risque émergent

Un risque qui reste un risque ne change rien. Pour exercer la procédure corrective, on fait effectivement survenir le risque, en portant sa probabilité à la certitude. La plateforme active alors l'actualité que cette potentialité engendre.

  1. Revenez dans r-iosemit et ouvrez l'onglet Potentialities Management.
  2. Cliquez sur refresh si la liste est vide : elle n'affiche que les potentialités émergentes et intrinsèques présentes dans le modèle.
  3. Repérez Power outages - le risque que vous avez validé, affiche en EMERGING a 70 %.
  4. Faites glisser le curseur de probabilité jusqu'à 1 (100 %) et relâchez pour valider.
r-iosemit - la potentialité émergente et les actualités qu'elle activerait, à sa probabilité détectée de 70 %.
r-iosemit - la potentialité émergente et les actualités qu'elle activerait, à sa probabilité détectée de 70 %.
Probabilité portée à 100 % : le risque est désormais certain et son actualité est activée.
Probabilité portée à 100 % : le risque est désormais certain et son actualité est activée.

RésultatL'actualité Power outage devient active et hérite de la géolocalisation de l'actif impacté. Dans le graphe, elle est rattachée au risque qui l'a engendrée par une arête Generated_By.

08 · Étape

Voir la procédure corrective démarrer d'elle-même

On ne clique plus rien ici. Le moteur de workflow scrute la condition de l'Event_Flow ; dès que l'actualité existe, est active et a été engendrée par ce risque précis, le sous-processus correctif est lancé en parallèle - le flux nominal n'est pas interrompu.

  1. Revenez dans r-iota, sur l'onglet Execution graph.
  2. Observez le sous-processus correctif changer de couleur, sans recharger la page.
  3. Basculez sur l'onglet Dashboard pour voir la carte.
Le sous-processus correctif est passé en orange : son Event_Flow s'est déclenché et il s'exécute.
Le sous-processus correctif est passé en orange : son Event_Flow s'est déclenché et il s'exécute.
Les deux problèmes sont pris en charge : pulsars bleus sur la carte et rond de statut bleu.
Les deux problèmes sont pris en charge : pulsars bleus sur la carte et rond de statut bleu.

RésultatCircuit breaker for all circuits except IT and communications passe en orange : il s'exécute. Sur la carte, les deux problèmes portent désormais des pulsars bleus et le rond de statut est bleu - chaque problème détecté est pris en charge par la solution déployée.

09 · Étape

Retrouver le travail dans la todo-list des intervenants

La procédure corrective n'est pas seulement un dessin dans un graphe : ses tâches sont affectées à des acteurs et arrivent dans leur todo-list, où elles sont planifiées, démarrées et terminées.

  1. Ouvrez r-ioga et cliquez sur l'icône checklist de la barre d'outils pour ouvrir la To Do List.
  2. Basculez le calendrier en vue list pour lire toutes les tâches d'un coup.
r-ioga - les tâches humaines déployées, nominales et correctives, sur la frise partagée.
r-ioga - les tâches humaines déployées, nominales et correctives, sur la frise partagée.

RésultatLes tâches des deux flux apparaissent côte à côte - Cut off the local gas valve et Report the damage pour l'alerte gaz, Electric vehicle charging circuit breaker et ses voisines pour la procedure corrective - chacune avec sa fenêtre prévue et son avancement réel.

Pour aller plus loin

Ce qui l’a réellement déclenché

Le correctif est relié au flux nominal par une arête Event_Flow dont la condition est générée par le planificateur. Elle est écrite dans le langage 2L et évaluée à chaque scrutation du moteur de workflow :

Node triggerActuality = findNodeInstance("Actuality", "Power outage");
boolean triggered = triggerActuality.isActive() && triggerActuality.Generated_By("Power outages") != null;
triggered;

La condition est délibérément qualifiée par le risque : un nom d’actualité seul n’est pas discriminant, car la même Power outage est décrite à la fois par le modèle de référence et par le risque que la détection a réellement trouvé. Exiger que l’actualité soit Generated_By ce risque précis est ce qui fait déclencher le correctif pour cette détection, et pas pour un homonyme.

Retour à IMT Albi Crisis →r-iosemit →r-iota →r-ioga →