Un référentiel externe ne gouverne pas le canon

Statut de cette position

Cette page est une projection publique d’une position architecturale proposée. Elle explique une frontière destinée à être spécifiée dans le dépôt doctrinal normatif ; elle ne remplace pas cette spécification et ne déclare pas qu’un mécanisme d’intégration externe est déjà actif en production.

La position est la suivante :

Un référentiel externe peut qualifier un risque, une mitigation, une obligation ou une correspondance. Il ne gouverne pas directement le canon interne et ne peut pas élargir les permissions qui en sont dérivées.

Cette règle s’applique aux taxonomies de risques, normes, cadres réglementaires, bases de mitigations, Codebooks, manuels de marque et autres formalismes importés.

1. Trois autorités qu’il faut cesser de confondre

Une architecture gouvernée doit distinguer au moins trois plans.

1.1 L’autorité de référence externe

Elle provient d’un organisme, d’un standard, d’un auteur ou d’une institution externe. Elle est autoritative sur son propre document : son vocabulaire, ses catégories, ses versions, sa licence et la portée qu’elle déclare.

Elle peut notamment servir à :

• nommer un type de risque reconnu ;
• comparer plusieurs cadres ;
• repérer une famille de contrôles ;
• documenter une obligation ou une pratique ;
• établir un vocabulaire commun avec des auditeurs ou des partenaires.

Cette autorité ne s’étend pas automatiquement aux affirmations internes d’une autre organisation.

1.2 L’autorité canonique interne

Elle détermine quelles sources font foi sur l’identité, les affirmations, les termes, les contraintes et les règles de préséance de l’organisation.

Elle répond à des questions différentes :

• quelle entité est concernée ;
• quel Claim est admis ;
• quelle source possède autorité sur sa classe ;
• quelles limites ou exclusions s’appliquent ;
• quelle règle arbitre un conflit ;
• quelle information peut être projetée dans une situation donnée.

Une source officielle peut être canonique sur l’identité, la doctrine publiée ou une limite déclarée. Elle ne devient pas pour autant l’arbitre absolu de la réputation, de la critique externe ou de la vérité objective.

1.3 L’autorité de décision opérationnelle

Elle appartient au mécanisme qui applique les règles compilées à une interaction concrète. Elle n’invente pas de nouvelles permissions. Elle sélectionne seulement parmi ce que les couches supérieures ont déjà autorisé.

Cette autorité peut décider :

• d’admettre une information ;
• de la borner ;
• de l’accompagner d’une contrainte ;
• de demander une clarification ;
• de produire une non-réponse légitime ;
• d’inscrire l’événement dans la chaîne de preuve.

Le runtime ne doit donc pas devenir juge de sa propre politique. Il exécute une projection déterministe issue d’autorités et de règles préalablement compilées.

2. Le Core reste fermé à cinq objets

La proposition v0.1 repose sur cinq objets seulement :

1. Entity ;
2. Claim ;
3. Term ;
4. Constraint ;
5. Precedence.

Leur petit nombre est une propriété de contrôle, pas une limitation accidentelle.

Un cadre externe ne crée pas un objet Risk, Control, Framework, Codebook ou Profile supplémentaire dans le Core. Ces notions peuvent exister dans un registre externe, une matrice de correspondance ou une projection, mais elles ne modifient pas le modèle canonique.

Cette fermeture évite qu’une nouvelle intégration impose chaque fois :

• son ontologie ;
• ses états ;
• son cycle de vie ;
• ses règles de priorité ;
• ses ambiguïtés ;
• ses dépendances techniques.

Les cinq objets doivent suffire à exprimer les effets internes d’une correspondance.

Exemple : un risque externe peut conduire à proposer une Constraint exigeant la date d’une certification avant livraison. Le risque externe n’est pas la Constraint. Il en est la justification référencée. La Constraint n’entre dans le Core qu’après décision d’autorité et admission selon les règles internes.

3. Les états du Core ne doivent pas être contaminés

Les états canoniques demeurent :

• allowed ;
• conditional ;
• forbidden ;
• deprecated.

Une correspondance externe peut posséder son propre statut de travail, par exemple « proposée », « revue », « acceptée », « rejetée » ou « remplacée ». Ce statut appartient au registre de correspondance, pas au Core.

