Rattachement, autorité, priorité et cohérence des données

Le chapitre 13 a identifié les principales familles de données dont Horizon a besoin. Le présent chapitre définit les règles permettant de déterminer qui fait autorité sur chaque donnée, comment Horizon maintient une représentation cohérente de sa valeur et quel comportement adopter lorsqu'une information devient indisponible, obsolète, incertaine ou conflictuelle.

Horizon relie plusieurs espaces qui conservent leurs propres responsabilités. Twitch reste l'autorité sur les informations natives de Twitch. Discord conserve la même responsabilité pour ses données. Horizon fait autorité sur ses identités, ses règles communes, ses valeurs calculées et ses paramètres internes. Une personne conserve la maîtrise des informations déclaratives qu'elle fournit dans les limites applicables.

Cette répartition ne forme pas une hiérarchie générale entre les plateformes. Elle doit être définie donnée par donnée, en fonction du rôle de l'information et de sa finalité.

Fonctionnement cible — Principes validés

Chaque donnée canonique possède une autorité fonctionnelle identifiable. Plusieurs sources peuvent contribuer à un calcul, mais elles ne deviennent pas toutes autorités sur le résultat.

Une différence confirmée par l'autorité fonctionnelle constitue une évolution normale. Une divergence ne devient un conflit que lorsqu'Horizon ne peut pas établir de manière suffisamment fiable la valeur applicable ou la conséquence à produire.

Une absence de réponse ne signifie jamais automatiquement qu'une donnée est fausse ou inexistante. Horizon distingue toujours une valeur absente, une valeur inconnue, une valeur obsolète et une valeur en conflit.

Synthèse normative

• Chaque Donnée canonique doit posséder une autorité fonctionnelle identifiable.
• Une Donnée peut provenir d'une source distincte de l'autorité qui établit sa valeur finale.
• Une Source doit décrire la provenance d'une observation, tandis que l'autorité fonctionnelle établit la valeur canonique.
• Une Valeur proposée, une valeur canonique acceptée et une représentation affichée doivent rester distinctes lorsqu'elles répondent à des décisions différentes.
• Une Copie locale ne doit jamais devenir l'autorité par le seul fait qu'Horizon la conserve.
• Twitch doit rester l'autorité sur les données natives de Twitch.
• Discord doit rester l'autorité sur les données natives de Discord.
• Horizon doit rester l'autorité sur ses identités, ses règles communes, ses valeurs calculées et ses paramètres propres.
• Une Personne doit conserver la décision sur ses informations déclaratives autorisées.
• Le Poste de commande doit rester une interface d'accès et non une autorité concurrente.
• P.O.U.B.E.L.L.E. peut demander certaines modifications autorisées, mais le Noyau doit en conserver le contrôle.
• Le LLM ne doit disposer d'aucune autorité directe sur les données.
• Une Valeur externe doit conserver sa source et son moment d'observation.
• Une Valeur obsolète ne doit pas être présentée comme actuelle.
• Une Source inaccessible ne doit pas être interprétée comme une réponse négative.
• Une Modification externe demandée ne doit pas être présentée comme exécutée avant confirmation.
• Un Événement ancien reçu tardivement ne doit pas écraser une valeur plus récente déjà validée.
• Une Permission sensible ne doit pas être accordée à partir d'une information insuffisamment vérifiée.
• Une Restriction déjà connue doit rester provisoirement applicable tant que sa levée n'est pas établie.
• Une Correction automatique doit rester déterministe, contrôlée et limitée aux cas autorisés.
• Une Résolution humaine doit conserver son auteur, son motif, sa portée et les valeurs concernées.
• Une Règle de sélection ne doit pas être confondue avec un calcul, une stratégie de fusion ou un arbitrage.
• Les Propriétés détaillées de chaque donnée devront être définies dans la future Annexe F.

Finalité et périmètre du chapitre

Le chapitre répond à quatre questions principales :

1. Quel acteur, système ou service fait autorité sur la donnée ?
2. Comment Horizon obtient-il et actualise-t-il la valeur qu'il utilise ?
3. Quelle valeur doit être retenue lorsque plusieurs valeurs candidates existent ?
4. Que doit faire Horizon lorsqu'aucun résultat suffisamment fiable ne peut être établi ?

Le rattachement indique le sujet fonctionnel décrit par une donnée. La responsabilité fonctionnelle précise ensuite les rôles des acteurs et systèmes qui la produisent, la conservent, la contrôlent ou établissent sa valeur canonique. Ces notions ne définissent ni une propriété juridique ni les droits réglementaires de la personne concernée, qui seront traités dans les chapitres consacrés à la classification, à la vie privée et à la conservation.

Le chapitre ne définit pas non plus :

• Le Schéma technique de la base de données.
• Les Protocoles précis d'interrogation des services externes.
• Les Durées de rafraîchissement de chaque champ.
• Les Formules métier produisant les valeurs calculées.
• La Matrice complète des permissions.
• Les Durées légales ou opérationnelles de conservation.

Ces éléments relèveront de la future Annexe F et des chapitres spécialisés.

Les rôles fonctionnels autour d'une donnée

Une même donnée peut faire intervenir plusieurs acteurs sans que leurs responsabilités soient équivalentes.

Rôle	Question traitée	Exemple
Sujet	Quelle personne, relation, procédure ou composante la donnée décrit-elle ?	Une Identité Horizon, un compte Twitch ou un protocole.
Origine	Où l'information ou la modification est-elle apparue ?	Un événement Twitch ou une demande depuis le Poste de commande.
Producteur	Quel acteur ou système a communiqué ou calculé la valeur ?	Twitch, Discord, le Noyau ou une personne.
Autorité fonctionnelle	Quel acteur, service ou règle établit la valeur canonique ?	Twitch pour l'état de follow.
Détenteur	Quel système conserve actuellement une représentation de la donnée ?	Horizon conservant le dernier pseudonyme Discord observé.
Modificateur autorisé	Qui peut demander ou provoquer une évolution ?	Une personne modifiant sa description Horizon.
Validateur	Quelle composante vérifie que la modification peut être acceptée ?	Le Noyau appliquant les règles et permissions.
Interface de consultation	Où la valeur peut-elle être affichée ou administrée ?	Le Poste de commande, Twitch ou Discord.

