Glossary

The words used across r-io suite, grouped by theme: how work is scoped, what the collaborative model contains, how concepts relate, which statuses a node can carry, and the platform notions behind deduction, interpretation, simulation and execution. Definitions follow the metamodel resources and the code, not marketing.

⌕

01 · Scope and structure

Where a model lives

Collaboration: The top-level working context: a set of users and the knowledge spaces they share. Managed by the system governance (GovSystem) and selected in r-ioga; every REST call and WebSocket topic is scoped by it.
Knowledge space: One graph inside a collaboration: the nodes and edges of a situation, its projects, sensors and processes. A collaboration may hold several knowledge spaces (for instance one per use case); r-io4U and the web applications always work in one selected knowledge space.
Project: A Project node that ties a domain, the model extensions it uses, a detection strategy, an operating mode (real or simulated), reference projects and shared resources. Use cases are ready-made projects.
Use case: A packaged project delivered as a Maven module (gind-usecases-*) with its models, images, game scenarios and datasets. Two are on the standalone runtime classpath; the others are test-scope demonstration projects. See use cases.
Shared resources project: A project mounted into another one to reuse its context and partners (for example IMT Albi Context or Albi Partners).
Reference project: A reusable catalogue of common problems or roles for a domain (Crisis Commons Problems, Health Commons Roles…) declared in the project descriptor.
Metamodel: The grammar of a model: concepts, their properties, inheritance and connection rules, published as XML resources and JAXB classes. The core metamodel defines the technical concepts, the collaborative model the shared vocabulary. See Metamodel, domains and extensions.
Domain: A business specialization of the collaborative model: Crisis, Health and Production, plus the technical Core domain. A project selects one domain.
Extension: An installable vocabulary package adding concrete concepts to a domain (Urban, Road Network, Hospital, Skateboard…). Twelve extensions exist; each declares a privileged domain.
Effective metamodel · effective domain: The metamodel actually available in a knowledge space once core, collaborative, domain and selected extensions are merged and published by the meta-models governance.
Concept · instance: A concept is a type declared by a metamodel (Person, Risk); an instance is a node of that type in a knowledge space. Abstract concepts (Asset, Resource, Potentiality) cannot be instantiated directly.
Node · edge · property: The generic model is a graph: nodes carry a type, a status, labels and typed properties (including geometries); edges carry a type, a source and a target, and may hold properties such as 2L code or an activation condition.
Label: Free tag on a node used for scoping and queries: instance, a solution identifier, EXPECTED_FREEZE… Detection and supervision rely on label combinations such as instance:EXPECTED_FREEZE:<solutionId>.
brokenEdges: Edges attached to a node whose other end is not yet in the graph (it lives in another file or batch). They are reconciled after all nodes are published. See model loading.

02 · Model concepts

The vocabulary of the collaborative model

Abstract concepts are marked; domain and extension specializations are listed at the end. Full inventories with properties are on the Collaborative page.

Asset abstract: Physical or logical entity with operational value; parent of territories and resources.
Territory: Geographical perimeter on which assets can be positioned.
Resource abstract: Mobilizable asset used by collaborative work; parent of Person, Group, Good, Stock and Sensor. Its hidden presumed trajectory property holds the JSON trajectory computed when a spatial sensor moves it (expected trajectory is computed on each move task of a deduced process: the walk along the pedestrian networks, dated from the task’s expected start).
Person: Human resource that can carry roles and perform functions; linked to a system User through Assigned_To.
Group: Organizational grouping of people and assets (an organization, a team, a company).
Role: Concrete set of responsibilities provided by a resource; the pivot between actors and the functions they Provide.
Good: Material or logical good used by the collaboration (a vehicle, a building, a camera…). Extensions specialize it heavily. Its optional commissioning date property (date it entered service) gives its age to the strain indicator, like the birthdate of a Person.
Stock: Countable or consumable resource quantity, consumed or produced by functions and tasks.
Sensor: Core concept for a data source: spatial, quantitative, social, dedicated, media or other. An ACTIVE Sensor node becomes a running sensor and a CEP or ML configuration. See Sensors.
Problem abstract: Problematic situation shared by actualities and potentialities.
Actuality: Observed fact requiring treatment or representing a resolved state. Alerts (Crisis), Act_of_care (Health) and Order (Production) are actualities.
Potentiality abstract: Possible situation carrying a probability; specialized into Risk and Opportunity.
Potential: Generic potential situation before specialization into risk or opportunity.
Risk: Adverse potentiality that objectives may prevent; its probability is written by CEP rule actions or 2L assignments.
Opportunity: Beneficial potentiality that objectives may enable.
Objective: Expected result used to drive deduction and planning; treats actualities, prevents risks or enables opportunities.
Objectives_Manager: Container and coordination point for the objectives of a project; the root a deduction starts from (its Plans edges).
Function: Capability or activity that a resource can perform; satisfies objectives, needs, implies or supports other functions.
Solution: Candidate or selected response satisfying the objectives: the deduced process with its assignments and indicators.
Process: Executable organization of collaborative work: tasks, events, gateways and flows compiled and deployed by the PRIO engine.
Task · Personal_Task · SubProcess_Task: Executable unit of work; a personal task targets one participant, a subprocess task delegates to a nested process.
Start_Event · End_Event · Timer_Event: Process events controlling the flow: entry point, terminal event, time-based trigger.
Exclusive · Inclusive · Parallel_Gateway: Branching and synchronization points selecting one, several compatible, or all branches.
Remove_Tag: Process action used to remove a designated task.
User system: System account with login and rights; a Person or Group is Assigned_To its User.
Alert crisis: Actuality specialization of the Crisis domain; thirteen typed alerts (fire, flood, toxic gas…) inherit the generic Alert.
Act_of_care health: Observed care situation that can consume a Patient or another resource.
Order production: Observed production or logistics demand (a Damage-typed actuality) that objectives treat.
Building · Parking · Road · Road_Network · Pedestrian_Path · Pedestrian_Network · Water_Network · Electrical_Network · Urban_rail_network: Goods brought by the Urban, Road Network, Pedestrian Network, Water Network, Electrical Network and Urban Rail Network extensions.
Camera · Photo_Camera · Phone · Watch: Goods of the Electronic Tools extension; cameras are the visual sources served by r-iopiot.
Patient · Operating_room · Wake_up_room · Transfert_room · Company · Skateboard · Dog: Concepts of the Hospital, Industry, Skateboard and Animal extensions.

