Rôle du LLM

Le modèle de langage fournit à Horizon une capacité souple de compréhension et de production du langage. Il peut interpréter une formulation, contribuer à un raisonnement contextuel, rédiger une réponse ou proposer une intention structurée lorsque des règles déterministes ne suffisent pas à traiter correctement la situation.

Cette capacité ne fait pas du modèle une autorité de la Plateforme. Le LLM n'est ni P.O.U.B.E.L.L.E., ni le Noyau Horizon, ni la mémoire, ni le détenteur des données qu'il reçoit temporairement. Il demeure une ressource technique locale et interchangeable, sollicitée par le Service LLM Horizon sous le contrôle du Noyau.

Le présent chapitre définit les situations qui justifient son utilisation, les traitements qui doivent rester déterministes, le statut de ses productions et les comportements attendus en cas d'incertitude, d'erreur ou d'indisponibilité. Il ne choisit pas encore le modèle open source qui sera employé et ne définit ni la construction détaillée du contexte, ni le catalogue des outils accessibles à P.O.U.B.E.L.L.E.

Fonctionnement cible — Principes validés

Horizon utilise un modèle open source téléchargé, exécuté localement et paramétré dans l'environnement maîtrisé du projet. Aucun fournisseur LLM extérieur n'est utilisé comme solution de secours automatique.

Le Service LLM Horizon présente au reste de la Plateforme une interface stable : il transmet un prompt textuel au modèle sélectionné et reçoit une réponse textuelle. Le modèle peut ainsi être remplacé sans redéfinir le rôle de P.O.U.B.E.L.L.E. ni les règles fonctionnelles du Noyau.

Seul le Capitaine peut sélectionner, installer, remplacer, configurer, activer ou désactiver le modèle. Les Super administrateurs peuvent exécuter les tests autorisés et consulter leurs résultats, sans modifier le modèle ou sa configuration active.

Synthèse normative

• Le LLM doit rester une ressource technique distincte de P.O.U.B.E.L.L.E., du Noyau, de la mémoire et des outils.
• Le modèle utilisé doit être open source, téléchargé et exécuté localement dans le fonctionnement cible actuellement retenu.
• Aucun contexte ou message ne doit être transmis automatiquement à un fournisseur LLM extérieur.
• Le Service LLM Horizon doit permettre de remplacer le modèle sans modifier les règles fonctionnelles de la Plateforme.
• Un changement de modèle ne doit pas créer une nouvelle identité ou une nouvelle version implicite de P.O.U.B.E.L.L.E.
• Seul le Capitaine doit pouvoir sélectionner, installer, remplacer, configurer, activer ou désactiver le modèle.
• Les Super administrateurs peuvent tester le modèle dans le périmètre autorisé sans modifier sa configuration active ni publier une réponse de test comme une intervention réelle.
• Le Noyau doit décider si un traitement justifie le recours au Service LLM Horizon.
• Le LLM doit être utilisé lorsque la compréhension, l'interprétation ou la formulation souple du langage apporte une valeur réelle.
• Les identités, permissions, confirmations, calculs, valeurs faisant autorité et résultats d'exécution doivent rester déterministes ou humains selon les règles applicables.
• Le LLM peut contribuer à l'interprétation contextuelle d'une règle communautaire sans décider ni appliquer une sanction.
• Un signalement proposé par le LLM doit être contrôlé par le Noyau avant toute demande de confirmation adressée à un Modérateur.
• Une sortie du modèle doit rester une proposition jusqu'à son interprétation et sa validation par le Noyau.
• Le LLM ne doit disposer d'aucun accès direct aux données, à la mémoire, aux interfaces ou aux outils.
• Le LLM ne doit jamais pouvoir exécuter directement une action, modifier une donnée ou confirmer sa propre proposition.
• Une réponse structurée doit rester transmissible sous la forme d'un texte respectant le format demandé par le Service LLM Horizon.
• Une information absente du contexte ne doit pas être inventée, reconstituée ou présentée comme connue.
• Une incertitude significative doit conduire à une demande de précision, à une formulation prudente ou à l'abandon de la proposition concernée.
• Une production du modèle ne doit créer par elle-même ni fait canonique, ni souvenir actif, ni profil, ni sanction, ni résultat d'exécution.
• Les prompts complets et réponses brutes ne doivent pas être conservés systématiquement.
• Les fonctions déterministes essentielles doivent pouvoir continuer lorsque le modèle est indisponible.
• Aucun mode dégradé ne doit assouplir une permission, inventer un résultat ou transmettre une demande à un service LLM extérieur.

