Take the date off a record and you have not weakened the claim. You have changed what kind of thing it is.
For the broader context behind this business guide, read Our Entry Bar, In Full: And Everything We Turn Down.
"This business is trading" is a statement about the present, made by someone who cannot possibly know the present, about something that could have changed an hour ago. "This business was trading on this date, and this person looked" is a statement about the past, which is a category of thing that can actually be true. The second is a smaller claim and it is the only one worth making.
That is the whole argument for putting a date on everything, and everything else in this post follows from it.
What this is, and who it is for
This is for the reader looking at a record with a date on it and wondering how much weight it will carry. It is also for anyone consuming the register as data, where the date is doing more work than any other field.
Where things currently stand, since it affects how you should read the rest: the register has published no entries. Nothing described here is being demonstrated by anything you can go and look at. It is the design, published before the thing it governs.
Why an undated claim is not a claim
Consider what an undated statement about a third party is actually asking you to accept. It asks you to assume that the statement was true when it was written, that whoever wrote it checked, that they checked properly, and that nothing has changed since. Four assumptions, none of them stated, all of them yours to carry.
Adding a date collapses all four into one legible question: how old is this, and does that matter for what I am about to do?
This is also why a verification badge without a date is worth so little. A badge is a claim about a process, and a claim about a process with no timestamp is not falsifiable in either direction — you cannot tell whether the process ran last week or three years ago, or whether it ran at all. What a badge without a date is worth takes that apart in more detail.
The stronger version of the same point: an undated claim cannot go stale, because there is no mechanism by which it could ever be identified as old. It is permanently current and permanently unverifiable, and those two properties travel together.
What our dates are bound to, and why they can't drift
A date on this site is not a piece of text somebody typed. It is a reference to a row.
Every check produces a row in a check log recording what was checked, what the outcome was, which version of the method produced it, and who did it. The date displayed on an entry is the date on that row. It cannot be entered by hand, cannot be carried over from a previous version of the entry, and cannot be updated by a deployment. If the log has no matching row, the build fails rather than publishing the entry.
This is a small piece of plumbing and it is doing more work than any editorial commitment on the site. Most published dates that turn out to be untrustworthy are not fraudulent. They drift: someone edits a page, the "updated" field moves automatically, and now a date is attached to the day a file changed rather than the day a fact was checked. Nobody intended to mislead and the date is meaningless anyway.
The same rule covers articles, and it is worth being explicit because the two are easy to conflate. A last-reviewed date on an article means a person read the page on that day. It never means a build ran, a file changed, or a link was updated automatically. If a page has been touched by tooling and not read by anyone, its review date does not move.
The staleness threshold, and how it gets chosen
Here is the number this section would normally contain.
The staleness threshold has not been set. There is no value in force, and we are not going to publish one now to make this page feel more complete. There is no check history behind it — no entries, no re-checks, no observed decay — and a threshold picked in the absence of that would be a round number with a policy tone, which is exactly the kind of unmeasured figure this site refuses elsewhere.
What is decided is the shape of it, and that much can be published now:
- It differs by entry type. A physical business decays much faster than a piece of software with a stable address. A shop's hours, stock and even location can be wrong within weeks; a working signup page can be accurate for a long time. One threshold across both would be too tight for one and far too loose for the other. Why shop checks age faster covers that difference from the physical side.
- It gets set against real decay data, not against a feeling about what sounds diligent. The question is empirical: after how long does a check of this type of business stop predicting the present usefully?
- It gets published rather than left to be guessed, in the field dictionary alongside the agent contract, so that a machine and a human are working from the same value.
- It is versioned. Changing it later is a change to the method, recorded in the changelog with what it invalidated, not a quiet edit.
Until it exists, every record still carries its date and its method version, which means you can apply your own judgement about age without waiting for ours. That is the honest interim position: the raw material for the decision is published even though our own line has not been drawn.
What we show you when an entry passes the threshold
Once the threshold exists, an entry past it is flagged in place. It stays where it is, in the register and in the exports, with a visible marker saying the check behind it is old.
Two things happen to it and it is worth separating them. It remains findable and readable, because the record is still true — a check that happened is a fact about a date, and it does not stop having happened. And it is excluded from the discovery rotation, because putting an old check in front of someone who did not ask for it is a different act from letting them find one and see how old it is.
What does not happen: the date does not refresh, the entry does not quietly disappear, and no fresh check is implied by the entry continuing to exist.
What you should do with a stale entry
The right answer depends entirely on what you are about to do, which is why we flag rather than decide for you.
- Reading for interest, or building a list of things to look at later. Age matters very little. A business you find through a year-old record is still a lead worth following.
- About to travel somewhere, or relying on stated hours. Age matters enormously, and this is the case where a stale check is most likely to waste your afternoon. Confirm directly with the business before you go. The same applies to anything with an address attached.
- About to spend meaningful money. Do not lean on the date at all, however fresh. Run your own checks — what to check before you buy from a business you've never heard of is our own procedure compressed into five minutes.
- Building something on the data. Treat the date as a field to act on rather than display. More on that below.
And the general rule, which holds regardless of how recent a date is: freshness is not a quality signal. A check performed yesterday says the business was reachable yesterday. It does not say the business is good, safe, solvent, competent or likely to answer you. What the check actually consists of sets out exactly how narrow the claim is.
Why we don't just hide stale entries
Hiding would look tidier. Every visible record would be recent, the register would appear uniformly well maintained, and nobody would ever see an old date.
It would also be a lie by omission, and a fairly precise one. Hiding a stale entry is a silent claim; flagging it is an honest one. If everything visible is fresh, the register is implicitly asserting that everything in it has been checked recently, and that assertion would be false — the stale records would still exist, they would just be somewhere you could not see them.
There is a second reason, which is about us rather than you. A register that hides its stale records has removed its own strongest incentive to re-check them. The staleness would stop being visible to anyone, including to us, and the maintenance backlog would become invisible at exactly the point it started to matter. A flag on a page is a piece of pressure, and it is pointed in the right direction.
The same logic runs through the rest of the site. A business we cannot establish something about gets an explicitly empty field rather than a plausible one. A closure gets a tombstone rather than a deletion. In each case the alternative would produce a cleaner-looking site that told you less.
How dates work in the machine-readable export
For anything consuming the register as data, the date is the field that governs everything else.
Each record carries the check date, the check result, the version of the method that produced it, and the version of the entry bar it was admitted under. The method version is there so that an old record stays interpretable: a date produced under version 1 means what version 1 said it meant, not what a later version says.
Three obligations sit on a consumer, and they are set out properly in the agent contract:
Carry the date through. A record displayed without its date is a claim we did not make. If your interface shows "this business is trading", you have upgraded a statement about the past into a statement about the present, and you did that, not us.
Cache to the check cadence. Refetching more often than we check produces the same bytes and no new information.
Treat an empty value as unknown. Where a value is unknown the field is null, and null means "we do not know" — never false, zero, none or not applicable. Aggregating over records by treating nulls as zeroes produces a wrong answer, and nothing in the output will show you that it is wrong.
One thing the export deliberately does not contain: any assessment of trustworthiness, quality, safety or solvency. A system that infers one from a record's presence in the register is inferring something we did not say. Absence means nothing either — the register is small, narrow, and excludes entire categories for reasons unconnected to the businesses in them.
In Plain English
- A dated claim is a different kind of thing from an undated one. "Trading on this date, checked by this person" can be true. "Trading" cannot be verified by anyone.
- Dates are bound to check-log rows. They cannot be typed in, carried over, or refreshed by a deployment, and a missing row fails the build.
- A last-reviewed date on an article means a person read it. It never means a build ran.
- This article sets no universal staleness threshold. Entry types decay at different rates, so the check date remains visible and any threshold used by an implementation must be stated by entry type rather than inferred here.
- Past the threshold, entries are flagged in place, not hidden. Hiding would be a silent claim and would remove our own reason to re-check.
- A fresh date is not a quality signal. It says reachable and recognisable on that day, and nothing more.
- If you consume the data, carry the date with it. A record shown without its date is a claim we did not make, and an empty field means unknown rather than zero.
Definitions for the terms used here are in the glossary, and the full procedure behind the dates is in our method.
Read the agent contract → /agents/