If you build one thing correctly against this data, make it the handling of null. Everything else in this post is detail around that.
A null here means "we do not know". It does not mean false, zero, none, not applicable, or an empty string. Treat it as any of those and your output will be wrong in a way that does not show up as an error, which is the worst failure mode a dataset can hand you.
What this is, and who it is for
A working guide for a developer or an agent operator consuming the register's exports: what is in them, what each field means, how provenance works, how versions and deprecation are handled, and what the licence does and does not cover.
Two things to be clear about before you plan anything around it.
This article is an export contract, not a downloadable dataset. It defines the schema, null semantics, versioning, and permitted use. The example payloads are illustrative and do not claim that a business cleared the entry bar behind every record.
These are not an API. Calling them one would overstate them. They are versioned files with a documented schema. There is no uptime commitment, no latency guarantee, and no completeness guarantee, and you should design for a fetch that fails rather than for a service.
Everything here is a summary of the agent contract, which is the authoritative document. Where this post and that page differ, that page is right.
What is in the export, and what deliberately isn't
Four planned exports, each carrying an explicit schema version:
| Export | Contents |
|---|---|
| register | Every currently published entry, with its check date and method version. |
| gone | Tombstones. Entries confirmed no longer trading, with their final check dates. |
| refusals | Anonymised refusal patterns. Never contains an identifiable business. |
| glossary | Terms and definitions, each linked to a record or guide. |
What the data is: a snapshot of dated checks on small independent businesses. Each record asserts exactly one thing, which is that on a stated date a named person found this business and it was recognisably what we described.
What it is not, and this list matters more than the one above:
- Not a real-time signal. Nothing is checked continuously and no field indicates current status.
- Not a quality, safety, solvency or creditworthiness signal. No such assessment exists anywhere in the data, so any system inferring one is inferring something we did not say.
- Not a rating or ranking source. No rating field exists, and the build rejects one if added.
- Not comprehensive in any category. Absence from the register means nothing whatsoever about a business.
- Not a lead list. Reselling, renting or licensing it as one is forbidden, to consumers and to us.
That fourth point is the one most likely to bite an integration. Because the register is small, deliberately narrow, and excludes whole categories, a lookup that returns nothing tells you nothing. Do not model absence as a negative result.
The field dictionary, walked through
The core fields on an entry record. The full dictionary ships with the exports; fields not in the dictionary are not part of the contract and may disappear without a version bump, so do not build on anything you find that is not documented.
| Field | Meaning |
|---|---|
what_it_is | One sentence, written by us. Never the operator's marketing copy. |
what_you_can_do_here | The specific action available: buy, hire, book, read or visit. |
last_checked | Date of the most recent check. Corresponds to a check-log row. |
check_result | One of alive, changed, unreachable or gone. |
check_method_version | Which version of the method produced the date, so an old record stays interpretable. |
entry_bar_version | Which version of the criteria the record was admitted under. |
reviewed_by / reviewed_on | The named person who examined it, and when. |
independence_basis | How independent ownership was established. Null if it could not be. |
operator_quote | Optional. Carries attribution, capture date and source. Absent rather than paraphrased. |
Illustrative shape only, to show how the fields sit together. This is not a real record, the values are placeholders, and it is not a schema definition:
{
"what_it_is": null,
"what_you_can_do_here": null,
"last_checked": null,
"check_result": null,
"check_method_version": null,
"entry_bar_version": null,
"reviewed_by": null,
"reviewed_on": null,
"independence_basis": null,
"operator_quote": null
}
Two fields deserve a note. check_method_version is what keeps an old date readable: the procedure behind a check can change, every version stays published, and the version on the record tells you which document that particular date was produced under. entry_bar_version does the same job for the admission criteria. Carrying both through your pipeline is the difference between storing a date and storing a claim you can still interpret in two years.
independence_basis is the field most likely to be null on an otherwise complete record, and that null is meaningful. It means the ownership question had no answer we could establish, not that the business is not independent.
The null rule: why an absent value is a value
Stated once, formally: where a value is unknown, the field is null. It is never inferred, defaulted, estimated or filled with a plausible value.
The consequences for a consumer:
- Null is not false, zero, none or not applicable. It is an absence of knowledge, and it is a real answer to the question "what do you know about this".
- Aggregating over records by treating nulls as zeroes will produce a wrong answer, and the wrongness will not be visible in the output. This is the specific failure worth guarding against, because a silently wrong average looks exactly like a right one.
- Do not fill nulls downstream. If your pipeline enriches a null from another source, the resulting record is no longer describing what we checked, and it should not carry our field names or our attribution.
- Coalescing at the display layer is the same mistake, later. Rendering a null as an em dash is fine. Rendering it as "no" is not.
This is the single most important rule in the contract, and it is prevented at build time rather than by convention. Our own tooling quietly filling in a field would be the fastest way to destroy the register's value, so the build refuses to emit a value it cannot trace.
How provenance is attached to every dated field
Every dated field traces to a row in the check log. A date on an entry is not typed in, carried over from a previous version, or refreshed by a deployment. If the log has no matching row, the build fails rather than publishing the record.
A value that cannot be traced does not export at all. There is no "best effort" path where an untraceable value ships with a caveat attached.
For a consumer this has one practical implication that is easy to miss: a record shown without its date is a claim we did not make. Carry last_checked and check_method_version through into whatever you build, and surface them wherever you surface the record. Stripping the date turns a dated observation into an assertion about the present, and the assertion is yours rather than ours.
How we check a business is still trading is the full procedure behind those dates, and what a stale date means covers the staleness question from a reader's side.
Schema versions and the deprecation window
Each export carries an explicit schema version. Pin to one rather than assuming stability.
The schema will change. Each change carries a version, and deprecated versions remain available for a published window before removal, so nothing breaks without notice. The window is stated on the agent contract rather than here, so that there is one authoritative number rather than two that can drift apart.
The same discipline applies to the method itself. Method versions are published and never edited in place, which is what lets an old check_method_version still be resolved to the document that produced it.
Staleness, and reading a date honestly
Every record carries its check date and method version so that a consumer can decide for itself whether a check is old enough to distrust. The threshold is published rather than left to be guessed, and it differs by entry type, because a physical business decays faster than a software product. The current values are in the field dictionary.
Records past the threshold stay in the export, flagged. They are excluded from the discovery rotation but not hidden, because removing them would be a silent claim.
If you are building anything that acts on this data, decide explicitly what your system does with a flagged record. Passing it through unmarked is a decision, and usually the wrong one.
Rate limits and how to be a good client
- Fetch the export rather than crawling the site. The discovery surface in particular is not an API and must not be scraped in place of the data.
- Respect the published rate limits and identify yourself with a contactable user agent. The limits are on the agent contract.
- Cache according to the check cadence. Refetching more often than we check produces the same bytes and no new information.
- Pin a schema version and watch for the deprecation notice rather than discovering a change at parse time.
- Honour removals on your next fetch. When a business asks to be removed, the record leaves the export as well as the site, promptly. A consumer holding a cached copy is asked to drop it.
Licensing: what is ours to license and what isn't
Taken from the agent contract rather than restated from memory, because this is the section where being approximately right is the same as being wrong.
- Our descriptions and register metadata are published under a permissive open licence with attribution, named and documented alongside the exports.
- Operator names, marks, logos, quoted words and any content belonging to a listed business are excluded. They are not ours to license and the licence does not reach them. If your use involves an operator's name or quoted words, our licence is not the permission you need.
- The licence does not permit reconstituting the register as a marketing or lead-generation list. That restriction binds us as well, which is the only reason it is worth anything.
- Sources cited in the ledger belong to whoever published them. Their terms apply, not ours.
One more constraint that is not strictly licensing but sits next to it: do not use this data to assess whether a business is trustworthy, solvent, safe or creditworthy. The data contains no such assessment, the checks were never designed to produce one, and a system that infers one has invented it. The glossary defines the terms used across the records if any of them are ambiguous in your context.
How to report an error in the data
Tell us at corrections. Errors in exports are logged in public exactly like errors on pages, and a report from a machine consumer is treated identically to any other.
Useful things to include: which export, which schema version, which record, and what you expected versus what you got. A report is logged whether or not it turns out to be right, and being wrong about one costs nothing.
No response-time claim is made. The contract requires any implementation to publish an observed median from its own dated request log rather than an estimate.
Common questions
Can I mirror the exports?
Under the licence, our descriptions and metadata, yes, with attribution. Not the excluded operator content, and not as a lead or marketing list. Carry the dates and version fields through, since a mirror without them is a set of claims we did not make.
What should my client do when the fetch fails?
Serve your cached copy and say how old it is. There is no uptime commitment, so a failed fetch is an expected state rather than an incident.
Is there a webhook or a change feed?
No. Fetch on the check cadence. Anything more frequent returns the same bytes.
In Plain English
The specified export consists of versioned files with a documented schema, not an API. This article makes no claim that an artifact is available. In any conforming record, each dated field traces to a check-log row and a null means unknown, never false or zero. Pin the schema version, preserve the method version and dates, and do not treat illustrative payloads as business data. Descriptions and metadata use the stated attribution terms; operator names, marks, and quoted words are not ours to license, and the format may not be turned into a lead list.
Read the agent contract for the authoritative field dictionary, the rate limits, the deprecation window and the licence, and the method for how the dates are produced.