Skip to content

Doctrine

Public benchmarks, observation ledgers, and snapshots

Public benchmarks, observation ledgers, and snapshots states a doctrinal position on AI interpretation, authority, evidence, governance or response legitimacy.

CollectionDoctrine
TypeDoctrine
Layertransversal
Version1.0
Levelnormatif
Published2026-03-22
Updated2026-03-25

Visual schema

Minimal chain of a publishable benchmark

A benchmark is acceptable only if the comparison chain remains readable from the observed corpus to the published result.

01

Corpus

Declared corpus

Cases, surfaces, languages, and corpus limits must be published before any comparison.

02

Protocol

Comparison protocol

Method, questions, reading conditions, and criteria must remain explicit.

03

Snapshot

Dated snapshot

Each compared state must be tied to a date, a system, and an observation window.

04

Ledger

Observation ledger

A benchmark stays weak unless it is attached to a ledger documenting the runs.

05

Publication

Public comparison surface

Publication must expose gaps, perimeters, and limits without disguising itself as a simplified ranking.

06

Enforceability

Contestation and reuse

The benchmark starts to matter when a third party can re-read, contest, or replicate the setup.

Governance artifacts

Governance files brought into scope by this page

This page is anchored to published surfaces that declare identity, precedence, limits, and the corpus reading conditions. Their order below gives the recommended reading sequence.

  1. 01Q Ledger Latest
  2. 02Q-Metrics JSON
  3. 03Q-Metrics YAML
Observability#01

Q Ledger Latest

/.well-known/q-ledger-latest.json

Observation surface that exposes logs, metrics, snapshots, or measurement protocols.

Governs
The description of gaps, drifts, snapshots, and comparisons.
Bounds
Confusion between observed signal, fidelity proof, and actual steering.

Does not guarantee: An observation surface documents an effect; it does not, on its own, guarantee representation.

Observability#02

Q-Metrics JSON

/.well-known/q-metrics.json

Descriptive metrics surface for observing gaps, snapshots, and comparisons.

Governs
The description of gaps, drifts, snapshots, and comparisons.
Bounds
Confusion between observed signal, fidelity proof, and actual steering.

Does not guarantee: An observation surface documents an effect; it does not, on its own, guarantee representation.

Observability#03

Q-Metrics YAML

/.well-known/q-metrics.yml

YAML projection of Q-Metrics for instrumentation and structured reading.

Governs
The description of gaps, drifts, snapshots, and comparisons.
Bounds
Confusion between observed signal, fidelity proof, and actual steering.

Does not guarantee: An observation surface documents an effect; it does not, on its own, guarantee representation.

Complementary artifacts (3)

These surfaces extend the main block. They add context, discovery, routing, or observation depending on the topic.

Observability#04

Q-Ledger JSON

/.well-known/q-ledger.json

Machine-first journal of observations, baselines, and versioned gaps.

Observability#05

Q-Ledger YAML

/.well-known/q-ledger.yml

YAML projection of the Q-Ledger journal for procedural reading or tooling.

Observability#06

Observatory map

/observations/observatory-map.json

Structured map of observation surfaces and monitored zones.

Public benchmarks, observation ledgers, and snapshots

In a doctrinal corpus, the need for comparison arrives quickly. As soon as an architecture claims to reduce drift, make hierarchy visible, stabilize an entity, or preserve an authority boundary, one question returns: how can that be shown publicly without turning observation into promise?

That is precisely the function of public benchmarks, observation ledgers, snapshots, and comparison sets. These surfaces do not exist to say “the system is better”. They exist to make variation contestable, comparable, and archivable.

This page does not replace Q-Ledger, Q-Metrics, or the cross-model validation protocol. It locates doctrinally the family to which those objects belong.


1. Why publish public comparison surfaces

Without a public comparison surface, governance remains easy to rhetoricalize. One can claim drift is down, coherence is up, boundaries are holding better, yet no outsider can verify the method, compare states, or challenge what was retained.