Ces rôles peuvent être portés par le même système. Horizon produit, conserve et contrôle par exemple l'Identifiant Horizon. Ils peuvent également être répartis : une personne propose son nom d'affichage, le Poste de commande reçoit sa demande, Horizon établit la valeur canonique acceptée et l'interface en produit une représentation affichée.

Le terme source désigne la provenance d'une observation ou d'une demande. Il ne constitue pas un synonyme général d'autorité. Lorsqu'un service externe est à la fois la provenance et l'autorité native, les deux rôles coïncident sans se confondre.

Autorité et droit de modification

Faire autorité ne signifie pas nécessairement être la seule entité capable de provoquer une modification.

La confiance relationnelle avec P.O.U.B.E.L.L.E. constitue une donnée Horizon. P.O.U.B.E.L.L.E. et un Super administrateur peuvent demander certaines modifications dans le cadre prévu, mais le Noyau reste responsable de leur validation et Horizon demeure l'autorité sur la valeur enregistrée.

Toute évolution de la confiance relationnelle ou de la proximité conserve l'ancienne valeur, la nouvelle valeur, la cause ou la règle appliquée, l'événement associé, la date et le traitement responsable. Ces indicateurs ne peuvent jamais, à eux seuls, accorder ou retirer une permission, déclencher une sanction ou produire une action critique.

Inversement, un Super administrateur peut consulter une donnée Twitch ou demander sa revérification sans devenir l'autorité sur le fait externe qu'elle représente.

Autorité et visibilité

L'autorité d'une donnée ne détermine pas sa visibilité. Twitch peut faire autorité sur un pseudonyme alors qu'Horizon conserve la liaison entre ce compte et une Identité Horizon comme information privée. De la même manière, Horizon peut faire autorité sur l'XP sans que cette valeur soit automatiquement publique.

Principe d'autorité unique

Chaque donnée canonique finale possède une autorité fonctionnelle identifiable. Cette règle évite qu'une même valeur puisse être déclarée simultanément correcte par plusieurs systèmes indépendants.

Une donnée canonique est la valeur fonctionnelle de référence utilisée par Horizon pour une notion donnée. Elle peut être :

• Une Valeur native d'un service externe.
• Une Valeur propre à Horizon.
• Une Valeur déclarée puis contrôlée par Horizon.
• Une Valeur calculée à partir de plusieurs données sources.
• Un État opérationnel établi après confirmation d'une exécution.

Plusieurs sources peuvent contribuer à une donnée canonique sans partager l'autorité sur le résultat.

Par exemple :

• Twitch fait autorité sur l'existence d'un follow Twitch.
• Discord fait autorité sur l'appartenance au serveur communautaire.
• Horizon fait autorité sur le statut de Membre d'équipage calculé à partir de ses propres règles et des conditions observées.

Une autorité unique ne signifie pas qu'une valeur ne peut jamais évoluer. Elle indique simplement quel système doit être consulté ou quelle règle doit être appliquée pour déterminer la situation correcte.

Répartition générale des autorités

La répartition suivante constitue le cadre général. La future Annexe F précisera l'autorité applicable à chaque donnée détaillée.

Famille de données	Autorité fonctionnelle	Précision
Identité Horizon	Horizon.	Horizon définit l'identifiant, les états d'existence et la revendication.
Compte Twitch	Twitch.	Twitch définit l'identifiant, le pseudonyme, l'existence ou le statut natif lorsqu'il l'expose, ainsi que les autres données natives du compte.
Compte Discord	Discord.	Discord définit l'identifiant, le pseudonyme, l'appartenance et les autres données natives du compte.
Liaison de compte	Horizon.	Horizon établit la relation vérifiée entre une identité et un compte externe.
Observabilité d'un compte externe	Horizon.	Horizon établit ce qu'il peut actuellement observer, à partir d'un constat daté qui peut devenir ancien ou inconnu.
Utilisabilité locale d'un compte	Horizon.	Horizon applique les autorisations, permissions et états techniques nécessaires à une fonction précise.
Autorisation OAuth native	Le fournisseur concerné.	Le fournisseur établit l'existence, la validité ou la révocation de l'autorisation qu'il délivre.
État observé de l'autorisation OAuth	Horizon.	Horizon conserve une représentation datée de la situation communiquée ou vérifiée.
Conservation technique du jeton OAuth	Horizon.	Horizon contrôle la présence, la protection et la suppression du moyen technique local sans décider de sa validité native.
Droit fonctionnel d'usage OAuth	Horizon.	Le Noyau décide si une fonction peut employer l'autorisation selon les permissions et le contexte.
Valeur de profil proposée	La personne.	La personne choisit le contenu soumis à Horizon dans les limites prévues.
Valeur de profil canonique acceptée	Horizon.	Horizon applique les règles, accepte ou refuse la proposition et conserve la valeur de référence.
Représentation affichée du profil	Horizon pour la règle de présentation.	L'interface applique le contexte, la langue et la visibilité effective sans redéfinir la valeur canonique.
Préférence de visibilité	La personne.	La personne choisit la présentation souhaitée pour une donnée modifiable.
Limite maximale de visibilité	Horizon.	Les permissions, la classification et les règles de sécurité fixent ce qui peut être divulgué.
Visibilité effective	Horizon.	Le Noyau combine la préférence avec les limites applicables pour établir la présentation réellement autorisée.
Statut communautaire	Horizon.	Horizon applique les conditions définies pour La Tanière.
Rôles et sanctions Twitch	Twitch.	Horizon peut traduire leurs conséquences sans modifier le fait natif.
Rôles et sanctions Discord	Discord.	Horizon peut traduire leurs conséquences sans modifier le fait natif.
Responsabilités propres à Horizon	Horizon.	Le Noyau applique les attributions et retraits autorisés.
Progression, niveau et grade	Horizon.	Les événements externes peuvent contribuer au calcul sans faire autorité sur le résultat.
Confiance et proximité avec P.O.U.B.E.L.L.E.	Horizon.	P.O.U.B.E.L.L.E. et les Super administrateurs disposent de capacités de modification encadrées.
État réel d'un service externe	Le service concerné.	Horizon n'en conserve qu'une observation ou un résultat communiqué.
État d'un traitement Horizon	Horizon.	Le Noyau établit l'état fonctionnel courant du traitement.
Intention d'action externe	Horizon.	Le Noyau établit ce qu'Horizon souhaite demander après les contrôles applicables.
Exécution et état réel externes	Le service concerné.	Le résultat communiqué ou observé reste distinct de l'intention et de la demande transmise.
Résultat calculé ou dérivé	Horizon.	La validité du résultat dépend néanmoins de celle de ses données sources.
Souvenir de P.O.U.B.E.L.L.E.	Horizon selon les règles de mémoire.	Le LLM ne choisit ni ne conserve directement un souvenir.

