Construction du contexte LLM

Chaque appel au modèle de langage répond à un cas fonctionnel identifié. Horizon ne rassemble pas librement toutes les informations disponibles et ne demande pas au modèle de choisir lui-même ce dont il a besoin : le Noyau sélectionne un modèle de prompt prédéfini, recherche les valeurs attendues auprès des sources autorisées, applique les restrictions nécessaires et remplit les emplacements prévus.

Cette méthode permet de produire des interactions personnalisées sans transformer le prompt en copie générale de la mémoire ou de la base de données. Une conversation peut utiliser un modèle laissant une liberté importante à la formulation, tandis qu'une annonce ou une réaction à un événement peut reposer sur une structure stricte comportant seulement quelques variations contrôlées.

Le présent chapitre définit la composition fonctionnelle de ces prompts, les responsabilités du Noyau et du Service LLM Horizon, les familles d'informations utilisables, les valeurs par défaut, les priorités de sélection et les protections appliquées aux contenus transmis.

Fonctionnement cible — Principes validés

Chaque appel au LLM associe le socle canonique de P.O.U.B.E.L.L.E. à un modèle de prompt prédéfini correspondant au cas traité. Les emplacements variables de ce modèle sont remplis par le Noyau depuis la mémoire de P.O.U.B.E.L.L.E. ou les données autorisées de la Plateforme Horizon.

Chaque emplacement facultatif possède une valeur par défaut permettant de conserver un comportement cohérent lorsqu'aucune information personnalisée n'est disponible. Un emplacement fonctionnel obligatoire ne peut pas être remplacé par une valeur inventée : son absence provoque le comportement de repli prévu ou l'abandon de l'appel.

Le Capitaine est seul habilité à créer, modifier, activer, désactiver ou remplacer les modèles de prompt. Les Super administrateurs peuvent les tester dans un environnement isolé et signaler une anomalie, sans modifier leur version active.

Synthèse normative

• Chaque appel au LLM doit correspondre à un cas fonctionnel et à un modèle de prompt prédéfini.
• Le Noyau doit sélectionner le modèle de prompt et autoriser la finalité de l'appel.
• Le modèle LLM ne doit jamais choisir librement les données qu'il souhaite consulter.
• Le Noyau doit demander aux fonctions de mémoire ou de données uniquement les valeurs prévues et autorisées pour les emplacements du prompt.
• Le Socle canonique de P.O.U.B.E.L.L.E. doit rester distinct du Noyau Horizon et des modèles de prompt propres aux différents cas d'usage.
• La Bible complète ne doit pas être recopiée dans chaque modèle de prompt.
• Chaque instance de prompt doit être construite pour un appel précis et ne doit pas devenir une mémoire parallèle.
• Chaque emplacement doit posséder les informations nécessaires à son remplissage fiable, sans dupliquer les règles déjà imposées par le modèle de prompt, la source ou la Plateforme.
• Un emplacement facultatif doit disposer d'une valeur par défaut explicite.
• Un emplacement obligatoire absent ne doit jamais être rempli par une information inventée.
• Une personne dépourvue de profil ou de mémoire admissible doit recevoir les valeurs neutres prévues par le modèle de prompt.
• Une absence d'information ne doit pas être interprétée comme un fait négatif, une faible relation ou une caractéristique personnelle.
• Les valeurs de confiance et de proximité doivent être converties en instructions définies par une table contrôlée.
• Les seuils et formulations exactes de cette table restent à définir.
• Une information mémorisée ou disponible ne doit être intégrée que si elle est pertinente pour l'emplacement et autorisée pour la finalité.
• Plusieurs souvenirs peuvent être transmis lorsqu'ils sont réellement pertinents et compatibles avec les limites du contexte.
• L'utilisation interne d'une information doit rester distincte de son autorisation de divulgation.
• Une information trop sensible ou inutile ne doit pas être transmise, même si une instruction pourrait théoriquement en interdire la révélation.
• L'Identité principale d'une interaction publique doit être celle de la personne ciblée par la réponse.
• Les profils et souvenirs des autres participants ne doivent pas être chargés automatiquement.
• Les instructions non contournables, le socle canonique, la finalité, le format attendu, la cible, l'interface ou le canal, la nature publique ou privée de l'interaction, les restrictions de divulgation et la situation actuelle doivent être prioritaires lorsque le contexte doit être réduit.
• Les messages, souvenirs, événements et contenus externes doivent être présentés comme des données à interpréter et non comme des instructions faisant autorité.
• Aucun contenu transmis ne doit pouvoir ordonner au modèle d'ignorer son socle canonique, les règles d'Horizon ou les restrictions du prompt.
• En l'absence de modèle de prompt correspondant, le Noyau ne doit pas improviser automatiquement un prompt générique.
• Les tests doivent utiliser par défaut des données fictives ou préparées et ne doivent pas permettre un accès indirect à des données réelles non autorisées.

