Historique Horizon

L'état global Horizon permet à la Plateforme de connaître directement la situation actuelle sans reconstruire l'ensemble des événements passés. Cette disponibilité immédiate ne suffit cependant pas à expliquer certains parcours, décisions, corrections ou évolutions importantes.

Le présent chapitre définit l'Historique Horizon : un ensemble volontairement sélectionné d'informations passées dont la conservation répond à une utilité fonctionnelle durable. Il précise quels événements peuvent l'alimenter, sous quelle forme les informations sont conservées, comment elles sont corrigées et ce qu'elles deviennent lors d'un départ, d'une fusion ou d'une suppression d'identité.

L'Historique Horizon ne constitue ni une copie intégrale des événements, ni une chronologie exhaustive proposée à chaque membre. Il reste distinct de la mémoire de P.O.U.B.E.L.L.E., des statistiques et profils comportementaux, ainsi que des journaux techniques et traces d'audit qui seront définis au chapitre 48.

Fonctionnement cible — Principes validés

Chaque événement Horizon peut être utilisé ou non à des fins historiques. Sa conservation dépend de sa finalité, de son importance fonctionnelle, de sa sensibilité et de la durée pendant laquelle il reste utile.

L'état actuel est conservé directement. Une nouvelle valeur remplace normalement l'ancienne lorsqu'aucun besoin historique ne justifie de maintenir les valeurs successives.

L'historique personnel reste compact. Horizon conserve les données importantes, quelques jalons, les trois dernières sanctions centralisées et les traces minimales nécessaires, sans enregistrer chaque interaction ni chaque gain d'expérience.

Synthèse normative

• Un Événement Horizon ne doit pas être conservé automatiquement dans l'Historique Horizon.
• Chaque Conservation historique doit répondre à une finalité identifiable.
• L'État actuel doit rester disponible sans rejeu intégral de l'historique.
• Une Information historique doit rester distincte de la valeur actuelle qu'elle contribue à expliquer.
• Une Interaction ordinaire ne doit pas produire systématiquement une entrée historique individuelle.
• Un Message Twitch ou Discord ne doit pas être conservé durablement par défaut dans l'historique.
• Les Gains d'XP individuels ne doivent pas former un historique détaillé.
• Les Valeurs actuelles de progression doivent être conservées directement.
• Les Anciennes valeurs ordinaires de niveau et de grade ne doivent pas être conservées sans jalon particulier.
• Un Succès obtenu doit conserver son état et sa date d'obtention.
• Une Correction ne doit jamais réécrire silencieusement une information historique.
• Une Demande de correction doit rester distincte de la décision et de la correction éventuellement appliquée.
• Les Trois dernières sanctions doivent être conservées de manière centralisée, toutes plateformes confondues.
• Une Restriction encore applicable doit rester dans l'état actuel même lorsqu'elle ne relève plus de l'historique roulant.
• Une Donnée sensible ne doit pas être reproduite inutilement dans une entrée historique.
• Une Modification administrative ne doit pas révéler au membre l'identité de son auteur.
• L'Auteur d'une action administrative sensible doit néanmoins rester identifiable dans la trace d'audit interne appropriée.
• Une Participation communautaire ordinaire doit principalement alimenter les statistiques.
• Un Résultat communautaire notable peut produire un jalon historique individuel.
• Une Fusion doit transférer les informations importantes vers l'identité conservée sans maintenir inutilement les données secondaires.
• Une Migration ne doit pas fabriquer artificiellement un passé qui n'a pas été observé par Horizon.
• Un Changement automatique vers le statut de Visiteur ne doit déclencher aucune suppression ni réinitialisation.
• Un Départ volontaire doit rester distinct d'une demande d'effacement et déclencher une période de sécurité de sept jours avant la réinitialisation prévue.
• Une Exclusion de l'équipage ne doit pas déclencher à elle seule la suppression des données Horizon.
• Un Ancien membre doit pouvoir être reconnu au moyen d'une donnée minimale privée sans conserver toute son ancienne mémoire relationnelle.
• Une Suppression d'identité doit supprimer l'historique personnel, sauf traces minimales encore nécessaires à la sécurité ou à la cohérence.
• L'Historique Horizon, la mémoire de P.O.U.B.E.L.L.E., les statistiques, les journaux techniques et les traces d'audit doivent rester fonctionnellement distincts.

