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-Ledger JSON
/.well-known/q-ledger.json
Journal machine-first des observations, baselines et écarts versionnés.
- Gouverne
- La description des écarts, des dérives, des snapshots et des comparaisons.
- Borne
- La confusion entre signal observé, preuve de fidélité et pilotage réel.
Ne garantit pas : Une surface d’observation documente un effet ; elle ne vaut pas, seule, comme garantie de représentation.
Q-Ledger YAML
/.well-known/q-ledger.yml
Projection YAML du journal Q-Ledger pour lecture procédurale ou outillage.
- Gouverne
- La description des écarts, des dérives, des snapshots et des comparaisons.
- Borne
- La confusion entre signal observé, preuve de fidélité et pilotage réel.
Ne garantit pas : Une surface d’observation documente un effet ; elle ne vaut pas, seule, comme garantie de représentation.
Q Ledger Latest
/.well-known/q-ledger-latest.json
Surface d’observation qui expose des journaux, métriques, snapshots ou protocoles de mesure.
- Gouverne
- La description des écarts, des dérives, des snapshots et des comparaisons.
- Borne
- La confusion entre signal observé, preuve de fidélité et pilotage réel.
Ne garantit pas : Une surface d’observation documente un effet ; elle ne vaut pas, seule, comme garantie de représentation.
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é.
Q-Metrics JSON
/.well-known/q-metrics.json
Surface de métriques descriptives pour observer des écarts, snapshots et comparaisons.
Q-Metrics YAML
/.well-known/q-metrics.yml
Projection YAML de Q-Metrics pour instrumentation et lecture structurée.
Carte de l’observatoire
/observations/observatory-map.json
Carte structurée des surfaces d’observation et des zones suivies.
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
- 03Observation faibleQ-Ledger
- 04AttestationQ-Attest protocol
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.
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.
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.
Q-Ledger
Q-Ledger est un journal d’observation machine-first dérivé d’observations edge, conçu pour rendre des artefacts de gouvernance détectables, traçables et chaînés dans le temps.
Portée : observation, pas attestation. Q-Ledger ne prouve ni identité, ni intention, ni conformité juridique. Il documente qu’une surface a été observée comme publiée et, dans certains cas, consultée, sur une fenêtre donnée.
Pourquoi Q-Ledger existe
Dans un web interprété, les systèmes reconstruisent un contexte à partir de signaux partiels. Q-Ledger publie une mémoire faible mais structurée de cette détectabilité :
- quels points d’entrée machine-first existent ;
- quels snapshots ont été publiés ;
- quelle continuité est visible ;
- quelles ruptures deviennent détectables.
Q-Ledger ne tranche donc pas la vérité. Il préserve les conditions d’observation à partir desquelles des discussions ultérieures sur continuité, dérive ou correction peuvent devenir moins anecdotiques.
Ce que Q-Ledger peut montrer
Q-Ledger peut montrer :
- qu’un ensemble d’artefacts machine-first était publiquement publié sur une fenêtre donnée ;
- que certains endpoints ou artefacts ont été observés comme consultés ;
- que des snapshots successifs existent avec une logique de chaînage ;
- qu’une continuité ou une rupture devient visible.
Il sert donc à rendre la publication historisable.
Ce que Q-Ledger ne peut pas prouver
Q-Ledger ne prouve pas :
- l’identité de l’acteur à l’origine des artefacts ;
- l’intention derrière une consultation ;
- la conformité éditoriale ou juridique ;
- l’exhaustivité absolue de l’observation ;
- la fidélité d’une synthèse produite à partir de ces surfaces.
C’est pourquoi Q-Ledger doit rester relié à Observation vs attestation : pourquoi Q-Ledger est volontairement faible.
Artefacts publiés
Entrypoints principaux :
- JSON :
/.well-known/q-ledger.json - YAML :
/.well-known/q-ledger.yml - Latest :
/.well-known/q-ledger-latest.json
Artefacts de contexte souvent lus avec Q-Ledger :
Chaînage, continuité et rupture
Q-Ledger s’appuie sur une logique de snapshots, de hachage et de précédent. L’intérêt n’est pas cryptographique en soi. L’intérêt est interprétatif :
- rendre visible qu’une suite de publications existe ;
- rendre une rupture ou une lacune plus facilement contestable ;
- éviter qu’une correction ou un changement silencieux efface toute mémoire de ce qui était publié.
La continuité n’établit pas une vérité absolue. Elle rend un historique plus lisible.
Relation à Q-Metrics et aux observations
Q-Ledger n’est pas un tableau de bord. Il est plus proche d’une mémoire faible des conditions observées.
Q-Metrics vient ensuite condenser certains de ces signaux en indicateurs comparables. Observations sert de hub descriptif pour relier snapshots, fenêtres, limites et interprétations.
La chaîne correcte ressemble donc à :
artefacts publiés → observation faible → chaînage → condensation métrique → lecture doctrinale
Pourquoi Q-Ledger compte dans un dispositif machine-first
Publier des fichiers de gouvernance ne suffit pas. Il faut encore pouvoir documenter leur continuité, leur visibilité et la stabilité de leur publication.
Dans cette logique, Q-Ledger contribue à rendre auditable le couplage entre :
- architecture machine-first ;
- fichiers de gouvernance ;
- surfaces d’identité et de limites ;
- couches d’observation et de mesure.
C’est ce qui relie Q-Ledger à Le machine-first ne suffit pas : pourquoi les fichiers de gouvernance changent le régime de lecture et à Ce que fait vraiment chaque fichier de gouvernance.
Limites et biais
- Les observations dépendent de la visibilité edge, des caches et des conditions d’accès.
- Le silence ne prouve pas l’absence : un artefact peut exister sans avoir été observé dans la fenêtre.
- Une consultation observée ne prouve pas l’usage correct de la surface.
- Un snapshot publié ne garantit pas que tous les systèmes en tiendront compte.
Q-Ledger reste donc descriptif. Sa force vient précisément du fait qu’il n’essaie pas de promettre plus que ce qu’il peut soutenir.