03 · Relations

How concepts connect

Relation names are the edge types of the collaborative model (plus Near from the core). Five relations (Generates, Proposes, Concerns, Treated_By, Applies_On) are declared without a connection rule and used programmatically only.

Plans: Places objectives, processes or tasks in an operational plan; the Plans edges of an Objectives_Manager are the entry of a deduction.
Satisfies: Links a Function to the Objective it can satisfy.
Provides: Links a Role, or a resource capability, to the Functions it can perform; used to find candidate actors.
Consumes · Produces: Declare the roles, stocks or resources a Function or Task requires or yields.
Needs · Implies · Supports: Functional dependencies between functions: a prerequisite, an implied follow-up, a supporting function. They shape the recursive function graph rebuilt during deduction. Implies, Supports and Needs can carry a 2L Condition Evaluation that guards the task of the dependent function at execution (see conditioned links); this condition is read once. To hold a task until a condition is true, a “Wait Until” Mediation function with a Wait Condition is placed between the two functions.
Treats · Prevents · Enables: Link an Objective to the Actuality it treats, the Risk it prevents or the Opportunity it enables; created or cloned by the Actuality/Potentiality interceptor.
Generated_By: Causal chain between actualities and potentialities; carries an activation condition evaluated by the 2L interpreter. See Generated_By interceptor.
Impacts: Concrete effect of a problem on an asset, role or resource.
Is_Susceptible_To: Declares that an asset or role can be affected by a problem or potentiality; the Has interceptor uses it to clone potentiality structures onto resources.
Near: Core proximity relation between instances (a node and its FREEZE or REFERENCE twin, a sensor and its reference instance).
Has: Links a Resource to its Roles, or a Group to the Assets it holds. See Has interceptor.
Pilots: A Sensor controls a Good, for example a radar controlling a camera; used by reflex events.
Fixed_Onto · Acts_On: Fix a resource onto another resource or territory; state that a resource acts on a territory or asset.
Assigned_To: Links a Person or Group to its system User, and assigns a Resource to an Objective, an Objectives_Manager or a Task.
Belongs_To: Membership in a group, process or structural container; computer tasks find their Good through it.
Solves: Connects a Solution to the objectives manager it resolves.
Induces · Created_By: Derived consequence between concepts; creator or generating concept of an element.
Sequence_Flow: Normal ordering between tasks, events and gateways of a process. It may carry a 2L condition copied from Implies/Needs, paired with an “otherwise” flow to the End_Event.
Exception_Flow: Alternate process path triggered by an exception; its condition is evaluated in 2L by the PRIO engine.
Event_Flow: Connects an event occurrence to the process path it activates; its condition can qualify the actuality that generated the event.
Code2L: Not a relation but the property of an edge holding 2L code; the Code2L interceptor registers it with the low-level manager. See Code2L interceptor.

04 · Statuses

Values of the node status

Enumerated by statusType in genericModel.xsd.