Finalité et périmètre du chapitre

L'Historique Horizon répond principalement à la question suivante :

Quelles évolutions passées doivent rester connues pour comprendre une situation, un parcours ou une décision ?

Il poursuit plusieurs objectifs :

• Expliquer certains éléments importants de la situation actuelle.
• Préserver les principaux jalons d'une Identité Horizon.
• Conserver les décisions limitées dont la consultation reste utile.
• Permettre la correction ou la contestation d'une information sans effacer son origine.
• Maintenir la cohérence après une fusion, un départ, une réintégration ou une migration.
• Fournir aux systèmes spécialisés les références historiques strictement nécessaires.

Le chapitre ne détermine pas à lui seul la durée juridique de conservation, la classification précise ou l'ensemble des permissions. Il définit les besoins fonctionnels et les limites générales. Les règles transversales de vie privée, d'effacement et de conservation seront établies au chapitre 35.

État actuel, événement et information historique

Une même évolution peut produire plusieurs représentations, chacune répondant à une finalité différente.

Élément	Question principale	Exemple
État actuel	Quelle est la situation maintenant ?	Niveau actuel, grade actuel ou sanction encore active.
Événement Horizon	Que vient-il de se produire ou d'être demandé ?	Gain d'XP, départ demandé ou décision de sanction.
Information historique	Quel fait passé reste utile dans le temps ?	Date d'arrivée dans l'équipage ou dernière sanction clôturée.
Statistique	Quelle mesure ou tendance ressort de plusieurs occurrences ?	Temps de présence mensuel ou régularité sur plusieurs semaines.
Souvenir de P.O.U.B.E.L.L.E.	Quelle information sélectionnée peut soutenir une relation future ?	Rencontre marquante ou préférence personnelle autorisée.
Journal technique	Que s'est-il produit dans le fonctionnement interne ?	Échec d'un appel externe ou durée d'un traitement.
Trace d'audit	Qui a autorisé ou exécuté une opération sensible ?	Auteur interne d'une correction administrative.

Un même événement peut contribuer à plusieurs ensembles sans être copié intégralement dans chacun d'eux. Un message Discord peut, par exemple, fournir un contexte temporaire, augmenter un compteur d'activité et provoquer une conséquence fonctionnelle sans devenir une entrée durable de l'historique.

Principe de sélection

L'entrée dans l'Historique Horizon résulte d'une décision fonctionnelle. Elle n'est pas déterminée uniquement par la catégorie de l'événement.

Une information peut être retenue lorsqu'elle :

• Explique une donnée actuelle importante.
• Constitue un jalon significatif du parcours d'une identité.
• Représente une décision encore utile ou récemment applicable.
• Documente une correction ou la résolution d'un conflit.
• Est nécessaire au maintien d'une restriction ou d'une garantie de sécurité.
• Produit un résultat communautaire notable.
• Reste nécessaire après une fusion, une suppression partielle ou une migration.

À l'inverse, une information ne doit pas être conservée durablement lorsque :

• Sa finalité disparaît à la fin du traitement.
• Elle ne fait que répéter une valeur actuelle déjà connue.
• Une statistique agrégée suffit à remplir la finalité.
• Elle reproduit inutilement un contenu personnel ou sensible.
• Elle correspond à une opération technique sans portée fonctionnelle durable.
• Son maintien augmenterait la quantité de données sans améliorer la compréhension ni la sécurité.

Le Noyau applique la règle définie pour la donnée ou le système concerné. Le LLM ne choisit jamais directement ce qui entre dans l'historique.

Formes de conservation historique

L'Historique Horizon ne prend pas nécessairement la forme d'une succession d'entrées narratives. Une information passée peut être conservée sous plusieurs formes.

Forme	Usage	Exemple
Jalon durable	Conserver un fait important et daté.	Date d'arrivée dans l'équipage ou obtention d'un succès.
Historique roulant limité	Conserver seulement les occurrences les plus récentes.	Trois dernières sanctions.
Valeur précédente unique	Faciliter la continuité sans constituer une liste complète.	Pseudonyme précédent sur Twitch, Discord ou Horizon.
Référence de correction	Relier une information erronée à sa rectification.	Succès retiré après vérification.
Trace minimale	Maintenir la sécurité ou la cohérence après suppression des données principales.	Identifiant externe encore associé à une exclusion active.
Situation importée	Établir un point de départ lors d'une migration.	Progression connue au moment de l'import.

