État global et événements Horizon

Le Noyau Horizon doit pouvoir interpréter une information à partir d'une représentation cohérente de la situation connue par la Plateforme. Cette représentation lui permet notamment d'identifier les personnes et services concernés, de vérifier les conditions d'un traitement, de comparer une demande avec l'état existant et de déterminer les conséquences encore pertinentes.

Le présent chapitre définit cet état global, les principales catégories d'événements Horizon et les relations qui permettent de rattacher une observation, une demande, une décision ou un résultat à l'évolution de la Plateforme. Il complète les responsabilités du Noyau Horizon et du cycle de traitement d'un événement.

Il ne constitue ni le catalogue fonctionnel des données, qui relève du chapitre 13, ni la définition détaillée de leur rattachement et de leurs autorités fonctionnelles, qui est établie au chapitre 14. Il ne fixe pas davantage les formats techniques des événements, les protocoles de transport, les mécanismes de stockage ou les durées de conservation.

Fonctionnement cible — Principes validés

L'état global d'Horizon est une représentation logique et contrôlée de la situation actuelle connue par la Plateforme. Il peut réunir des données internes, des observations externes, des valeurs calculées et des états temporaires sans attribuer à toutes ces informations la même autorité ni le même niveau de certitude.

Horizon conserve directement son état actuel. Les événements contextualisent et expliquent ses évolutions, mais la Plateforme ne dépend pas du jeu intégral de tous les événements passés pour reconstruire sa situation présente.

Une divergence avec un service externe doit être représentée comme un conflit ou une incertitude jusqu'à sa résolution. Horizon ne doit jamais présenter comme certaine une information dont la validité n'est plus suffisamment établie.

Synthèse normative

• L'état global Horizon constitue le terme fonctionnel canonique pour la représentation actuelle connue par la Plateforme.
• La disponibilité, la fraîcheur, la confiance, la cohérence et la transition d'une information sont des dimensions distinctes et cumulables.
• L'origine d'un événement reste distincte de sa fonction dans un traitement.
• Une interaction possède un événement d'origine ; ses décisions, résultats, échéances, transitions, anomalies et corrections peuvent produire des événements dérivés reliés causalement.
• Une donnée utilisée comme preuve ou comme entrée de contexte doit être rattachée au traitement sans devenir automatiquement un événement autonome.
• Horizon conserve directement son état actuel et ne dépend pas d'une reconstruction intégrale par rejeu de tous les événements passés.

Une représentation commune de la situation actuelle

L'état global d'Horizon désigne l'ensemble organisé des informations actuelles dont le Noyau peut avoir besoin pour comprendre la situation de la Plateforme et conduire ses traitements. Il constitue une représentation fonctionnelle commune, indépendamment du nombre de bases de données, de services ou de composants techniques qui seront finalement utilisés.

L'expression état global Horizon est le terme fonctionnel canonique de la documentation. Les anciennes occurrences d'« état partagé » désignaient cette même représentation commune ; elles sont remplacées et ne définissent pas un second concept. Une future architecture pourra employer plusieurs stockages ou mécanismes de partage sans modifier cette définition fonctionnelle.

Cet état peut notamment permettre de savoir :

• Quelle identité Horizon est concernée par un traitement.
• Quels comptes externes sont actuellement reliés à cette identité.
• Quels niveaux, grades, rôles ou responsabilités sont connus.
• Quel système ou service fait autorité pour une information donnée.
• Quel traitement, protocole ou état temporaire est actuellement actif.
• Quelles demandes attendent une confirmation ou un résultat.
• Quelles ressources externes sont disponibles, indisponibles ou incertaines.
• Quelles différences ou anomalies nécessitent une résolution.

L'état global ne doit pas être compris comme une copie intégrale et permanente de tous les systèmes reliés. Horizon ne possède pas l'ensemble des informations de Twitch, Discord, OBS ou des autres services. Il maintient uniquement les informations nécessaires à ses propres fonctions, dans les limites de leur finalité, de leur classification et des permissions applicables.

De la même manière, le terme « global » ne signifie pas « accessible à tous ». Une information peut appartenir à la représentation commune d'Horizon tout en restant consultable uniquement par certaines fonctions, certains acteurs ou certains traitements. La centralisation logique ne supprime ni la minimisation des données ni la séparation entre lecture, utilisation, modification et divulgation.

