Le Noyau Horizon

Le Noyau Horizon constitue le cœur fonctionnel de la Plateforme. Il maintient une interprétation commune des informations utiles, applique les règles et les permissions, coordonne les traitements et conserve l'autorité sur les actions demandées aux autres composantes.

Le présent chapitre définit ses responsabilités, ses limites et ses principales relations. Il ne décrit pas encore l'enchaînement détaillé des étapes d'un traitement, qui sera présenté au chapitre 8, ni le modèle de l'état global Horizon et des événements, qui relèvera du chapitre 9. Il ne fixe pas davantage le découpage logiciel, les protocoles ou le déploiement technique du Noyau, réservés à la Partie XI.

Fonctionnement cible — Validé

Toute information fonctionnelle susceptible d'influencer une donnée, une règle, une permission, une décision, une action ou l'état connu d'Horizon doit être traitée ou contrôlée par le Noyau.

Le Noyau vérifie l'origine et le contexte de la demande, détermine les contrôles nécessaires, coordonne les fonctions utiles et reste l'autorité qui autorise, refuse ou suspend l'exécution. Aucune interface, extension, tâche automatique, intervention de P.O.U.B.E.L.L.E. ou proposition du LLM ne peut contourner cette autorité.

Synthèse normative

• Le Noyau constitue l'unique périmètre d'autorité fonctionnelle pour les traitements et les actions d'Horizon.
• Toute information capable d'influencer Horizon est traitée ou contrôlée par le Noyau ; les ressources strictement inertes peuvent être servies directement.
• L'orchestrateur est la fonction logique principale de coordination du Noyau, sans constituer une autorité distincte ni imposer un découpage logiciel particulier.
• L'identité, les capacités, le contexte, la cible et les conditions d'une demande sont vérifiés au moment du traitement et de l'exécution.
• Une correction automatique n'est permise que pour une donnée Horizon non sensible lorsqu'une règle déterministe, explicite et autorisée établit la valeur correcte.
• P.O.U.B.E.L.L.E., le LLM, les interfaces et les extensions utilisent des capacités limitées ; aucun de ces composants ne contrôle directement l'exécution ni ne contourne le Noyau.

Le cœur fonctionnel de la Plateforme

La centralité du Noyau ne signifie pas que toutes les fonctions d'Horizon doivent être réalisées par un seul programme, un seul processus ou une seule machine. Elle désigne une unicité fonctionnelle : quelle que soit la manière dont la Plateforme sera techniquement déployée, les décisions communes doivent relever d'un même périmètre d'autorité.

Le Noyau est notamment chargé de :

• Recevoir ou produire les événements utiles au fonctionnement d'Horizon.
• Identifier leur origine, leur auteur éventuel et leur contexte.
• Déterminer les données, règles et ressources nécessaires au traitement.
• Vérifier les permissions du demandeur et des autres acteurs impliqués.
• Classifier les données et les actions afin d'appliquer les protections adaptées.
• Limiter chaque consultation, transmission et capacité d'action aux informations et permissions nécessaires au traitement concerné.
• Demander une confirmation humaine lorsqu'elle est nécessaire.
• Exécuter les traitements internes autorisés.
• Transmettre aux extensions des instructions limitées et contextualisées.
• Interpréter les résultats, erreurs ou absences de réponse retournés.
• Mettre à jour l'état d'Horizon lorsqu'une conséquence est effectivement établie.
• Conserver les traces nécessaires à l'explication et au suivi du traitement.
• Superviser la cohérence de la Plateforme et déclencher certaines vérifications internes.

Le Noyau ne se contente donc pas de faire circuler des messages entre des services. Il donne à chaque traitement un contexte commun, applique les règles d'Horizon et évite qu'une interface ou une automatisation construise sa propre version de la situation.

Les informations qui doivent passer par le Noyau

Une information doit être traitée ou contrôlée par le Noyau dès lors qu'elle peut avoir une conséquence fonctionnelle. Cela concerne notamment :

• Un événement provenant de Twitch, Discord, OBS, du Poste de commande ou d'un autre service relié.
• Une demande formulée par une personne, P.O.U.B.E.L.L.E., une extension ou une tâche interne.
• Une lecture, une création ou une modification de donnée.
• Un calcul influençant la progression, un niveau, un grade, un rôle ou une permission.
• Une confirmation, une annulation, un refus ou une demande de correction.
• Un résultat retourné par une extension ou un service externe.
• Une différence constatée entre deux représentations d'un même état.
• Toute information utilisée pour décider si une action est autorisée, critique ou pertinente.