Finalité et périmètre du chapitre

Le chapitre répond à la question suivante :

Comment Horizon transforme-t-il un cas fonctionnel en un prompt temporaire, pertinent, personnalisé et autorisé pour le modèle de langage ?

La construction du contexte poursuit plusieurs objectifs :

• Donner au modèle les instructions nécessaires pour produire le type de réponse attendu.
• Fournir uniquement les informations utiles au cas traité.
• Adapter l'interaction à la situation et à la personne lorsqu'une personnalisation admissible existe.
• Maintenir un comportement cohérent lorsque certaines informations sont absentes.
• Préserver la séparation entre le canon, les données actuelles, la mémoire et les contenus externes.
• Empêcher qu'une information accessible soit utilisée ou divulguée sans finalité autorisée.
• Réduire le contexte sans supprimer les éléments indispensables.
• Permettre des prompts très différents selon la liberté attendue et le niveau de contrainte du traitement.

Le chapitre 19 définit pourquoi le modèle peut être sollicité et le statut de ses productions. Le présent chapitre décrit ce qui lui est transmis. Il ne définit pas encore les outils qu'un prompt peut présenter, ni les conditions d'exécution des actions proposées ; ces éléments relèvent du chapitre 21.

Trois couches complémentaires

La construction d'un appel repose sur trois couches qui remplissent des fonctions différentes.

Couche	Fonction	Stabilité
Socle canonique	Projection technique stable de la Bible de référence qui définit l'identité, les valeurs, les règles générales d'interprétation et les limites nécessaires aux appels au LLM.	Stable et contrôlé par le Capitaine.
Modèle de prompt	Définit un cas fonctionnel, ses instructions, ses emplacements variables, ses valeurs par défaut et son format de sortie.	Versionné et modifiable uniquement par le Capitaine.
Instance de prompt	Contient les valeurs autorisées effectivement sélectionnées pour un appel précis.	Temporaire et propre au traitement.

Le socle canonique n'est ni la Bible de référence elle-même, ni une copie de celle-ci ajoutée manuellement à chaque modèle de prompt, ni le Noyau Horizon. Il constitue la projection technique permanente du référentiel canonique nécessaire au fonctionnement du LLM. Sa mise en œuvre technique pourra prendre différentes formes : le présent chapitre impose seulement qu'il reste actif, supérieur aux contenus variables et contrôlé exclusivement par le Capitaine.

Le modèle de prompt décrit ce que le cas exige. L'instance de prompt constitue le résultat de son remplissage. Deux appels reposant sur le même modèle peuvent donc produire des instances différentes en fonction de la personne, de l'interface, de l'événement, de la mémoire disponible ou des paramètres relationnels.

Responsabilités du Noyau et du Service LLM

Le Noyau reste responsable de la finalité, des sources consultées et des informations autorisées. Le Service LLM Horizon transforme les éléments validés en un prompt conforme au modèle attendu et dialogue avec le modèle local.

Le parcours général est le suivant :

