Aller au contenu

Doctrine

Runtime de contexte gouverné

Spécification proposée pour servir des packs de contexte précompilés sans résolution libre d’intention, génération de réponse ou recommandation.

CollectionDoctrine
TypeSpécification
Version0.1-proposed
Niveauinformatif
Stabilisation2026-07-10
Publié2026-07-10
Mise à jour2026-11-07

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. 01governed-context-runtime.json
  2. 02governed-context-runtime.json
  3. 03intent-registry.json
Artefact#01

governed-context-runtime.json

/governed-context-runtime.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

governed-context-runtime.json

/.well-known/governed-context-runtime.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

intent-registry.json

/intent-registry.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é.

Artefact#04

intent-registry.json

/.well-known/intent-registry.json

Surface publiée de gouvernance machine-first.

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
  2. 02
    Artefact probatoirecontent-digests.json
  3. 03
    Artefact probatoiredoctrine-glossary.json
Artefact#01

attested-interpretive-units.json

/attested-interpretive-units.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.
Artefact#02

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.
Artefact#03

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 de contexte gouverné

Le runtime de contexte gouverné est une infrastructure dont les contrats demeurent proposés, pas une couche doctrinale. Il sert un artefact précompilé pour un token d’intention canonique déjà sélectionné par un agent externe.

Le runtime ne choisit pas l’intention à partir d’une requête libre. Il ne génère pas de réponse, ne recommande pas de service, ne mesure pas la fidélité d’une sortie et ne modifie pas la gouvernance publiée.

La séquence visée est fermée : le site déclare les intentions, la CI précompile les packs, CAI atteste les unités, puis un runtime isolé sert le pack exact demandé.

Frontière v0

La v0 ne compose rien à la requête. Les entrées admissibles sont des identifiants fermés comme intentToken, lang, version, packId, unitId et digest.

Les prompts, conversations, réponses, identités personnelles, IP brutes et cookies sont hors périmètre. Le ledger de l’instance est limité aux événements techniques de distribution.

Relation avec les couches doctrinales

CCL et SAL déclarent le contexte et l’applicabilité. CPI et CAI contrôlent la pondération et l’intégrité. Q-Layer arbitre la légitimité de réponse. Le runtime ne remplace aucune de ces couches : il distribue seulement une vue précompilée du corpus gouverné.

Voir aussi le registre d’intentions canoniques, les packs de contexte gouvernés et la clarification runtime vs agent génératif.

Projection de laboratoire

Cette page demeure la source doctrinale canonique. Le programme public sur le runtime de contexte gouverné borne séparément la question de recherche, le protocole et l’état des preuves. L’existence du programme ne constitue pas un résultat.

État de l’implémentation

La mise en production du 11 octobre 2026, clôturée le 12 octobre UTC, comprend un résolveur HTTP et un adaptateur MCP séparé. Le contrôle technique des points d’accès publics, effectué par le producteur le 12 octobre à 02:18 UTC, confirme leur accès et l’égalité des octets d’un pack français reçu par les deux transports. L’interface déclare la version 0.3.0-proposed ; les contrats restent proposés, sans changement du rang doctrinal de cette page.

Le service distribue des artefacts précompilés à partir d’identifiants fermés. Il ne génère pas de réponse. Le consommateur sélectionne le contexte, vérifie l’instantané et ses archives sous sa politique locale, puis décide de l’usage. Une lecture peut produire un événement technique de distribution ; cet événement ne prouve ni l’usage du contenu ni la fidélité d’une réponse.

Le parcours et l’observation datée sont présentés ci-dessous. Le pilote comparatif sur modèles à quatre conditions est préparé mais n’a pas été exécuté (NOT_RUN). Il demeure distinct des essais locaux MCP Apps, dont T3, documentés ci-dessous.

Critères du site agentique gouverné.

Choisir un contexte dans une conversation

Mise à jour du 27 octobre 2026. Le compagnon MCP Apps propose un parcours local pour choisir un pack Runtime entier, examiner ses déclarations, ses conditions et ses sources archivées, puis fournir explicitement ce contexte à un assistant. Le premier exemple, Atelier Boréal, est fictif et disponible en français et en anglais.

Runtime sert et vérifie un contexte précompilé. MCP expose des outils et des ressources. MCP Apps ajoute une interface dans un client compatible. WebMCP concerne les outils exposés par une page Web au navigateur. Ces mécanismes peuvent être complémentaires ; leur présence ne prouve pas la bonne interprétation du contexte.

Le compagnon réutilise le vérificateur public côté serveur avec une racine attendue fournie séparément pour l’exercice. Le pack sélectionné, ses conditions, ses exclusions et ses sources archivées sont conservés ensemble. Un lien déclaré dans une source n’est pas une preuve de consultation actuelle.

Après inspection, le bouton « Faire lire ce pack à l’assistant » prépare une demande avec les quatre champs exacts de la sélection. La personne envoie le message ; l’assistant appelle ensuite l’outil texte read_gcr_pack, qui renvoie la projection complète. Le contexte reste lié à une sélection identifiable, sans ajout de permission métier.

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.

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.

Essayer le comparateur sur des exemples fictifs

Découvrir les contrats et lire les versions

La déclaration du Runtime est le point d’entrée vers les contrats et le service. Son chemin historique de spécification désigne une organisation des sources ; il ne doit pas être concaténé à l’adresse du dépôt public. Le contrat de déclaration 0.4.0 préparé ajoute des liens épinglés vers les schémas bruts, leur correspondance et les guides FR/EN. Vérifier la version effectivement reçue : cette préparation ne prouve pas une publication, et un consommateur strict limité à 0.3.0 refuse la nouvelle forme.

