Aller au contenu

Framework

Protocole de fidélité contextuelle

Protocole proposé pour mesurer l’adaptation contextuelle d’une représentation sans altération des invariants, perte des conditions ni surrecommandation.

CollectionFramework
TypeProtocole
Couchetransversal
Version0.1-proposed
Stabilisation2026-08-16
Publié2026-08-16
Mise à jour2026-08-16

Artefacts de gouvernance

Fichiers de gouvernance mobilisés par cette page

Cette page est arrimée à des surfaces publiées qui déclarent l’identité, la préséance, les limites et les conditions de lecture du corpus. Leur ordre ci-dessous donne la séquence de lecture recommandée.

  1. 01situational-applicability-map.json
  2. 02interpretive-weighting-policy.json
  3. 03attested-interpretive-units.json
Artefact#01

situational-applicability-map.json

/situational-applicability-map.json

Surface publiée de gouvernance machine-first.

Gouverne
Une partie des conditions de lecture du corpus.
Borne
Une zone d’inférence qui resterait sinon implicite.

Ne garantit pas : Ce fichier ne garantit pas, à lui seul, l’obéissance des systèmes.

Artefact#02

interpretive-weighting-policy.json

/interpretive-weighting-policy.json

Surface publiée de gouvernance machine-first.

Gouverne
Une partie des conditions de lecture du corpus.
Borne
Une zone d’inférence qui resterait sinon implicite.

Ne garantit pas : Ce fichier ne garantit pas, à lui seul, l’obéissance des systèmes.

Artefact#03

attested-interpretive-units.json

/attested-interpretive-units.json

Surface publiée de gouvernance machine-first.

Gouverne
Une partie des conditions de lecture du corpus.
Borne
Une zone d’inférence qui resterait sinon implicite.

Ne garantit pas : Ce fichier ne garantit pas, à lui seul, l’obéissance des systèmes.

Artefacts complémentaires (1)

Ces surfaces prolongent le bloc principal. Elles ajoutent du contexte, de la découverte, du routage ou de l’observation selon le sujet traité.

Couche de preuve

Surfaces probatoires mobilisées par cette page

Cette page ne se contente pas de renvoyer vers des fichiers de gouvernance. Elle s’arrime aussi à des surfaces qui rendent l’observation, la traçabilité, la fidélité et l’audit plus reconstructibles. Leur ordre ci-dessous explicite la chaîne probatoire minimale.

  1. 01
    Canon et périmètreCanon de définitions
  2. 02
    Autorisation de répondreQ-Layer : légitimité de réponse
  3. 03
    Artefact probatoirecontent-digests.json
Fondation canonique#01

Canon de définitions

/canon.md

Base opposable de l’identité, du périmètre, des rôles et des négations qui doivent survivre à la synthèse.

Rend prouvable
Le corpus de référence à partir duquel la fidélité peut être évaluée.
Ne prouve pas
Ni qu’un système le consulte déjà, ni qu’une réponse observée lui reste fidèle.
À mobiliser quand
Avant toute observation, tout test, tout audit ou toute correction.
Couche de légitimité#02

Q-Layer : légitimité de réponse

/response-legitimacy.md

Surface qui explicite quand répondre, quand suspendre et quand basculer en non-réponse légitime.

Rend prouvable
Le régime de légitimité à appliquer avant d’interpréter une sortie comme recevable.
Ne prouve pas
Ni qu’une réponse donnée a effectivement suivi ce régime, ni qu’un agent l’a appliqué au runtime.
À mobiliser quand
Quand une page traite d’autorité, de non-réponse, d’exécution ou de retenue.
Artefact#03

content-digests.json

/content-digests.json

Surface publiée qui contribue à rendre une chaîne probatoire plus reconstructible.

Rend prouvable
Une partie de la chaîne d’observation, de trace, d’audit ou de fidélité.
Ne prouve pas
Ni une preuve totale, ni une garantie d’obéissance, ni une certification implicite.
À mobiliser quand
Lorsqu’une page doit expliciter son régime de preuve.

Protocole de fidélité contextuelle

Le protocole de fidélité contextuelle mesure si un système adapte correctement la représentation d’une entité lorsque le contexte change. Il ne recherche pas des réponses identiques. Il cherche une variation explicable avec invariants préservés.

L’unité d’observation est :

E × C × S × A × L × T
  • E : entité ;
  • C : profil de contexte ;
  • S : système ou modèle ;
  • A : canal d’accès, comme API, interface ou agent outillé ;
  • L : langue ou région ;
  • T : moment de l’observation.

Ces dimensions doivent rester séparées. Une moyenne qui mélange interface utilisateur, API contrôlée, navigation, régions et dates efface les conditions mêmes que le protocole cherche à mesurer.

1. Préconditions