Absence de priorité générale entre plateformes

Twitch, Discord et Horizon ne forment pas une hiérarchie universelle. Twitch n'est pas prioritaire sur Discord pour toutes les données, et le Poste de commande n'est pas prioritaire parce qu'une modification y est réalisée par une personne authentifiée.

La règle applicable dépend toujours :

• De la Donnée concernée.
• De son Autorité fonctionnelle.
• Du Rôle de l'opération.
• De l'Autorisation de l'auteur.
• De la Fraîcheur des valeurs disponibles.
• De la Stratégie définie pour cette donnée.

Données déclarées par une personne

Les informations déclaratives comprennent notamment le nom d'affichage Horizon, la description, les pronoms, la langue, les préférences de notification et les préférences de visibilité.

La personne décide du contenu qu'elle propose dans les limites prévues. Horizon :

• Vérifie que la demande provient d'une session ou d'une commande autorisée.
• Contrôle la forme, les limites et les règles applicables.
• Établit et conserve la valeur canonique acceptée.
• Calcule la visibilité effective à partir de la préférence et des limites autorisées.
• Produit l'événement ou la trace nécessaire.
• Permet la modification ou le retrait lorsque cette capacité est autorisée.

La proposition, la valeur canonique acceptée et la représentation affichée sont trois données ou états distincts. Une interface peut adapter la présentation d'une valeur canonique sans acquérir d'autorité sur son contenu. Une proposition refusée ne remplace jamais silencieusement la valeur actuelle.

Une fonction de modération peut masquer ou retirer un contenu contraire aux règles, mais elle ne doit pas remplacer arbitrairement une information personnelle par une autre. La personne doit être informée lorsque la décision peut lui être communiquée sans compromettre la sécurité ou une procédure en cours.

Une information déclarative ne peut pas remplacer une donnée native externe. Une personne peut choisir son nom d'affichage Horizon, mais elle ne peut pas déclarer elle-même qu'un compte Twitch est follower ou qu'un rôle Discord lui appartient.

Représentations locales des données externes

Horizon peut conserver une représentation locale d'une donnée externe lorsque cette copie est nécessaire à son fonctionnement, à sa continuité ou à l'explication d'un traitement.

Cette représentation peut contenir :

• La Dernière valeur connue.
• La Source de la valeur.
• Le Moment de l'occurrence lorsqu'il est connu.
• Le Moment de réception ou d'observation.
• Le Moment de la dernière vérification.
• La Version ou révision communiquée par la source lorsqu'elle existe.
• L'Identifiant externe permettant la corrélation ou la déduplication lorsqu'il existe.
• L'État de disponibilité.
• L'État de fraîcheur.
• L'État de confiance de l'information.
• L'État de cohérence.
• L'Éventuelle transition en cours.

La représentation locale ne devient pas l'autorité par le seul fait qu'elle est disponible plus rapidement ou qu'elle est conservée dans la base de données Horizon.

Existence native, observabilité et utilisabilité locale

Pour un compte ou une capacité externe, Horizon distingue trois informations :

Information	Autorité ou établissement	Signification
Existence ou état natif	Service externe lorsqu'il expose cette information.	Le compte ou la capacité existe-t-il selon son fournisseur ?
Observabilité ou accessibilité	Horizon à partir d'un constat daté.	Horizon peut-il actuellement consulter ou recevoir l'information utile ?
Utilisabilité locale	Horizon selon ses règles.	Horizon peut-il employer cette information ou cette autorisation pour la fonction demandée ?

Un compte peut exister sans être momentanément observable. Une donnée observable peut également rester inutilisable localement en raison d'une autorisation absente, d'une permission insuffisante ou d'une indisponibilité technique.

Valeur absente, inconnue et indisponible

Les situations suivantes doivent rester distinctes :

Situation	Signification
Valeur présente	La source confirme qu'une valeur existe.
Valeur absente	La source confirme suffisamment que la donnée n'existe pas ou plus.
Valeur inconnue	Horizon ne dispose pas d'une information suffisante.
Source indisponible	La source ne peut pas être consultée ou n'a pas répondu correctement.
Autorisation expirée	Horizon ne dispose plus du moyen autorisé nécessaire à la consultation.
Compte inaccessible	Le compte existe peut-être encore, mais Horizon ne peut pas actuellement l'utiliser ou le vérifier.

Une erreur réseau, une expiration OAuth ou une réponse incomplète ne doit jamais être traduite automatiquement par « faux », « absent » ou « supprimé ».

Propriétés de connaissance indépendantes

La connaissance d'une donnée repose sur plusieurs dimensions indépendantes définies au chapitre 9.

