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.
- 01Artefact probatoiredoctrine-glossary.json
doctrine-glossary.json
/doctrine-glossary.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.
Runtime vs MCP
Le Runtime de contexte gouverné sert des packs précompilés pour une intention déclarée, une langue et une version. MCP est un protocole d’accès à des outils et à des ressources. Il peut transporter une lecture aussi bien qu’une action ; l’opposition « MCP pour agir, Runtime pour comprendre » serait trop absolue.
Un adaptateur MCP séparé expose déjà des outils de lecture pour l’instance de gautierdorval.com. Le guide de l’instance précise le profil servi et les observations datées. La proposition conceptuelle de juillet conserve son statut proposé ; la description de l’implémentation est actualisée au 26 octobre 2026.
Les limites de cet adaptateur Runtime sont locales au projet : pas d’écriture, de résolution libre d’intention, de composition de pack à la demande, de scoring de réponse ou de recommandation, ni de génération de réponse dans le noyau. Le Runtime ne devient pas une autorité interprétative autonome. Ce ne sont pas des interdictions générales imposées par MCP.
Publication, MCP Apps et WebMCP
Une publication canonique rend les sources consultables. MCP fournit une interface d’outils et de ressources. MCP Apps permet d’associer une interface interactive à ces outils dans un client compatible. WebMCP expose des outils depuis une page Web dans le navigateur. Runtime apporte un contexte identifié et des vérifications d’intégrité ; il ne remplace aucune de ces couches.
Une interface qui montre un pack ne prouve pas que le modèle l’a reçu ou utilisé. Une racine de corpus doit être admise séparément par le consommateur ; une empreinte conforme ne prouve ni vérité, ni autorité, ni permission d’usage, ni fidélité sémantique. La décision d’admission reste locale.
Le compagnon MCP Apps met ces rôles à l’épreuve
Le compagnon local utilise MCP pour présenter un sélecteur dans un hôte compatible, puis réutilise le vérificateur du Runtime pour inspecter un pack fictif entier, sa langue, sa version, ses conditions et ses sources archivées. Le choix ne compose aucun nouveau pack et la vérification ne transforme pas le contenu en permission d’action.
Le bouton « Faire lire ce pack à l’assistant » prépare un message avec la sélection inspectée. Après son envoi par la personne, l’assistant appelle read_gcr_pack. MCP transporte le texte complet renvoyé par l’outil. Ce parcours utilise message.text sans dépendre de updateModelContext.text.
Le 27 octobre 2026, T3 a réussi le parcours du bouton jusqu’à la réponse dans Claude Desktop Windows 3.6556.2.0, modèle affiché Opus 5.5 Max, pour le pack fictif français. La lecture a renvoyé 57 236 octets UTF-8 conformes à la référence ; la réponse finale, examinée séparément de l’aperçu, restitue les cinq listes et leurs 11 éléments sans ajout ni omission. Elle conserve l’identité du pack, les limites liées aux preuves manquantes ou contradictoires et l’absence de permission d’action.
T3 a repris la même conversation privée après l’annulation T2, dont la cause reste inconnue. T2 n’avait déclenché aucun appel texte effectif. Une nouvelle inspection, un clic et un envoi ont produit l’unique lecture observée sur la séance T2/T3. La lecture directe T1 avait réussi séparément. Ces essais ne donnent pas un taux de fiabilité ni une garantie de réussite dès la première tentative.
L’interface et le pack existent en français et en anglais ; cette qualification réelle porte uniquement sur le français. Le compagnon reste un prototype local, distinct du service hébergé et sans service MCP Apps public déployé. L’observation ne démontre ni fidélité générale, ni validation métier, ni effet sur la visibilité. Le pilote comparatif demeure NOT_RUN.
Le canal natif updateModelContext reste expérimental et non qualifié. Le 26 octobre 2026, deux parcours dans l’ancien client ont reçu un accusé après soumission, mais le modèle a déclaré ne disposer que du catalogue et n’a pas restitué les conditions du pack. Ces observations ne permettent ni de localiser l’échec ni d’en établir la cause. Les diagnostics A/B du 26 octobre dans le client plus récent sont distincts : bloqués avant soumission, ils restent NOT_RUN, sans jeton soumis.
Le 27 octobre, A/B ont répondu NON_DISPONIBLE sous une consigne interdisant les outils, facteur de confusion possible si l’hôte utilise un lecteur interne. H1 autorisait ce lecteur et a reçu la même réponse, sans invocation effective observée. Un jeton imprévisible retrouvé par un canal isolé peut établir sa disponibilité ; une réponse négative ne prouve pas symétriquement une non-remise interne. Aucune cause n’est attribuée à Claude, au SDK ou à l’adaptateur. T3 n’a pas relancé ce canal. Le composant ne lit pas lui-même la conversation.
La réponse conservée et sa comparaison hors ligne sont consultables : cinq listes de 2, 2, 2, 3 et 2 éléments, comparées exactement au pack fictif épinglé, sans ajout, omission ni duplication dans ces listes. Les limites liées aux preuves, aux sources et aux permissions font l’objet d’une lecture éditoriale distincte. Les 57 236 octets désignent la projection de l’outil ; la réponse conservée en contient 6 029. Cette vérification de fichiers ne rejoue pas le client et n’authentifie pas indépendamment la séance. Le nom du modèle affiché ne certifie pas son identité interne.
Reproduire le parcours local et lire ses limites ; résultat T3 dans le relevé historique. La page du Runtime détaille la vérification et ses limites.
Comparer deux états avant de choisir le contexte
Une condition retirée, une preuve ajoutée ou une source modifiée mérite une revue avant la réutilisation du contexte. Le comparateur montre les différences de B par rapport à A, deux états choisis explicitement pour la même intention et la même langue.
Chaque entrée est vérifiée avec son instantané complet et ses archives sous une racine admise séparément, puis validée contre les schémas du pack et du manifeste. Ajouts, retraits, valeurs modifiées et changements d’ordre restent consultables avec les originaux et un rapport exportable. Une phrase réécrite dans une liste produit un retrait et un ajout ; aucune continuité de règle ni équivalence de sens n’est supposée.
Une démonstration Web FR/EN permet de choisir les deux états fictifs, de consulter leurs différences et d’exporter le rapport complet. Les huit paires compatibles sont calculées avec l’admission complète lors de la construction, puis contrôlées au chargement. Le diagnostic des états réels conservés reste hors ligne. A et B n’établissent aucune succession de publications. Comparer ne transmet aucun pack au modèle. T3 reste une qualification distincte ; aucun bénéfice métier ni effet sur une réponse n’est établi par cette comparaison.
Examiner le parcours local et le rapport exportable · Lire la qualification datée et ses limites.
Sources de la distinction : MCP Apps, parcours local documenté par Claude et brouillon WebMCP. Leur documentation décrit les mécanismes ; elle ne certifie pas ce prototype.
MCP ne valide pas la réponse du modèle
Un appel MCP peut prouver qu’un outil a retourné un contexte précis. Il ne prouve pas que le modèle en a conservé les conditions ou évité les affirmations sans source. L’évaluation des réponses exige un protocole distinct, qui conserve le message envoyé, la réponse reçue, les erreurs et les critères appliqués.
Le moteur expérimental du Runtime prépare ce contrôle sur sept cas fictifs avec deux juges automatiques distincts. Leurs annotations restent séparées ; une panne technique n’est pas transformée en réponse sémantiquement incorrecte, et un accord entre juges ne certifie pas la vérité. Le transport HTTP ou MCP, la réponse du modèle et son évaluation conservent ainsi leurs preuves propres.
Examiner la frontière fournisseur et les règles de jugement · Lire le relevé d’implémentation daté. Les mentions NOT_RUN des qualifications MCP Apps ci-dessus décrivent ces essais historiques et restent distinctes de l’état d’une campagne fournisseur.
Le transport MCP n’établit pas qu’une réponse fournisseur a été acceptée. Réévaluer des octets archivés après la correction d’un adaptateur exige une preuve distincte épinglée, le maintien des réserves de dépense et l’identité de l’exécutable corrigé. Cette opération ne modifie pas la requête et ne transforme pas un contrôle préalable en résultat scientifique.
Ces analyses vous sont utiles ?
Ajouter à mes sources Google