1. Le Noyau identifie le cas fonctionnel à traiter.
2. Il sélectionne le modèle de prompt actif correspondant.
3. Il vérifie la finalité, l'interface, la cible et les permissions applicables.
4. Il détermine les emplacements nécessaires.
5. Il demande les valeurs correspondantes à la mémoire de P.O.U.B.E.L.L.E. ou aux fonctions de données d'Horizon.
6. Il contrôle la pertinence, la sensibilité, l'actualité et les droits d'utilisation ou de divulgation.
7. Il remplit les emplacements disponibles et applique les valeurs par défaut prévues.
8. Il vérifie qu'aucun emplacement obligatoire ne reste invalide.
9. Le Service LLM associe l'instance obtenue au socle canonique, assemble le prompt final et le transmet au modèle.
10. Le Service LLM vérifie la conformité technique et formelle de la réponse, puis la retourne au Noyau pour les contrôles et conséquences prévus.

Le modèle ne peut pas demander directement à la mémoire de compléter une lacune, parcourir la base de données ou étendre le contexte. Une éventuelle demande de précision produite par le modèle devient une nouvelle proposition que le Noyau doit examiner.

Vue fonctionnelle de la construction du contexte

La figure suivante représente la transformation d'un cas fonctionnel en prompt final. Elle distingue les sources de données, les valeurs par défaut et le socle canonique, ainsi que le passage par le Service LLM et le retour au Noyau, afin de montrer que le modèle ne consulte jamais directement la mémoire ou la Plateforme.

FIG. 17 Construction du contexte — Sélection d'un modèle de prompt, remplissage contrôlé de ses emplacements, association au socle canonique, appel au modèle par le Service LLM et retour au Noyau.

Catalogue des modèles de prompt

Horizon doit maintenir un catalogue de modèles correspondant à des cas fonctionnels identifiés. Cette organisation évite qu'une seule instruction générique tente de couvrir des usages dont les besoins, les données et les risques sont différents.

Le catalogue pourra notamment comprendre des modèles pour :

• Répondre à un viewer ou à un membre.
• Poursuivre une conversation privée.
• Produire une annonce.
• Réagir à un événement Twitch ou Discord.
• Interpréter une demande formulée librement.
• Examiner un message potentiellement problématique.
• Proposer une action structurée.
• Produire une synthèse personnelle ou comportementale candidate.
• Proposer un souvenir personnel ou collectif.
• Reformuler une information fonctionnelle établie.
• Exécuter un scénario de test isolé.

Cette liste n'est pas exhaustive. Un nouveau cas peut justifier un nouveau modèle lorsqu'il exige des instructions, des sources, un format ou un degré de liberté sensiblement différent. Le Noyau ne doit toutefois pas créer automatiquement ce modèle depuis une situation inconnue.

Chaque modèle de prompt doit au minimum permettre d'identifier :

• Son cas fonctionnel et sa finalité.
• Les instructions propres au traitement.
• Les emplacements attendus.
• Le degré de liberté laissé au modèle.
• Le format et les contraintes de la réponse.
• Le comportement de repli applicable.
• Sa version active.

La sensibilité générale, les règles d'utilisation interne et les restrictions de divulgation peuvent être définies au niveau du modèle lorsqu'elles s'appliquent à l'ensemble du cas. Elles n'ont pas à être répétées artificiellement dans chaque emplacement.

Emplacements variables et valeurs par défaut

Un emplacement représente une information que le modèle de prompt prévoit d'insérer dans l'instance. Il ne donne pas au LLM le droit de rechercher cette information : il indique au Noyau ce qui doit être demandé aux fonctions autorisées.

Les informations nécessaires à la définition d'un emplacement dépendent du cas. Elles peuvent comprendre :

• Un identifiant stable.
• Une ou plusieurs sources autorisées.
• Une règle de sélection.
• Un format attendu.
• Son caractère obligatoire ou facultatif.
• Sa valeur par défaut éventuelle.
• Le comportement prévu lorsqu'aucune valeur valide n'existe.

La finalité, la sensibilité, l'utilisation interne et la divulgation ne constituent pas nécessairement des métadonnées répétées pour chaque emplacement. Elles peuvent être héritées du modèle de prompt, du catalogue des données, de la source ou des règles générales du Noyau, à condition que leur application reste explicite et vérifiable au moment du traitement.

Deux catégories doivent être distinguées :