Le niveau de détail doit rester proportionné à la finalité. Une trace minimale ne doit pas reconstituer indirectement l'ensemble des données supprimées.

Historique de l'identité et des comptes

L'Identité Horizon reste la référence centrale du parcours de la personne. Les informations historiques utiles peuvent notamment comprendre :

• La Date de création de l'identité.
• La Date et la méthode de revendication.
• La Date d'arrivée dans l'équipage lorsqu'elle reste applicable.
• Les Liaisons actuelles avec Twitch et Discord.
• Les Événements importants de liaison, de retrait ou de fusion.
• Le Pseudonyme Twitch actuel et le précédent.
• Le Pseudonyme Discord actuel et le précédent.
• Le Nom d'affichage Horizon actuel et le précédent.
• La Donnée privée indiquant que la personne est un ancien membre.

Horizon ne conserve pas une liste illimitée des pseudonymes successifs. Lorsqu'un nouveau pseudonyme est établi, il devient la valeur actuelle, l'ancienne valeur actuelle devient la valeur précédente et la valeur précédente plus ancienne peut être supprimée.

Un pseudonyme précédent ne constitue jamais une preuve d'identité. Les liaisons restent fondées sur les identifiants permanents fournis par Twitch ou Discord et sur les vérifications définies au chapitre 11.

Progression conservée

La progression est principalement représentée par son état actuel. Horizon conserve directement les valeurs nécessaires au fonctionnement des systèmes communautaires.

Donnée	Conservation fonctionnelle
Grade	Grade actuel.
Niveau	Niveau actuel.
XP dans le niveau	Quantité acquise dans le niveau courant et quantité nécessaire au prochain niveau.
XP totale	Quantité totale d'XP acquise dans la progression actuelle.
Date de montée de grade	Date d'obtention du grade actuel.
Classe de grade	Classe actuelle, telle que Matelot, Sous-officier, Officier, Amiral ou Amiral de la Tanière.
Date de changement de classe	Date du dernier passage dans une nouvelle classe de grade.

Lorsqu'une personne monte de niveau, l'ancien niveau n'est pas conservé uniquement pour constituer une chronologie. La même règle s'applique aux anciens grades et aux quantités successives d'XP dans le niveau.

Les gains d'XP individuels ne forment pas un historique détaillé. Les agrégations éventuellement nécessaires relèvent du chapitre 17, tandis que les formules, seuils, grades et règles de promotion relèvent du chapitre 26.

Certains jalons exceptionnels peuvent être conservés lorsqu'une règle métier le prévoit, sans créer pour autant un historique exhaustif de la progression.

Succès

Un succès constitue une donnée durable rattachée à l'Identité Horizon. Il possède fonctionnellement :

• Un État indiquant s'il est obtenu ou non.
• Une Date d'obtention lorsque son état est obtenu.

La visibilité publique du succès reste indépendante de sa conservation. Un succès peut être acquis tout en restant privé selon les préférences de la personne et les limites de visibilité applicables.

Lorsqu'un succès est retiré à la suite d'une erreur ou d'une correction :

• Son État repasse à non obtenu.
• Sa Date d'obtention est supprimée.
• Une Trace limitée de la correction est conservée lorsqu'elle reste nécessaire à l'explication ou au contrôle.
• L'Ancienne obtention ne reste pas affichée comme un succès valide.

Le catalogue, les conditions et les éventuelles progressions des succès seront définis dans les systèmes communautaires concernés.

Sanctions et demandes de débannissement

Les sanctions pertinentes sont centralisées dans Horizon, quelle que soit leur origine sur Twitch, Discord ou Horizon. L'historique conserve les trois dernières sanctions toutes plateformes confondues.

Pour chaque sanction, la présentation communicable se limite notamment à :

• La Décision.
• La Durée.
• Le Motif communicable.

Lorsqu'une quatrième sanction est ajoutée, la plus ancienne peut être supprimée si aucune autre finalité ne justifie sa conservation. Une restriction encore active demeure toutefois dans l'état actuel aussi longtemps qu'elle reste applicable. Elle ne disparaît pas uniquement parce qu'elle sort d'un historique roulant.

