Our method
The procedure behind every check date on this site: what runs automatically, what a person does, what counts as a failure, how often it repeats, and what a passing check does not tell you.
What a check is trying to establish
One thing only: that on a stated date, this business was reachable and recognisably the business we described. That is the entire claim.
It is a deliberately narrow claim, and narrowness is the point. A check that tried to establish quality, safety or solvency would be a check we could not actually perform, and the date next to it would then be decorating a guess.
What we check, in order
- The destination resolves and responds, without a redirect to an unrelated site.
- The page still describes the same business doing the same thing.
- The route by which a customer acts — buy, book, enquire, visit — is still present.
- The way to reach a human still exists and has not been removed.
- Nothing on the page contradicts what our entry says about the business.
- For a physical business, the additional steps set out at real places, checked.
The first step is automated. The rest are read by a person, because each of them requires judgement that a status code cannot supply.
The four outcomes
| Outcome | What it means | What happens next |
|---|---|---|
| Alive | Reachable, recognisable, and still doing the thing we described. | The entry keeps its place; the date advances. |
| Changed | Reachable, but the business has materially changed what it does or how you reach it. | A person re-reviews the entry against the bar and rewrites or removes it. |
| Unreachable | No response, or a response that is not the business. | Enters the failure sequence; nothing is published about it yet. |
| Gone | Two failures at least fourteen days apart, plus one human confirmation. | Becomes a tombstone with the date of the final check. |
Why one failed check is never enough
Sites go down. Certificates expire on a Friday. Owners take a week off and pause a shop. Declaring a working business closed is the most damaging error this site can make, and it is expensive for the operator in a way that a missing entry never is.
So the threshold is high and deliberately slow: two failures separated by at least fourteen days, then a person confirming it independently. Where a business has moved or rebranded rather than closed, it is re-reviewed rather than tombstoned.
Dates cannot drift
Every date displayed on an entry corresponds to a row in a check log. A date cannot be typed in, carried over, or refreshed by a deployment. If the log has no matching row, the build fails rather than publishing the entry.
The same applies to the last-reviewed date on an article: it records the day a person read the page, never the day a build ran.
Staleness
A check is a claim with an expiry. Past our staleness threshold an entry is flagged in place rather than hidden — hiding it would be a silent claim, and flagging it is an honest one.
The threshold differs by entry type, because a shop's details decay considerably faster than a software product's. The specific values belong in the field dictionary of any conforming export, as set out in the agent contract so that a machine consuming the register can act on them rather than guess.
What a passing check does not tell you
- Not that the business is good, competent or well run.
- Not that it is safe, solvent, insured or licensed.
- Not that it will still be trading tomorrow, or today.
- Not that it will answer you, or answer you quickly.
- Not that any claim the business makes about itself is accurate.
It tells you that on a stated date, a named person found it and it was there.
Where the method handles things badly
Seasonal businesses, businesses that trade only inside a platform we cannot see into, sites behind a login, and shops whose hours change week to week are all cases where a dated check is a weak instrument. We would rather say that than pretend otherwise. Seasonal closures and the is-it-open problem covers this in detail.
Versioning
This is version 1, the first published version. Changes are recorded at the method changelog, including what each change invalidated and which entries had to be re-checked. Published versions are never edited in place, so an old entry can always be read against the version that produced it.
Questions about the method
Is the check automated or done by a person?
Both. Reachability is automated because it is cheap and repeatable. Everything requiring judgement — is this still the same business, can a customer still act — is read by a person, and the person is named on the record.
How often is a business re-checked?
On a published cadence that varies by entry type, with physical businesses checked more often than online-only ones because their details decay faster. The current values are in the field dictionary at the agent contract.
What if a business is temporarily closed?
It is not a tombstone. A temporary closure produces an unreachable or changed result and the entry is flagged, not removed. Permanent closure needs the full failure sequence plus a human confirmation.
Can a business ask for a re-check?
Yes, through corrections, and there is no charge or queue-jumping involved because there is no paid queue to jump.
Does the method detect fraud?
No, and it is not designed to. It establishes that something exists and is reachable. Anyone using this register as a fraud screen is using it for something it cannot do.
Why not just show a live status indicator?
Because it would be a lie. We check on a cadence, not continuously. A live indicator would imply real-time knowledge we do not have, which is why the register publishes dates instead of a status light.
What happens if you get a closure wrong?
The entry is reinstated, the error is logged in public at corrections, and the sequence that produced it is reviewed. Reinstatement is free and does not require the operator to prove anything beyond being there.
Method version 1. Every entry records the method version used to produce its date. See the changelog for the history.