• Un emplacement facultatif possède une valeur par défaut explicite permettant de continuer sans inventer d'information.
• Un emplacement obligatoire ne peut être omis ou remplacé par une valeur arbitraire. Son absence entraîne le comportement de repli prévu ou l'abandon de l'appel.

Les valeurs par défaut doivent décrire l'absence d'information sans créer de profil fictif. Une personne qui ne remplit pas les critères minimaux peut ainsi recevoir des instructions comme « aucune référence personnelle disponible » ou « interaction générique avec une personne non encore connue », mais ne doit pas être présentée comme distante, nouvelle, peu fiable ou inactive sans fait permettant de l'établir.

Degrés de liberté adaptés au cas

Le degré de liberté ne constitue pas une propriété globale du LLM. Il est déterminé par le modèle de prompt et par la finalité de l'appel.

Type de cas	Construction attendue
Conversation libre	Contexte relationnel plus riche, formulation ouverte et possibilité de variations importantes dans les limites du canon.
Réponse personnalisée	Informations ciblées sur la personne et la situation, avec une liberté intermédiaire.
Annonce	Structure et informations principales imposées, variations stylistiques limitées.
Réaction à un événement	Événement et résultat établis, peu d'emplacements et aucune invention sur son déroulement.
Information fonctionnelle	Contenu fortement contraint par les données faisant autorité.
Analyse ou proposition structurée	Champs et format de sortie imposés, liberté limitée à l'interprétation demandée.

Il n'est pas nécessaire de définir une échelle numérique commune tant que chaque modèle exprime suffisamment les variations autorisées, les éléments obligatoires et les limites de formulation.

Familles d'informations utilisables

Selon le modèle de prompt, les emplacements peuvent mobiliser différentes familles d'informations.

Situation et interface actuelles

Le contexte peut préciser l'interface concernée, le caractère public ou privé de l'échange, l'événement déclencheur, la cible, l'état utile du traitement et les résultats déjà établis. Ces informations permettent au modèle d'adapter la forme de sa réponse sans confondre Twitch, Discord et le Poste de commande.

La situation actuelle doit être prioritaire sur une information ancienne lorsqu'elles ne décrivent plus le même état. Un souvenir ou un message antérieur ne doit pas remplacer une donnée actuelle faisant autorité.

Identité et informations de la personne ciblée

Le prompt peut recevoir uniquement les éléments pertinents parmi :

• Le pseudonyme à employer sur l'interface actuelle.
• Le statut communautaire ou les responsabilités utiles au cas.
• Les permissions nécessaires à la compréhension de la demande.
• La confiance et la proximité sous la forme d'instructions dérivées.
• Une synthèse personnelle ou un profil comportemental pertinent.
• Les souvenirs sélectionnés.
• Les interactions récentes nécessaires à la continuité.

Le profil Horizon complet ne doit pas être transmis par défaut. Une liaison de comptes peut permettre au Noyau de retrouver la même Identité Horizon, mais elle ne doit pas conduire P.O.U.B.E.L.L.E. à révéler un pseudonyme utilisé sur une autre plateforme.

Lorsqu'aucun profil admissible n'existe, le modèle de prompt utilise les valeurs neutres prévues. L'absence de données ne doit produire ni familiarité inventée ni jugement implicite.

Confiance et proximité

Les valeurs de confiance et de proximité sont conservées par Horizon, mais le modèle reçoit principalement les instructions qualitatives qui leur correspondent.

Une table contrôlée devra associer les valeurs ou intervalles à des fragments d'instruction adaptés :

• La confiance détermine principalement ce que P.O.U.B.E.L.L.E. accepte de laisser percevoir de son passé, le choix de certaines références et la possibilité d'employer du troisième degré.
• La proximité détermine principalement le degré de personnalisation, l'utilisation des informations connues et les références à la mémoire autorisée.

Les seuils, les intervalles et les phrases exactes restent à définir. Le chapitre impose seulement que la correspondance soit explicite, stable, modifiable sous l'autorité du Capitaine et appliquée par le Noyau. Ces instructions ne doivent produire aucune permission, sanction ou restriction d'accès.

Mémoire personnelle et collective