La différence est importante.

Une condition qui n’est pas satisfaite ou ne peut pas être évaluée rend le Claim non admissible dans la situation. Elle ne transforme pas automatiquement ce Claim en forbidden. Le statut forbidden doit rester réservé à une interdiction explicite relevant de l’autorité compétente.

De la même manière, une catégorie de risque élevée ne transforme pas à elle seule tous les Claims reliés en forbidden. Elle peut imposer un seuil de preuve plus élevé, une qualification, une escalade ou une non-réponse. La décision dépend du contexte et des règles internes.

4. Une correspondance est une projection dérivée

La relation entre un cadre externe et le Core doit être représentée comme une correspondance versionnée et réversible.

Elle peut déclarer :

• l’espace de noms externe ;
• l’identifiant du risque ou du contrôle ;
• la version ou la date du snapshot ;
• la source et sa licence ;
• le mode de défaillance interne ciblé ;
• les objets du Core concernés ;
• l’autorité ayant approuvé la correspondance ;
• les conditions d’applicabilité ;
• les preuves attendues ;
• les limites résiduelles.

Elle doit aussi déclarer :

canonical: false

Ce champ ne signifie pas que le cadre externe est peu fiable. Il signifie que ce cadre ne détient pas l’autorité de définir le canon interne.

Une correspondance acceptée peut influencer la politique de gouvernance ou la construction d’une projection. Elle demeure supprimable ou remplaçable sans réécrire les objets du Core qu’elle référence.

5. Règle de non-élargissement

L’axiome de non-élargissement s’applique à toute la chaîne :

Une couche inférieure ne peut jamais élargir les permissions accordées par une couche supérieure.

Par conséquent :

• un référentiel externe ne peut pas autoriser un Claim que le canon n’autorise pas ;
• une matrice de correspondance ne peut pas neutraliser une Constraint ;
• une projection ne peut pas ajouter un sens absent des objets admis ;
• le runtime ne peut pas compléter une condition non satisfaite ;
• une restitution fluide ne peut pas être requalifiée en réponse légitime après coup ;
• une métrique agrégée ne peut pas effacer une condition nécessaire non satisfaite.

Les exceptions doivent être explicites, localisées et autorisées par une règle de niveau supérieur. Une exception implicite est un élargissement non gouverné.

6. Relation avec un Codebook

Un Codebook peut jouer deux rôles valides, mais pas simultanément.

6.1 Source de bootstrap

Le Codebook est analysé et normalisé vers les cinq objets du Core. Chaque élément importé reçoit une provenance, une autorité, un statut et, si nécessaire, une revue humaine.

Après cette étape, le Codebook ne demeure pas la dépendance opérationnelle du runtime. Les changements ultérieurs suivent le processus d’autorité du Core.

6.2 Vue régénérée

Le Codebook devient une représentation lisible produite à partir du Core. Il peut servir à la consultation humaine, à l’édition encadrée ou à l’échange, mais il ne doit pas réinjecter automatiquement ses propres sorties comme nouvelles vérités.

La boucle bidirectionnelle non arbitrée est interdite. Elle rend impossible de savoir quelle surface gouverne l’autre.

La même règle vaut pour un registre de risques : import contrôlé vers un espace externe, puis correspondances approuvées. Jamais une synchronisation vivante capable de muter le Core sans décision.

7. Le statut épistémique accompagne chaque transformation

Une architecture capable d’importer des cadres et d’utiliser des modèles de classification doit conserver la nature de chaque connaissance.

Au minimum, elle distingue :

• déclaré par la source : l’information est explicitement publiée par l’autorité citée ;
• dérivé de manière déterministe : l’information résulte d’une règle reproductible ;
• classifié par un modèle : l’information est une sortie probabiliste ;
• revu par un humain : une personne identifiée a examiné la proposition ;
• observé en interaction : l’information décrit un événement ou une restitution dans une fenêtre donnée.

Un résultat peut porter plusieurs statuts successifs, mais leur chaîne doit être conservée.

Une classification par modèle doit au minimum transporter :