Les principales composantes de l'état

L'état global peut réunir plusieurs catégories d'informations dont la nature et l'autorité diffèrent. Cette première distinction reste fonctionnelle et ne préjuge pas de leur futur emplacement technique.

Composante de l'état	Rôle général	Exemple indicatif
Données internes faisant autorité dans Horizon	Décrivent les éléments dont Horizon établit directement la valeur actuelle selon ses propres règles.	Niveau Horizon, grade calculé ou paramètre propre à la Plateforme.
Informations externes observées	Représentent les informations communiquées ou consultées auprès d'un service qui conserve son autorité native.	Follow Twitch, appartenance à un serveur Discord ou scène OBS observée.
Valeurs calculées ou dérivées	Résultent d'une ou plusieurs données sources et peuvent être recalculées lorsque celles-ci évoluent.	Progression vers le niveau suivant ou capacité déduite de plusieurs responsabilités.
États opérationnels temporaires	Décrivent une situation active dont la durée est limitée.	Protocole de Raid en cours, indisponibilité d'une extension ou tâche suspendue.
États en attente	Représentent une demande ou une évolution envisagée dont le résultat n'est pas encore établi.	Action critique en attente de confirmation ou modification externe en attente de réponse.
Conflits et anomalies connus	Signalent une divergence, une incohérence ou une absence de certitude nécessitant une règle ou une intervention.	Différence entre un rôle externe observé et la représentation locale attendue.

Une même situation peut mobiliser plusieurs composantes. L'attribution envisagée d'un rôle Discord peut, par exemple, partir d'un grade Horizon faisant autorité, créer un état temporaire en attente d'exécution, puis devenir une information externe observée lorsque Discord confirme le résultat.

Ces catégories n'accordent aucune priorité générale à une origine. La détermination de l'autorité, de la fréquence de vérification et de la règle de résolution doit rester définie donnée par donnée au chapitre 14.

Un état actuel conservé directement

Horizon conserve directement les valeurs nécessaires à la représentation de sa situation actuelle. Le Noyau ne doit pas être obligé de relire et de rejouer l'intégralité des événements passés pour connaître le niveau d'un membre, ses liaisons de comptes, les paramètres actifs ou l'état courant d'un traitement.

Cette orientation répond à plusieurs objectifs :

• Permettre un accès direct à la situation actuelle.
• Éviter qu'une perte ou une réduction légitime d'historique rende la Plateforme inutilisable.
• Limiter la charge nécessaire à la reconstruction de données fréquemment consultées.
• Séparer la continuité du service de la conservation indéfinie de chaque événement passé.
• Maintenir des règles de conservation différentes selon la finalité des informations.

Les événements n'en deviennent pas inutiles. Ils permettent de conserver l'origine d'une modification, de relier plusieurs conséquences, d'expliquer une correction et de distinguer une valeur établie d'une simple intention. Certains alimenteront l'historique fonctionnel, certains ne seront conservés que dans les traces nécessaires à l'exploitation, et d'autres pourront ne plus être retenus lorsque leur finalité et leur durée de conservation seront épuisées.

L'état actuel et les événements remplissent donc des fonctions complémentaires : l'état répond à la question « Quelle est la situation connue maintenant ? », tandis que les événements permettent notamment de comprendre « Qu'est-il arrivé et comment cette situation a-t-elle évolué ? ».

Dimensions de l'information

L'existence d'une valeur dans Horizon ne suffit pas à garantir qu'elle représente encore correctement la situation réelle. Le Noyau doit pouvoir qualifier plusieurs dimensions indépendantes de cette information lorsque ces distinctions influencent un traitement.