Finalité et périmètre du chapitre

Le chapitre répond à la question suivante :

Quand Horizon doit-il recourir à un modèle de langage, quelle contribution peut-il en attendre et quelles responsabilités doivent rester hors de son contrôle ?

La réponse ne dépend pas du modèle précis qui sera retenu. Horizon doit pouvoir faire évoluer ce composant en fonction de la qualité des réponses, des capacités matérielles disponibles et des besoins de La Tanière sans modifier ses principes fondamentaux.

Le chapitre poursuit plusieurs objectifs :

• Réserver le LLM aux situations dans lesquelles sa souplesse apporte une valeur identifiable.
• Éviter qu'un traitement déterministe devienne inutilement dépendant d'une production probabiliste.
• Donner un statut explicite aux interprétations, réponses et propositions du modèle.
• Empêcher tout accès ou toute exécution directe.
• Organiser une réaction sûre face aux erreurs, ambiguïtés et informations manquantes.
• Maintenir la continuité des fonctions essentielles en cas d'indisponibilité.
• Permettre l'interchangeabilité du modèle sans altérer P.O.U.B.E.L.L.E.

La place de P.O.U.B.E.L.L.E., son identité et son autorité canonique ont été définies au chapitre 18. La construction du contexte précisera les informations effectivement transmises pour une interaction. Les actions et outils définiront les opérations susceptibles d'être proposées et les contrôles qui précèdent leur exécution.

Une ressource technique locale et interchangeable

Le modèle LLM est le composant qui reçoit un texte et produit un texte. Le Service LLM Horizon est la fonction de la Plateforme qui prépare cet échange, dialogue avec le modèle sélectionné et restitue son résultat au Noyau dans une forme exploitable.

Cette séparation permet au Noyau de ne pas dépendre des particularités d'un modèle donné. Du point de vue fonctionnel, l'échange conserve une interface stable :

1. Le Noyau autorise la finalité et le périmètre du recours au LLM.
2. Le Service LLM construit ou reçoit le prompt correspondant.
3. Le modèle local traite ce prompt.
4. Le modèle retourne une réponse textuelle.
5. Le Service LLM vérifie que cette réponse peut être interprétée dans le format attendu.
6. Le Noyau décide de l'utilisation autorisée du résultat.

Le modèle retenu n'est pas encore défini. Sa famille, sa taille, sa quantification, ses besoins matériels, ses paramètres d'inférence et son mode de chargement relèvent d'une décision technique ultérieure. Le présent chapitre impose seulement que son remplacement reste possible sans réécrire les règles métier ou le canon de P.O.U.B.E.L.L.E.

Le fonctionnement cible repose actuellement sur une exécution locale. Aucun basculement automatique vers une API ou un fournisseur extérieur ne doit intervenir lorsque le modèle local est indisponible. Une évolution de ce principe nécessiterait une nouvelle décision explicite, accompagnée d'une réévaluation des données transmises, de leur confidentialité, de leur conservation et du coût associé.

Usages pertinents du modèle

Le LLM doit être sollicité parce que la situation exige une capacité linguistique ou contextuelle, et non simplement parce qu'il est disponible. Son recours n'est pas justifié lorsqu'une règle explicite, un calcul ou un texte préparé permet d'obtenir un résultat exact, plus sûr et suffisamment adapté.

Compréhension du langage

Le modèle peut contribuer à déterminer ce qu'une personne semble demander, les éléments auxquels elle fait référence et les ambiguïtés qui empêchent une interprétation certaine. Cette capacité est particulièrement utile pour les conversations libres, les demandes formulées sans commande rigide ou les messages dépendant d'échanges antérieurs.

L'interprétation produite ne remplace toutefois pas l'identité réelle de l'auteur, ses permissions ou l'état connu de la Plateforme. Le modèle peut comprendre qu'une personne demande une action, il ne peut pas en conclure qu'elle possède le droit de l'obtenir.

Production et adaptation des réponses

Le LLM peut rédiger une intervention de P.O.U.B.E.L.L.E. à partir des règles, informations et contraintes qui lui sont fournies. Il peut adapter la formulation au canal, à la situation, à la relation avec la personne et au niveau de clarté nécessaire.