Cette règle n'impose pas de faire transiter par le Noyau chaque ressource strictement inerte. Une feuille de style, une image publique, une police de caractères, un fichier documentaire ou un autre contenu statique peut être servi directement lorsqu'il ne dépend d'aucune donnée protégée et ne produit aucun effet fonctionnel.

La frontière dépend donc de la capacité de l'information à influencer Horizon, et non de son seul format. Une page Web statique peut être distribuée sans traitement fonctionnel ; l'affichage du niveau d'un membre sur cette même page doit au contraire passer par les contrôles du Noyau.

Le Noyau et l'orchestrateur

Le Noyau désigne l'ensemble du périmètre fonctionnel qui possède l'autorité de traitement et d'exécution d'Horizon. L'orchestrateur est sa fonction interne principale, chargée de conduire un traitement et de mobiliser les autres fonctions du Noyau dans l'ordre nécessaire.

L'orchestrateur constitue la fonction logique principale de coordination du Noyau. Il n'a pas vocation à contenir lui-même chaque règle, chaque calcul ou chaque mécanisme de contrôle. Il peut s'appuyer sur des fonctions spécialisées appartenant au Noyau, puis consolider leurs réponses afin de poursuivre, suspendre, refuser, abandonner ou terminer le traitement.

Cette définition reste fonctionnelle. Elle n'impose ni un programme principal unique, ni un processus, ni une machine particulière. Le futur découpage logiciel sera étudié dans la Partie XI ; toute orientation vers un programme central devra y être explicitement validée.

Cette distinction permet d'éviter deux confusions :

• Le Noyau n'est pas réduit à l'orchestrateur ; il comprend également les fonctions internes que celui-ci coordonne.
• L'orchestrateur ne constitue pas une autorité distincte ; il exerce la coordination au sein des règles et du périmètre d'autorité du Noyau.

L'orchestrateur doit conserver le lien entre la demande d'origine, les contrôles réalisés, les ressources consultées, les conséquences produites et leurs résultats. Le détail de cet enchaînement sera défini au chapitre 8.

Première cartographie des fonctions internes

La liste suivante constitue une première cartographie fonctionnelle. Elle est non exhaustive et pourra être complétée ou regroupée à mesure que les besoins seront précisés. Elle n'impose pas qu'une fonction corresponde à un service logiciel indépendant : plusieurs fonctions pourront être réalisées par un même composant, tandis qu'une fonction complexe pourra s'appuyer sur plusieurs composants techniques.

Fonction interne	Responsabilité générale
Réception et validation	Reçoit les événements et demandes, vérifie leur structure, leur origine technique et leur caractère exploitable.
Identification et contexte	Identifie l'acteur, le service, l'identité Horizon et le contexte fonctionnel auxquels rattacher le traitement.
Orchestrateur	Conduit le traitement, sélectionne les fonctions nécessaires et coordonne leurs résultats.
Moteur de règles	Applique les règles déterministes propres à Horizon et produit les décisions ou calculs faisant autorité.
Contrôle des permissions	Vérifie que l'auteur, le demandeur et, le cas échéant, la personne confirmant l'action disposent des capacités requises.
Classification et protection	Évalue la sensibilité des données et le niveau de risque des actions, puis applique la minimisation des informations, le moindre privilège et les restrictions de lecture, d'utilisation, de modification ou de divulgation.
Gestion des confirmations	Suspend les actions qui l'exigent, présente leur portée et valide l'identité ainsi que l'habilitation de la personne qui confirme.
Accès contrôlé aux données et à l'état	Consulte ou modifie les informations utiles en respectant leur autorité, leur finalité et les règles de cohérence.
Planification des tâches internes	Déclenche les vérifications périodiques, maintenances et automatisations autorisées sans dépendre d'une demande externe immédiate.
Supervision de la cohérence	Recherche les erreurs potentielles, les états incohérents et les différences nécessitant une correction ou un signalement.
Gestion des actions autorisées	Produit des instructions limitées à destination des extensions et empêche qu'une conséquence dépasse le périmètre validé.
Consolidation des résultats	Interprète les retours, distingue réussite, refus, erreur et exécution partielle, puis détermine l'état réellement atteint.
Mise à jour de l'état	Enregistre les changements confirmés et maintient la représentation actuelle connue d'Horizon.
Traçabilité et audit	Rattache les demandes, contrôles, décisions, confirmations, corrections, résultats et erreurs au traitement concerné.
Coordination du mode dégradé	Maintient les fonctions déterministes disponibles et adopte un comportement prévisible lorsqu'une ressource devient indisponible.