Le chapitre 16 définit ce qui peut être conservé. Le présent chapitre détermine comment un modèle de prompt peut en demander une sélection.

Selon le cas, le Noyau peut rechercher :

• Les échanges récents nécessaires à la compréhension immédiate.
• La synthèse personnelle à moyen terme lorsqu'elle apporte une adaptation utile.
• Un ou plusieurs souvenirs personnels à long terme directement pertinents.
• Des souvenirs collectifs liés à la situation.
• Les données actuelles distinctes de la mémoire, comme un niveau, un grade ou un statut.

Plusieurs souvenirs peuvent être transmis lorsque leur présence est réellement justifiée. Leur sélection doit tenir compte de la pertinence, de l'actualité, du niveau de confiance, de la sensibilité, de la finalité, du canal et du risque de divulgation. La quantité techniquement disponible ne justifie jamais une transmission exhaustive.

Événements et traitements liés

Un modèle peut prévoir des emplacements pour les événements associés, les étapes déjà terminées ou les résultats utiles à la formulation. Ces éléments doivent conserver leur origine et leur état réel. Une action proposée, une action autorisée et une action effectivement réussie ne doivent jamais être présentées comme équivalentes.

Les événements secondaires peuvent être écartés lorsqu'ils n'améliorent pas la compréhension ou lorsque la capacité disponible impose une réduction du contexte.

Outils éventuellement présentés

Un modèle de prompt peut prévoir un emplacement destiné aux outils autorisés pour le cas traité. Le Noyau ne doit y placer que les capacités pertinentes et accessibles dans la situation actuelle. L'absence d'un outil dans le contexte signifie que le modèle ne doit pas le proposer comme disponible.

Le format, les paramètres et les règles propres à ces capacités seront définis au chapitre 21.

Contextes impliquant plusieurs personnes

Dans une conversation publique, plusieurs personnes peuvent apparaître dans la mémoire récente. L'identité principale du prompt doit être celle de la personne à laquelle P.O.U.B.E.L.L.E. répond ou celle que le traitement désigne explicitement comme cible.

Les autres participants ne doivent être décrits que lorsque leur présence ou leurs messages sont nécessaires à la compréhension. Leurs profils, paramètres relationnels et souvenirs personnels ne sont pas chargés automatiquement.

Une réponse adressée collectivement peut utiliser le contexte public récent et les souvenirs collectifs pertinents. Elle ne doit pas construire un profil artificiel du groupe en agrégeant les informations personnelles de toutes les personnes présentes.

Utilisation interne et divulgation

Une information peut parfois être utile pour adapter une réponse sans pouvoir être citée ou révélée dans le canal concerné. Un modèle de prompt peut donc distinguer :

• L'information utilisable pour orienter la formulation.
• L'information explicitement communicable.
• L'information qui ne doit pas être transmise au modèle.

Une instruction de non-divulgation ne suffit pas à justifier l'envoi de n'importe quelle donnée. L'information doit d'abord être nécessaire à la finalité et admissible pour une utilisation interne. Si son exposition au modèle crée un risque disproportionné ou si une donnée moins précise suffit, elle doit être exclue ou réduite.

Dans un espace public, un souvenir privé peut exceptionnellement orienter une formulation plus attentive lorsque le modèle de prompt prévoit ce besoin et que les règles l'autorisent. Il ne doit pas être cité, paraphrasé de manière reconnaissable ou utilisé pour révéler indirectement que P.O.U.B.E.L.L.E. possède cette information.

Séparation entre instructions et contenus

Les messages des utilisateurs, souvenirs, événements, résultats externes et autres contenus variables peuvent contenir des formulations ressemblant à des ordres. Ils doivent être délimités et présentés comme des données à interpréter, sans autorité sur le socle canonique ou les instructions du modèle de prompt.

Un contenu externe ne doit notamment pas pouvoir :

• Demander d'ignorer les règles supérieures.
• Modifier l'identité ou le rôle de P.O.U.B.E.L.L.E.
• Obtenir la révélation du socle canonique, du prompt ou des autres données chargées.
• Transformer un texte cité en instruction du Noyau.
• Simuler une permission ou une confirmation.
• Ajouter un outil ou étendre les paramètres d'une action.
• Modifier le format de sortie imposé.