Dimension	États indicatifs	Question traitée
Disponibilité	Connue ou inconnue.	Horizon possède-t-il une valeur exploitable ?
Fraîcheur	Actuelle ou obsolète.	La valeur est-elle encore suffisamment récente ?
Confiance de l'information	Confirmée ou incertaine.	La valeur est-elle suffisamment établie ?
Cohérence	Cohérente ou en conflit.	La valeur est-elle compatible avec les autres informations crédibles ?
Transition	Stable, en attente ou en vérification.	Une évolution reste-t-elle en cours ?

Une donnée peut être connue mais obsolète, récente mais incertaine, ou disponible tout en restant en conflit. Horizon ne doit pas réduire ces dimensions à un état unique qui ferait perdre leur signification.

La confiance de l'information ne doit pas être confondue avec la confiance relationnelle de P.O.U.B.E.L.L.E. La première qualifie la certitude d'une valeur. La seconde décrit un paramètre de relation rattaché à une Identité Horizon.

Fraîcheur et stratégies d'actualisation

Il n'existe aucune durée universelle de fraîcheur. Une valeur est suffisamment actuelle lorsqu'elle respecte la condition définie pour son usage.

Les principales stratégies fonctionnelles sont :

Stratégie	Utilisation indicative
Réception événementielle	Actualiser une valeur lorsqu'un événement fiable est reçu.
Vérification périodique	Contrôler une donnée susceptible d'évoluer sans événement garanti.
Vérification à la consultation	Rafraîchir une valeur lorsqu'elle est affichée ou demandée.
Vérification avant utilisation	Contrôler une donnée avant une permission ou une action sensible.
Recalcul à la modification	Recalculer une valeur dérivée lorsque ses données sources évoluent.
Invalidation à l'échéance	Marquer une information obsolète lorsque sa durée acceptable est dépassée.
Actualisation opportuniste	Profiter d'une interaction légitime pour rafraîchir une donnée non critique.

Une même donnée peut utiliser plusieurs stratégies. Un rôle Discord peut être actualisé par événement, revérifié périodiquement et contrôlé à nouveau avant une action administrative sensible.

Les délais et déclencheurs détaillés devront être définis dans la future Annexe F ou dans le chapitre maître du domaine concerné.

Cycle fonctionnel de synchronisation

Lorsqu'Horizon reçoit ou recherche une valeur, le cycle fonctionnel comprend les étapes suivantes :

1. Horizon identifie la donnée et son sujet fonctionnel.
2. Horizon conserve l'origine et la source de la valeur candidate.
3. Horizon vérifie que la source est autorisée et attendue pour cette donnée.
4. Horizon contrôle l'ordre, la fraîcheur et la validité de l'information.
5. Horizon compare la valeur candidate à la valeur actuelle et aux autres informations crédibles.
6. Horizon détermine s'il s'agit d'une évolution normale, d'une valeur obsolète, d'une incertitude ou d'un conflit.
7. Horizon applique la stratégie définie pour la donnée.
8. Horizon met à jour l'état global uniquement lorsque le résultat est suffisamment établi.
9. Horizon recalcule ou invalide les données dépendantes.
10. Horizon produit les événements, traces et notifications nécessaires.

Une synchronisation ne doit pas modifier silencieusement une valeur sensible ou structurelle. Son origine et son résultat doivent rester identifiables.

Ordre des événements et modifications tardives

L'ordre de réception par Horizon ne correspond pas toujours à l'ordre réel des événements. Une interruption réseau ou une reprise de service peut retarder un événement plus ancien.

Horizon utilise, dans l'ordre de préférence :

1. Une Version, une révision ou un ordre fourni par l'autorité fonctionnelle ou par le service qui porte la donnée native.
2. La Date d'occurrence communiquée par la source.
3. La Date de réception par Horizon lorsque aucun meilleur repère n'existe.

Lorsqu'un identifiant stable d'événement, de notification ou de requête est fourni, Horizon l'utilise également pour corréler les livraisons et détecter la réception répétée d'un même fait. L'absence d'identifiant externe n'autorise pas à ignorer les autres contrôles d'ordre et de déduplication.

Un événement ancien reçu tardivement ne doit pas écraser une valeur plus récente déjà validée. Lorsqu'Horizon ne peut pas établir l'ordre de manière suffisamment fiable, il doit :

• Maintenir la dernière valeur sûre lorsqu'elle reste utilisable.
• Marquer la donnée comme incertaine ou en conflit.
• Demander une nouvelle vérification lorsque cela est possible.
• Suspendre les conséquences sensibles dépendant de cette valeur.

La prévention des doubles exécutions et des doubles conséquences définie au chapitre 8 reste applicable à toute synchronisation, reprise ou nouvelle livraison d'un même événement. Un même fait externe ne doit pas produire plusieurs gains, notifications ou actions uniquement parce qu'il a été reçu plusieurs fois.

État souhaité, état en attente et état réel

Une demande de modification ne constitue pas la preuve de son exécution.

Lorsqu'Horizon agit sur un service externe, il doit distinguer :

État	Signification
État actuel connu	Dernière situation suffisamment établie avant la demande.
État souhaité	Résultat qu'Horizon cherche à obtenir.
Demande transmise	Instruction effectivement envoyée au service.
État en attente	Résultat non encore confirmé.
Résultat communiqué	Réponse reçue après la tentative d'exécution.
État réel établi	Situation confirmée ou observée après l'opération.
Résultat incertain	Situation dans laquelle l'exécution a pu avoir lieu sans confirmation suffisante.

Une demande d'attribution d'un rôle Discord, d'envoi d'un message Twitch ou de modification d'une scène OBS ne doit donc pas actualiser immédiatement l'état réel. Le service extérieur conserve l'autorité sur l'exécution.

En cas de résultat incertain, Horizon ne doit pas répéter aveuglément l'action si cette répétition risque de produire une double conséquence. Il doit appliquer la stratégie d'idempotence, de vérification ou d'intervention définie pour l'action.