Les noms définitifs, la granularité et la répartition technique de ces fonctions seront précisés pendant la conception de l'architecture cible. Leur présence dans ce chapitre exprime des responsabilités à couvrir, et non une architecture logicielle déjà figée.

Des relations contrôlées avec les autres composantes

Le Noyau se trouve au centre des échanges fonctionnels sans devenir propriétaire de toutes les composantes qu'il coordonne. Chaque relation conserve une frontière particulière.

Composante ou acteur	Relation avec le Noyau	Limite principale
P.O.U.B.E.L.L.E.	Observe, communique, consulte les informations autorisées et demande des actions par l'intermédiaire du Noyau.	Elle reste une entité indépendante et ne confirme pas elle-même une action critique.
Poste de commande Web	Présente les informations et transmet les demandes, modifications ou confirmations des personnes authentifiées.	L'interface n'accorde aucun droit par elle-même et ne modifie pas directement les données.
Extensions Horizon	Traduisent les événements externes, exécutent les instructions autorisées et retournent leurs résultats.	Elles ne décident pas seules des règles communes et ne peuvent pas élargir une instruction.
Persistance et état global Horizon	Fournissent au Noyau les informations persistantes et la représentation fonctionnelle actuelle nécessaires aux traitements.	L'existence d'une donnée ne crée pas un droit général d'accès ou d'utilisation.
Mémoire de P.O.U.B.E.L.L.E.	Restitue au Noyau les éléments autorisés et pertinents pour construire un contexte.	Elle ne remplace ni l'état actuel, ni l'historique, ni les journaux d'audit.
Service LLM Horizon	Composant interne sollicité par le Noyau pour assembler la demande à partir du modèle de prompt, des sources, des données et des restrictions sélectionnés par le Noyau, puis vérifier la conformité technique et formelle du résultat.	Le service appartient à Horizon ; le modèle local reste une ressource distincte. Ni le service ni le modèle ne décident d'une valeur faisant autorité et n'accèdent directement aux systèmes.
Services externes	Produisent des événements ou reçoivent des demandes par l'intermédiaire d'une extension contrôlée.	Ils conservent l'autorité sur leurs données natives, leurs contraintes et l'exécution réelle de leurs fonctions.

Le Noyau ne doit pas créer de connexion libre entre ces composantes. Une extension ne consulte pas directement la mémoire parce qu'elle en a techniquement la possibilité. Ni le service LLM ni le modèle sollicité n'interrogent librement la base de données. P.O.U.B.E.L.L.E. ne transmet pas une instruction directement à Discord ou OBS. Le Noyau autorise la finalité et le périmètre du traitement, sélectionne le modèle de prompt, les sources, les données et les restrictions, puis le service LLM assemble et vérifie techniquement la demande dans ces limites. Plus généralement, seules les informations nécessaires et les actions accessibles doivent être mises à la disposition de chaque composante.

La place particulière de P.O.U.B.E.L.L.E. sera développée au chapitre 18, celle du modèle au chapitre 19, et les outils accessibles à P.O.U.B.E.L.L.E. au chapitre 21.

Schéma du périmètre fonctionnel du Noyau

Le schéma suivant représente l'orchestrateur au centre du Noyau, entouré des principales fonctions qu'il coordonne. Il distingue ces fonctions internes des services communs de la Plateforme, des extensions placées à sa frontière et des acteurs ou systèmes extérieurs. P.O.U.B.E.L.L.E. y apparaît comme une entité indépendante utilisant Horizon. Le service LLM demeure à l'intérieur de la Plateforme, tandis que le modèle local, dont le choix exact relève du chapitre 19, reste une ressource technique distincte.

Il ne représente pas encore l'ordre exact d'un traitement. Les flèches doivent être comprises comme des relations de contrôle et de coordination : le parcours séquentiel d'un événement sera présenté dans le chapitre suivant.

FIG. 05 Figure fonctionnelle — Périmètre du Noyau Horizon, fonctions coordonnées par l'orchestrateur et frontières entre les composants internes, P.O.U.B.E.L.L.E., le modèle éventuellement sollicité et les systèmes extérieurs.

Des événements et tâches produits par le Noyau

