Checked On A Date, Not Checked Forever

Every entry here carries a date. The date is the most honest thing on the page and also the most easily misread, because a date invites a reader to make one of two assumptions and both of them are wrong.

For the broader context behind this business guide, read How We Verify A Physical Business Without Publishing Anyone's Home Address.

The first wrong assumption is that a recent date means the information is currently true. The second is that an older date means the business has probably gone. Neither follows. What a date actually gives you is an age, and an age has to be interpreted against how fast the particular thing decays.

That is what this is about: what decays quickly about a physical business, what decays slowly, and what an old date should and should not make you think.

What this is, and who it is for

For a reader working out how much weight to put on a check date before acting on it, and for anyone building against the register who needs to decide when a record has stopped being useful.

It is specific to physical businesses. The general argument for dating everything is at why we date everything, and the check procedure itself is at the check procedure.

Why decay rate differs by entry type

A single freshness rule applied to everything would be wrong in both directions at once: too aggressive for entries that barely change and far too relaxed for entries that change weekly.

Consider the difference in what has to happen for a record to go wrong.

For a software product with no physical presence, most of the record stays true until the business does something deliberate. The description holds. The way you buy holds. The thing does not have hours, and it does not have a door that could be locked. A record can sit unchanged for a long time and remain accurate the whole time.

For a shop, a studio or a workshop, the record can go wrong without anybody deciding anything. Hours shift for a holiday. Stock turns over. A lease ends. A season starts. Nothing was announced because nothing felt like news.

So we apply different re-check cadences by entry type, with physical businesses checked more often than online-only ones. That is stated on our method and in the field dictionary at the agent contract.

What ages fastest about a physical business

Roughly in order, fastest first. This ordering comes from reasoning about how each attribute changes, not from measurement — we have no decay statistics of our own, and we are not going to borrow somebody else's and present it as ours.

1. Hours. The fastest-moving attribute by a distance. They move for holidays, for seasons, for staffing, for weather, for a delivery day, for a funeral. Many changes are never written down anywhere. Hours are the single most likely detail on a physical entry to be wrong at any given moment, which is why the is-it-open problem exists as a separate piece.

2. Stock, range and what is actually available. What a place sells this month is not necessarily what it sold last month. Suppliers change, lines are dropped, a maker moves on to different work. This is one reason our descriptions stay at the level of what a business does rather than listing what it carries.

3. Contact routes. A number is retired, a message channel is abandoned, an ordering route moves. Usually announced somewhere, often not somewhere a stranger would find.

4. Location and how you attend. Slower, but consequential when it moves. A move between premises, a shift from a shop to appointment-only, a market pitch changing days. When this changes, the record does not merely become imprecise. It sends somebody to the wrong place.

5. Existence. The slowest and the most serious. Most businesses that exist today will exist next month. When this one goes wrong, everything else on the record goes with it.

The useful consequence of that ordering is that an old date does not degrade a record evenly. A six-month-old check has probably gone wrong about hours and has probably not gone wrong about existence. Read the age against the field you actually care about.

What ages slowly

Some things on an entry barely decay at all, and it is worth knowing which, because they are the parts an old record still supports.

• What the business fundamentally is. A bindery is still a bindery. Trades change slowly.
• Who owns it, in the sense we record. Independence is a structural fact that changes rarely, and when it does it is usually visible.
• The name. Rebrands happen, but they are events, not drift.
• What we said about it, in our own words. Written to be durable rather than current, which is why our descriptions avoid anything that would date them.
• The record of the check itself. The date, the reviewer, the method version and the entry bar version do not decay at all. They describe a moment, and the moment stays true forever.

That last one is why an old entry is still worth something. It is a dated, attributed observation that a business existed. That claim never expires. It just stops being about now.

The thresholds we apply, and where they came from

Here we have to be straightforward about something.

The specific threshold values are not finalised, and we are not going to publish numbers we have not settled.

What is settled is the structure. The threshold differs by entry type. Physical businesses have a shorter one than online-only businesses, for the reasons above. Past the threshold an entry is flagged in place rather than hidden. The current values live in the field dictionary that ships with the exports and are documented at the agent contract, which is the single place they are stated so they cannot drift between pages.

Where they will come from, when they are set, is our own re-check log: how often we find that something material has changed between one check and the next, by entry type. That requires a register with enough history in it to produce a real answer, and it does not have one yet.

A plausible-sounding number without a dated measurement would be exactly the failure this site exists to avoid. This article therefore makes no threshold claim. Any implementation that sets one must record the evidence and later changes in the method changelog, including what each change invalidated.

What we show when a physical entry goes stale

Flagged, in place, still visible.

Hiding a stale entry would be a silent claim. A reader who cannot find something has no way to tell whether it was removed because it closed, removed because we stopped maintaining it, or never existed. A flagged entry answers all of that: it says here is a record, here is when it was last checked, here is why we are telling you the check is old.

So a stale physical entry keeps its description, keeps its date, and gains a visible indication that the date is past the threshold for its type. It is excluded from the discovery rotation, because pushing an unreliable record at somebody who did not ask for it is different from letting somebody find it deliberately. It stays in the register and it stays in the export.

What we do not do is quietly refresh the date. A date on this site corresponds to a row in the check log. It cannot be typed in, carried over, or advanced by a deployment, and if the log has no matching row the build fails rather than publishing the entry.

What you should do with a stale shop entry

Read the age against the thing you need.

• If you need to know whether it exists: an old date is weak evidence but not nothing. Existence decays slowly.
• If you need to know the hours: treat them as unverified regardless of the age, and treat an old date as no information at all.
• If you are going to travel: ring first. This applies to fresh entries too. A recent check is not a live status, and no check on this site ever will be.
• If it looks wrong: tell us at corrections. A report from someone who was actually there is worth more than a desk check and it starts a re-check.
• If you are the operator: corrections again. There is no charge and no queue to jump, because there is no paid queue.

How this appears in the machine-readable export

For anyone consuming the register programmatically, the relevant points are these, and the authoritative version is the agent contract rather than this page.

• Every record carries last_checked and check_method_version, so a consumer can compute an age and interpret it against the method that produced it.
• Every dated field traces to a row in the check log. A value that cannot be traced does not export at all.
• Unknown values are null. They are never inferred, defaulted or filled with something plausible.
• Records past the staleness threshold remain in the export, flagged rather than dropped. Disappearance would be indistinguishable from deletion.
• Nothing in the export is a real-time signal, and no field indicates current status. A consumer that treats last_checked as an open-now proxy is using the data for something it structurally cannot do.
• Caching more often than we check yields no new information. The cadence, and the current thresholds, are in the field dictionary.

The broader physical-business material is collected at real places, checked.

In Plain English

A date on an entry is an age, not a status, and different parts of a record age at different speeds.

• Fastest to slowest: hours, then stock, then contact routes, then location, then existence itself.
• So read the age against the thing you care about. A six-month-old check tells you little about hours and quite a lot about whether the business exists.
• What barely ages: what the business is, who owns it, its name, and the record of the check itself.
• Physical entries are re-checked more often than online-only ones. The exact staleness values are not finalised, and we are not publishing numbers we have not settled.
• Stale entries are flagged and kept, never hidden. Hiding one would be a silent claim.
• Dates cannot be refreshed by hand or by a build. Each one traces to a check-log row or the build fails.
• Before travelling, ring first, however fresh the date looks.

Browse the register → /register/