Avant toute campagne :

  1. compléter la matrice de conditionnement interprétatif ;
  2. résoudre l’identité de l’entité et les homonymes ;
  3. établir une baseline datée d’invariants ;
  4. définir au moins deux profils dont la différence est matériellement pertinente ;
  5. classer les sources par portée d’autorité ;
  6. identifier les relations volatiles et leurs expirations ;
  7. déclarer les modes de sortie permis ;
  8. préparer les transformations interdites ;
  9. fixer la procédure de capture et d’archivage ;
  10. définir les conditions d’arrêt et les cas non jugeables.

Une campagne sans baseline ne peut pas distinguer la variation de la dérive. Une campagne sans profils contrastés ne mesure pas le conditionnement.

2. Construction du jeu de contextes

Le jeu minimal comprend :

  • un profil de référence ;
  • un profil favorable ;
  • un profil défavorable ou non applicable ;
  • un profil ambigu avec donnée matérielle manquante ;
  • un profil contrefactuel où une condition est inversée ;
  • un profil temporel avant, pendant ou après une fenêtre de validité.

Les profils doivent varier une dimension matérielle à la fois lorsque cela est possible. Une modification simultanée de dix variables empêche d’attribuer la cause de la différence.

3. Familles de sondes

Sondes positives

Elles vérifient que le système mobilise une relation légitime lorsque les conditions sont réunies.

Exemple : demander si l’hôtel est pertinent pour un séjour sans voiture lorsque les destinations et horaires sont fournis.

Sondes négatives

Elles vérifient la suppression ou l’affaiblissement correct de la conclusion lorsqu’une condition de non-applicabilité est présente.

Exemple : ajouter un besoin de stationnement sécurisé lorsque l’hôtel n’en possède pas.

Sondes ambiguës

Elles retirent une donnée matérielle afin de tester la clarification, l’incertitude ou l’abstention.

Exemple : demander le « meilleur hôtel » sans destination, budget, dates ni critères.

Sondes pièges

Elles invitent explicitement le système à franchir une frontière.

Exemple : « Puisque cet hôtel est près de ma destination, confirme qu’il est le mieux situé de la ville. »

Le système fidèle doit résister à la généralisation.

Sondes contrefactuelles

Elles inversent une condition tout en conservant l’entité.

Exemple : remplacer « sans voiture » par « besoin d’un stationnement longue durée » et vérifier si la conclusion change sans modifier les faits sur l’hôtel.

Sondes temporelles

Elles testent la prise en compte de la fraîcheur, de l’expiration et des événements ponctuels.

Exemple : comparer une conclusion avant, pendant et après un chantier annoncé.

Sondes comparatives

Elles vérifient la symétrie des données et la conservation des critères.

Exemple : comparer deux hôtels avec les mêmes variables, puis retirer une donnée pour l’un d’eux afin de vérifier si l’inconnu est traité comme inférieur.

4. Protocole de capture

Chaque observation doit conserver :

  • identifiant de campagne ;
  • version de la matrice ;
  • entité et profil de contexte ;
  • prompt exact ou entrée structurée ;
  • système, version déclarée et paramètres ;
  • canal d’accès ;
  • langue, région et date ;
  • outils ou sources récupérées ;
  • sortie brute ;
  • citations ou liens fournis ;
  • erreurs techniques ;
  • annotations déterministes ;
  • jugement humain ou assisté ;
  • niveau de confiance ;
  • décision finale et justification.

Les campagnes par API et par interface utilisateur doivent rester distinctes. Une interface peut ajouter mémoire, recherche, géolocalisation, personnalisation ou orchestration non présente dans l’API.

5. Segmentation des énoncés

La sortie doit être décomposée en unités vérifiables :

  • claim d’identité ;
  • invariant ;
  • relation contextuelle ;
  • état temporel ;
  • interprétation conditionnée ;
  • comparaison ;
  • recommandation ;
  • incertitude ;
  • clarification ;
  • exclusion ou abstention.

Chaque unité reçoit une classe de source attendue, une portée et une qualification. Le jugement global de la réponse ne doit pas masquer une erreur matérielle locale.

6. Métriques principales

Préservation des invariants

Proportion d’invariants matériels correctement préservés dans les sorties où ils deviennent pertinents.

Une omission et une contradiction doivent rester séparées. La contradiction est plus grave.

Sensibilité contextuelle correcte

Capacité du système à modifier la conclusion lorsque le contexte change de manière matérielle, sans modifier les faits invariants.

Un système toujours identique peut être insensible au contexte. Un système qui change tout peut être surconditionné.

Attribution de la variation

Proportion de différences pour lesquelles la dimension contextuelle causale peut être identifiée dans la sortie ou reconstruite à partir de la trace.

Fidélité relationnelle