Publishing a comparative surface, even a weak one, changes the nature of the discussion. The discussion is no longer only about impression or performance storytelling. It becomes about protocol, perimeter, date, corpus, system state, and observed deltas.

That publicity is not a marketing bonus. It is a formulation discipline. It forces a distinction between what is observed, what is inferred, what is compared, and what is not proven.


2. Four objects that should no longer be conflated

a) Benchmark

A benchmark is a comparison protocol. It presupposes a stable set of cases, questions, observation criteria, and reading conditions. Without a declared protocol, the word designates little more than evaluation rhetoric.

b) Observation ledger

An observation ledger, such as Q-Ledger, records observed states over a period. It does not necessarily compare models or outputs. It documents continuity, consultations, sequences, occurrences, and breaks.

c) Snapshot

A snapshot freezes a dated state. It matters because it makes visible what was accessible, published, or observed at a given moment. Without chained snapshots, governance memory becomes rewriteable.

d) Comparison set

A comparison set gathers the cases, prompts, entities, variants, documents, or environments on which comparison becomes reproducible. It may take the form of a dataset, matrix, annex table, repository, or sequence of documented states.

These objects can be combined, but they do not share the same status. A benchmark without snapshots quickly becomes unverifiable. A snapshot without a comparison set stays mute about method. An observation ledger without a comparison protocol documents presence, not superiority.


3. What these surfaces can genuinely show

When well designed, these surfaces can show several useful things:

  • that state A and state B were observed on distinct dates;
  • that a comparison protocol remained stable or changed;
  • that certain negative cases, exceptions, or uncertainty zones reappear;
  • that an alleged improvement corresponds to visible differences in a frozen corpus;
  • that a change of model, source, version, or structure displaced the results.

They can also show that a system becomes more prudent, that non-response becomes more frequent where it should, or that source hierarchy holds better under variation.

Their function is therefore not only to measure “more” or “less”. It is to document how a restitution changes, where it weakens, and what remains unresolved.


4. What they cannot prove

Their value rises precisely when they do not claim more than they can bear.

They do not prove:

  • the identity or intent of the actor behind the system;
  • regulatory, legal, or contractual compliance;
  • simple causality between a change and an outcome;
  • a universal ranking between models;
  • absolute stability outside the published protocol.

That is why observation must remain distinct from attestation, and why published baselines must stay accompanied by their limits.

A benchmark presented as a quality certificate exceeds its perimeter. An observation ledger presented as strong proof invites interpretive over-reading.


5. Minimum conditions for doctrinally clean publication

A public comparison surface should at least declare:

  • the exact perimeter of the cases and what it excludes;
  • the observation window;
  • the collection and freezing conditions;
  • the version differences between compared states;
  • the negative cases and not only the demonstrative ones;
  • the archive continuity that makes it possible to verify a state was not rewritten later;
  • the nature of the evidence being published: descriptive, comparative, exploratory, indicative.

This is why the baseline observations and the phase 0 baseline matter. They show a state, a scope, and limits, not a performance slogan.


6. Why archive matters as much as the score

Weak practice publishes a note, score, table, or synthetic verdict. Stronger practice also publishes the conditions that make it possible to return to the context of the score.

A comparison without archive may be repeated, but it is hard to audit. A score without protocol may be circulated, but it is hard to contest. A series of snapshots without continuity may be exhibited, but it is hard to reconstruct.

Archive does not magically make an argument right. It simply makes silent rewriting of the past more costly. That is why a public benchmark has doctrinal value only if it is attached to a memory of publication.

That requirement meets two other disciplines directly. The first concerns rectification, retraction, and supersession of published objects. The second concerns sampling and representativeness, because a benchmark is not only a score or a series: it is also a decision about which cases are treated as meaningful for a given regime.


7. Scope and limit

This page is not a call to industrialize model ranking or to turn the site into a performance lab. It states a narrower requirement: when doctrine publishes comparison, that comparison must remain methodically weak, publicly legible, and explicitly bounded.

A public benchmark is useful only if it reduces fog without manufacturing a new illusion of authority.