Le Noyau ne réagit pas uniquement aux événements reçus depuis Twitch, Discord, le Poste de commande ou un autre système. Il peut produire ses propres événements et déclencher des traitements internes afin de maintenir la Plateforme dans un état cohérent.

Ces traitements peuvent notamment servir à :

• Effectuer une vérification périodique de cohérence.
• Détecter une donnée manquante, invalide ou contradictoire.
• Reprendre une opération temporairement interrompue.
• Expirer un état, une autorisation ou une demande devenue obsolète.
• Recalculer une donnée dérivée lorsque sa source évolue.
• Contrôler qu'une synchronisation attendue a bien eu lieu.
• Préparer une notification ou demander une intervention humaine.
• Réaliser une tâche de maintenance fonctionnelle autorisée.

Une tâche interne n'échappe pas aux règles applicables aux autres traitements. Elle doit posséder une origine identifiable, généralement un acteur système ou une fonction planifiée, un objectif défini et un périmètre d'action limité. Ses contrôles, ses décisions et ses résultats importants doivent rester traçables.

Le simple fait qu'une anomalie ait été détectée par le Noyau ne l'autorise pas à la corriger par n'importe quel moyen. La nature de la donnée, son autorité, sa sensibilité et les conséquences de la modification déterminent la réponse permise.

Détection des différences et corrections encadrées

Le Noyau doit pouvoir comparer les informations utiles, détecter des écarts et proposer ou réaliser les corrections compatibles avec son périmètre. Cette capacité participe à la continuité d'Horizon, mais elle ne crée pas un droit général de modification.

L'autorité et l'éventuelle priorité doivent rester définies donnée par donnée, conformément au chapitre 14.

Situation constatée	Réponse générale du Noyau
Conflit portant sur une donnée native d'Horizon, non sensible, dont la règle de correction est déterministe et autorisée	Le Noyau peut appliquer automatiquement la correction, conserver les valeurs avant et après, puis l'inscrire dans la page de suivi des corrections. Un niveau ou un grade Horizon peut relever de ce cas lorsque sa règle de calcul permet d'établir sans ambiguïté la valeur correcte.
Différence portant sur une donnée Horizon présentant une sensibilité, même limitée	Le Noyau signale l'anomalie et fournit les éléments nécessaires à sa compréhension. La modification est réalisée par un Super administrateur ou le Capitaine selon ses permissions.
Différence portant sur une donnée dont un service externe est l'autorité	Le Noyau peut demander une nouvelle lecture, corriger sa représentation locale selon les règles établies ou signaler l'écart. Il ne remplace pas silencieusement la valeur détenue par le service externe.
Correction ambiguë, non prévue ou susceptible d'entraîner une conséquence importante	Le Noyau suspend la correction automatique et demande une décision humaine adaptée au niveau de risque.

Une correction automatique autorisée doit être aussi explicable qu'une modification humaine. La trace doit au minimum permettre d'identifier la différence constatée, la règle appliquée, la valeur précédente, la nouvelle valeur, l'origine du traitement et son résultat.

La page de suivi des corrections réunit les corrections appliquées automatiquement et celles qui nécessitent encore une intervention manuelle. À l'issue d'une vérification ayant produit au moins une correction ou une demande d'intervention, Horizon émet une seule notification consolidée indiquant le nombre de corrections réalisées et le nombre de corrections restant à effectuer manuellement.

Cette notification ne constitue pas une demande d'approbation rétroactive. Elle permet aux personnes disposant de la capacité de supervision nécessaire, notamment les Super administrateurs et le Capitaine, de consulter le détail, de contrôler les règles appliquées et d'intervenir uniquement lorsque cela est nécessaire. Les mécanismes de regroupement, de gravité, d'alerte et de journalisation seront approfondis aux chapitres 47 et 48.

Vérification des permissions et des confirmations

Le Noyau doit toujours vérifier qu'une demande provient d'une personne, d'une entité ou d'un service habilité à la formuler. Cette vérification ne peut pas être déléguée définitivement à l'interface depuis laquelle la demande a été reçue.

Une interface peut authentifier une personne, afficher uniquement les commandes auxquelles elle semble avoir accès et recueillir sa confirmation. Le Noyau doit néanmoins vérifier de nouveau :

