Support Availability
Nobody sets out to publish a stale directory.
They are all accurate on the day they are made. Understanding exactly how they rot is what a Support Availability record is designed around, because the rot is structural rather than careless.
The four mechanics
One. Compilation is a project and maintenance is a job. A directory gets funded, staffed and celebrated as a launch. Maintenance has no launch date, no ribbon and usually no budget line. The people who built it move on to the next funded project and the file sits there, still correct, quietly ageing.
Two. Nothing tells the directory when something changes. An organization that stops a programme notifies its clients and its funder. It does not notify the eleven directories that list it, because it does not know which eleven those are. The information exists and simply never travels.
Three. Directories copy each other. A new list is often seeded from existing lists, which means an error made once propagates outward and gains credibility with every copy. By the fourth copy the original source is unrecoverable and the entry looks corroborated precisely because several places agree, when in fact there was only ever one source.
Four. There is no way to tell a fresh entry from an ancient one. Both are just a line with a phone number. The reader is given no signal, so they extend the same trust to a row confirmed last week and a row nobody has looked at since 2019.
What a Support Availability record does differently
Each of those has a specific structural answer, and none of them is trying harder.
- Against decay: a claim expires. Ninety days without reconfirmation and open becomes worth calling to check.
- Against silence: a standing route for anybody who just called somewhere to tell us what they heard, because they are the freshest source that exists.
- Against copying: a source on every row, and a preference for the organization's own words over any aggregator's summary of them.
- Against uniform trust: the date is shown to the reader, not stored privately. The family can see how much to rely on it.
The one that matters most
Showing the date. Everything else is process, and process is invisible. Putting the confirmation date in front of the family transfers a judgement they are entitled to make back to them, and it makes our own decay visible rather than hidden. A site that shows you when it last checked is making a much smaller claim than one that does not, and a much more useful one.
The cost of doing it this way
This site covers less ground than a scraped directory and always will. Verification is slow, decay is constant, and the honest consequence is an uneven map with thin places we name.
We think that trade is correct for this particular subject. A family looking for help with an ageing parent is not short of listings. They are short of listings that are true. A smaller set they can rely on beats a larger set they have to test one call at a time, because the testing is done in the currency they have least of.
What this is not
It is not a criticism of the organizations listed anywhere, including in stale directories. They are running food programmes on thin budgets. Keeping third-party listings current is nobody's job and should not have to be. The failure is in how the information is published, not in the people doing the work.
Related: how a row gets verified and what each availability label means.