Dimension	Valeurs fonctionnelles indicatives	Question traitée	Comportement général
Disponibilité	Connue / Inconnue	Une valeur exploitable est-elle disponible ?	Une valeur inconnue conduit à rechercher l'information lorsque cela est autorisé ou à appliquer le comportement prévu en son absence.
Fraîcheur	Actuelle / Obsolète	La date d'observation permet-elle encore l'usage envisagé ?	Une valeur obsolète peut rester affichable à titre indicatif tout en exigeant une nouvelle vérification avant une décision sensible.
Confiance	Confirmée / Incertaine	La valeur ou le résultat est-il suffisamment établi ?	Une information incertaine ne doit pas être présentée comme certaine et peut nécessiter une vérification ou une intervention.
Cohérence	Cohérente / En conflit	Les informations disponibles sont-elles compatibles entre elles et avec les règles attendues ?	Un conflit conserve les valeurs concernées et suit les règles d'autorité définies pour la donnée.
Transition	Stable / Modification en attente / Vérification en cours	Une évolution est-elle en cours sans résultat final établi ?	L'intention, la valeur actuelle et le résultat attendu restent distingués jusqu'à la conclusion du traitement.

Ces dimensions sont indépendantes et peuvent se combiner. Une valeur peut être connue mais obsolète, connue mais incertaine, ou en conflit alors que chaque observation est individuellement fiable. Une modification peut être en attente tout en conservant une valeur actuelle connue et confirmée.

Elles constituent un vocabulaire fonctionnel commun et non un enum technique unique. Leur représentation détaillée pourra varier selon la donnée et l'usage sans effacer la distinction entre les questions qu'elles permettent de traiter.

Le Noyau doit également tenir compte de l'usage envisagé. Une information légèrement ancienne peut rester suffisante pour un affichage indicatif, tout en étant trop incertaine pour autoriser une modification sensible. La certitude nécessaire dépend donc de la donnée, de la décision et du risque associé.

Informations externes et conflits

Les informations externes observées appartiennent à l'état connu d'Horizon lorsqu'elles sont nécessaires à son fonctionnement. Elles doivent toutefois conserver leur provenance, leur moment d'observation et l'autorité du service qui les détient réellement.

Lorsqu'une information externe devient contradictoire avec la représentation locale, Horizon ne doit pas conserver silencieusement l'une des valeurs comme si aucune divergence n'existait. Il doit notamment pouvoir :

• Signaler que la donnée est en conflit.
• Identifier les valeurs ou observations incompatibles.
• Conserver la source et le moment de chaque observation utile.
• Demander une nouvelle lecture lorsque cette opération est autorisée et pertinente.
• Appliquer la règle de résolution prévue pour la donnée concernée.
• Suspendre une conséquence qui exige une certitude devenue insuffisante.
• Notifier les responsables lorsqu'une intervention humaine est nécessaire.

Une différence n'autorise pas automatiquement Horizon à modifier le service externe. Si Discord conserve l'autorité sur un rôle Discord, le Noyau peut actualiser sa représentation, signaler l'écart ou demander une action autorisée par l'intermédiaire de l'extension. Il ne doit ni inventer la valeur externe ni considérer l'envoi d'une demande comme la preuve que cette valeur a changé.

La correction automatique d'une donnée interne non sensible reste possible lorsqu'une règle déterministe et préalablement autorisée permet d'établir la valeur correcte. Elle suit alors les principes définis au chapitre 7 : conservation des valeurs avant et après, rattachement au traitement et notification des Super administrateurs ainsi que du Capitaine.

Définition fonctionnelle d'un événement Horizon

Un événement Horizon représente une occurrence contextualisée susceptible d'être examinée par le Noyau. Il peut décrire un fait observé, une demande, une décision, un résultat, une échéance, une anomalie ou un changement produit par la Plateforme.

L'événement ne constitue pas automatiquement :

• Une information fiable.
• Une autorisation.
• Une modification de l'état.
• Une instruction d'exécution.
• Une preuve de réussite.

Il constitue l'entrée ou le résultat d'un traitement dont le Noyau doit déterminer la portée. Un événement signalant un changement de rôle Discord peut être valide, obsolète, répété ou incompatible avec une autre observation. Une demande de modification peut être authentique sans être autorisée. Un résultat d'exécution peut indiquer une réussite, un échec ou une situation encore incertaine.

Le parcours permettant de valider l'événement et d'en produire des conséquences est défini au chapitre 8. Le présent chapitre s'intéresse principalement à la nature de l'information, à sa relation avec l'état et aux liens qu'elle conserve avec les autres événements.