Cette liberté de formulation reste encadrée par le canon et par les exigences fonctionnelles. Une phrase élégante mais contraire à la personnalité de P.O.U.B.E.L.L.E., trompeuse sur l'état d'Horizon ou excessive au regard des informations disponibles constitue une réponse incorrecte.

Raisonnement contextuel et interprétation d'événements

Le modèle peut rapprocher plusieurs éléments fournis dans le contexte, proposer une lecture de la situation ou expliquer pourquoi une information semble pertinente. Il peut également aider à interpréter un événement accompagné d'un message libre, par exemple lorsqu'une réaction doit tenir compte à la fois de l'événement, de l'échange en cours et de la personne concernée.

Ce raisonnement reste consultatif. Le Noyau conserve les règles déterministes, vérifie les données et décide des conséquences autorisées. Une conclusion plausible ne devient pas vraie uniquement parce qu'elle a été produite avec assurance.

Synthèses, profils et souvenirs candidats

Le LLM peut proposer une synthèse qualitative à partir d'informations sélectionnées ou formuler un souvenir candidat dans les conditions prévues par les chapitres consacrés aux statistiques et au profil comportemental et à la mémoire de P.O.U.B.E.L.L.E..

Cette proposition ne modifie jamais directement la mémoire ou le profil. Le Noyau doit contrôler sa source, son admissibilité, son niveau de confiance, sa catégorie et les autres conditions nécessaires avant tout enregistrement ou toute utilisation durable.

Proposition d'intentions et d'actions

Le modèle peut transformer une demande libre en intention structurée ou proposer une action qui semble répondre à la situation. Cette capacité permet de relier une conversation naturelle aux fonctions contrôlées d'Horizon sans donner au modèle un accès direct aux outils.

Une intention proposée ne vaut ni autorisation ni ordre d'exécution. Elle doit être confrontée aux règles, à l'identité, aux permissions, à la cible, aux confirmations requises et à l'état réel du système.

Ce qui doit rester déterministe ou humain

Le LLM produit des résultats probabilistes : deux demandes proches peuvent recevoir des réponses différentes, et une réponse convaincante peut être incorrecte. Il ne doit donc pas déterminer seul les éléments pour lesquels Horizon exige une valeur stable, vérifiable ou faisant autorité.

Domaine	Autorité attendue	Contribution éventuelle du LLM
Identité et rattachement des comptes	Sources vérifiées et règles du Noyau.	Comprendre une demande ou expliquer une procédure.
Permissions et confirmations	Noyau et personnes habilitées.	Reformuler la portée d'une action sans accorder le droit.
Progression, niveaux, grades et récompenses	Calculs et règles déterministes.	Présenter ou commenter le résultat établi.
Classification des données et des actions	Règles de protection et contrôles du Noyau.	Signaler un risque possible sans fixer la classification définitive.
Création, modification et suppression de données	Fonctions autorisées du Noyau.	Proposer une opération ou extraire ses paramètres.
Résultat d'une action	Retour établi par le composant ou le service responsable.	Formuler une explication depuis le résultat confirmé.
Canon de P.O.U.B.E.L.L.E.	Capitaine et Bible de référence.	Produire une formulation compatible sans créer de vérité canonique.
Sanction communautaire	Règle déterministe ou décision humaine autorisée.	Détecter un problème possible et préparer un signalement.

Cette séparation n'interdit pas au modèle de contribuer à un traitement. Elle interdit que sa production soit considérée comme suffisante lorsque la conséquence exige une autorité, une certitude ou une permission qu'il ne possède pas.

Cas particulier des règles communautaires

Certaines règles communautaires peuvent être appliquées depuis des faits simples et objectivement vérifiables. D'autres situations dépendent du contexte, de l'ironie, du sous-entendu, de la répétition ou de la relation entre les personnes. Le LLM peut alors fournir un signal contextuel lorsqu'un message semble problématique.

Le modèle ne prononce aucune sanction. Il peut seulement produire une interprétation structurée comprenant, selon les besoins :

• Le message ou l'élément examiné.
• La règle ou la catégorie potentiellement concernée.
• La raison du signalement.
• Les éléments contextuels ayant influencé l'analyse.
• Le degré d'incertitude de cette interprétation.
• La nécessité éventuelle d'une vérification humaine.

Le Noyau contrôle ensuite que le signalement appartient au périmètre autorisé. Horizon peut alors transmettre une demande privée de confirmation à un Modérateur présent et habilité sur le direct. Le LLM ne choisit pas librement le destinataire, n'envoie pas lui-même le message et ne transforme pas l'absence de réponse en validation implicite.

