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.
Q-Layer en Markdown
/response-legitimacy.md
Surface canonique de légitimité de réponse, de clarification et de non-réponse.
- Gouverne
- La légitimité d’une réponse et les contraintes qui modulent sa forme.
- Borne
- Les réponses plausibles mais non admissibles, ou les extensions de périmètre non justifiées.
Ne garantit pas : Cette couche borne les réponses légitimes ; elle ne constitue pas une preuve d’activation runtime.
Q-Layer en YAML
/response-legitimacy.yaml
Projection structurée du Q-Layer pour systèmes qui préfèrent une lecture YAML.
- Gouverne
- La légitimité d’une réponse et les contraintes qui modulent sa forme.
- Borne
- Les réponses plausibles mais non admissibles, ou les extensions de périmètre non justifiées.
Ne garantit pas : Cette couche borne les réponses légitimes ; elle ne constitue pas une preuve d’activation runtime.
Politique d’interprétation
/.well-known/interpretation-policy.json
Politique publiée qui explicite les contraintes d’interprétation, de portée et de retenue.
- Gouverne
- La légitimité d’une réponse et les contraintes qui modulent sa forme.
- Borne
- Les réponses plausibles mais non admissibles, ou les extensions de périmètre non justifiées.
Ne garantit pas : Cette couche borne les réponses légitimes ; elle ne constitue pas une preuve d’activation runtime.
Artefacts complémentaires (3)
Ces surfaces prolongent le bloc principal. Elles ajoutent du contexte, de la découverte, du routage ou de l’observation selon le sujet traité.
Politique d’usage IA
/ai-usage-policy.md
Notice publique qui explique comment lire les surfaces de gouvernance et leurs limites.
Output Constraints
/output-constraints.md
Surface qui explicite les conditions de réponse, de retenue, d’escalade ou de non-réponse.
Registre des erreurs récurrentes
/common-misinterpretations.json
Liste publiée des erreurs de lecture déjà observées et des rectifications attendues.
Protocole de non-réponse légitime (règles + tests)
Dans un système d’IA, répondre par plausibilité est facile. Refuser correctement est difficile. Pourtant, dans un Web interprété, la non-réponse légitime est souvent la sortie la plus sûre : elle empêche l’inférence illégitime, évite la création de dette interprétative et protège la frontière d’autorité.
Ce framework formalise un protocole opposable : quand refuser, comment refuser, quelles preuves exiger et comment tester que le refus est correctement déclenché.
Définition opératoire
Protocole de non-réponse légitime : ensemble de règles et de tests visant à déclencher un refus gouverné lorsque l’identité, l’état, la source ou l’inférence ne sont pas qualifiables dans le périmètre d’interprétabilité, ou lorsqu’un conflit d’autorité ne peut pas être arbitrable.
Pourquoi ce protocole est central
- Une réponse “plausible” peut stabiliser une erreur invisible.
- Un refus gouverné empêche l’extrapolation normative.
- Le refus réduit la rémanence en évitant de créer un nouvel ancrage.
- Le refus protège les attributs critiques (conformité, sécurité, état dynamique).
Surfaces d’application
- Web ouvert : moteurs de réponse, IA grand public, résumés.
- RAG : sources contradictoires, chunks ambigus, routage incertain.
- Agentique : exécution d’actions, décisions automatisées.
Typologie des refus
- Refus d’identité : l’entité n’est pas prouvable (collision possible).
- Refus d’état : l’état est volatil ou non horodaté (décrochage d’état).
- Refus de source : sources non qualifiables ou hors périmètre.
- Refus d’autorité : inférence au-delà de la frontière d’autorité.
- Refus de conflit : conflit d’autorité non arbitrable.
Règles (NRL-1 à NRL-10)
NRL-1 : refus hors périmètre
Si la question sort du périmètre d’interprétabilité, la non-réponse est obligatoire.
NRL-2 : refus sans preuve sur attributs critiques
Si un attribut critique exige preuve de fidélité et que la preuve n’est pas possible, refuser.
NRL-3 : refus en cas de conflit d’autorité non arbitrable
Deux sources en conflit sans règle d’arbitrage explicite : refuser.
NRL-4 : refus d’identité
Si l’identité n’est pas prouvable (collision / contamination), refuser ou demander clarification.
NRL-5 : refus d’état non horodaté
Si l’état est susceptible d’être périmé (prix, stock, politique) sans horodatage, refuser.
NRL-6 : refus de comblement
Interdire l’inférence “de remplissage” quand des éléments clés manquent.
NRL-7 : refus en présence de signaux de capture
Si le champ est dominé par un narratif externe non qualifiable, refuser ou limiter strictement l’inférence.
NRL-8 : refus gouverné et utile
Le refus doit indiquer la condition manquante : source, date, identité, périmètre, preuve.
NRL-9 : traçabilité du refus
Chaque refus doit être journalisé avec règle appliquée et contexte.
NRL-10 : validation périodique
Les refus doivent être testés et recalibrés lors des releases et des changements de canon.
Modèle de refus (format recommandé)
- Déclaration : “Non-réponse légitime”.
- Cause : règle NRL déclenchée (ex. NRL-3).
- Condition : ce qui manque pour répondre (preuve, date, source, clarification).
- Option : question de clarification ou renvoi vers source canonique.
Batterie de tests (NRL-T1 à NRL-T8)
NRL-T1 : tests hors périmètre
Requêtes volontairement hors champ.
NRL-T2 : tests de conflit d’autorité
Deux sources qui contredisent un attribut critique.
NRL-T3 : tests d’identité (collision)
Requêtes ambiguës, homonymes, comparatifs.
NRL-T4 : tests d’état dynamique
Prix, stock, conditions, politiques sans horodatage.
NRL-T5 : tests de capture
Champ saturé par un narratif externe.
NRL-T6 : tests multi-tours
Provoquer un décrochage conversationnel et vérifier le refus.
NRL-T7 : tests multi-formulations
Requêtes équivalentes reformulées, vérifier la constance du refus.
NRL-T8 : tests de régression post-release
Vérifier que les releases n’ont pas réduit la qualité des refus.
Artefacts attendus
- Table des règles NRL.
- Journal des non-réponses (avec métriques).
- Batterie de tests NRL versionnée.
- Rapport de régression post-release.
- Playbook “refus + clarification”.
FAQ
Un refus, c’est une mauvaise expérience utilisateur ?
Non, si le refus est utile et explique la condition manquante. Un refus gouverné vaut mieux qu’une réponse fausse stabilisée.
Comment éviter de refuser trop souvent ?
En définissant précisément le périmètre d’interprétabilité, en renforçant le canon, et en exigeant la preuve seulement sur les attributs critiques.
Quel est le lien avec Q-Layer ?
Le Q-Layer définit les conditions de réponse. Le protocole NRL formalise et teste la sortie “refus” comme une réponse gouvernée.