La limite de trois sanctions ne suffit pas à justifier une conservation indéfinie. Les sanctions closes doivent également faire l'objet d'une durée ou d'un réexamen périodique défini au chapitre 35. Une sanction très ancienne ne reste donc pas automatiquement conservée au seul motif qu'aucune sanction plus récente ne l'a remplacée.

Une personne reconnue comme exclue peut déposer une demande de débannissement lors de sa connexion au Poste de commande. La demande, la décision et son résultat sont conservés selon un principe limité comparable à celui des sanctions.

Les éléments internes de modération, les preuves, les échanges complets et l'identité des responsables ne sont pas exposés dans l'historique personnel. Les règles métier de modération seront définies au chapitre 29, tandis que les permissions et durées de conservation seront établies dans les chapitres spécialisés.

Corrections et contestations

Une personne peut demander la correction ou contester une information depuis le Poste de commande. Cette capacité ne lui permet jamais de modifier directement l'état actuel ou l'historique.

La procédure distingue :

1. La Demande formulée par la personne.
2. La Décision prise après vérification.
3. La Correction appliquée lorsque la demande est acceptée.

Une correction crée une nouvelle information reliée à l'élément corrigé. L'élément précédent peut être marqué comme corrigé, annulé ou remplacé selon la situation. L'interface présente ensuite la valeur actuellement reconnue comme correcte sans supprimer silencieusement l'origine de la rectification.

L'historique visible par le membre ne signale pas qu'une modification a été réalisée par un administrateur et ne révèle pas l'identité de cet administrateur. Lorsque l'opération est sensible, l'auteur réel, son motif et les contrôles appliqués restent conservés dans une trace d'audit interne distincte.

Participation communautaire

Les participations ordinaires aux directs, raids, missions, défis ou autres activités ne produisent pas systématiquement une entrée historique individuelle. Elles alimentent principalement les données et agrégations définies au chapitre 17.

Un événement communautaire peut néanmoins produire un jalon individuel lorsqu'il entraîne :

• Un Succès.
• Une Récompense durable.
• Une Responsabilité particulière.
• Une Participation exceptionnelle reconnue par une règle métier.
• Un Résultat personnel significatif.

La participation aux raids peut ainsi contribuer aux tendances calculées à moyen ou long terme sans occuper une place disproportionnée dans l'historique personnel.

Relation avec les trois niveaux de mémoire

P.O.U.B.E.L.L.E. utilisera trois niveaux de mémoire dont le fonctionnement détaillé sera défini au chapitre 16.

Niveau	Orientation fonctionnelle
Court terme	Conserver pendant une durée initiale configurable de vingt-quatre heures les interactions récentes utiles à la compréhension de la situation immédiate.
Moyen terme	Conserver pendant quelques mois des statistiques simples et tendances récentes, comme la régularité ou le délai moyen d'arrivée.
Long terme	Mobiliser les données durables actuelles et un nombre très limité de souvenirs relationnels sélectionnés.

Ces niveaux ne constituent pas trois historiques généraux. Une interaction peut rester disponible à court terme sans entrer dans l'Historique Horizon. Une statistique à moyen terme est une agrégation et non une collection de chaque événement d'origine. Un niveau ou un grade consulté à long terme reste une donnée actuelle.

La mémoire relationnelle durable de P.O.U.B.E.L.L.E. restera limitée à environ dix informations par identité. Elle pourra comprendre une rencontre marquante, une plaisanterie récurrente, une préférence personnelle ou une perception synthétique de la personnalité. Ces souvenirs suivent leurs propres règles de sélection, de révision et d'oubli.

Consultation et présentation

Le Poste de commande ne propose pas nécessairement une chronologie générale regroupant chaque action d'une personne. Il présente surtout les informations importantes dans les espaces où elles sont utiles.

Une personne peut notamment consulter, selon les permissions et la visibilité applicables :

• Sa Date d'arrivée dans l'équipage.
• Sa Progression actuelle.
• Ses Succès obtenus.
• La Situation de ses comptes liés.
• Ses Sanctions communicables récentes.
• Ses Demandes de correction ou de débannissement.
• Certains Jalons communautaires significatifs.

Les informations présentées au membre doivent employer des formulations fonctionnelles compréhensibles. Les identifiants techniques, détails d'exécution, preuves internes et traces d'audit restent absents des vues ordinaires.

