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.
- 01Observation mapObservatory map
- 02Weak observationQ-Ledger
- 03AttestationQ-Attest protocol
- 04Memory and versioningAI changelog
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.
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.
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.
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.
q-ledger.yml
/.well-known/q-ledger.yml
Published surface that contributes to making an evidence chain more reconstructible.
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.