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.
- 01Autorisation de répondreQ-Layer : légitimité de réponse
- 02Observation faibleQ-Ledger
- 03Mesure dérivéeQ-Metrics
- 04AttestationQ-Attest protocol
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.
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-Metrics
/.well-known/q-metrics.json
Couche dérivée qui rend certaines variations plus comparables d’un snapshot à l’autre.
- Rend prouvable
- Qu’un signal observé peut être comparé, versionné et contesté comme indicateur descriptif.
- Ne prouve pas
- Ni la vérité d’une représentation, ni la fidélité d’une sortie, ni un pilotage réel à elle seule.
- À mobiliser quand
- Pour comparer des fenêtres, prioriser un audit et documenter un avant/après.
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.
Surfaces probatoires complémentaires (1)
Ces artefacts prolongent la chaîne principale. Ils servent à qualifier un audit, un niveau de preuve, une citation ou une trajectoire de version.
Changelog IA
/changelog-ai.md
Journal public qui rend les évolutions des surfaces IA plus datables et plus auditables.
Dans un web interprété, l’enjeu n’est plus seulement de publier de l’information, mais de réduire la distorsion entre ce qui est publié et ce que des systèmes probabilistes reconstruisent à partir de signaux partiels.
Un problème revient sans cesse : l’observation est confondue avec la preuve. Q-Ledger est conçu pour éviter cette confusion. Il produit volontairement une preuve faible : structurée, chaînée, archivable, mais non attestative.
Portée : observation, pas attestation.
Q-Ledger ne prouve ni l’identité, ni la paternité, ni l’intention, ni la conformité.
Pourquoi l’observation est une preuve faible (et pourquoi c’est voulu)
Une observation dérivée de logs edge décrit ce qui a été vu dans une fenêtre donnée. Elle peut être utile, mais elle n’est jamais totale : cache, filtrage, restrictions, variations d’agents, et asymétries d’accès rendent la visibilité incomplète.
Dans ce contexte, la valeur de Q-Ledger n’est pas de « prouver », mais de rendre un fait minimal plus difficile à effacer : des entrypoints ont été observés comme consultés, à des dates précises, dans une séquence chaînée.
Ce que l’observation permet
- Constater que des entrypoints (ex.
/.well-known/*) ont été observés comme consultés sur une période donnée. - Suivre une continuité via des snapshots datés et un chaînage (ex.
previous_ledger_hash_sha256). - Réduire les modifications silencieuses grâce à l’historique public (archive immuable).
Ce que l’observation ne permet pas
- Prouver l’identité de l’émetteur ou la légitimité d’une autorité.
- Prouver une intention, une conformité, ou une responsabilité.
- Prouver la complétude (un log n’est jamais une vérité totale).
Pourquoi l’attestation est une couche différente
L’attestation relève d’une discipline distincte : signature, preuve cryptographique, responsabilité, chaîne de confiance. Autrement dit : un mécanisme explicite d’engagement vérifiable.
Q-Ledger ne remplace pas cela. Il prépare une surface minimale : la publication chaînée et archivable. Une couche suivante (par exemple, un mécanisme d’attestation cryptographique) peut ensuite s’appuyer sur cette surface pour transformer une observation en engagement vérifiable.
Le piège à éviter : mélanger observation et attestation
Mélanger ces deux registres produit des lectures fausses :
- Transformer un signal d’accès en preuve d’identité.
- Transformer une continuité d’artefacts en preuve de conformité.
- Transformer une archive en mécanisme de sécurité.
L’objectif est inverse : rendre les limites explicites, afin d’empêcher la reconstruction automatique d’une certitude non justifiée.
Ressources
- Q-Ledger : /doctrine/q-layer/q-ledger/
- Q-Metrics : /doctrine/q-layer/q-metrics/
- Archive des snapshots : github.com/GautierDorval/q-ledger-archive
- Outils et format : github.com/GautierDorval/q-ledger