• L'identité effectivement rattachée à la session ou au compte externe.
• La validité actuelle des rôles et responsabilités nécessaires.
• La permission précise correspondant à l'opération demandée.
• Le périmètre sur lequel cette permission s'applique.
• La classification des données consultées ou modifiées.
• L'état courant de la cible et la persistance des conditions d'exécution.
• L'identité et l'habilitation de la personne confirmant une action critique.

Une confirmation humaine n'autorise donc pas à contourner les autres règles. Si la situation a changé, si la permission a été retirée ou si l'action n'est plus valide, le Noyau doit refuser ou demander une nouvelle confirmation adaptée au contexte actuel.

Le modèle détaillé des capacités sera défini au chapitre 32, la sensibilité des informations au chapitre 33 et les mécanismes de confirmation au chapitre 34.

Les capacités étendues et encadrées de P.O.U.B.E.L.L.E.

P.O.U.B.E.L.L.E. dispose de capacités de service propres, accordées fonction par fonction et limitées à une finalité. Certaines peuvent couvrir un périmètre étendu de lecture, de supervision ou de diagnostic afin de détecter des erreurs potentielles, d'effectuer des vérifications, d'automatiser des tâches et de demander les corrections nécessaires. Elles ne dérivent d'aucun rôle humain et n'en reproduisent pas les permissions.

Ces capacités sont accordées à des finalités définies et exercées sous le contrôle du Noyau. Elles ne constituent ni une liberté d'administration générale ni un statut humain de Super administrateur.

P.O.U.B.E.L.L.E. peut notamment, lorsque la fonction et le contexte l'autorisent :

• Consulter un périmètre étendu d'informations nécessaire à la supervision ou à l'assistance.
• Lancer des diagnostics et des vérifications de cohérence.
• Transmettre des demandes susceptibles de conduire le Noyau à produire un événement dérivé ou à autoriser une action.
• Demander ou déclencher, par l'intermédiaire du Noyau, certaines corrections non sensibles prévues par des règles déterministes.
• Signaler une différence, expliquer son origine probable et demander une intervention humaine.
• Notifier les responsables des résultats d'une vérification ou d'une correction.

Elle ne peut pas, de sa propre autorité :

• S'accorder de nouvelles permissions ou modifier son propre périmètre d'accès.
• Contourner l'orchestrateur, le contrôle des permissions ou les extensions.
• Produire, modifier ou valider de sa propre autorité un événement dérivé ou une correction.
• Confirmer elle-même une action critique qu'elle a proposée ou préparée.
• Modifier librement une donnée sensible ou une règle de sécurité.
• Fusionner, supprimer ou réattribuer une identité sans le contrôle humain requis.
• Consulter ou divulguer une information sans finalité autorisée.
• Transformer une proposition du LLM en action directement exécutable.

Cette asymétrie permet à P.O.U.B.E.L.L.E. de jouer un rôle actif dans l'exploitation d'Horizon tout en maintenant une autorité humaine supérieure pour les décisions sensibles. Le Super administrateur conserve une capacité d'administration de la Plateforme et le Capitaine l'autorité humaine générale définies au chapitre 5.

Une autorité d'exécution fondée sur les résultats

Le Noyau autorise les conséquences, mais il n'exécute pas nécessairement lui-même chaque action dans son environnement final. Lorsqu'une action concerne Twitch, Discord, OBS ou un autre service, il transmet une instruction contextualisée à l'extension compétente.

Cette transmission ne suffit pas à établir que l'action a réussi. L'extension doit retourner un résultat exploitable, et le Noyau doit distinguer :

• L'instruction préparée mais non transmise.
• La demande transmise mais non confirmée.
• L'action refusée par le service.
• L'action échouée pour une raison technique.
• L'action entièrement réussie.
• L'exécution partielle de plusieurs conséquences liées.
• Une situation dont le résultat reste incertain.

Le Noyau met à jour l'état d'Horizon en fonction de ce qui est réellement établi, et non de la seule intention initiale. Il doit également éviter qu'une reprise, une répétition d'événement ou une absence temporaire de réponse produise involontairement plusieurs fois la même conséquence. Ces mécanismes seront détaillés dans le chapitre 8.

Continuité et mode dégradé

Le Noyau coordonne également la réaction de la Plateforme lorsqu'une ressource devient indisponible. Le comportement attendu dépend de la fonction concernée, de son caractère essentiel et du niveau de certitude nécessaire.

Les fonctions déterministes essentielles doivent continuer autant que possible sans LLM. De la même manière, l'indisponibilité du Poste de commande ne doit pas interrompre les traitements indépendants de cette interface, et l'arrêt d'un service externe ne doit pas rendre incohérentes les données internes qui peuvent encore être consultées de manière sûre.