Le choix précis du Modérateur, le contenu de la notification, sa durée de validité, le comportement en l'absence de personne disponible et la conséquence d'une confirmation seront définis avec les interfaces, les permissions et les outils concernés. Le présent chapitre établit seulement qu'une analyse contextuelle peut déclencher une demande de vérification humaine, jamais une sanction directe.

Une réponse textuelle éventuellement structurée

Le Service LLM Horizon échange avec le modèle au moyen de textes. Cette simplicité ne limite pas la possibilité d'obtenir une réponse structurée : le prompt peut imposer un format textuel interprétable par la Plateforme.

Selon la finalité du traitement, la réponse peut comprendre :

• Une intention reconnue.
• Une réponse destinée à la personne.
• Une ou plusieurs informations extraites.
• Une proposition d'action et ses paramètres.
• Une indication d'incertitude.
• Une demande de précision.
• Une impossibilité ou un refus motivé.

Ces éléments peuvent être sérialisés dans un format défini, par exemple un objet textuel structuré. Le format technique exact sera établi pendant la conception des contrats du Service LLM. Quelle que soit sa forme, la réponse doit être considérée comme non fiable tant qu'elle n'a pas été analysée et confrontée aux règles applicables.

Une réponse qui ne respecte pas le format demandé, contient des champs inconnus, omet une information obligatoire ou propose une valeur invalide doit être refusée, corrigée par un mécanisme explicitement prévu ou soumise à un nouveau traitement limité. Elle ne doit jamais être interprétée de manière permissive afin de poursuivre à tout prix.

Incertitude, erreurs et informations manquantes

Une sortie du LLM reste une proposition produite depuis le contexte transmis. Elle ne prouve ni l'existence d'un fait dans la base de données, ni une permission, ni l'exécution d'une action. Le modèle peut produire une information inexacte, interpréter excessivement un message ou présenter une hypothèse comme une certitude : Horizon doit donc prévoir cette possibilité au lieu de supposer une fiabilité parfaite.

Lorsque les informations disponibles ne permettent pas une réponse suffisamment sûre, le comportement attendu suit l'ordre général suivant :

1. Demander une précision lorsque celle-ci peut résoudre l'ambiguïté.
2. Exprimer explicitement l'incertitude lorsqu'une réponse prudente conserve une utilité.
3. Limiter la réponse aux faits effectivement disponibles.
4. Renoncer à une proposition dont la conséquence exigerait une certitude absente.

Le modèle ne doit jamais combler une lacune en inventant :

• Une donnée Horizon.
• Un souvenir ou une interaction passée.
• Une caractéristique personnelle.
• Une permission ou un statut.
• Un résultat d'action.
• Une information provenant de Twitch, Discord ou d'un autre service.
• Un élément du canon de P.O.U.B.E.L.L.E.

Une production incorrecte peut être abandonnée ou faire l'objet d'une nouvelle tentative encadrée. Si elle a déjà été communiquée et peut avoir une conséquence réelle, sa correction doit être explicite.

Relation avec les données et la mémoire

Le LLM n'accède jamais librement à la persistance d'Horizon. Il reçoit uniquement les éléments que le Service LLM est autorisé à intégrer au prompt pour la finalité concernée.

La présence d'une information dans la mémoire ou dans la base de données ne constitue pas une autorisation automatique de la transmettre. La sélection doit tenir compte de la pertinence, de la sensibilité, des permissions, du canal, de la personne concernée et du risque de divulgation. Ces règles seront détaillées au chapitre 20.

Le modèle ne peut pas :

• Parcourir librement la mémoire ou la base de données.
• Demander davantage d'informations sans que cette demande soit contrôlée.
• Conserver lui-même une information entre deux appels.
• Transformer une information temporaire en souvenir durable.
• Réutiliser une donnée privée dans un espace public sans autorisation.
• Reconstituer une information supprimée ou arrivée à expiration.

Le prompt complet et la réponse brute ne sont pas conservés systématiquement. Horizon peut retenir les éléments fonctionnels nécessaires à l'explication d'un traitement, à la validation d'une proposition ou au diagnostic d'une erreur, dans les limites prévues par le catalogue des données. Cette trace ne devient ni mémoire conversationnelle ni historique complet de la discussion.

Proposition d'actions sans exécution directe

Le LLM peut reconnaître qu'une personne demande une action ou suggérer qu'une opération semble utile. Il ne reçoit toutefois aucun accès direct à l'outil correspondant.