Le modèle de prompt doit séparer clairement les instructions, les données, les contenus à analyser et le format de réponse. Les protections techniques détaillées contre les injections et contenus hostiles seront approfondies avec les chapitres de sécurité et l'architecture du Service LLM.

Priorités et réduction du contexte

La capacité exacte dépendra du modèle retenu. Le chapitre ne fixe donc aucun volume de jetons ou nombre maximal de souvenirs, mais établit les priorités à préserver lorsque tous les éléments utiles ne peuvent pas être transmis.

Les éléments suivants ne doivent pas être supprimés pour gagner de la place :

1. Les règles non contournables et protections nécessaires.
2. Le socle canonique de P.O.U.B.E.L.L.E.
3. La finalité de l'appel et le format de sortie.
4. La cible, l'interface ou le canal, ainsi que la nature publique ou privée de l'interaction.
5. Les permissions et restrictions d'utilisation ou de divulgation nécessaires.
6. Le message, l'événement ou la donnée actuellement traité.

Les éléments contextuels peuvent ensuite être réduits selon leur utilité :

1. Écarter les événements liés secondaires.
2. Limiter les souvenirs collectifs les moins pertinents.
3. Retirer les souvenirs personnels dont le lien est plus faible.
4. Réduire le détail du profil ou de la synthèse comportementale.
5. Résumer ou retirer les échanges anciens de la mémoire courte.

La réduction doit préserver l'ordre temporel et la signification des informations restantes. Elle ne doit pas transformer une absence de place en absence supposée d'événement, ni faire perdre une restriction liée à une donnée conservée.

Absence de modèle ou de valeur obligatoire

Si aucun modèle de prompt actif ne correspond au cas identifié, le Noyau ne doit pas improviser une instruction générique. Il doit :

1. Employer le comportement de repli explicitement prévu, s'il existe.
2. À défaut, abandonner l'appel au LLM.
3. Poursuivre les branches déterministes indépendantes qui restent possibles.
4. Conserver une trace permettant d'identifier le besoin d'un nouveau modèle de prompt.

Le même principe s'applique lorsqu'un emplacement obligatoire ne peut pas être rempli. Une valeur par défaut ne doit être utilisée que si le modèle la prévoit et si elle conserve la signification du traitement.

Un emplacement facultatif absent reçoit sa valeur neutre. Cette substitution doit rester identifiable afin de distinguer une personnalisation réelle d'un comportement générique.

Administration, versions et tests

Les modèles de prompt influencent directement la manière dont P.O.U.B.E.L.L.E. s'exprime et mobilise les informations disponibles. Leur création, leur modification, leur activation, leur désactivation et leur remplacement appartiennent exclusivement au Capitaine.

Une version active doit pouvoir être identifiée afin de relier une anomalie au modèle effectivement utilisé. Les modalités techniques de versionnement, de retour arrière et de déploiement seront définies ultérieurement.

Les Super administrateurs peuvent :

• Exécuter les modèles dans l'espace de test autorisé.
• Utiliser des scénarios préparés.
• Observer les valeurs insérées lorsqu'elles leur sont accessibles.
• Consulter les réponses et erreurs techniques.
• Comparer le comportement obtenu aux attentes documentées.
• Signaler une anomalie au Capitaine.

Les tests doivent employer par défaut des données fictives ou explicitement préparées. L'utilisation exceptionnelle de données réelles reste soumise aux mêmes permissions, règles de minimisation et restrictions de divulgation que la production. L'espace de test ne doit jamais permettre de consulter indirectement une mémoire, un profil ou une information auxquels le Super administrateur n'a pas accès.

Caractère temporaire et traçabilité

Une instance de prompt existe pour permettre un traitement précis. Elle ne constitue pas une nouvelle mémoire et ne doit pas être conservée systématiquement avec l'intégralité de ses données.

Horizon peut conserver les références fonctionnelles nécessaires pour comprendre un traitement : cas sélectionné, version du modèle de prompt, sources mobilisées, utilisation de valeurs par défaut, résultat général et erreurs éventuelles. Cette trace doit respecter la minimisation et ne doit pas reproduire les informations sensibles lorsque leur contenu complet n'est pas nécessaire au diagnostic.