Le mode dégradé ne doit toutefois pas inventer un résultat, assouplir une permission ou considérer une action externe comme réussie sans preuve suffisante. Le Noyau peut différer une conséquence, la refuser temporairement, employer une réponse déterministe ou signaler l'indisponibilité. Il doit privilégier un comportement prévisible, explicable et sûr.

Limites du Noyau

La position centrale du Noyau ne lui accorde pas une autorité universelle. Il ne doit pas :

• Se substituer à Twitch, Discord, OBS ou un autre service pour les données et fonctions dont ceux-ci restent l'autorité.
• Exécuter silencieusement une action externe sans passer par une extension ou un mécanisme contrôlé équivalent.
• Donner à une interface, une extension, P.O.U.B.E.L.L.E. ou au LLM un accès direct et général aux données.
• Transmettre à P.O.U.B.E.L.L.E., à une extension, au service LLM ou au modèle davantage d'informations que ne l'exige la finalité autorisée du traitement.
• Confondre l'état actuel, l'historique, les journaux techniques et la mémoire de P.O.U.B.E.L.L.E.
• Traiter la possession technique d'une information comme une permission de la lire, de l'utiliser, de la modifier ou de la divulguer.
• Corriger automatiquement une donnée sensible, ambiguë ou extérieure à son autorité sans règle explicite.
• Considérer une confirmation comme permanente lorsque le contexte ou les permissions ont changé.
• Dépendre du LLM pour les décisions, calculs et contrôles qui font autorité.
• Transformer sa centralité fonctionnelle en contrainte prématurée sur le nombre de services, de processus ou de machines nécessaires à son implémentation.

Ces limites garantissent que le Noyau reste un centre de coordination et de contrôle, sans devenir une justification pour concentrer indistinctement tous les accès et toutes les responsabilités.

Synthèse des responsabilités

Domaine	Responsabilité du Noyau	Frontière conservée
Information fonctionnelle	Traite ou contrôle toute information pouvant influencer une donnée, une règle, une permission, une décision, une action ou un état.	Les ressources strictement inertes peuvent être servies sans traitement fonctionnel.
Orchestration	Coordonne les fonctions internes et conserve le contexte commun du traitement.	L'orchestrateur est une fonction du Noyau, pas une autorité séparée.
Règles et permissions	Applique les règles déterministes, vérifie le demandeur et contrôle les confirmations.	Une interface ou une confirmation humaine ne remplace jamais les contrôles du Noyau.
Données et état	Consulte, calcule et modifie les informations selon leur autorité, leur sensibilité et leur finalité.	Centraliser une donnée ne crée ni propriété universelle ni accès général.
Supervision	Produit des événements dérivés, effectue des vérifications et détecte les incohérences.	Une tâche automatique reste identifiée, limitée, contrôlée et traçable.
Corrections	Peut corriger automatiquement certaines données Horizon non sensibles lorsque la règle est déterministe et autorisée.	Les valeurs avant et après sont tracées ; une page de suivi et une notification consolidée distinguent les corrections réalisées de celles qui exigent une intervention humaine.
P.O.U.B.E.L.L.E.	Lui fournit des capacités de service propres, finalisées et contrôlées pour ses demandes d'action, d'événement dérivé ou de correction.	Elle ne reçoit pas le rôle de Super administrateur et ne devient ni autorité d'exécution, ni source de sa propre confirmation.
Extensions et services externes	Autorise les instructions, collecte les résultats et met à jour l'état réellement établi.	Les services externes gardent leurs contraintes et l'autorité sur l'exécution native.
Résilience	Maintient les fonctions déterministes possibles et coordonne le mode dégradé.	Il ne doit ni inventer un résultat ni affaiblir les contrôles pour préserver artificiellement une fonction.
Implémentation	Définit un périmètre d'autorité fonctionnelle unique.	Le présent chapitre ne fixe pas le découpage logiciel ou l'infrastructure technique.

Le Noyau Horizon constitue ainsi le point commun auquel les informations prennent un contexte, les règles deviennent des décisions et les demandes deviennent éventuellement des actions autorisées. Le chapitre suivant décrira précisément ce passage en suivant le cycle complet d'un événement, depuis sa réception ou sa production interne jusqu'à l'enregistrement des résultats et de ses différentes conséquences.