La référence publique, le logiciel hébergé, le format de chaque document et les packs suivent des versions distinctes. corpusVersion désigne une famille ; corpusRootDigest identifie un instantané exact. Le commit déclaré par le service appartient à son implémentation, pas au dépôt public. La date de création d’une version du Worker ne prouve ni son premier trafic ni un retard documentaire. Une empreinte conforme ne prouve ni vérité, ni permission, ni fidélité d’une réponse.

Lire les contrats, versions et limites de provenance · Consulter l’état déclaré du service · Consulter l’instantané courant.

Examiner la référence publique 0.2.1

La préversion de référence 0.2.1-proposed fournit les contrats proposés, les vérificateurs et un parcours consommateur exécutable hors ligne. Le kit fictif permet d’inspecter un pack complet avec ses sources et ses limites. Sa racine et sa politique de confiance sont fournies pour l’exercice, sans établir une confiance de production.

Essayer le kit consommateur hors ligne · Comprendre la portée sémantique du pack · Examiner la qualification locale du producteur

La qualification locale documente les contrôles du producteur sur ses actifs conservés, sans rendre son corpus privé reproductible publiquement. La version 0.2.1 désigne la référence hors ligne, distincte de la version conceptuelle et de celle du service hébergé.

L’intégrité des octets, la permission d’utiliser le contexte et la fidélité d’une réponse restent distinctes. Le pilote comparatif sur modèles est préparé mais non exécuté (NOT_RUN). Cette publication ne constitue ni une nouvelle observation du service hébergé, ni un déploiement clé en main pour d’autres domaines. Le contrôle du 12 octobre 2026 présenté ci-dessous conserve sa portée historique.

Distinguer la distribution du contexte et l’évaluation des réponses

Un moteur d’expérimentation distinct du Runtime permet d’exécuter le protocole à quatre conditions sur sept cas fictifs, en français et en anglais. Il conserve les messages exacts, les réponses terminées, les erreurs techniques et les reprises admissibles sous un budget commun. Deux juges automatiques distincts appliquent la même grille et conservent leurs annotations séparées. Une réponse vide, refusée ou tronquée n’est pas remplacée par une nouvelle tentative destinée à l’améliorer.

Le transport du pack, l’exécution d’un appel et l’admission d’un jugement restent trois faits différents. Les comptes descriptifs et l’accord entre juges conservent leurs dénominateurs, les jugements manquants et les cas non applicables. Le statut privé relie la campagne à son manifeste et à la version du moteur, sans exposer les réponses. Cette instrumentation ne prouve ni fidélité générale, ni effet causal du vérificateur, ni supériorité d’architecture.

Examiner le protocole d’exécution et ses contrôles et le relevé d’implémentation du 7 novembre 2026. Une qualification synthétique, un appel fournisseur et une campagne terminée exigent des preuves distinctes. Les mentions NOT_RUN des observations et éditions précédentes décrivent leur état historique.

Une reprise qualifiée conserve les entrées, les échéances et le plafond de dépense initiaux. Une réponse fournisseur archivée peut être réévaluée sans nouvel appel ; sa réserve de coût incertain reste comptabilisée. Un amendement épinglé relie l’exécutable corrigé aux preuves originales.

Un contexte prêt à examiner avant de répondre

Un assistant qui explique une doctrine doit pouvoir retrouver ses sources et ses limites. L’instance de gautierdorval.com distribue des packs précompilés pour une intention déclarée et une langue choisie. L’intégrateur peut examiner la version reçue avant de la fournir à l’assistant.

Le contrôle technique effectué par le producteur le 12 octobre 2026 à 02:18 UTC a confirmé l’accès HTTP, huit outils MCP et un pack français reçu à l’identique par les deux transports. Le registre observé contient six intentions et douze packs FR/EN.

Explorer les intentions disponibles · Suivre le guide d’intégration REST/MCP · Consulter le dépôt public de référence

  1. Choisir une intention exacte dans le registre, puis la langue et la version du pack. Le choix appartient au consommateur.
  2. Récupérer le pack et son manifeste par HTTP ou MCP. L’interface sert les artefacts précompilés correspondant aux identifiants demandés.
  3. Vérifier l’instantané complet et ses archives sous une racine de corpus épinglée séparément, puis décider localement de l’utilisation du contexte.

L’accès HTTP commence à https://context.gautierdorval.com/. L’adaptateur séparé reçoit les requêtes POST à https://context.gautierdorval.com/mcp. Son profil MCP 2026-07-28 utilise server/discover et des métadonnées par requête. Le guide fournit les commandes PowerShell et précise les limites de compatibilité des clients.

Consulter l’état technique · Examiner l’instantané du corpus · Lire l’observation datée

Ces contrôles établissent un fonctionnement technique observé, sans garantir la disponibilité future. Ils ne mesurent ni adoption spontanée ni effet sur une réponse de modèle. L’intégrité du contexte, la permission de l’utiliser et la fidélité de la réponse demeurent trois questions distinctes. Une unité v0 isolée exige la vérification de son enregistrement complet dans l’instantané : son empreinte historique ne couvre pas tous ses champs. Le guide fournit un exemple consommateur qui conserve cette portée au point d’usage. Les clés restent réservées aux essais et les racines archivées ne constituent pas un historique des déploiements.

Apprendre la vérification avec un exemple fictif

La démonstration locale rassemble un reçu, un instantané et ses archives pour suivre le parcours de vérification sans compte ni appel réseau. Ses données et clés de test restent distinctes de l’observation du service hébergé. Examiner la démonstration exécutable.

Ces analyses vous sont utiles ?

Ajouter à mes sources Google