Skip to content

Definition

Q-Ledger

Canonical definition of Q-Ledger: a weak, machine-first observation ledger used to record dated governance-surface observations without confusing observation with attestation.

CollectionDefinition
TypeDefinition
Version1.0
Stabilization2026-05-07
Published2026-05-07
Updated2026-05-07

Evidence layer

Probative surfaces brought into scope by this page

This page does more than point to governance files. It is also anchored to surfaces that make observation, traceability, fidelity, and audit more reconstructible. Their order below makes the minimal evidence chain explicit.

  1. 01
    Observation mapObservatory map
  2. 02
    Weak observationQ-Ledger
  3. 03
  4. 04
    Memory and versioningAI changelog
Observation index#01

Observatory map

/observations/observatory-map.json

Machine-first index of published observation resources, snapshots, and comparison points.

Makes provable
Where the observation objects used in an evidence chain are located.
Does not prove
Neither the quality of a result nor the fidelity of a particular response.
Use when
To locate baselines, ledgers, snapshots, and derived artifacts.
Observation ledger#02

Q-Ledger

/.well-known/q-ledger.json

Public ledger of inferred sessions that makes some observed consultations and sequences visible.

Makes provable
That a behavior was observed as weak, dated, contextualized trace evidence.
Does not prove
Neither actor identity, system obedience, nor strong proof of activation.
Use when
When it is necessary to distinguish descriptive observation from strong attestation.
Attestation protocol#03

Q-Attest protocol

/.well-known/q-attest-protocol.md

Optional specification that cleanly separates inferred sessions from validated attestations.

Makes provable
The minimal frame required to elevate an observation toward a verifiable attestation.
Does not prove
Neither that an attestation endpoint exists nor that an attestation has already been received.
Use when
When a page deals with strong proof, operational validation, or separation between evidence levels.
Change log#04

AI changelog

/changelog-ai.md

Public log that makes AI surface changes more dateable and auditable.

Makes provable
That a probative state can be placed back into an explicit version trajectory.
Does not prove
Neither the effective absorption of a drift nor third-party consultation of the change.
Use when
When a page deals with snapshots, rectification, withdrawal, or supersession.
Complementary probative surfaces (2)

These artifacts extend the main chain. They help qualify an audit, an evidence level, a citation, or a version trajectory.

ArtifactEvidence artifact

q-ledger.yml

/.well-known/q-ledger.yml

Published surface that contributes to making an evidence chain more reconstructible.

ArtifactEvidence artifact

q-ledger-latest.json

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

Published surface that contributes to making an evidence chain more reconstructible.

Q-Ledger

This page is the canonical definition for Q-Ledger inside the interpretive governance corpus.

Q-Ledger is a weak, machine-first observation ledger used to record dated governance-surface observations without confusing observation with attestation.

Short definition

Q-Ledger is a structured ledger of observed governance signals. It can record that a machine-first artifact, route, response surface, or governance entry point was available, observed, consulted, changed, or missing within a declared window.

Its role is modest by design. Q-Ledger does not prove that a system understood the canon. It does not certify compliance. It preserves observable continuity so later interpretation, metrics, audit, or correction work does not begin from anecdote.

Why it matters

In an interpreted web, many failures are temporal. A file existed but was later removed. A route was available but not consulted. A policy changed, but older outputs continued to circulate. A correction was published, but its effect could not be dated.

Q-Ledger gives these events a memory. It creates a weak evidentiary substrate for observability and auditability.

What Q-Ledger can record

A Q-Ledger entry can record:

  • the observed surface or route;
  • the observation timestamp;
  • the observed status;
  • the expected governance role of the surface;
  • version, hash, or snapshot reference when available;
  • whether the observation was direct, inferred, or externally reported;
  • the limitation of the observation;
  • the relation to a later correction, audit, or metric.

The ledger should preserve enough context to prevent later inflation of the observation.

What Q-Ledger is not

Q-Ledger is not proof of fidelity. It is not a legal attestation. It is not a guarantee that an AI system used a file. It is not an analytics tool that measures audience, rankings, or traffic.

It is a disciplined observation layer. Its strength comes from refusing to claim more than it observed.

Common failure modes

  • treating observation as certification;
  • recording a surface without preserving version or date;
  • merging external claims and direct observations without distinction;
  • using the ledger to imply model compliance;
  • deriving Q-Metrics from incomplete or ambiguous observations;
  • failing to record negative observations such as missing files or broken routes.

Relation to Q-Metrics

Q-Metrics is derived from Q-Ledger. A metric may describe entry point continuity, escape rate, freshness, rupture, or sequence fidelity, but it inherits the evidentiary limits of the ledger.

If the ledger is weak, the metric is weak. This dependency keeps measurement honest.

Relation to the evidence layer

Q-Ledger sits inside the evidence layer. It contributes observation memory, but it does not replace reconstructable evidence, interpretation traces, or proof of fidelity.

Operational rule

Every Q-Ledger entry should state what was observed, when it was observed, what was not observed, and what conclusion must not be drawn from the entry.