Un membre peut rendre publics les éléments dont la publication est autorisée, comme certains succès, son grade ou des informations de profil. Cette publication ne rend pas public l'ensemble de son historique et reste soumise aux préférences et limites définies pour chaque donnée.

Changement de statut, départ volontaire, exclusion et effacement

Horizon distingue quatre situations qui ne produisent pas les mêmes effets.

Situation	Événement fonctionnel	Effet immédiat	Effet sur les données
Perte simultanée des appartenances externes	Changement automatique de statut.	L'identité devient Visiteur.	Aucune suppression ni réinitialisation n'est déclenchée.
Départ demandé depuis le Poste de commande	Demande de départ.	L'identité devient Visiteur et la réentrée automatique est bloquée.	Une période de sécurité de sept jours calendaires commence avant la réinitialisation prévue.
Exclusion décidée par Horizon	Décision d'exclusion.	L'identité devient Exclue de l'équipage.	Les restrictions s'appliquent, mais l'exclusion ne déclenche pas à elle seule un effacement.
Demande d'effacement	Demande d'effacement.	Une procédure dédiée est ouverte après identification et confirmation.	Les données sont traitées selon leur finalité, leur sensibilité et les règles du chapitre 35.

La perte automatique des appartenances externes n'est donc ni un départ volontaire ni une demande d'effacement. Les données de progression, l'historique, les statistiques, le profil et la mémoire restent associés à l'Identité Horizon selon leurs règles ordinaires. Si la personne remplit de nouveau une condition d'entrée, les données encore valides redeviennent utilisables sans restauration particulière.

Une exclusion protège la Plateforme et maintient les informations nécessaires à la restriction, à la contestation et à la demande de débannissement. Elle ne sert pas de mécanisme indirect de suppression des données personnelles.

Période de sécurité après un départ volontaire

Seule une demande volontaire de départ déclenche la période de sécurité de sept jours calendaires précédant la réinitialisation fonctionnelle décrite dans ce chapitre. Cette durée constitue une exigence fonctionnelle validée.

Pendant cette période :

• Les Permissions et responsabilités dépendant du statut de membre cessent de produire leurs effets.
• Les Données destinées à être réinitialisées restent temporairement archivées.
• La Personne peut annuler sa demande selon la procédure prévue.
• Aucune Suppression définitive ne doit intervenir avant l'expiration du délai.

Le retour automatique provoqué par une nouvelle interaction ne suffit pas à annuler un départ volontaire. Une demande explicite de retour ou d'annulation est nécessaire.

Réinitialisation définitive après un départ volontaire

À l'expiration des sept jours, le départ volontaire devient définitif. Aucune restauration automatique des données supprimées n'est alors possible.

Données réinitialisées ou supprimées

• L'XP totale de la progression quittée.
• L'XP acquise dans le niveau.
• Le Niveau.
• Le Grade.
• La Classe de grade.
• Les Dates associées à la progression supprimée.
• Les Souvenirs personnels durables de P.O.U.B.E.L.L.E.
• Les Responsabilités et distinctions dépendant de l'appartenance à l'équipage.

La distinction de Membre honorifique suit le même délai de sécurité de sept jours avant son retrait définitif.

Données minimales conservées

• L'Identité Horizon.
• Les Comptes Twitch et Discord liés.
• Les Pseudonymes actuels et précédents autorisés.
• Le Nom d'affichage Horizon actuel et précédent.
• Les Succès obtenus et leurs dates.
• Les Trois dernières sanctions selon leurs règles propres.
• Les Restrictions encore applicables.
• Les Demandes de débannissement encore nécessaires.
• Les Traces minimales de fusion, de correction et de sécurité.
• La Donnée privée ancien membre.

La donnée ancien membre est uniquement accessible aux fonctions Horizon autorisées et à P.O.U.B.E.L.L.E. Elle ne doit pas être affichée publiquement ni devenir un moyen indirect de reconstituer l'ancienne activité de la personne.

La présence d'une donnée dans cette liste n'autorise pas sa conservation sans limite. Les pseudonymes précédents, succès, sanctions closes, demandes terminées, traces de sécurité et donnée ancien membre doivent disposer d'une durée, d'un critère de suppression ou d'un réexamen périodique dans le chapitre 35. Leur finalité reste définie séparément.

