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.
- 01Carte d’observationObservatory map
- 02Observation faibleQ-Ledger
- 03AttestationQ-Attest protocol
- 04Mémoire et versionChangelog IA
Observatory map
/observations/observatory-map.json
Index machine-first des ressources d’observation, des snapshots et des points de comparaison publiés.
- Rend prouvable
- Où se trouvent les objets d’observation mobilisables dans une chaîne probatoire.
- Ne prouve pas
- Ni la qualité d’un résultat, ni la fidélité d’une réponse particulière.
- À mobiliser quand
- Pour localiser les baselines, journaux, snapshots et artefacts dérivés.
Q-Ledger
/.well-known/q-ledger.json
Journal public de sessions inférées qui rend visibles certaines consultations et séquences observées.
- Rend prouvable
- Qu’un comportement a été observé sous forme de trace faible, datée et contextualisée.
- Ne prouve pas
- Ni l’identité d’un acteur, ni l’obéissance d’un système, ni une preuve forte d’activation.
- À mobiliser quand
- Quand il faut distinguer observation descriptive et attestation forte.
Q-Attest protocol
/.well-known/q-attest-protocol.md
Spécification facultative qui sépare clairement les sessions inférées des attestations validées.
- Rend prouvable
- Le cadre minimal requis pour élever une observation vers une attestation vérifiable.
- Ne prouve pas
- Ni qu’un endpoint d’attestation existe, ni qu’une attestation a déjà été reçue.
- À mobiliser quand
- Quand une page traite de preuve forte, de validation opérationnelle ou de séparation des niveaux de preuve.
Changelog IA
/changelog-ai.md
Journal public qui rend les évolutions des surfaces IA plus datables et plus auditables.
- Rend prouvable
- Qu’un état probatoire peut être replacé dans une trajectoire de version explicite.
- Ne prouve pas
- Ni la résorption effective d’une dérive, ni la consultation du changement par un tiers.
- À mobiliser quand
- Quand une page traite de snapshots, de rectification, de retrait ou de supersession.
Surfaces probatoires complémentaires (2)
Ces artefacts prolongent la chaîne principale. Ils servent à qualifier un audit, un niveau de preuve, une citation ou une trajectoire de version.
q-ledger.yml
/.well-known/q-ledger.yml
Surface publiée qui contribue à rendre une chaîne probatoire plus reconstructible.
q-ledger-latest.json
/.well-known/q-ledger-latest.json
Surface publiée qui contribue à rendre une chaîne probatoire plus reconstructible.
Q-Ledger
Cette page est la définition canonique de Q-Ledger dans le corpus de gouvernance interprétative.
Q-Ledger est un journal d’observation faible et machine-first servant à consigner des observations datées de surfaces de gouvernance sans confondre observation et attestation.
Définition courte
Q-Ledger est un journal structuré de signaux de gouvernance observés. Il peut consigner qu’un artefact machine-first, une route, une surface de réponse ou un point d’entrée de gouvernance était disponible, observé, consulté, modifié ou manquant dans une fenêtre déclarée.
Son rôle est volontairement modeste. Q-Ledger ne prouve pas qu’un système a compris le canon. Il ne certifie pas la conformité. Il préserve une continuité observable pour que l’observabilité, les métriques, l’audit ou la correction ne commencent pas dans l’anecdote.
Pourquoi c’est important
Dans un web interprété, plusieurs échecs sont temporels. Un fichier existait puis a disparu. Une route était disponible, mais n’a pas été consultée. Une politique a changé, mais d’anciennes sorties continuent de circuler. Une correction a été publiée, mais son effet ne peut plus être daté.
Q-Ledger donne une mémoire à ces événements. Il crée un substrat probatoire faible pour l’observabilité et l’auditabilité.
Ce que Q-Ledger peut consigner
Une entrée Q-Ledger peut consigner :
- la surface ou la route observée ;
- l’horodatage de l’observation ;
- le statut observé ;
- le rôle de gouvernance attendu de la surface ;
- la version, le hash ou la référence de snapshot lorsque disponible ;
- le caractère direct, inféré ou rapporté de l’observation ;
- la limite de l’observation ;
- la relation avec une correction, un audit ou une métrique ultérieure.
Le journal doit préserver assez de contexte pour empêcher l’inflation ultérieure de l’observation.
Ce que Q-Ledger n’est pas
Q-Ledger n’est pas une preuve de fidélité. Ce n’est pas une attestation juridique. Ce n’est pas une garantie qu’un système d’IA a utilisé un fichier. Ce n’est pas un outil analytique de trafic, de classement ou d’audience.
C’est une couche disciplinée d’observation. Sa force vient du fait qu’elle refuse d’affirmer plus que ce qui a été observé.
Modes d’échec courants
- traiter l’observation comme une certification ;
- consigner une surface sans préserver la version ou la date ;
- mélanger des déclarations externes et des observations directes sans distinction ;
- utiliser le journal pour suggérer une conformité modèle ;
- dériver Q-Metrics d’observations incomplètes ou ambiguës ;
- ne pas consigner les observations négatives comme les fichiers manquants ou les routes brisées.
Relation avec Q-Metrics
Q-Metrics est dérivé de Q-Ledger. Une métrique peut décrire la continuité des points d’entrée, le taux d’échappement, la fraîcheur, la rupture ou la fidélité de séquence, mais elle hérite des limites probatoires du journal.
Si le journal est faible, la métrique est faible. Cette dépendance garde la mesure honnête.
Relation avec la couche de preuve
Q-Ledger se situe dans la couche de preuve. Il contribue une mémoire d’observation, mais il ne remplace pas la preuve reconstructible, les traces d’interprétation ou la preuve de fidélité.
Règle opérationnelle
Chaque entrée Q-Ledger devrait déclarer ce qui a été observé, quand l’observation a eu lieu, ce qui n’a pas été observé et quelle conclusion ne doit pas être tirée de l’entrée.