Familles de règles applicables aux valeurs

Plusieurs valeurs ou observations peuvent contribuer à une même situation. Horizon distingue quatre familles de règles qui répondent à des questions différentes et ne doivent jamais être réunies sous une priorité générale.

Sélection d'une représentation

La sélection choisit parmi plusieurs observations recevables d'une même donnée, sans produire une nouvelle valeur métier.

Critère	Finalité
Autorité confirmée	Écarter une observation provenant d'une source non recevable pour la donnée.
Version ou révision source	Préférer l'évolution dont l'ordre est établi par le service compétent.
Date d'occurrence	Reconstituer l'ordre fonctionnel lorsque la source fournit le moment du fait.
Date de réception	Départager les arrivées uniquement lorsqu'aucun meilleur repère n'existe.
Validité et fraîcheur	Éviter qu'une observation invalide ou trop ancienne remplace une représentation encore sûre.

Une plateforme ne bénéficie d'aucune priorité générale. Une règle peut sélectionner une observation issue d'une source précise pour une donnée déterminée, mais cette sélection découle de l'autorité applicable ou d'une règle métier nommée et limitée.

Calcul ou agrégation

Le calcul produit une donnée dérivée à partir de valeurs déjà recevables. Il peut appliquer une somme contrôlée, un minimum, un maximum, une moyenne ou une autre formule métier. Chaque calcul doit préciser ses entrées, sa règle, ses conditions de validité et la manière dont les doublons sont empêchés.

Une règle telle que « valeur la plus élevée » ne doit pas être utilisée pour une permission, une sanction, un statut ou une donnée sensible simplement parce qu'elle permet d'obtenir un résultat.

Fusion d'identités

La fusion consolide plusieurs valeurs déjà légitimes lorsqu'elles appartiennent à des Identités Horizon différentes reconnues comme représentant la même personne. La stratégie reste propre à chaque donnée : conservation d'une valeur, maximum, cumul contrôlé, choix autorisé, recalcul ou maintien séparé. Elle ne modifie jamais l'autorité fonctionnelle de la donnée.

Arbitrage et issue

Lorsque les règles automatiques ne produisent aucun résultat suffisamment sûr, Horizon applique une issue de procédure :

• Demander un choix à la personne lorsqu'elle est autorisée à décider.
• Demander une décision administrative motivée à une personne habilitée.
• Maintenir temporairement les valeurs en conflit.
• Placer la donnée en attente d'une vérification supplémentaire.
• Refuser une valeur non recevable ou refuser de décider lorsqu'aucune base suffisante n'existe.

Règles et autorisation

Aucune règle de sélection, de calcul, de fusion ou d'arbitrage ne contourne les permissions. Une demande provenant du Capitaine, d'un Super administrateur ou du Poste de commande peut recevoir un traitement adapté à son urgence sans transformer son auteur en autorité sur une donnée externe.

Règles et interface

L'interface utilisée ne détermine jamais la valeur applicable. Une modification depuis le Poste de commande n'est pas automatiquement supérieure à une commande Twitch ou Discord. Horizon contrôle l'identité de l'auteur, sa permission, le rôle de l'opération et la famille de règle prévue pour la donnée.

Évolution normale, obsolescence, incertitude et conflit

Toutes les différences ne sont pas des conflits.

Situation	Qualification	Comportement général
L'autorité fonctionnelle confirme une nouvelle valeur.	Évolution normale.	Horizon actualise sa représentation et produit les conséquences autorisées.
La valeur locale dépasse sa durée de fraîcheur.	Obsolescence.	Horizon la signale et tente une actualisation selon la stratégie prévue.
La source ne répond pas ou répond partiellement.	Incertitude ou indisponibilité.	Horizon conserve la dernière valeur connue sans la présenter comme actuelle.
Deux informations crédibles restent incompatibles.	Conflit.	Horizon applique une résolution prévue ou demande une intervention.
Une valeur provient d'une source non autorisée.	Valeur non recevable.	Horizon la rejette sans modifier l'état actuel.
Une modification est encore en cours.	Transition.	Horizon distingue l'état souhaité de l'état réel.

Un changement de pseudonyme, de rôle ou de statut confirmé par l'autorité est une évolution normale. Il ne doit pas ouvrir systématiquement un conflit.

Un conflit existe notamment lorsque :

• Plusieurs sources recevables fournissent des valeurs incompatibles sans stratégie suffisante.
• L'Autorité attendue ne peut pas être déterminée.
• L'Ordre des modifications reste impossible à établir.
• Une Correction manuelle contredit une nouvelle valeur externe sans règle applicable.
• Une Donnée structurelle ne possède aucune stratégie de résolution.
• Une Valeur calculée dépend d'entrées elles-mêmes conflictuelles.
• Une Action sensible pourrait produire des conséquences différentes selon la valeur retenue.

Résolution automatique des conflits

Une résolution automatique n'est autorisée que lorsque la stratégie est suffisamment précise, déterministe et sûre.

Le Noyau peut notamment :

• Remplacer une copie obsolète par une valeur actuelle confirmée par l'autorité.
• Rejeter une valeur provenant d'une source non autorisée.
• Ignorer un événement ancien dont l'ordre est établi.
• Recalculer une valeur dérivée après la correction de ses entrées.
• Appliquer une stratégie explicite de valeur maximale, minimale ou cumulative.
• Restaurer la cohérence d'une donnée non sensible lorsque la correction est réversible et vérifiable.

Une résolution automatique ne doit pas :

• Accorder une permission sensible à partir d'une information incertaine.
• Lever une restriction sans confirmation suffisante.
• Choisir arbitrairement entre deux données personnelles concurrentes.
• Modifier définitivement une donnée externe contre l'autorité de sa plateforme.
• Masquer l'origine d'une correction.
• Réécrire un événement ou une décision passée.