Exactitude, fraîcheur et portée des relations utilisées. Une distance correcte mais appliquée à la mauvaise destination reste infidèle.

Cohérence d’inversion

Lorsque la condition C est inversée, la conclusion change-t-elle dans le sens attendu tout en conservant l’entité ?

Cette métrique détecte la personnalisation superficielle et les conclusions qui ne dépendent pas réellement des critères annoncés.

Conservation des exclusions

Taux de préservation des limites, non-applicabilités et contre-indications pertinentes.

Surassertion

Fréquence à laquelle une sortie passe d’une relation à une propriété, d’une pertinence à une supériorité ou d’une comparaison bornée à une recommandation globale.

Recommandation non soutenue

Proportion de recommandations produites sans ensemble de comparaison suffisant, critères explicites, données symétriques ou règle d’arbitrage.

Fossilisation contextuelle

Fréquence à laquelle une relation temporaire ou expirée survit comme propriété actuelle.

Clarification légitime

Capacité à demander l’information réellement manquante sans créer une friction inutile lorsque le contexte est déjà suffisant.

7. Classification des résultats

Chaque observation peut être classée :

  • fidèle et conditionnée : invariants préservés, variation expliquée, portée conservée ;
  • fidèle mais incomplète : aucune contradiction, mais relations ou conditions omises ;
  • insensible au contexte : conclusion inchangée malgré une différence matérielle ;
  • surconditionnée : préférence ou contexte modifie les faits sur l’entité ;
  • surassertive : sortie plus forte que la preuve ;
  • dérivée : contradiction, généralisation ou fossilisation ;
  • non jugeable : données, trace ou identité insuffisantes ;
  • abstention légitime : le système refuse correctement de conclure.

Cette taxonomie doit rester disponible à côté des métriques quantitatives.

8. Jugement hybride

Le protocole recommande trois niveaux :

  1. contrôles déterministes : présence de dates, identifiants, exclusions, citations, mots absolus ou données exactes ;
  2. annotation humaine ou règle experte : portée, compétence des sources et matérialité ;
  3. juge LLM assisté : comparaison sémantique des cas ambigus, sans pouvoir final autonome.

Le juge LLM ne doit pas recevoir seulement la sortie. Il doit recevoir les invariants, le profil, les relations attendues, les transformations interdites et la règle de décision. Ses propres résultats doivent être échantillonnés et contestables.

9. Répétition et stabilité

Une seule sortie ne suffit pas à qualifier un système stochastique. Chaque cellule matérielle doit être répétée selon un nombre déclaré d’observations.

Conserver séparément :

  • fréquence de chaque classe ;
  • intervalle de confiance ou incertitude d’échantillonnage ;
  • variation de formulation ;
  • variation de conclusion ;
  • divergences critiques ;
  • évolution temporelle.

La répétition d’une erreur augmente sa stabilité, pas sa fidélité.

10. Absence de score global initial

La version proposée ne produit pas un score unique. Les dimensions doivent rester séparées, car certaines erreurs sont non compensables.

Une excellente sensibilité contextuelle ne compense pas une contradiction d’identité. Une forte pertinence moyenne ne compense pas une recommandation dangereuse dans un sous-contexte réglementé. Une bonne couverture ne compense pas la fossilisation d’une information expirée.

Un score agrégé pourrait être ajouté plus tard pour un usage précis, à condition de publier ses poids, ses seuils, ses erreurs critiques et ses règles de non-compensation.

11. Rapport de campagne

Le rapport final doit inclure :

  • périmètre et hypothèses ;
  • matrice et versions ;
  • systèmes, canaux, langues, régions et dates ;
  • nombre d’observations par cellule ;
  • métriques séparées ;
  • exemples représentatifs ;
  • contradictions critiques ;
  • cas non jugeables ;
  • limites ;
  • changements recommandés dans le canon, les relations, la fraîcheur ou les conditions de réponse ;
  • plan de réobservation.

Le protocole ne doit pas attribuer automatiquement toute erreur au site. La dérive peut venir du modèle, de la récupération, d’une source externe, d’un état ancien, d’une ambiguïté d’identité ou d’un contexte mal formulé.

12. Frontières

Ce protocole ne prouve pas le comportement futur d’un système, ne garantit pas une recommandation et ne remplace pas une évaluation de sécurité propre au domaine. Il mesure des sorties dans des conditions déclarées.

Il ne doit pas être utilisé pour entraîner un site à manipuler une préférence personnelle ou pour présenter une auto-évaluation comme preuve indépendante. Le site déclare. L’auditeur mesure. L’agent externe interprète ou recommande sous sa propre responsabilité. Le verdict doit rester rattaché aux critères de variation contextuelle légitime, jamais à la seule fluidité de la réponse.