Retour d'un ancien membre

Lorsqu'une personne revient après un départ volontaire devenu définitif :

• Son Identité Horizon existante est réutilisée.
• Sa Progression reprend depuis l'état initial défini par le système de progression.
• Ses Succès précédemment conservés restent acquis.
• Ses Anciennes responsabilités ne sont pas restaurées automatiquement.
• Ses Anciens souvenirs relationnels ne sont pas restaurés.
• Ses Sanctions ou restrictions encore applicables restent prises en compte.
• La Donnée ancien membre permet à P.O.U.B.E.L.L.E. d'adapter son accueil.

P.O.U.B.E.L.L.E. peut reconnaître qu'il s'agit d'un ancien membre et produire une formule d'accueil adaptée. Elle ne doit cependant pas prétendre se souvenir d'informations relationnelles supprimées ni reconstruire artificiellement une ancienne proximité.

Fusion d'identités

Lors d'une fusion d'identités, l'identité la plus ancienne reste la référence conservée. Les informations importantes de l'autre identité sont transférées ou consolidées selon leurs règles propres.

La fusion applique notamment les principes suivants :

• Les Données actuelles sont sélectionnées ou consolidées selon les règles métier applicables.
• Les Succès sont conservés lorsqu'ils sont valides.
• Les Sanctions encore retenues sont réunies puis limitées selon la règle des trois dernières sanctions centralisées.
• Les Informations non importantes ou devenues redondantes peuvent être supprimées.
• Une Trace minimale de la fusion empêche la réutilisation incohérente de l'ancienne identité.
• Aucune Chronologie artificielle ne doit être créée à partir de données insuffisantes.

L'identité secondaire suit ensuite le cycle d'archivage temporaire et de suppression défini au chapitre 12.

Migration depuis les systèmes existants

Lors de la migration vers Horizon, seules les informations réellement disponibles et suffisamment fiables sont importées. Horizon crée une situation initiale importée indiquant que les valeurs constituent un point de départ et non un historique complet du passé.

La migration peut notamment reprendre :

• La Progression actuelle connue.
• Les Succès dont l'obtention peut être établie.
• Les Comptes et pseudonymes actuellement reconnus.
• Les Statuts, responsabilités et restrictions encore applicables.
• Les Jalons dont la date et la signification sont suffisamment fiables.

Horizon ne doit pas fabriquer des événements intermédiaires pour expliquer rétrospectivement une valeur importée. La provenance, la date d'import et le niveau de confiance de la donnée doivent rester identifiables.

Suppression d'une Identité Horizon

Lorsqu'une Identité Horizon est supprimée, son historique personnel disparaît avec elle, sous réserve des traces minimales encore nécessaires.

Peuvent notamment subsister :

• Les Références indispensables à la cohérence d'une fusion.
• Les Identifiants externes strictement nécessaires au maintien d'une exclusion applicable.
• Les Traces imposées par une obligation de sécurité ou de responsabilité.
• Les Informations anonymisées dont la conservation reste légitime.

Ces éléments sont séparés de l'identité supprimée. Ils ne doivent pas permettre aux interfaces ordinaires de reconstituer le profil, l'activité ou les souvenirs de la personne.

Les identifiants nécessaires au maintien d'une exclusion sont placés dans un registre de restriction distinct. Une entrée de ce registre conserve uniquement les éléments nécessaires à sa finalité, notamment la portée de la restriction, son motif, sa durée ou sa condition de réexamen et les personnes autorisées à la consulter. Elle est pseudonymisée lorsque cette protection reste compatible avec l'efficacité de la restriction.

Ce registre ne constitue ni une Identité Horizon active ni un historique personnel résiduel. Il ne peut être utilisé pour restaurer le profil supprimé ou poursuivre des finalités communautaires ordinaires.

Une suppression ne doit pas permettre de contourner une exclusion en recréant immédiatement une identité depuis le même compte externe. Les règles de suppression, d'anonymisation et de durée seront précisées au chapitre 35.

Cycle fonctionnel d'une information historique

La figure suivante présente la sélection d'une information après le traitement d'un événement. Elle montre qu'un même événement peut mettre à jour l'état actuel, alimenter une statistique ou un contexte temporaire sans devenir automatiquement une information historique durable.