Ce qui ne constitue pas nécessairement un événement fonctionnel

Une consultation sans conséquence sur la Plateforme n'a pas besoin de devenir un événement fonctionnel soumis à l'ensemble du cycle du chapitre 8. L'affichage d'une page publique statique, la lecture d'une documentation ou la récupération d'une ressource inerte ne modifient pas l'état global.

Une lecture de donnée peut néanmoins nécessiter un contrôle de permissions et produire une trace d'accès, notamment lorsqu'elle concerne une information protégée. Cette trace relève de la sécurité et de la journalisation, sans transformer automatiquement la consultation en événement fonctionnel destiné à modifier l'état.

La situation change lorsque la lecture :

• Influence une décision, un calcul ou une action.
• Alimente le contexte transmis à P.O.U.B.E.L.L.E. ou au service LLM.
• Produit une divulgation vers une personne, une interface ou un service.
• Déclenche une correction, une synchronisation ou une notification.
• Modifie un état de connaissance, par exemple en confirmant qu'une donnée externe est actuelle.

Dans ces cas, l'information doit être rattachée au traitement correspondant, car elle contribue effectivement au fonctionnement d'Horizon.

Ce rattachement ne transforme pas nécessairement la lecture en événement autonome. Une valeur consultée peut rester une preuve, une précondition ou une entrée de contexte enregistrée dans le traitement. Un nouvel événement fonctionnel n'est nécessaire que lorsqu'une occurrence distincte doit être comprise, décidée, suivie ou reliée causalement.

Deux axes de classification des événements

La classification d'un événement doit distinguer son origine de sa fonction. Une origine indique qui ou quoi a produit ou transmis l'information. Une fonction indique le rôle que cette information joue dans le traitement.

Lorsque la distinction est utile, l'événement conserve séparément l'acteur concerné, l'entité demandeuse, le service source, la composante technique qui l'a transmis et la fonction qui l'a produit. Une demande humaine transmise par le Poste de commande reste une demande de cette personne ; une observation Twitch traduite par une extension conserve Twitch comme service source.

Origine de l'événement

Un événement peut notamment être produit par :

• Une personne utilisant Twitch, Discord ou le Poste de commande Web.
• P.O.U.B.E.L.L.E. lorsqu'elle consulte Horizon ou demande une action dans le cadre de ses capacités.
• Un service externe par l'intermédiaire d'une extension Horizon.
• Une extension retournant un résultat ou signalant une anomalie.
• Une fonction du Noyau, une règle, une tâche planifiée ou un traitement précédent.

L'origine reste identifiable même lorsqu'un événement traverse plusieurs composantes. Une demande de P.O.U.B.E.L.L.E. transmise par le Noyau ne devient pas une demande humaine. Un événement Twitch traduit par une extension ne devient pas un événement créé par l'extension.

Fonction de l'événement

La fonction permet de distinguer les principales familles suivantes :

Famille fonctionnelle	Rôle général
Observation	Signale un fait ou une situation constatée dans Horizon ou dans un service relié.
Demande	Exprime l'intention d'obtenir une consultation, une modification ou une action.
Décision	Enregistre une confirmation, un refus, une annulation, une expiration ou une autre décision applicable au traitement.
Résultat	Indique ce qu'une conséquence interne ou externe a effectivement produit, ou l'impossibilité de l'établir.
Transition d'état	Signale qu'une information ou un traitement est passé d'un état fonctionnel à un autre.
Échéance	Signale l'arrivée d'un moment prévu, la fin d'une durée de validité ou le déclenchement d'une vérification temporelle.
Anomalie ou conflit	Décrit une incohérence, une divergence, une absence inattendue ou une situation nécessitant une résolution.
Correction	Décrit la résolution appliquée à une donnée, une relation ou un état après les contrôles nécessaires.

Cette typologie reste volontairement générale. Le caractère interne ou externe appartient à l'origine de l'événement et non à sa famille fonctionnelle. Un événement peut être décrit plus précisément dans le système qui l'utilise sans remettre en cause ces familles communes.

Quelques événements représentatifs

Les exemples suivants servent uniquement à illustrer la typologie. Ils ne constituent pas encore le catalogue définitif des événements d'Horizon.

