Using this record as a retrieval source

For systems that read this archive rather than people. What the identifiers guarantee, the cadence the data moves at, the form a citation takes, the path by which a value is checked, and which entries carry text that may travel.

Identifiers

Every tracked entry has a slug — eu-gmp-annex-11 — and that slug is its identifier at /instrument/<id>/ and in every API response. A published URL is treated as a citation here: it keeps resolving, directly or by redirect, and scripts/test_url_stability.py fails the build if one stops. When an entry changes kind — two moved from instruments to bodies on 2026-08-02 — the old URL redirects rather than disappearing.

The v1 contract

Additive only. A field is never removed and never re-typed; a new field or a new endpoint may appear. A consumer that reads fields it knows and ignores the rest will not break. Where a value's MEANING changes, a correction is logged, the feed carries it, and the change is described in the changelog — that has happened twice, and both entries are public.

/api/v1/instruments.json · observations.json · citations.json · crawlability.json

Cadence

Sources are fetched and hashed daily, and the hash is recorded whether or not anything changed — "unchanged for N days" is only a fact if every one of those days was observed. Statuses change only when a person confirms one against the primary source. There is no undertaking about when a run happens, and a day with no run is visible as a gap in the series rather than smoothed over.

Citing a value

A value here is a reading of a source on a date, so a citation needs both:

GxPlex, "<short title>" (<instrument id>), status <status>
  as recorded on <YYYY-MM-DD>. https://gxplex.com/instrument/<id>/

Citing the status without the date cites a fact that has no owner: this record's claim is always about a day.

Checking a retrieved claim

Each observation carries a SHA-256 of the normalised text of the source on that day — in observations.json and on the instrument page.
Fetch the source yourself and compare, or compare against the retained snapshot where one exists.
Recompute the day's integrity root from the published leaves and check it against the published root: the command is on /verify, and it is run against the shipping bytes on every build.

These are hashes, not signatures. They prove the published data is the data the root was built from. They do not prove who published it, because no signing key exists yet — a fact /verify states in its own words. When one does, the manifest carries a detached signature and this step becomes a signed hash. A consumer describing values from here as cryptographically attributable would, today, be claiming something this record does not yet support.

Licence — which text may travel

Every row in instruments.json carries licence_class and text_retained, so a pipeline inherits the boundary instead of discovering it.

What each licence position permits a consumer
Value	Count	What it means here
`open`, text retained	42	A snapshot and a hash exist. Quotations can be checked against retained bytes.
`restricted`	27	The document's text is not reproduced or retained here, and none is available through this record. Metadata and a link only — a consumer that generates text for these is not quoting this archive.
`text_retained: false`	41	Nothing was hashed, so there is nothing here to verify a quotation against. The entry states why on its own page.

What this record warrants, and what it does not

Integrity is provable. That the published data is the data the root was built from, and that a document's text on a given day hashed to a given value, are things a consumer can check without trusting this site — the arithmetic is published and so are the inputs.

Accuracy is not a cryptographic property. A status read wrongly hashes exactly as well as one read correctly. Accuracy lives in the reading, in the human check, and in the corrections log, which is additive and never silently edits. "Verified" carries exactly one sense here — checked against the primary source by a person, on a stated date — and it is the only sense this record can support for a value taken from it.

This record makes no assessment of what any document requires of anyone. A consumer that presents its contents as a compliance obligation has added a claim that is not here.

Found something wrong? corrections@gxplex.com. Method: how this record is maintained.

Last updated: 3 August 2026