Le parcours fonctionnel reste le suivant :

1. Le modèle propose une intention ou une action dans le format attendu.
2. Le Service LLM transmet cette proposition au Noyau.
3. Le Noyau vérifie la cible, les paramètres, les règles et les permissions.
4. Une confirmation humaine est demandée lorsqu'elle est nécessaire.
5. Le Noyau autorise, refuse, suspend ou abandonne la conséquence.
6. L'outil ou l'extension compétente exécute uniquement l'instruction autorisée.
7. Le résultat réel est retourné, consolidé et tracé.

Le modèle ne doit pas pouvoir fabriquer un nom d'outil exécutable, élargir les paramètres autorisés, contourner une confirmation ou considérer sa proposition comme réussie. Le chapitre 21 définira le catalogue des capacités, leurs paramètres, leurs confirmations et leurs interdictions.

Réponses préparées et réponses générées

La présence du LLM ne signifie pas que chaque intervention de P.O.U.B.E.L.L.E. doit être générée. Horizon adopte un fonctionnement hybride afin d'utiliser la méthode la plus adaptée à chaque situation.

Type de communication	Mode privilégié
Confirmation, refus ou information critique	Texte préparé ou formulation fortement contrainte.
Erreur technique et état d'une opération	Message déterministe fondé sur le résultat établi.
Conversation libre	Réponse générée depuis un contexte autorisé.
Réaction relationnelle ou contextualisée	Réponse générée lorsque l'adaptation apporte une valeur réelle.
Annonce récurrente	Texte préparé, variante contrôlée ou génération selon le besoin.
Mode dégradé	Réponse préparée, report ou absence d'intervention non essentielle.

Un texte déterministe peut être formulé dans le style de P.O.U.B.E.L.L.E. sans recourir au modèle. Inversement, une réponse générée ne doit pas être employée lorsque la précision exacte du message prime sur sa variété ou sa personnalisation.

Administration du modèle et espace de test

Le modèle et sa configuration relèvent exclusivement du Capitaine. Depuis son espace réservé dans le Poste de commande, il doit pouvoir sélectionner, installer, remplacer, configurer, activer ou désactiver un modèle compatible et autoriser sa mise en production.

Les Super administrateurs disposent uniquement des capacités de test autorisées. Ils peuvent :

• Envoyer des prompts dans un environnement isolé.
• Lancer des scénarios de test préparés.
• Consulter les réponses, erreurs, durées et résultats techniques.
• Comparer les comportements constatés aux attentes documentées.
• Signaler une anomalie au Capitaine.

Ils ne peuvent pas modifier le modèle, son prompt système, ses paramètres, sa configuration active ou sa version. Une réponse de test ne doit pas être publiée comme une intervention réelle de P.O.U.B.E.L.L.E. Les données réelles accessibles pendant les tests devront rester limitées par les permissions et règles de classification.

Disponibilité et fonctionnement dégradé

L'exécution locale peut être limitée par la puissance disponible, le chargement du modèle, le nombre de demandes simultanées ou une erreur technique. Le LLM ne constitue donc pas une étape obligatoire de tous les traitements.

Lorsqu'il est indisponible ou ne peut pas répondre dans les conditions attendues :

• Les fonctions déterministes doivent continuer autant que possible.
• Une action déjà autorisée ne doit pas dépendre d'une reformulation générative pour être exécutée.
• Un message important peut utiliser une formulation préparée.
• Une intervention conversationnelle non essentielle peut être différée ou abandonnée.
• Une conversation directe peut signaler que certaines capacités sont temporairement réduites.
• Aucun fournisseur extérieur ne doit être sollicité automatiquement.
• Aucune permission ne doit être assouplie afin de maintenir artificiellement une fonction.
• Aucun résultat absent ne doit être inventé.

Le mode dégradé doit rester prévisible. Il vaut mieux produire une réponse limitée ou ne pas produire une intervention facultative que présenter comme fiable un traitement incomplet.

Les mécanismes techniques de chargement seront définis au chapitre 41. Les reprises relèveront du chapitre 47, tandis que les seuils de durée, les files et les limites de concurrence seront précisés dans le chapitre 50.

Exigences fonctionnelles pour le futur modèle

Le choix du modèle reste à définir. Son évaluation devra toutefois vérifier sa capacité à respecter les besoins fonctionnels d'Horizon.

Le modèle retenu devrait notamment pouvoir :