Les corrections réalisées et les interventions restantes apparaissent dans la page de suivi des corrections. Lorsqu'au moins une correction ou intervention existe, une notification administrative consolidée indique le nombre d'opérations exécutées et le nombre d'actions manuelles encore nécessaires.

Résolution administrative

Une intervention humaine devient nécessaire lorsque la stratégie automatique ne permet pas d'obtenir un résultat suffisamment sûr.

La résolution doit conserver :

• La Donnée concernée.
• Les Valeurs concurrentes.
• La Source et la fraîcheur de chaque valeur.
• La Situation fonctionnelle ayant produit le conflit.
• La Décision retenue.
• Le Motif de la décision.
• L'Auteur et la date de l'intervention.
• La Portée temporaire ou permanente.
• L'Éventuelle date d'expiration.
• Les Valeurs avant et après la résolution.
• Les Conséquences recalculées ou maintenues en attente.

Une résolution portant sur une donnée Horizon peut devenir la nouvelle valeur de référence lorsqu'elle respecte les permissions et les règles applicables.

Pour une donnée externe, l'intervention peut :

• Demander une nouvelle vérification.
• Corriger un rattachement erroné à une Identité Horizon.
• Marquer la copie locale comme incertaine ou inutilisable.
• Suspendre une conséquence dépendant de la valeur.
• Définir temporairement l'interprétation utilisée par Horizon lorsque cette possibilité est autorisée.
• Ajouter une décision propre à Horizon sans modifier le fait externe.

Elle ne peut pas déclarer durablement qu'un follow, un rôle ou une sanction externe possède une valeur différente de celle établie par le service faisant autorité.

Demandes de correction par une personne

Une personne doit pouvoir demander la correction d'une donnée qui la concerne depuis le Poste de commande lorsque cette fonction est disponible.

Le traitement dépend de la nature de la donnée :

• Une Donnée déclarative modifiable peut être corrigée directement après contrôle.
• Une Donnée Horizon non modifiable directement produit une demande de correction.
• Une Donnée externe déclenche une actualisation ou indique le service auprès duquel la correction doit être réalisée.
• Une Erreur de liaison ou de rattachement ouvre une procédure d'identité adaptée.
• Une Donnée de modération suit la procédure et les restrictions propres à ce domaine.

L'interface doit présenter un état compréhensible sans révéler les informations sensibles utilisées par le contrôle.

Visibilité des conflits

Une personne peut consulter les conflits concernant ses propres données lorsqu'ils sont compréhensibles et qu'elle peut contribuer à leur résolution.

Horizon peut notamment afficher :

• La Donnée ou la famille concernée.
• Un État tel que « Vérification nécessaire » ou « Intervention en cours ».
• L'Action que la personne peut réaliser.
• La Date de la dernière vérification utile.
• Le Résultat général d'une demande de correction.

Horizon ne doit pas divulguer :

• Les Informations personnelles d'une autre personne.
• Les Détails susceptibles de compromettre la sécurité.
• Les Mécanismes internes de détection.
• Les Informations confidentielles d'une procédure de modération.
• Les Données que la personne n'est normalement pas autorisée à consulter.

Une personne habilitée à l'administration peut disposer d'une vue plus détaillée selon ses permissions.

Notifications relatives aux incohérences

Une notification personnelle est envoyée lorsqu'un conflit :

• Affecte l'Accès de la personne.
• Modifie son Statut communautaire.
• Concerne une Liaison de compte.
• Affecte une Donnée qu'elle a rendue publique.
• Nécessite une Action ou une confirmation de sa part.

Une correction mineure sans conséquence visible peut rester consultable depuis la page de suivi sans produire de notification personnelle immédiate.

Une alerte administrative immédiate est réservée aux situations sensibles, répétées, anormales ou susceptibles d'affecter les permissions, les restrictions et la sécurité. Les autres corrections utilisent la notification consolidée définie précédemment.

Données calculées et dépendances

Une valeur calculée ou dérivée reste sous l'autorité d'Horizon, même lorsqu'elle dépend de données Twitch, Discord ou déclarées par une personne.

Horizon doit pouvoir identifier :

• La Règle ayant produit le résultat.
• Les Données sources nécessaires.
• La Version applicable de la règle lorsque cette distinction est utile.
• Le Moment du dernier calcul.
• L'État de validité des entrées.
• Le Besoin éventuel de recalcul.

Lorsqu'une donnée source validée évolue, Horizon applique la stratégie prévue :

• Recalculer immédiatement le résultat.
• Marquer le résultat comme obsolète jusqu'au prochain calcul.
• Différer le recalcul jusqu'à la fin d'une procédure en cours.
• Suspendre les conséquences sensibles.
• Placer le résultat en conflit lorsque les entrées ne permettent plus un calcul fiable.

Une valeur calculée ne doit pas paraître plus certaine que ses entrées. Si une donnée déterminante devient incertaine ou conflictuelle, le résultat doit porter l'état approprié ou cesser temporairement d'être utilisé.

La modification ultérieure d'une formule ne doit pas réécrire silencieusement les résultats passés. Les migrations, recalculs et corrections nécessaires produisent leurs propres événements et suivent les règles du système concerné.

Modifications concurrentes des données Horizon

Plusieurs demandes valides peuvent concerner presque simultanément une même donnée. Le Noyau doit les ordonner et les traiter comme des opérations distinctes.

Les règles générales sont les suivantes :

• Une Modification acceptée s'applique à l'état courant connu.
• Une Opération ancienne ne doit pas écraser silencieusement une modification plus récente.
• Une Opération cumulative applique la règle métier prévue et prévient les doublons.
• Une Opération de remplacement vérifie que sa valeur de départ est toujours valable.
• Une Opération sensible peut utiliser un verrou ou une attente fonctionnelle.
• Une Divergence non résolue produit un conflit ou une intervention nécessaire.