• le fournisseur et le modèle ;
• la version disponible ;
• le protocole ou les instructions ;
• la date ;
• le corpus utilisé ;
• le score ou degré de pertinence ;
• le statut de revue humaine ;
• les désaccords connus.

Aucun score de confiance ne convertit automatiquement une classification en fait canonique.

8. Le référentiel est capturé, jamais consulté en direct par le runtime

Une intégration sérieuse utilise un snapshot local et versionné.

Le flux minimal est :

source externe sélectionnée
        ↓
snapshot daté
        ↓
hachage
        ↓
licence et attribution
        ↓
normalisation externe
        ↓
revue de correspondance
        ↓
compilation
        ↓
projection autorisée

Le runtime ne doit pas interroger directement une base externe au moment de livrer une réponse. Cette dépendance introduirait une mutation potentielle hors contrôle, une impossibilité de reproduire l’état et une ambiguïté sur la version effectivement appliquée.

Une nouvelle version du référentiel déclenche une comparaison. Elle ne remplace jamais automatiquement la version activée.

9. Cycle de gouvernance et de preuve

Le référentiel externe intervient dans une boucle plus large :

Authority
    → admissibility
    → projection
    → delivery
    → restitution
    → deviation
    → conformance
    → ledger

La projection peut être représentée ainsi :

P = f(A, G, I, C)

avec :

• A : l’autorité et les objets canoniques admis ;
• G : la politique de gouvernance applicable ;
• I : l’intention ou la classe de requête ;
• C : le contexte, incluant audience, canal, juridiction et temporalité ;
• P : la projection autorisée.

Le cadre externe peut informer G. Il ne remplace pas A.

La restitution R est ensuite comparée à P :

Δ = g(P, R)

La conformité Q qualifie l’écart selon la gouvernance :

Q = h(Δ, G)

Une observation inscrite au ledger peut déclencher une révision de la politique ou d’une correspondance. Elle ne modifie pas directement les cinq objets.

10. Contradictions et échecs de compilation

Lorsqu’un référentiel externe entre en tension avec une autorité interne, le système ne doit pas résoudre le conflit par proximité textuelle ou par moyenne.

Les règles minimales sont :

• une autorité externe reste bornée à son propre objet ;
• une correspondance doit identifier la classe de Claim concernée ;
• une règle de Precedence explicite doit arbitrer les autorités comparables ;
• deux règles contradictoires de même autorité provoquent un échec de compilation ;
• une correspondance dont l’applicabilité ne peut pas être évaluée demeure inactive ;
• une non-réponse est préférable à une permission inventée.

L’échec de compilation est un mécanisme de sécurité. Il empêche la contradiction de devenir une décision arbitraire au moment de l’interaction.

11. Ce que cette position interdit

Cette position interdit les dérivations suivantes :

1. traiter une taxonomie externe comme autorité interne par défaut ;
2. créer un nouvel objet du Core pour chaque cadre importé ;
3. promouvoir une classification de modèle en fait canonique sans revue ;
4. brancher le runtime sur une source externe vivante ;
5. laisser une observation muter directement le canon ;
6. utiliser une mitigation déclarée comme preuve d’efficacité ;
7. prétendre à une conformité globale à partir d’une correspondance partielle ;
8. laisser une couche inférieure élargir une permission supérieure.

12. Conséquence architecturale

Un système interopérable n’est pas celui qui absorbe tous les cadres dans son noyau. C’est celui qui peut :

• capturer leur version ;
• préserver leur attribution ;
• les garder dans un espace de noms externe ;
• expliciter une correspondance ;
• soumettre cette correspondance à une autorité interne ;
• compiler un contrôle sans élargir les permissions ;
• mesurer un résultat sans confondre observation et attestation ;
• retirer ou remplacer la correspondance sans déstabiliser le Core.

La valeur du référentiel externe est donc préservée, mais sa juridiction est bornée.

Règle finale

Le canon déclare ce que l’organisation est autorisée à affirmer et sous quelles contraintes. Le référentiel externe explique pourquoi certaines défaillances comptent ou quelles familles de contrôles existent. La matrice relie les deux. Le runtime exécute la décision compilée. L’audit mesure la restitution. Le ledger conserve une preuve bornée.

Aucun de ces plans ne doit absorber les autres.