FIG. 13 Cycle fonctionnel — Sélection, conservation et devenir d'une information historique Horizon.

Garanties fonctionnelles

L'Historique Horizon doit garantir les principes suivants :

• La Situation actuelle reste accessible sans reconstruction intégrale du passé.
• La Conservation d'une information répond toujours à une finalité définie.
• Les Interactions ordinaires ne produisent pas une accumulation illimitée d'entrées.
• Les Valeurs successives sans utilité historique peuvent être remplacées.
• Les Jalons importants restent compréhensibles sans exposer les détails techniques.
• Les Corrections conservent une relation avec l'information corrigée.
• Les Sanctions actives ne disparaissent pas en raison d'une limite d'historique.
• Les Données privées ne deviennent pas publiques parce qu'elles possèdent une dimension historique.
• Les Membres ne peuvent pas modifier directement leurs informations historiques.
• Les Auteurs d'opérations sensibles restent identifiables dans les traces internes nécessaires.
• Les Changements automatiques de statut ne provoquent aucune suppression de données.
• Les Départs volontaires bénéficient d'un délai permettant leur annulation.
• Les Exclusions ne deviennent pas des procédures d'effacement implicites.
• Les Départs volontaires devenus définitifs ne maintiennent pas inutilement une mémoire relationnelle complète.
• Les Anciens membres peuvent être reconnus sans restauration automatique de leur progression ou de leurs souvenirs.
• Les Fusions et migrations ne créent pas de faux événements.
• Les Suppressions ne peuvent pas être contournées par des copies historiques injustifiées.
• Les Restrictions nécessaires à la sécurité restent applicables après la suppression des données ordinaires.

Limites du présent chapitre

Le présent chapitre définit la sélection et le cycle fonctionnels des informations historiques. Les domaines suivants relèvent de leurs chapitres maîtres :

• L'État global et les événements relèvent des chapitres 8 et 9.
• L'Identité Horizon et le statut communautaire relèvent du chapitre 10.
• Les Liaisons de comptes relèvent du chapitre 11.
• Les Fusions d'identités relèvent du chapitre 12.
• Le Catalogue fonctionnel des données relève du chapitre 13.
• Les Autorités, priorités et conflits relèvent du chapitre 14.
• Les Trois niveaux de mémoire de P.O.U.B.E.L.L.E. relèvent du chapitre 16.
• Les Agrégations et profils comportementaux relèvent du chapitre 17.
• Les Règles détaillées de progression relèvent du chapitre 26.
• Les Règles de modération relèvent du chapitre 29.
• Les Permissions, classifications et durées de conservation relèvent des chapitres 32 à 35.
• La Traduction technique des données historiques relève du chapitre 43.
• Les Journaux techniques, traces d'audit et outils de diagnostic relèvent du chapitre 48.
• Le Catalogue exhaustif des données historiques sera complété dans la future Annexe F après la stabilisation des chapitres spécialisés.

Synthèse

L'Historique Horizon conserve uniquement les informations passées dont l'utilité reste identifiable. Il ne remplace pas l'état actuel et ne cherche pas à enregistrer chaque interaction, chaque variation d'XP ou chaque opération technique. Les valeurs courantes restent directement disponibles, tandis que les jalons, historiques roulants, valeurs précédentes et traces minimales sont sélectionnés selon leur finalité.

La progression conserve le grade, le niveau, l'XP dans le niveau, l'XP totale et les dates structurantes actuellement applicables. Les succès restent des données durables. Les sanctions sont centralisées et limitées aux trois dernières, sans supprimer une restriction encore active. Les participations ordinaires alimentent principalement les statistiques.

La perte automatique des appartenances externes entraîne uniquement un passage au statut de Visiteur et ne supprime aucune donnée Horizon. Un retour réutilise alors les informations encore valides. Le départ volontaire déclenche une période de sécurité de sept jours puis, s'il n'est pas annulé, la réinitialisation de la progression et des souvenirs relationnels prévue. Une exclusion maintient ses restrictions sans devenir un effacement implicite, tandis qu'une demande d'effacement suit une procédure autonome.

Le chapitre 16 peut désormais définir les trois niveaux de mémoire de P.O.U.B.E.L.L.E., leurs durées, leurs contenus et les règles permettant de sélectionner, résumer, remplacer ou oublier les informations accessibles lors de futures interactions.