• Comprendre et produire correctement le français.
• Suivre des consignes hiérarchisées et des contraintes de format.
• Restituer une réponse textuelle structurée de manière suffisamment fiable.
• Exploiter un contexte comprenant des règles, des faits et une conversation récente.
• Distinguer les informations fournies de ses hypothèses et signaler les informations manquantes.
• Maintenir la cohérence de P.O.U.B.E.L.L.E. dans les limites du prompt transmis.
• Fonctionner avec les ressources matérielles et les délais réellement compatibles avec Horizon.

Ces exigences constituent des critères d'évaluation et non le choix implicite d'une technologie. Les tests devront comparer les résultats sur des scénarios représentatifs : conversation ordinaire, ambiguïté, contexte incomplet, réponse structurée, tentative d'action non autorisée, information sensible, cohérence du personnage et fonctionnement dégradé.

La sélection finale et toute modification de la configuration appartiennent au Capitaine. Une amélioration des performances ou un changement de modèle ne doit jamais être considéré comme une autorisation de modifier les règles fonctionnelles établies.

Garanties fonctionnelles

Les garanties suivantes doivent rester vraies quel que soit le modèle utilisé :

• P.O.U.B.E.L.L.E. ne doit jamais être réduite au modèle actif.
• Le Noyau doit contrôler la finalité de chaque recours au LLM.
• Le modèle doit recevoir uniquement le contexte autorisé et nécessaire.
• Une sortie doit rester une proposition et ne doit accorder aucune permission ou établir seule une valeur faisant autorité.
• Aucune action ne doit être exécutée directement depuis le texte produit.
• Une analyse communautaire ne doit produire aucune sanction automatique.
• Une information inconnue ne doit pas être inventée.
• Une réponse de test ne doit pas être confondue avec une intervention réelle, et un changement de modèle ne doit modifier ni le canon ni les permissions.
• Une indisponibilité ne doit pas interrompre les fonctions déterministes indépendantes.
• Aucun basculement vers un fournisseur extérieur ne doit avoir lieu sans nouvelle décision explicite.

Limites du présent chapitre

Le présent chapitre définit le rôle fonctionnel du LLM mais ne fixe pas :

• Le modèle open source précis, sa taille ou sa licence.
• Le matériel nécessaire à son exécution.
• Les paramètres détaillés d'inférence et de génération.
• Le contenu et la structure exacte du socle canonique.
• Les informations sélectionnées pour chaque type d'interaction.
• La quantité maximale de contexte transmise.
• Le format technique définitif des réponses structurées.
• Le catalogue des outils et actions proposés.
• Les règles détaillées de modération et de désignation d'un Modérateur disponible.
• Les durées maximales de traitement et stratégies de mise en file.
• L'architecture logicielle du Service LLM Horizon.

Le chapitre 20 définira le contenu transmis au modèle et les règles de sélection correspondantes. Le chapitre 21 précisera les capacités susceptibles d'être proposées. Les interfaces et les chapitres de sécurité fixeront ensuite les modalités de notification, de confirmation, de classification et de traçabilité.

Synthèse

Le LLM fournit à Horizon une capacité locale de compréhension, d'interprétation et de formulation. Il peut contribuer aux conversations de P.O.U.B.E.L.L.E., produire des synthèses, interpréter certains événements, détecter un problème communautaire potentiel ou proposer une intention structurée. Il ne constitue toutefois ni P.O.U.B.E.L.L.E., ni une source d'autorité, ni un moyen d'exécution.

Le Noyau décide de la finalité du recours au modèle, limite le contexte transmis et contrôle l'utilisation de la réponse. Les identités, permissions, calculs, données, sanctions et résultats réels restent établis par des règles déterministes, des sources faisant autorité ou des personnes habilitées. Une analyse communautaire peut ainsi conduire à une demande privée de confirmation adressée à un Modérateur, mais jamais à une sanction directement décidée par le modèle.

Le modèle sera open source, exécuté localement et interchangeable derrière une interface textuelle stable. Seul le Capitaine pourra le sélectionner, le configurer et autoriser son utilisation en production. Les Super administrateurs pourront exécuter des tests isolés et signaler les anomalies sans modifier sa configuration active.

Horizon doit enfin rester capable de fonctionner lorsque cette ressource est indisponible. Les réponses préparées, les règles déterministes et les autres branches indépendantes du traitement assurent cette continuité sans fournisseur extérieur automatique, sans assouplissement des permissions et sans invention d'un résultat absent.