ACTIVE: The node is part of the current situation: it is queried by rules, shown by the applications and counted by detection as the field model.
FREEZE: A frozen template or twin: not active, kept as a model to clone from (for instance potentiality structures cloned onto resources).
EXPECTED_FREEZE: The expected situation attached to a solution (its twin), compared with ACTIVE instances by detection and highlighted in blue or orange on r-iota maps.
PROJECTED_ACTIVE · PROJECTED_EXPECTED_FREEZE: Projected variants: a situation computed from a Forecast at a future date (a projection knowledge space), never executed as such.
REFERENCE: Reference instance of a concept, used as a template for potentiality clones and for ML alert validation (Near edge to the reference).
NOT_VALIDATED: Produced by an ML prediction and awaiting human validation in r-iota; excluded from sure alerts.
SHARE: Shared element made available across knowledge spaces.

05 · Platform notions

Words from the services and tools

Governance: The container that validates, enriches and persists models: core (graph), system (users, collaborations), meta-core and meta-models (metamodels, effective domains), models (publication), deduction and AI assistants. See Core governance.
Interceptor: Hook executed before and after a node or edge is written (Sensor, Function, Actuality/Potentiality, Code2L, Has, Generated_By). See model loading.
Publication (sync · async · bulk): Writing a model into a knowledge space through the models governance; the bulk path (UNWIND by lots) is used for initial imports and replays interceptors and history.
2L: The small language written on the edges of the collaborative model (JavaCC grammar, LLInterpretor), with $source and $target bound to the edge: activation, susceptibility and impact rules that set statuses, probabilities and zones, and the Condition Evaluation of links and flows evaluated by the workflow engine. See the 2L language reference and Models & DSL.
KPIL · indicator · metric: The indicator language: declarations Concept:name[aggregation, objective, "unit", "description", {icon, color, thresholds}], optionally followed by a function body, evaluated on functions, tasks and processes to value solutions (duration, cost, distance, strain…). The optional display block gives the Material icon (plain or per concept), the colour and the ascending level thresholds that r-iosepe uses to draw the indicator. A body sees the task as this and calls whitelisted methods (getAssignedTo, getResources, getAgeInYears, getSharersCount, Indicator.sum / Indicator.max…). When flows of the process carry conditions, an indicator is an interval from the scenario where it is lowest to the one where it is highest (one scenario per combination of the values the conditions read, up to 512; a process that loops is not measured). Task, function and resource counts follow the same rule, and moves are not counted as tasks. Each outcome of the branches is stored with the solution (branchOutcome: its decisions, executed tasks and indicators). A metric is a computed value in a strict canonical format. See Models & DSL.
Strain: Default indicator of the r-ioga script (Resource:strain, in %): fatigue of a person or wear of a good on a task, 10 % per hour shared between the engaged resources, plus 2 % per year of age (birthdate of a Person, commissioning date of a Good); Function:strain keeps the most strained resource. Its thresholds 50 and 75 colour it green, orange or red. Two levels: the strain a task adds to each of its resources, and the current strain of the resource (real value of its Resource:strain), increased by the share of each task once done, up to 100 %; the deduction does not read the current level, the supervision fires Failing when it crosses 75 %.
Move · Wait: Tasks added to the deduced process once it is planned, when the indicators script of the project allows them: a “Move to <task>” (move improver, Function:distance indicator) when the actor has to travel to its task, a “Wait before <activity>” (wait improver, Function:wait indicator) when it stands idle at least 60 s, held back by a task of another actor. Neither counts as a task or a function of the solution; Resource:wait gives the waiting time of each actor.
Interpretation config: A deployable configuration carrying either a CEP rule (Siddhi) or an ML config (prediction module); created for each active sensor. See Interpretation.
CEP rule: Siddhi application correlating sensor events over windows; its actions publish typed events that concept interpreters turn into ACTIVE facts (Danger, Effect, Emerging_Risk…).
ML config · predict module: Interpretation config delegating to an SPIAbstractPredictModule (ChatGPT today); predictions come back as a generic model whose nodes are NOT_VALIDATED.
Reflex event: Event emitted by the high-level interpretation linking a produced fact to the sensor and the Good it pilots; consumed by r-iota for immediate reactions.
Supervision · supervision strategy: Continuous comparison, every 10 s by default, of the field (ACTIVE instances) with the supervised solution (its EXPECTED_FREEZE twins) and a baseline taken after their clone. Each strategy is a plugin on the shelf (Maven module plus r-iota configuration extension) checked in the supervision configuration property of the project; Weighted Graph Distance Strategy and KPIL indicators recalculation are checked by default. It replaces the former F-score and D3 detection methods. See Supervision engine and Supervision strategies.
Failure category: One of the five ways a supervised solution can fail: Uncovered (new problems not treated), Failing (resources of remaining tasks gone, the process cannot complete), Obsolete (treated problems vanished), Wrong (indicators drift from the deduced values), Improvable (better resources available). Strategies feed them with values normalized by their thresholds, 1.0 meaning action needed; a category takes the highest value. An alert category newly crossing 1 opens a single alert box in r-iota; Improvable only shows a blue badge and a light banner.
Deduction · deduction strategy: Generating collaborative process candidates from objectives, functions, actors and resources. Strategies are AbstractProcessGenerator implementations: Drools profiles and the native Basic Bloc Satisfaction. See Deduction & planning.
Planner: Assigns actors and resources, sequences tasks and stamps expected dates on a deduced plan; only the Default planner is built.
Campaign · campaign solution · signature: A campaign groups the solutions of one deduction or experiment; each solution carries indicators and a signature used to drop duplicates. See Campaigns.
FIRST_GOOD_SOLUTION · ALL_SOLUTIONS: Deduction modes: stop at the first unique solution and publish it, or explore every combination.
Process instance · exchange: A running deployed process and each monitored SOAP exchange (task call, response, fault) recorded by the monitoring service.
Human task · to-do list: Task created by the PRIO engine for a person or group, stored by the human-task service and shown in the to-do lists (web applications, r-io4U).
Mock endpoint: Simulated SOAP or REST partner standing in for a Good’s real service; answers process tasks with recorded exchanges. See Simulation.
Game scenario · dataset · sensor controller: A replayable configuration of sensor controllers and mock endpoints; a dataset is the recorded sequence a controller plays into a sensor.
Topic · TopicSet · WS-Notification: Named event streams declared by producers in TopicSet files and routed by the event broker; browsers receive them through scoped WebSocket topics. See Event broker.
Time series: MongoDB time-series collection per sensor storing every measurement with second precision.
Profile · wave: A container profile lists which web applications and backends run; backends start in four waves. See Configuration & ports.
Standalone: The single-JVM distribution that runs all services and web applications with embedded databases.
Driver: Language-native façade (Java, Python, C#, Dart) over the REST resources and WebSocket topics. See API reference.
WebJar: Compiled Angular application packaged as a Maven artifact and served by its Dropwizard web module.
GJaxb classes: Java types generated from the XSD schemas (prefix GJaxb), mirrored in TypeScript, Dart, Python and C#.

Metamodel reference →Core governance →Getting started →

Glossaire

Les mots employés dans l’ensemble de r-io suite, regroupés par thème : comment le travail est cadré, ce que contient le modèle collaboratif, comment les concepts se relient, quels statuts un nœud peut porter, et les notions de plateforme derrière la déduction, l’interprétation, la simulation et l’exécution. Les définitions suivent les ressources du métamodèle et le code.

⌕

01 · Périmètre et structure

Où vit un modèle

Collaboration: Le contexte de travail de plus haut niveau : un ensemble d’utilisateurs et les espaces de connaissance qu’ils partagent. Gérée par la gouvernance système (GovSystem) et choisie dans r-ioga ; chaque appel REST et chaque topic WebSocket en dépend.
Espace de connaissance: Un graphe au sein d’une collaboration : les nœuds et arêtes d’une situation, ses projets, capteurs et processus. Une collaboration peut en contenir plusieurs (par exemple un par cas d’usage) ; r-io4U et les applications web travaillent toujours dans un espace sélectionné.
Projet: Un nœud Project qui relie un domaine, les extensions de modèle utilisées, une stratégie de détection, un mode de fonctionnement (réel ou simulé), des projets de référence et des ressources partagées. Les cas d’usage sont des projets prêts à l’emploi.
Cas d’usage: Un projet empaqueté en module Maven (gind-usecases-*) avec ses modèles, images, scénarios de jeu et jeux de données. Deux sont sur le classpath runtime du standalone ; les autres sont des projets de démonstration en portée test. Voir cas d’usage.
Projet de ressources partagées: Un projet monté dans un autre pour réutiliser son contexte et ses partenaires (par exemple IMT Albi Context ou Albi Partners).
Projet de référence: Un catalogue réutilisable de problèmes ou de rôles communs à un domaine (Crisis Commons Problems, Health Commons Roles…) déclaré dans le descripteur de projet.
Métamodèle: La grammaire d’un modèle : concepts, propriétés, héritage et règles de connexion, publiés en ressources XML et classes JAXB. Le métamodèle core définit les concepts techniques, le modèle collaboratif le vocabulaire partagé. Voir Métamodèle, domaines et extensions.
Domaine: Une spécialisation métier du modèle collaboratif : Crisis, Health et Production, plus le domaine technique Core. Un projet choisit un domaine.
Extension: Un paquet de vocabulaire installable ajoutant des concepts concrets à un domaine (Urban, Road Network, Hospital, Skateboard…). Douze extensions existent ; chacune déclare un domaine privilégié.
Métamodèle effectif · domaine effectif: Le métamodèle réellement disponible dans un espace de connaissance une fois core, collaboratif, domaine et extensions choisies fusionnés et publiés par la gouvernance des métamodèles.
Concept · instance: Un concept est un type déclaré par un métamodèle (Person, Risk) ; une instance est un nœud de ce type dans un espace de connaissance. Les concepts abstraits (Asset, Resource, Potentiality) ne s’instancient pas directement.
Nœud · arête · propriété: Le modèle générique est un graphe : les nœuds portent un type, un statut, des labels et des propriétés typées (y compris des géométries) ; les arêtes portent un type, une source et une cible, et peuvent tenir des propriétés comme du code 2L ou une condition d’activation.
Label: Étiquette libre d’un nœud servant au cadrage et aux requêtes : instance, un identifiant de solution, EXPECTED_FREEZE… La détection et la supervision s’appuient sur des combinaisons comme instance:EXPECTED_FREEZE:<solutionId>.
brokenEdges: Arêtes attachées à un nœud dont l’autre extrémité n’est pas encore dans le graphe (elle vit dans un autre fichier ou lot). Elles sont réconciliées après la publication de tous les nœuds. Voir chargement des modèles.

02 · Concepts du modèle

Le vocabulaire du modèle collaboratif

Les concepts abstraits sont marqués ; les spécialisations par domaine et extension sont listées à la fin. Les inventaires complets avec propriétés sont sur la page Collaborative.

Asset abstrait: Entité physique ou logique ayant une valeur opérationnelle ; parent des territoires et des ressources.
Territory: Périmètre géographique sur lequel les actifs peuvent être positionnés.
Resource abstrait: Actif mobilisable utilisé par le travail collaboratif ; parent de Person, Group, Good, Stock et Sensor. Sa propriété masquée presumed trajectory contient la trajectoire JSON calculée quand un capteur spatial la déplace (expected trajectory est calculée sur chaque tâche de déplacement d’un processus déduit : la marche le long des réseaux piétons, datée depuis le début attendu de la tâche).
Person: Ressource humaine pouvant porter des rôles et réaliser des fonctions ; reliée à un User système par Assigned_To.
Group: Regroupement organisationnel de personnes et d’actifs (une organisation, une équipe, une entreprise).
Role: Ensemble concret de responsabilités porté par une ressource ; le pivot entre les acteurs et les fonctions qu’ils fournissent (Provides).
Good: Bien matériel ou logique utilisé par la collaboration (véhicule, bâtiment, caméra…). Les extensions le spécialisent abondamment. Sa propriété optionnelle commissioning date (date de mise en service) donne son âge à l’indicateur strain, comme le birthdate d’une Person.
Stock: Quantité de ressource dénombrable ou consommable, consommée ou produite par les fonctions et les tâches.
Sensor: Concept core d’une source de données : spatial, quantitatif, social, dédié, média ou autre. Un nœud Sensor ACTIVE devient un capteur en marche et une configuration CEP ou ML. Voir Capteurs.
Problem abstrait: Situation problématique commune aux actualités et aux potentialités.
Actuality: Fait observé nécessitant un traitement ou représentant un état résolu. Les alertes (Crisis), Act_of_care (Health) et Order (Production) sont des actualités.
Potentiality abstrait: Situation possible portant une probabilité ; spécialisée en Risk et Opportunity.
Potential: Situation potentielle générique avant spécialisation en risque ou opportunité.
Risk: Potentialité défavorable que les objectifs peuvent prévenir ; sa probability est écrite par les actions de règles CEP ou des assignations 2L.
Opportunity: Potentialité favorable que les objectifs peuvent rendre possible.
Objective: Résultat attendu pilotant la déduction et la planification ; traite des actualités, prévient des risques ou rend possibles des opportunités.
Objectives_Manager: Conteneur et point de coordination des objectifs d’un projet ; la racine d’une déduction (ses arêtes Plans).
Function: Capacité ou activité qu’une ressource peut réaliser ; satisfait des objectifs, a besoin, implique ou supporte d’autres fonctions.
Solution: Réponse candidate ou retenue satisfaisant les objectifs : le processus déduit avec ses affectations et ses indicateurs.
Process: Organisation exécutable du travail collaboratif : tâches, événements, passerelles et flux compilés et déployés par le moteur PRIO.
Task · Personal_Task · SubProcess_Task: Unité de travail exécutable ; une tâche personnelle vise un participant, une tâche de sous-processus délègue à un processus imbriqué.
Start_Event · End_Event · Timer_Event: Événements de processus contrôlant le flux : point d’entrée, événement terminal, déclencheur temporel.
Exclusive · Inclusive · Parallel_Gateway: Points de branchement et de synchronisation sélectionnant une, plusieurs branches compatibles, ou toutes.
Remove_Tag: Action de processus supprimant une tâche désignée.
User système: Compte système avec identifiant et droits ; une Person ou un Group est Assigned_To son User.
Alert crisis: Spécialisation d’Actuality du domaine Crisis ; treize alertes typées (feu, inondation, gaz toxique…) héritent de l’Alert générique.
Act_of_care health: Situation de soin observée pouvant consommer un Patient ou une autre ressource.
Order production: Demande de production ou de logistique observée (actualité de type Damage) que les objectifs traitent.
Building · Parking · Road · Road_Network · Pedestrian_Path · Pedestrian_Network · Water_Network · Electrical_Network · Urban_rail_network: Biens apportés par les extensions Urban, Road Network, Pedestrian Network, Water Network, Electrical Network et Urban Rail Network.
Camera · Photo_Camera · Phone · Watch: Biens de l’extension Electronic Tools ; les caméras sont les sources visuelles servies par r-iopiot.
Patient · Operating_room · Wake_up_room · Transfert_room · Company · Skateboard · Dog: Concepts des extensions Hospital, Industry, Skateboard et Animal.

03 · Relations

Comment les concepts se relient

Les noms de relations sont les types d’arêtes du modèle collaboratif (plus Near du core). Cinq relations (Generates, Proposes, Concerns, Treated_By, Applies_On) sont déclarées sans règle de connexion et n’ont qu’un usage programmatique.

Plans: Place objectifs, processus ou tâches dans un plan opérationnel ; les arêtes Plans d’un Objectives_Manager sont l’entrée d’une déduction.
Satisfies: Relie une Function à l’Objective qu’elle peut satisfaire.
Provides: Relie un Role, ou une capacité de ressource, aux Functions qu’il peut réaliser ; sert à trouver les acteurs candidats.
Consumes · Produces: Déclarent les rôles, stocks ou ressources qu’une Function ou une Task requiert ou produit.
Needs · Implies · Supports: Dépendances fonctionnelles entre fonctions : un prérequis, une suite impliquée, une fonction de support. Elles façonnent le graphe récursif de fonctions reconstruit pendant la déduction. Implies, Supports et Needs peuvent porter une Condition Evaluation 2L qui garde la tâche de la fonction dépendante à l’exécution (voir liens conditionnés) ; cette condition est lue une fois. Pour retenir une tâche jusqu’à ce qu’une condition soit vraie, une fonction Mediation « Wait Until » portant une Wait Condition est placée entre les deux fonctions.
Treats · Prevents · Enables: Relient un Objective à l’Actuality qu’il traite, au Risk qu’il prévient ou à l’Opportunity qu’il rend possible ; créées ou clonées par l’intercepteur Actuality/Potentiality.
Generated_By: Chaîne causale entre actualités et potentialités ; porte une condition d’activation évaluée par l’interpréteur 2L. Voir intercepteur Generated_By.
Impacts: Effet concret d’un problème sur un actif, un rôle ou une ressource.
Is_Susceptible_To: Déclare qu’un actif ou un rôle peut être affecté par un problème ou une potentialité ; l’intercepteur Has s’en sert pour cloner les structures de potentialités sur les ressources.
Near: Relation de proximité du core entre instances (un nœud et son jumeau FREEZE ou REFERENCE, un capteur et son instance de référence).
Has: Relie une Resource à ses Roles, ou un Group aux Assets qu’il détient. Voir intercepteur Has.
Pilots: Un Sensor pilote un Good, par exemple un radar contrôlant une caméra ; utilisé par les événements réflexes.
Fixed_Onto · Acts_On: Fixe une ressource sur une autre ressource ou un territoire ; précise qu’une ressource agit sur un territoire ou un actif.
Assigned_To: Relie une Person ou un Group à son User système, et affecte une Resource à un Objective, un Objectives_Manager ou une Task.
Belongs_To: Appartenance à un groupe, un processus ou un conteneur structurel ; les tâches informatiques retrouvent leur Good par cette arête.
Solves: Relie une Solution au gestionnaire d’objectifs qu’elle résout.
Induces · Created_By: Conséquence dérivée entre concepts ; créateur ou concept générateur d’un élément.
Sequence_Flow: Ordre normal entre tâches, événements et passerelles d’un processus. Il peut porter une condition 2L recopiée depuis Implies/Needs, associée à un flux « otherwise » vers l’End_Event.
Exception_Flow: Chemin alternatif déclenché par une exception ; sa condition est évaluée en 2L par le moteur PRIO.
Event_Flow: Relie un événement au chemin de processus qu’il active ; sa condition peut qualifier l’actualité qui a généré l’événement.
Code2L: Non une relation mais la propriété d’une arête portant du code 2L ; l’intercepteur Code2L l’enregistre auprès du gestionnaire bas niveau. Voir intercepteur Code2L.

04 · Statuts

Valeurs du statut d’un nœud

Énumérées par statusType dans genericModel.xsd.

ACTIVE: Le nœud fait partie de la situation courante : interrogé par les règles, affiché par les applications et compté par la détection comme modèle terrain.
FREEZE: Gabarit ou jumeau gelé : inactif, conservé comme modèle à cloner (par exemple les structures de potentialités clonées sur les ressources).
EXPECTED_FREEZE: La situation attendue attachée à une solution (son jumeau), comparée aux instances ACTIVE par la détection et surlignée en bleu ou orange sur les cartes de r-iota.
PROJECTED_ACTIVE · PROJECTED_EXPECTED_FREEZE: Variantes projetées : situation calculée à partir d’une prévision (Forecast) à une date future, dans un espace de projection, jamais exécutée telle quelle.
REFERENCE: Instance de référence d’un concept, servant de gabarit aux clones de potentialités et à la validation des alertes ML (arête Near vers la référence).
NOT_VALIDATED: Produit par une prédiction ML et en attente de validation humaine dans r-iota ; exclu des alertes sûres.
SHARE: Élément partagé rendu disponible entre espaces de connaissance.

05 · Notions de plateforme

Les mots des services et des outils

Gouvernance: Le conteneur qui valide, enrichit et persiste les modèles : core (graphe), système (utilisateurs, collaborations), meta-core et meta-models (métamodèles, domaines effectifs), models (publication), déduction et assistants IA. Voir Gouvernance centrale.
Intercepteur: Hook exécuté avant et après l’écriture d’un nœud ou d’une arête (Sensor, Function, Actuality/Potentiality, Code2L, Has, Generated_By). Voir chargement des modèles.
Publication (sync · async · bulk): Écriture d’un modèle dans un espace de connaissance via la gouvernance des modèles ; le chemin bulk (UNWIND par lots) sert aux imports initiaux et rejoue intercepteurs et historique.
2L: Le petit langage écrit sur les arêtes du modèle collaboratif (grammaire JavaCC, LLInterpretor), avec $source et $target liés à l’arête : règles d’activation, de susceptibilité et d’impact qui fixent statuts, probabilités et zones, et Condition Evaluation des liens et des flux évaluée par le moteur de workflow. Voir la référence du langage 2L et Modèles & DSL.
KPIL · indicateur · métrique: Le langage d’indicateurs : déclarations Concept:nom[agrégation, objectif, "unité", "description", {icon, color, thresholds}], suivies ou non d’un corps de fonction, évaluées sur fonctions, tâches et processus pour valoriser les solutions (durée, coût, distance, strain…). Le bloc d’affichage optionnel donne l’icône Material (simple ou par concept), la couleur et les seuils croissants de niveau que r-iosepe utilise pour dessiner l’indicateur. Un corps voit la tâche comme this et appelle des méthodes autorisées (getAssignedTo, getResources, getAgeInYears, getSharersCount, Indicator.sum / Indicator.max…). Quand des flux du processus portent des conditions, un indicateur est un intervalle, du scénario où il est le plus bas à celui où il est le plus haut (un scénario par combinaison des valeurs lues par les conditions, jusqu’à 512 ; un processus qui boucle n’est pas mesuré). Les nombres de tâches, de fonctions et de ressources suivent la même règle, et les déplacements ne comptent pas comme tâches. Chaque issue des branches est conservée avec la solution (branchOutcome : ses décisions, ses tâches exécutées et ses indicateurs). Une métrique est une valeur calculée dans un format canonique strict. Voir Modèles & DSL.
Strain: Indicateur par défaut du script de r-ioga (Resource:strain, en %) : fatigue d’une personne ou usure d’un bien sur une tâche, 10 % par heure partagés entre les ressources engagées, majorés de 2 % par année d’âge (birthdate d’une Person, commissioning date d’un Good) ; Function:strain garde la ressource la plus sollicitée. Ses seuils 50 et 75 le colorent en vert, orange ou rouge. Deux niveaux : le strain qu’une tâche ajoute à chacune de ses ressources, et le strain actuel de la ressource (valeur réelle de son Resource:strain), augmenté de la part de chaque tâche terminée, jusqu’à 100 % ; la déduction ne lit pas ce niveau, la supervision déclenche Failing quand il franchit 75 %.
Move · Wait: Tâches ajoutées au processus déduit une fois planifié, quand le script d’indicateurs du projet les autorise : un « Move to <tâche> » (move improver, indicateur Function:distance) quand l’acteur doit se déplacer jusqu’à sa tâche, un « Wait before <activité> » (wait improver, indicateur Function:wait) quand il reste inactif au moins 60 s, retenu par la tâche d’un autre acteur. Ni l’un ni l’autre ne compte comme tâche ou fonction de la solution ; Resource:wait donne le temps d’attente de chaque acteur.
Configuration d’interprétation: Configuration déployable portant soit une règle CEP (Siddhi), soit une config ML (module de prédiction) ; créée pour chaque capteur actif. Voir Interprétation.
Règle CEP: Application Siddhi corrélant les événements capteurs sur des fenêtres ; ses actions publient des événements typés que les interpréteurs de concepts transforment en faits ACTIVE (Danger, Effect, Emerging_Risk…).
Config ML · module de prédiction: Configuration d’interprétation déléguant à un SPIAbstractPredictModule (ChatGPT aujourd’hui) ; les prédictions reviennent en modèle générique dont les nœuds sont NOT_VALIDATED.
Événement réflexe: Événement émis par l’interprétation haut niveau reliant un fait produit au capteur et au Good qu’il pilote ; consommé par r-iota pour les réactions immédiates.
Supervision · stratégie de supervision: Comparaison continue, toutes les 10 s par défaut, du terrain (instances ACTIVE) avec la solution supervisée (ses jumeaux EXPECTED_FREEZE) et une référence prise après leur clonage. Chaque stratégie est un plugin sur l’étagère (module Maven plus extension de configuration de r-iota) cochée dans la propriété supervision configuration du projet ; Weighted Graph Distance Strategy et KPIL indicators recalculation sont cochées par défaut. Elle remplace les anciennes méthodes de détection F-score et D3. Voir Moteur de supervision et Stratégies de supervision.
Catégorie d’échec: L’une des cinq façons dont une solution supervisée peut échouer : Uncovered (nouveaux problèmes non traités), Failing (ressources des tâches restantes disparues, le processus ne peut pas aboutir), Obsolete (problèmes traités disparus), Wrong (indicateurs qui s’écartent des valeurs déduites), Improvable (meilleures ressources disponibles). Les stratégies les alimentent avec des valeurs normalisées par leurs seuils, 1.0 signifiant qu’une action est nécessaire ; une catégorie prend la valeur la plus haute. Une catégorie d’alerte qui franchit 1 ouvre une seule boîte d’alerte dans r-iota ; Improvable n’affiche qu’un badge bleu et un bandeau discret.
Déduction · stratégie de déduction: Génération de candidats de processus collaboratifs à partir des objectifs, fonctions, acteurs et ressources. Les stratégies sont des implémentations d’AbstractProcessGenerator : profils Drools et Basic Bloc Satisfaction native. Voir Déduction & planification.
Planificateur: Affecte acteurs et ressources, séquence les tâches et fixe les dates attendues d’un plan déduit ; seul le planificateur Default est compilé.
Campagne · solution de campagne · signature: Une campagne regroupe les solutions d’une déduction ou d’une expérience ; chaque solution porte des indicateurs et une signature servant à écarter les doublons. Voir Campagnes.
FIRST_GOOD_SOLUTION · ALL_SOLUTIONS: Modes de déduction : s’arrêter à la première solution unique et la publier, ou explorer toutes les combinaisons.
Instance de processus · échange: Un processus déployé en cours d’exécution et chaque échange SOAP supervisé (appel de tâche, réponse, faute) enregistré par le service de supervision.
Tâche humaine · liste de tâches: Tâche créée par le moteur PRIO pour une personne ou un groupe, stockée par le service de tâches humaines et affichée dans les listes de tâches (applications web, r-io4U).
Mock endpoint: Partenaire SOAP ou REST simulé remplaçant le service réel d’un Good ; répond aux tâches du processus avec des échanges enregistrés. Voir Simulation.
Scénario de jeu · jeu de données · contrôleur de capteurs: Configuration rejouable de contrôleurs de capteurs et de mock endpoints ; un jeu de données est la séquence enregistrée qu’un contrôleur joue dans un capteur.
Topic · TopicSet · WS-Notification: Flux d’événements nommés déclarés par les producteurs dans des fichiers TopicSet et routés par le broker ; les navigateurs les reçoivent par des topics WebSocket cloisonnés. Voir Broker événementiel.
Série temporelle: Collection MongoDB time-series par capteur stockant chaque mesure à la seconde près.
Profil · vague: Un profil de conteneur liste les applications web et backends qui tournent ; les backends démarrent en quatre vagues. Voir Configuration & ports.
Standalone: La distribution en une seule JVM qui exécute tous les services et applications web avec des bases embarquées.
Driver: Façade native par langage (Java, Python, C#, Dart) au-dessus des ressources REST et des topics WebSocket. Voir Référence API.
WebJar: Application Angular compilée, empaquetée en artefact Maven et servie par son module web Dropwizard.
Classes GJaxb: Types Java générés depuis les schémas XSD (préfixe GJaxb), reflétés en TypeScript, Dart, Python et C#.

Référence du métamodèle →Gouvernance centrale →Premiers pas →