La règle « dernière écriture reçue » ne suffit pas lorsqu'elle risque d'effacer une évolution légitime. Le Noyau doit prendre en compte la nature de l'opération, son ordre fonctionnel, son auteur, ses permissions et la stratégie propre à la donnée.

Fonctionnement dégradé

Lorsqu'une source devient indisponible, Horizon poursuit uniquement les fonctions compatibles avec le niveau de certitude restant.

Données non sensibles

Une dernière valeur connue peut continuer à être utilisée lorsqu'elle :

• Reste signalée comme obsolète dans l'état interne et dans les interfaces de contrôle.
• Ne produit aucune permission sensible.
• Ne lève aucune restriction.
• Ne déclenche aucune action critique.
• Respecte la stratégie définie pour la donnée.

Le signal interne de fraîcheur n'a pas à être divulgué dans chaque interaction publique. Un ancien pseudonyme connu peut, par exemple, rester utilisable pour une adresse ordinaire sans afficher d'alerte à l'équipage, à condition qu'Horizon ne le présente pas comme récemment vérifié ou nécessairement actuel.

Permissions sensibles

Une permission sensible issue d'une source externe doit être suffisamment actuelle au moment de son utilisation. Si elle ne peut plus être vérifiée, Horizon suspend la capacité correspondante selon la stratégie prévue.

L'impossibilité de vérifier un droit ne doit pas être interprétée comme la preuve définitive de son retrait, mais elle interdit son utilisation lorsqu'un niveau de sécurité supérieur est nécessaire.

Restrictions et exclusions

Une restriction ou une exclusion déjà connue reste provisoirement applicable jusqu'à ce que sa levée soit suffisamment établie. Cette règle évite qu'une panne de synchronisation accorde involontairement un accès précédemment interdit.

Le maintien provisoire doit rester visible dans les états administratifs et faire l'objet d'une nouvelle vérification. Il ne doit pas devenir une restriction permanente sans base valide.

Continuité des fonctions ordinaires

Les fonctions ordinaires non sensibles peuvent continuer avec une représentation obsolète lorsqu'aucun risque significatif n'en résulte. Une interaction publique peut par exemple utiliser le pseudonyme externe actuellement connu, tandis qu'une action administrative exige une vérification plus récente.

Disparition et suppression d'une donnée externe

Horizon distingue toujours :

• Une Suppression confirmée par l'autorité fonctionnelle.
• Une Absence de réponse.
• Une Autorisation externe expirée ou révoquée.
• Une Liaison retirée dans Horizon.
• Un Compte temporairement inaccessible.
• Une Valeur devenue inconnue après une erreur de synchronisation.

Seule une confirmation suffisamment fiable permet de considérer la donnée externe comme absente ou supprimée dans l'état actuel.

La disparition d'un compte externe ne supprime pas automatiquement :

• L'Identité Horizon.
• Les Données propres à Horizon.
• Les Autres comptes liés.
• Les Références historiques nécessaires.
• Les Décisions de modération ou de sécurité encore applicables.

La liaison concernée peut devenir indisponible, être placée en conflit ou suivre une procédure de retrait selon la situation définie au chapitre 11.

Autorité et fusion des identités

L'autorité et la stratégie de fusion répondent à deux questions différentes :

• L'Autorité détermine l'acteur, le service ou la règle qui établit la valeur canonique d'une donnée.
• La Stratégie de fusion détermine comment plusieurs valeurs légitimes sont réunies lorsqu'elles appartiennent à des Identités Horizon différentes.

Le fait qu'Horizon soit l'autorité sur l'XP ne signifie pas que les XP de deux identités doivent nécessairement être additionnés. La progression peut utiliser une valeur maximale, un cumul contrôlé, un recalcul ou une autre règle nommée et définie par le chapitre 26.

Lors d'une fusion :

• L'Identité la plus ancienne reste l'identité conservée.
• Chaque Donnée utilise sa stratégie de fusion définie.
• L'Autorité de la donnée reste inchangée.
• Les Valeurs en conflit restent identifiables.
• Une Absence de stratégie bloque ou limite la consolidation selon le risque.
• Le Compte rendu indique les règles appliquées sans divulguer inutilement les données sensibles.

Les mécanismes complets de consolidation, d'archivage et de correction relèvent du chapitre 12.

Cas de référence

Les exemples suivants illustrent la répartition des responsabilités sans constituer le catalogue exhaustif.

Donnée	Autorité	Valeur Horizon	Comportement en cas de divergence
Follow Twitch	Twitch.	Dernier état observé avec sa fraîcheur.	Actualisation si Twitch confirme la nouvelle valeur, sinon incertitude.
Rôle Discord	Discord.	Représentation locale utilisée selon sa fraîcheur.	Vérification avant une permission sensible.
Statut de Membre d'équipage	Horizon.	Résultat actuel des règles communautaires.	Recalcul après l'évolution validée des conditions.
Nom d'affichage Horizon	La personne pour la proposition ; Horizon pour la valeur canonique acceptée.	Valeur actuelle du profil, présentée par l'interface selon le contexte.	Nouvelle proposition, validation ou modération conforme aux règles.
XP et niveau	Horizon.	Valeurs actuelles calculées par le système de progression.	Recalcul ou correction selon les règles métier.
Confiance et proximité	Horizon.	Valeurs actuelles cachées.	Modification contrôlée par le Noyau à la demande d'un acteur autorisé.
Scène OBS réelle	OBS ou le service d'intégration faisant autorité sur l'exécution.	Dernier état observé.	Vérification après une demande dont le résultat reste incertain.
Liaison Twitch ou Discord	Horizon.	Relation vérifiée entre l'identité et le compte.	Procédure de vérification, remplacement ou conflit.

Relation avec l'Annexe F

La future Annexe F — Catalogue des données constituera le référentiel détaillé des propriétés propres à chaque donnée après la stabilisation des chapitres spécialisés.

Elle pourra notamment préciser :

