Baseline (phase 0) : Q-Ledger (v0.1) — 2026-01-19 → 2026-02-06

Baseline (phase 0) : Q-Ledger (v0.1) — 2026-01-19 → 2026-02-06

Cette page fige et documente la baseline d’observation (phase 0) produite via Q-Ledger et Q-Metrics sur la période indiquée. Elle sert de point zéro comparatif avant le passage à une phase de découvrabilité passive.

Portée : observation, pas attestation.
Cette baseline ne prouve ni identité, ni paternité, ni intention, ni conformité. Elle décrit des accès observés (requêtes HTTP) et des artefacts dérivés, avec leurs limites.

Document (PDF)

Rapport baseline (PDF) :
Baseline (phase 0) : Q-Ledger (v0.1)

Note : le document synthétise les constats, les indicateurs et les limites de lecture. La présente page en constitue la référence canonique sur gautierdorval.com.

Entrypoints (machine-first)

Q-Ledger :
/.well-known/q-ledger.json · /.well-known/q-ledger.yml

Q-Metrics :
/.well-known/q-metrics.json · /.well-known/q-metrics.yml

Pages associées :
Q-Ledger · Q-Metrics · Observations (baseline)

Couverture

Fenêtre (UTC) : 2026-01-19 → 2026-02-06
Objectif : produire une baseline descriptive, archivable, et comparabile d’une phase à l’autre.

Lecture minimale : ce baseline documente un démarrage d’instrumentation. Certaines séquences reflètent des régimes de validation (vérification d’entrypoints), d’autres des régimes d’exploration (navigation) ou mixtes.

Interprétation : ce que la baseline peut et ne peut pas dire

Ce que la baseline peut montrer

• Des accès observés vers des entrypoints machine-first (consultations HTTP) sur une fenêtre donnée.
• Une continuité de publication (snapshots) lorsque le chaînage et l’archive le permettent.
• Des signaux descriptifs (compliance, escape, fidelity) lorsque Q-Metrics est disponible.

Ce que la baseline ne peut pas prouver

• L’ingestion effective dans un modèle, la compréhension sémantique, ou l’usage en génération de réponses.
• L’identité de l’agent réel derrière un user agent (spoofing possible).
• Une conformité, une responsabilité, ou une autorité.

Archive (audit surface)

La baseline est archivée dans un dépôt distinct afin de conserver une timeline immuable et de réduire les modifications silencieuses :

• Archive des snapshots : github.com/GautierDorval/q-ledger-archive
• Outils et format : github.com/GautierDorval/q-ledger

Prochaine étape

Une fois cette baseline figée, l’étape suivante consiste à passer à une phase expérimentale de découvrabilité passive : publication stable des entrypoints et observation des comportements sans extraction active continue.

Note : cette page restera stable. Toute mise à jour ultérieure fera l’objet d’un nouveau baseline versionné.

Comment interpréter cette baseline

Une baseline est un état de départ, pas une conclusion. Elle donne aux observations futures un point de comparaison. Sa valeur vient de l’explicitation des conditions initiales : ce qui a été observé, ce qui ne l’a pas été, les systèmes inclus, les signaux faibles et les incertitudes restées ouvertes.

Sans baseline, l’amélioration ou la dégradation ultérieure peut être mal lue. Une correction peut sembler réussie simplement parce que la requête a changé. Une dérive peut sembler nouvelle alors qu’elle était déjà présente. Une citation peut paraître stable pendant que l’interprétation sous-jacente reste instable.

Implication de maintenance

Les éléments de baseline doivent rester séparés de l’autorité actuelle. Ils documentent un état historique. Ils peuvent informer l’analyse ultérieure, mais ne doivent pas être traités comme la dernière interprétation sans rafraîchissement, comparaison et réconciliation avec les observations actuelles.

Voir aussi

• Q-Ledger
• Q-Metrics
• Observations (baseline) : Q-Ledger & Q-Metrics
• Doctrine

Règle de lecture

Cette note doctrinale sur Baseline (phase 0) : Q-Ledger (v0.1) — 2026-01-19 → 2026-02-06 doit être lue comme une surface de positionnement dans le corpus de gouvernance interprétative. Elle ne remplace ni les définitions canoniques ni les frameworks opérationnels. Elle explique pourquoi une distinction compte, où la doctrine trace une frontière et quel type d’erreur devient plus probable lorsque cette frontière est ignorée.

Le lecteur doit distinguer trois niveaux. D’abord, le niveau conceptuel : ce que la page nomme ou refuse de nommer. Ensuite, le niveau procédural : ce qu’un système, une organisation ou un évaluateur devrait vérifier avant de s’appuyer sur une réponse. Enfin, le niveau probatoire : ce qui rendrait l’interprétation reconstructible, contestable et corrigeable. Une page doctrinale est plus forte lorsqu’elle garde ces trois niveaux visibles plutôt que de les fondre dans une formulation persuasive unique.

Usage dans le corpus

Cette page sert de pont entre les définitions, les frameworks et les observations. Elle peut guider un parcours de lecture, justifier l’existence d’un framework ou expliquer pourquoi une réponse devrait être bornée, refusée ou auditée. Elle ne doit pas être traitée comme une instruction runtime, une garantie de comportement de modèle ou un substitut à la preuve. Si une réponse fondée sur cette doctrine ne peut pas montrer quelle source a été utilisée, quelle inférence était permise et quelle incertitude demeure non résolue, la doctrine reste un principe de lecture plutôt qu’un contrôle opérationnel.