Événement indicatif	Origine	Fonction principale	Effet possible sur l'état
Raid Twitch reçu	Twitch, par l'intermédiaire de l'extension.	Observation.	Création d'un traitement et enregistrement du raid lorsqu'il est validé.
Liaison de comptes demandée	Personne authentifiée dans le Poste de commande.	Demande.	Création d'un état en attente jusqu'aux vérifications et confirmations nécessaires.
Action critique confirmée	Personne habilitée.	Décision.	Autorisation de poursuivre la conséquence concernée si les conditions restent valides.
Rôle Discord attribué	Discord, par le retour de l'extension.	Résultat.	Actualisation de l'information externe observée lorsque le résultat est établi.
Conflit de niveau détecté	Fonction de supervision du Noyau.	Anomalie ou conflit.	Correction interne autorisée ou création d'une demande d'intervention.

Lorsqu'une correction est effectivement appliquée, elle produit un événement dérivé distinct de l'anomalie ou du conflit qui l'a rendue nécessaire. Cette séparation permet de conserver la détection, la décision et le résultat de correction sans les confondre.

Les chapitres consacrés aux systèmes fonctionnels définiront les événements propres aux niveaux, au Protocole de Raid, aux annonces, à la modération et aux autres fonctionnalités. Les parties techniques préciseront ensuite les formats, attributs, protocoles et conditions d'émission nécessaires à leur implémentation.

Contexte minimal d'un événement

Sans imposer encore de structure technique, un événement doit conserver les éléments fonctionnels nécessaires à son interprétation. Selon sa nature, il doit pouvoir être rattaché à :

• Une référence permettant de le distinguer des autres occurrences.
• Une famille fonctionnelle.
• Une origine technique identifiable.
• Un acteur demandeur ou producteur lorsqu'il existe.
• Un moment de production, d'observation ou de réception adapté à sa provenance.
• Une cible et un contexte fonctionnel.
• Un traitement parent ou un événement lié lorsqu'ils existent.
• Les informations strictement nécessaires à sa compréhension.
• Les dimensions de disponibilité, de fraîcheur, de confiance, de cohérence ou de transition pertinentes pour son interprétation.

Ces éléments ne doivent pas devenir une justification pour copier indistinctement toutes les données disponibles. Le contexte conservé et transmis doit respecter la minimisation, la classification et les permissions. Une référence peut parfois suffire là où la reproduction complète d'une donnée sensible serait excessive.

La définition des identifiants, des horodatages, des structures de données et des conventions d'échange sera réalisée dans la Partie XI.

Relations et causalité entre événements

Les événements ne forment pas nécessairement une succession indépendante. Horizon doit pouvoir conserver les relations qui expliquent pourquoi une nouvelle information existe et à quel traitement elle appartient.

Les relations fonctionnelles principales comprennent notamment :

• L'événement à l'origine d'un traitement.
• Le traitement chargé de l'interpréter.
• Les conséquences planifiées ou exécutées.
• Les événements produits par ces conséquences.
• Les résultats retournés par les extensions ou les services externes.
• Les décisions et confirmations rattachées à une conséquence précise.
• Les corrections, reprises ou alertes produites ultérieurement.

Un résultat retourné par Discord après une demande d'attribution de rôle constitue un nouvel événement. Il ne remplace pas l'événement qui a demandé l'action et ne doit pas être confondu avec lui. Il reste lié à la conséquence concernée afin que le Noyau puisse déterminer si l'état externe a réellement changé.

De même, un changement d'état peut produire un nouvel événement fonctionnel. Lorsqu'un gain d'expérience entraîne un changement de niveau, le changement de niveau peut déclencher une réévaluation du grade ou une notification. Ces événements suivent leur propre traitement, mais conservent leur lien causal avec l'évolution qui les a produits.

Les relations doivent permettre de distinguer la causalité, qui indique l'occurrence ayant produit le nouvel événement, et la corrélation, qui rassemble les éléments appartenant à un même parcours fonctionnel. Avant de produire une nouvelle conséquence, le Noyau doit pouvoir reconnaître une chaîne déjà traitée afin qu'un événement de synchronisation ne déclenche pas indéfiniment la synchronisation qui l'a provoqué.

