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.
Carte de contexte causal
/causal-context-map.json
Projection machine-readable de la couche CCL reliant déclencheurs, besoins latents, surfaces canoniques et conséquences visées.
- Gouverne
- La lecture causale des contenus et les ponts légitimes entre problème, besoin, surface et conséquence.
- Borne
- Les reconstructions par plausibilité qui confondent sujet apparent, besoin latent, service et promesse.
Ne garantit pas : Cette carte ne garantit ni conversion, ni classement, ni citation, ni adoption par un modèle tiers.
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.
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.
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é.
authority-scope-matrix.json
/authority-scope-matrix.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.
- 01Canon et périmètreCanon de définitions
- 02Autorisation de répondreQ-Layer : légitimité de réponse
- 03Artefact probatoireclaims.json
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.
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.
claims.json
/claims.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.
Matrice de conditionnement interprétatif
La matrice de conditionnement interprétatif prépare une entité avant toute campagne de recommandation, de comparaison ou d’audit contextuel. Elle ne génère pas la conclusion. Elle rend explicites les éléments qui permettent ensuite de qualifier une sortie comme factuelle, conditionnelle, comparative, insuffisante ou dérivée.
Son unité de travail est :
entité × profil de contexte × relation × source × mode de sortieObjectifs
La matrice sert à :
- établir une baseline datée de l’entité ;
- séparer invariants et variables contextualisables ;
- définir des profils de contexte reproductibles ;
- attribuer chaque relation à une source compétente ;
- conserver la temporalité et les conditions inversantes ;
- déclarer les transformations interdites ;
- limiter la force des sorties autorisées ;
- préparer les sondes du protocole de fidélité contextuelle.
Elle doit être remplie avant d’observer un système. Sinon, l’auditeur risque de juger les réponses après coup selon une intuition mouvante.
Étape 1 : fiche de l’entité
| Champ | Question | Exigence |
|---|---|---|
| Identité | Quelle entité est visée ? | Identifiants, homonymes et périmètre résolus |
| Catégorie | Quel rôle matériel remplit-elle ? | Catégorie assez précise pour éviter la fusion |
| Capacités | Que peut-elle réellement faire ? | Claims documentés et versionnés |
| Exclusions | Que ne fait-elle pas ? | Limites explicites, non déduites par silence |
| Autorité | Sur quels claims peut-elle parler ? | Portée par classe de claim |
| Temporalité | Quel état est actuel ? | Date d’observation et historique pertinent |
La fiche ne doit pas contenir seulement des attributs favorables. Les exclusions, incompatibilités et conditions de non-applicabilité sont nécessaires pour empêcher la recommandation automatique.
Étape 2 : registre des invariants
Pour chaque invariant d’entité, consigner :
| Champ | Contenu attendu |
|---|---|
invariantId |
Identifiant stable |
| Claim canonique | Formulation bornée |
| Classe de claim | Identité, capacité, politique, limite, relation constitutive |
| Source compétente | Source ou combinaison de sources |
| Version | Version ou date de l’état |
| Tolérance de formulation | Variantes linguistiques acceptables |
| Contradictions critiques | Formulations incompatibles |
| Expiration | Date ou événement qui impose une révision |
Un invariant n’est pas une phrase à répéter. Il est une contrainte matérielle à préserver.
Étape 3 : profils de contexte
Un profil de contexte doit être fermé, nommé et reproductible. Il peut rester impersonnel.
| Dimension | Exemples | Règle |
|---|---|---|
| Intention | choisir, vérifier, comparer, planifier | Une intention par profil principal |
| Public | famille, équipe technique, acheteur réglementé | Ne pas généraliser à tous les publics |
| Lieu | zone, juridiction, destination | Déclarer le périmètre exact |
| Temps | date, heure, saison, durée | Déclarer la fenêtre de validité |
| Usage | séjour sans voiture, intégration locale | Déclarer le scénario concret |
| Contraintes | budget, accessibilité, conformité | Séparer contraintes et préférences |
| Préférences | calme, animation, contrôle | Les attribuer à l’utilisateur |
| Dépendances | transport, événement, fournisseur tiers | Identifier les sources externes |
| Données absentes | inconnues matérielles | Ne pas les convertir en valeurs par défaut |
Chaque profil doit préciser ce qui le distingue des autres profils. Deux profils presque identiques ne doivent pas être utilisés pour fabriquer artificiellement de la variation.
Étape 4 : registre des relations contextuelles
Pour chaque relation contextuelle, consigner :
| Champ | Fonction |
|---|---|
relationId |
Identifiant de la relation |
| Sujet | Entité concernée |
| Relation | Distance, compatibilité, disponibilité, dépendance ou autre |
| Objet | Destination, événement, règle, public ou contrainte |
| Source | Autorité compétente |
| Observé le | Date de collecte |
| Valide jusqu’au | Expiration ou prochaine vérification |
| Portée | Temps, lieu, public et usage |
| Incertitude | Faible, moyenne, élevée ou non qualifiable |
| Condition inversante | Changement qui peut modifier la conclusion |
| Inférence permise | Usage interprétatif autorisé |
| Inférence interdite | Généralisation ou classement prohibé |
La matrice doit distinguer absence de relation, absence de preuve et absence d’observation. Ces états ne sont pas équivalents.
Étape 5 : modes de sortie
| Mode | Autorisé lorsque | Formulation type | Interdit lorsque |
|---|---|---|---|
| Description factuelle | Claim direct et source compétente | « L’entité possède X. » | Source ou état incertain |
| Relation bornée | Relation vérifiée et portée conservée | « À la date T, X est relié à Y sous C. » | Date ou objet absent |
| Pertinence conditionnelle | Plusieurs relations soutiennent une adéquation locale | « Semble pertinent pour C, sous réserve de Z. » | Condition inversante inconnue |
| Comparaison bornée | Critères explicites et données symétriques | « Selon X, A est plus proche que B. » | Ensemble incomplet ou métriques incompatibles |
| Recommandation qualifiée | Comparaison suffisante, arbitrage et incertitude | « A est préféré sous C pour X et Y. » | Critères ou alternatives insuffisants |
| Clarification | Donnée matérielle manquante | « Préciser X avant de conclure. » | Question déjà résolue |
| Abstention | Preuve insuffisante ou conflit critique | « Les données ne permettent pas de conclure. » | Une réponse bornée reste possible |
La fluidité du texte ne permet pas de passer à un mode plus fort. Chaque transition doit être soutenue par davantage de contexte et de preuve.
Étape 6 : transformations interdites
La matrice doit déclarer explicitement les dérivations interdites. Le noyau minimal comprend :
| Transformation | Entrée légitime | Sortie interdite |
|---|---|---|
| Condition → propriété | Compatible sous C | Intrinsèquement adapté |
| Relation locale → supériorité globale | Plus proche de X | Mieux situé en général |
| Préférence → vérité | Préféré par cet utilisateur | Objectivement meilleur |
| État temporaire → propriété permanente | Fermé jusqu’à T | Toujours indisponible |
| Donnée absente → valeur implicite | Information inconnue | Capacité supposée |
| Applicabilité → recommandation | Peut convenir sous C | Doit être choisi |
| Documentation → supériorité | Mieux documenté | Meilleur produit |
| Répétition → preuve | Souvent affirmé par les modèles | Fait établi |
Ces transformations servent de tests négatifs dans le protocole.
Étape 7 : conditions inversantes
Une condition inversante est une donnée dont la modification peut changer la conclusion sans modifier l’entité. Exemples :
- changement d’horaire ;
- indisponibilité d’une option ;
- nouvelle contrainte d’accessibilité ;
- juridiction différente ;
- budget révisé ;
- interruption d’une dépendance externe ;
- modification de la composition du groupe ;
- expiration d’une politique ou d’un événement.
Pour chaque conclusion candidate, la matrice doit demander :
Quelle modification minimale du contexte rendrait cette conclusion fausse, insuffisante ou moins forte ?
Une conclusion sans condition inversante identifiable peut être un invariant, une tautologie, une généralisation excessive ou une affirmation mal spécifiée.
Exemple condensé : hôtel et séjour sans voiture
| Élément | Déclaration |
|---|---|
| Entité | Hôtel H, identité résolue |
| Invariants | Adresse, absence de stationnement, catégories de chambres, politiques |
| Profil | Deux adultes, séjour du 14 au 17 octobre, sans voiture, événement à 20 h |
| Relations | Distance à la station, horaire du service, trajet vers l’événement |
| Sources | Site de l’hôtel pour ses politiques, opérateur de transport pour les horaires |
| Condition inversante | Interruption du service après 22 h |
| Sortie admise | Pertinence conditionnelle |
| Sortie interdite | « Meilleur hôtel de la ville » |
Cette fiche ne recommande pas l’hôtel. Elle déclare la matière nécessaire pour produire et évaluer une conclusion située.
Gouvernance de la matrice
Chaque version doit conserver :
- auteur ou système préparateur ;
- date ;
- sources ;
- changements depuis la version précédente ;
- invariants ajoutés, retirés ou révisés ;
- profils actifs et expirés ;
- relations périmées ;
- décisions de frontière ;
- cas non résolus.
Une matrice préparée par l’entité peut documenter son canon et ses politiques. Elle ne doit pas auto-évaluer sa réputation externe ni décider seule de sa supériorité comparative.
Sortie vers le protocole
La matrice produit un paquet d’essai, non un score. Ce paquet contient :
- les invariants à préserver ;
- les profils à comparer ;
- les relations attendues ;
- les pièges et transformations interdites ;
- les inversions à tester ;
- les modes de sortie permis ;
- les critères de clarification et d’abstention.
Le protocole de fidélité contextuelle utilise ce paquet pour construire une campagne reproductible.
Limites
La matrice ne prouve pas qu’un modèle utilisera le contexte correctement. Elle ne garantit pas une recommandation, ne mesure pas une performance commerciale et ne remplace pas l’audit des sources externes. Elle structure les conditions du test et rend les écarts classables.