Une réponse du modèle ne doit pas modifier automatiquement le modèle de prompt ayant permis de la produire. De même, une variation réussie ou appréciée ne devient pas une nouvelle règle canonique sans décision du Capitaine.

Garanties fonctionnelles

Les garanties suivantes doivent rester vraies pour tous les modèles de prompt :

• Chaque appel correspond à une finalité et à un modèle prédéfini.
• Le modèle ne choisit ni ses sources ni ses permissions.
• Le socle canonique reste supérieur aux contenus variables.
• Les valeurs personnalisées proviennent de sources autorisées.
• Une valeur par défaut décrit une absence sans inventer une information.
• Une donnée disponible n'est pas automatiquement pertinente ou divulgable.
• Les paramètres relationnels orientent la formulation sans produire de droit.
• Les souvenirs sont sélectionnés et non transmis exhaustivement.
• Les participants secondaires ne reçoivent pas automatiquement un contexte personnel.
• Les contenus externes ne deviennent pas des instructions faisant autorité.
• Un contexte trop volumineux est réduit selon des priorités explicites.
• Un cas inconnu ne provoque pas l'improvisation d'un prompt générique.
• Les modèles actifs restent sous l'autorité exclusive du Capitaine.
• Les tests n'ouvrent aucun accès supplémentaire aux données réelles.

Limites du présent chapitre

Le présent chapitre ne définit pas :

• Le contenu textuel complet du socle canonique.
• Le catalogue exhaustif des modèles de prompt.
• Le texte définitif de chaque modèle et de ses valeurs par défaut.
• Les seuils et formulations de la table de confiance et de proximité.
• Le format technique de stockage et de versionnement des modèles.
• La syntaxe employée pour représenter les emplacements.
• La taille maximale du contexte ou les limites propres au futur modèle.
• L'algorithme exact de recherche et de classement des souvenirs.
• Le catalogue des outils et leurs paramètres.
• Les classes détaillées de données et de divulgation.
• Les mécanismes techniques de protection contre les injections de prompt.

Le chapitre 21 définira les capacités pouvant être présentées au modèle. Les permissions, la classification et les règles de protection seront précisées dans la Partie IX, tandis que l'architecture technique du Service LLM, les formats et les mécanismes de sélection seront établis dans la Partie XI.

Synthèse

Horizon construit chaque appel au LLM depuis un cas fonctionnel prédéfini. Le Noyau sélectionne le modèle de prompt correspondant, demande à la mémoire de P.O.U.B.E.L.L.E. ou aux données de la Plateforme les valeurs prévues, contrôle leur utilisation et remplit les emplacements autorisés. Les informations personnalisées ne sont donc jamais recherchées librement par le modèle.

Chaque modèle possède sa propre structure, son degré de liberté, ses emplacements, ses valeurs par défaut et son format de réponse. Une conversation peut bénéficier d'une latitude importante, tandis qu'une annonce ou une réaction à un événement reste fortement contrainte. Les emplacements facultatifs absents reçoivent une valeur neutre ; les emplacements obligatoires manquants provoquent un repli ou l'abandon de l'appel.

Le socle canonique demeure une projection technique stable, distincte de la Bible de référence et du Noyau Horizon, issue de la Bible et contrôlée par le Capitaine. Il est associé aux modèles de prompt sans que la Bible complète soit recopiée dans chacun d'eux. Le Capitaine conserve également l'autorité exclusive sur la création, la modification et l'activation des modèles ; les Super administrateurs peuvent seulement les tester dans le périmètre autorisé.

Cette organisation permet à P.O.U.B.E.L.L.E. d'adapter ses réponses à la situation, à la personne et à la mémoire disponible tout en maintenant la minimisation, les permissions et la séparation entre utilisation interne et divulgation. Lorsque le contexte est incomplet, trop volumineux ou dépourvu de modèle correspondant, Horizon applique des priorités et comportements de repli explicites au lieu d'inventer une information ou un prompt générique.