Cette distinction permet :

• D'expliquer l'origine d'une conséquence.
• De suivre plusieurs branches issues d'un même événement.
• De distinguer une reprise légitime d'une répétition accidentelle.
• D'éviter qu'un résultat soit attribué au mauvais traitement.
• De conserver les réussites indépendantes lorsqu'une autre conséquence échoue.

De l'événement à la mise à jour de l'état

Un événement ne modifie pas l'état global au seul motif qu'il a été reçu. La mise à jour intervient lorsque le Noyau a suffisamment établi la nature de l'information, son autorité et le résultat du traitement.

Le comportement général suit les principes suivants :

• Une observation valide peut actualiser l'information connue et son moment d'observation.
• Une demande crée une intention ou un état en attente, sans prouver que la modification souhaitée a eu lieu.
• Une confirmation permet de poursuivre une conséquence, mais ne prouve pas encore son exécution.
• Un résultat établi permet d'enregistrer l'état effectivement atteint.
• Un résultat incertain conserve la distinction entre l'état précédent, l'intention et la situation non confirmée.
• Un conflit est conservé comme tel jusqu'à l'application de la règle de résolution adaptée.
• Une conséquence devenue inutile ou non applicable ne produit pas artificiellement un nouvel état.

Cette progression protège Horizon contre une confusion fréquente entre demande, instruction transmise et résultat obtenu. Si l'extension Discord reçoit l'instruction d'attribuer un rôle, Horizon peut enregistrer une opération en attente. Il ne doit considérer le rôle comme attribué que lorsque le résultat est suffisamment établi.

La mise à jour peut ensuite produire une propagation utile vers les interfaces concernées. Cette propagation dépend des connexions, des permissions et de la finalité. Elle ne signifie ni que toutes les interfaces reçoivent toutes les données ni qu'un changement interne doit être reproduit indistinctement dans chaque service.

Corrections sans réécriture silencieuse

Lorsqu'un événement initial contient une information incorrecte ou qu'une décision ultérieure corrige son effet, Horizon ne doit pas réécrire silencieusement l'événement d'origine comme s'il avait toujours été exact.

La correction doit produire une nouvelle information identifiable qui précise :

• L'événement, la donnée ou le traitement corrigé.
• La différence constatée.
• L'autorité ou la règle ayant permis la correction.
• La valeur précédente lorsque sa conservation est justifiée.
• La nouvelle valeur établie.
• L'acteur ou la fonction ayant effectué la correction.
• Les notifications ou confirmations éventuellement requises.

L'état actuel est alors mis à jour avec la valeur correcte, tandis que les relations entre l'information initiale et la correction permettent d'expliquer l'évolution. Cette règle s'applique aux corrections automatiques autorisées comme aux modifications réalisées par un Super administrateur ou le Capitaine.

Pour une correction automatique déterministe, la valeur précédente et la nouvelle valeur doivent toujours être conservées dans la trace de correction afin de rendre la règle appliquée contrôlable. Pour les autres modifications, la conservation de la valeur précédente dépend de la finalité, de la sensibilité et des règles de conservation applicables. Cette différence de périmètre évite d'imposer un historique illimité à toute modification sans affaiblir l'explicabilité des corrections automatiques.

La conservation précise de ces éléments dépendra de la sensibilité de la donnée et de la finalité. La traçabilité ne doit pas conduire à reproduire inutilement des informations personnelles ou sensibles dans plusieurs journaux.

Schéma de l'état global et des événements

Le schéma suivant présente les principales origines d'événements, leur passage par le Noyau et leur relation avec les différentes composantes de l'état global. Il distingue l'état actuel des informations conservées à des fins d'historique, de journalisation ou de mémoire.

Il représente un modèle fonctionnel et non une architecture de stockage. Les blocs ne préjugent ni du nombre de bases de données ni du découpage futur des services techniques.

FIG. 07 Figure fonctionnelle — Événements contrôlés par le Noyau, dimensions qualifiant les informations de l'état global Horizon et séparation entre état actuel, historique, journalisation et mémoire.

État actuel, historique, journalisation et mémoire