• Le Nom fonctionnel canonique.
• Le Sujet auquel la donnée se rattache.
• Le Mode de production.
• Le Rôle fonctionnel.
• Le Cycle de vie.
• La Source ou les sources possibles.
• L'Autorité fonctionnelle.
• Les Métadonnées temporelles, de version et d'identification disponibles.
• Les Modificateurs autorisés.
• Les Validations nécessaires.
• La Stratégie d'actualisation.
• La Condition de fraîcheur.
• La Stratégie en cas d'indisponibilité.
• La Règle de sélection d'une représentation.
• La Règle de calcul ou d'agrégation éventuelle.
• La Stratégie de correction.
• La Stratégie de fusion.
• Les Issues d'arbitrage autorisées.
• Les Données calculées dépendantes.
• Les Conséquences d'une incertitude ou d'un conflit.
• Les Événements capables de modifier la valeur.

Un chapitre spécialisé reste la référence fonctionnelle de ses règles métier. La future Annexe F réunira leurs propriétés dans un format commun afin de permettre leur consultation, leur contrôle et leur future traduction technique.

Vue fonctionnelle de l'autorité et de la cohérence

La figure suivante représente l'arrivée d'une valeur depuis une source interne, externe ou humaine, puis la décision commune fondée sur les contrôles applicables d'autorité, de fraîcheur et de cohérence. Elle distingue quatre issues : valeur acceptée, valeur refusée ou non recevable, valeur en attente de vérification, et conflit ou intervention requise.

FIG. 12 Autorité et cohérence — Contrôles appliqués avant l'intégration d'une valeur dans l'état global Horizon.

Garanties fonctionnelles

Le modèle de rattachement, d'autorité, de priorité et de cohérence doit garantir les principes suivants :

• Chaque Donnée canonique possède une autorité identifiable.
• Une Donnée externe reste rattachée au service qui la définit.
• Une Copie locale conserve sa provenance et sa fraîcheur.
• Une Absence de réponse ne devient jamais automatiquement une valeur négative.
• Une Valeur obsolète reste distinguée d'une valeur absente.
• Une Évolution confirmée ne produit pas inutilement un conflit.
• Une Divergence non résolue ne doit pas être transformée arbitrairement en certitude.
• Une Modification demandée reste distincte du résultat réellement établi.
• Un Événement tardif ne doit pas faire régresser silencieusement l'état actuel.
• Une Permission sensible exige une vérification adaptée à son risque.
• Une Restriction connue ne doit pas être levée par une simple panne de synchronisation.
• Une Valeur calculée ne doit pas paraître plus fiable que ses données sources.
• Une Correction automatique doit rester déterministe et autorisée.
• Une Décision humaine doit être motivée et traçable.
• Une Personne peut consulter les conflits la concernant dans les limites de sécurité et de confidentialité.
• Une Sélection de représentation, un calcul, une fusion et un arbitrage doivent rester des mécanismes distincts.
• Le LLM ne doit disposer d'aucun accès direct permettant d'imposer une valeur.
• Les Stratégies propres à chaque donnée devront rester consultables dans la future Annexe F.

Limites du présent chapitre

Le présent chapitre définit les principes communs d'autorité, de priorité, de synchronisation et de cohérence. Les domaines suivants relèvent de leurs chapitres ou référentiels maîtres :

• L'État global et les dimensions de connaissance relèvent du chapitre 9.
• L'Identité Horizon et ses états relèvent du chapitre 10.
• Les Liaisons et autorisations externes relèvent du chapitre 11.
• Les Stratégies de consolidation relèvent du chapitre 12.
• Le Catalogue fonctionnel des données relève du chapitre 13.
• La Conservation des évolutions et corrections relève du chapitre 15.
• Les Statistiques et agrégations relèvent du chapitre 17.
• Les Règles propres à P.O.U.B.E.L.L.E., au LLM et aux outils relèvent des chapitres 18 à 21.
• Les Interfaces externes et leurs mécanismes de synchronisation relèvent des chapitres 22 à 25.
• Les Règles de progression et des systèmes communautaires relèvent des chapitres 26 à 30.
• L'Authentification et les autorisations relèvent du chapitre 31.
• Le Modèle de permissions relève du chapitre 32.
• La Classification et la sensibilité des données relèvent du chapitre 33.
• Les Actions critiques et confirmations relèvent du chapitre 34.
• La Vie privée et les durées de conservation relèvent du chapitre 35.
• La Traduction technique du modèle relève du chapitre 43.
• Le Catalogue exhaustif des données relèvera de la future Annexe F.
• Les Matrices de permissions et de sensibilité relèvent des Annexes H et J.
• Le Schéma technique de la base de données relève de l'Annexe P.

Synthèse

Horizon ne remplace pas les autorités des services auxquels il est relié. Twitch et Discord restent responsables de leurs comptes, rôles, sanctions et événements natifs. Horizon conserve l'autorité sur ses identités, ses relations entre comptes, ses règles communes, sa progression, ses paramètres et les résultats qu'il calcule.

Une valeur locale demeure une représentation dont la provenance, la fraîcheur et la certitude doivent rester visibles. Une évolution confirmée est appliquée normalement. Une source inaccessible produit une information inconnue ou obsolète. Une divergence non résolue devient un conflit et ne doit jamais être transformée arbitrairement en certitude.

Le Noyau contrôle l'ordre des événements, les modifications concurrentes, les recalculs, les corrections et les conséquences sensibles. Il distingue toujours ce qu'Horizon souhaite obtenir, ce qui reste en attente et ce qui a réellement été établi par la source compétente.

La Partie IV fournit ainsi les deux fondations du modèle fonctionnel des données : le chapitre 13 définit ce qu'Horizon doit connaître, tandis que le chapitre 14 détermine le rattachement et l'autorité de chaque valeur, sépare les différentes familles de règles et encadre le traitement des divergences. La future Annexe F pourra réunir progressivement les propriétés détaillées de chaque donnée lorsque les chapitres spécialisés auront stabilisé leur contenu.