Une même situation peut produire plusieurs formes d'information, mais celles-ci ne répondent pas aux mêmes finalités.

Forme d'information	Question principale	Finalité
État actuel	Quelle est la situation connue maintenant ?	Permettre au Noyau et aux interfaces autorisées de fonctionner à partir des valeurs actuelles.
Historique Horizon	Quelles évolutions fonctionnelles doivent être conservées dans le temps ?	Expliquer un parcours, produire certaines statistiques et conserver les événements pertinents.
Journalisation et audit	Que s'est-il produit pendant le fonctionnement technique et les contrôles ?	Diagnostiquer, superviser, sécuriser et auditer la Plateforme.
Mémoire de P.O.U.B.E.L.L.E.	Quelles informations autorisées peuvent contribuer à la continuité des interactions ?	Fournir un contexte conversationnel sélectionné, révisable et distinct des traces techniques.

L'enregistrement d'une évolution dans l'état actuel ne signifie pas qu'elle doit être conservée indéfiniment dans l'historique. Un événement technique ne devient pas automatiquement un souvenir. Une information mémorisée par P.O.U.B.E.L.L.E. ne constitue pas la preuve d'une action et ne remplace pas les journaux d'audit.

Les règles détaillées seront définies au chapitre 15, 16 et 48.

Garanties fonctionnelles

Le modèle de l'état et des événements doit garantir que :

• Toute information fonctionnelle conserve une origine identifiable.
• Une demande ne soit pas confondue avec un résultat.
• Une instruction transmise ne soit pas présentée comme une action réussie.
• L'état souhaité reste distinct de l'état effectivement établi.
• Une information incertaine ou en conflit ne soit pas présentée comme certaine.
• Une observation externe conserve sa source et son moment d'observation.
• Une correction produise une nouvelle information sans effacer silencieusement son origine.
• Plusieurs conséquences restent rattachées à l'événement et au traitement communs.
• Une répétition ne provoque pas involontairement les mêmes effets.
• L'état actuel reste disponible sans reconstruction intégrale de l'historique.
• Les données soient utilisées, conservées et transmises uniquement selon leur finalité et leurs permissions.
• L'état, l'historique, la journalisation et la mémoire restent fonctionnellement distincts.

Ces garanties décrivent le comportement attendu sans imposer encore une structure de stockage, un format de message ou une technologie particulière.

Limites du modèle fonctionnel

Le présent chapitre ne doit pas être interprété comme :

• Un schéma définitif de base de données.
• Un catalogue exhaustif des événements.
• Une liste complète des données et de leurs attributs.
• Une règle générale de priorité entre Twitch, Discord et Horizon.
• Une obligation de conserver indéfiniment tous les événements reçus.
• Une architecture imposant une file, un bus d'événements ou un mécanisme de rejeu particulier.
• Une autorisation de centraliser toutes les informations disponibles auprès des services reliés.
• Une définition détaillée des permissions, de la classification ou des durées de conservation.

Le catalogue des données, les règles d'autorité et de cohérence, le modèle de permissions, la classification des données et l'architecture technique préciseront ultérieurement ces éléments.

Synthèse de la Partie II

Chapitre	Question traitée	Principe établi
Chapitre 7 — Le Noyau Horizon	Qui contrôle les traitements et les actions d'Horizon ?	Le Noyau constitue l'autorité fonctionnelle et l'orchestrateur coordonne ses fonctions internes.
Chapitre 8 — Cycle de traitement d'un événement	Comment une information devient-elle une décision et des conséquences maîtrisées ?	Tout événement suit un traitement contextualisé, contrôlé et traçable jusqu'à l'établissement de ses résultats.
Chapitre 9 — État global et événements Horizon	Sur quelles informations le Noyau travaille-t-il et comment évoluent-elles ?	Horizon conserve un état actuel cohérent, distingue les dimensions de connaissance et rattache chaque évolution à des événements contextualisés.

La Partie II établit ainsi l'autorité du Noyau, le parcours commun des traitements et le modèle fonctionnel des informations qu'ils mobilisent. La Partie III — Identité et équipage peut désormais définir la première composante majeure de l'état global Horizon : l'identité commune derrière les différents comptes et contextes d'une même personne.