The claim
Methodology
We record what a named URL said on a named date, and we keep the copy. We show you the text, the date and the source. We do not verify that a vendor's statement is true. We verify that they made it, and we tell you when it changes.
That is the whole of what we promise, and it is deliberately narrow. It describes something you can check against our behavior rather than something you have to take on trust.
What we do not do
We do not judge whether a vendor is telling the truth
If a vendor states that they do not train on your data, we record that they state it. Whether it is accurate is a question for your own review, and we would be guessing.
We do not explain why something changed
We can see that a page changed and when. We cannot see the reason, and writing a plausible one would be the single easiest way for invented material to re-enter the record.
We do not see anything unpublished
Private notices, contract amendments and conversations are outside what we can read. We publish the list of pages we watch for every vendor so you can see the boundary.
Invariants
Seven rules the system holds to
These are enforced by the database and by automated checks that run on every change, rather than by anyone remembering to follow them. Each one exists because of a specific way the previous system went wrong.
| # | The rule | What it prevents |
|---|---|---|
| I1 | A claim cannot be stored without a source URL, a fetch timestamp, a snapshot hash and a verbatim quote. All four are required by the database itself. | Unsourced claims. The previous system checked for sources when publishing, which meant unsourced material could still be created and sit in the database waiting to escape. |
| I2 | Pages are assembled from stored claims. No page contains prose written by a model. | A document where a few invented sentences travel alongside sound ones and are published as a single unit. |
| I3 | A source URL must be on a domain we neither own nor publish to. | Citing ourselves. In the old system, generated lists created the catalog entries they then cited as corroboration. |
| I4 | An interpretation references exactly one observation, and is displayed beside it, labeled as an inference. | Our reading of a document being mistaken for the document. You can always see what we actually read. |
| I5 | Absence is stored as a value with a date, never as a blank field or a default. | Guessing. A field that has to hold something will be filled with something, and the old schema asserted compliance on thousands of rows because a checkbox could not be left empty. |
| I6 | A vendor produces no claims until a person has confirmed which pages we watch for it. | Recording pages that belong to someone else, or to a product the vendor no longer sells. |
| I7 | When a page we watch stops resolving, its claims are marked stale rather than left standing. | A record that looks current because nothing has updated it, when in fact we stopped being able to read the source months ago. |
What we have got wrong
We publish this because you should not have to take our accuracy on faith, and because a record of mistakes and what was done about them tells you more than a page that claims there have been none.
2026-08
Our previous product generated directory content with a language model. Fifty evaluation guides carried statistics attributed to reports that do not exist, along with invented practitioner quotes. Compliance certifications were asserted on thousands of vendors with no source of any kind, and ranked lists cited catalog entries that the lists themselves had created.
What changed: The generative content system and everything it produced were deleted — about 108,000 lines. The product no longer writes about vendors. It records what vendors publish, and the rules above make an unsourced claim impossible to store rather than merely difficult to publish.
2026-08-31
The first run of our vendor scan reported seventeen companies as publishing nothing, including several that unquestionably publish privacy policies. Some had refused our scanner, one had a network fault, and three were reachable pages our own code failed to read correctly.
What changed: Those four situations are now recorded separately, and only one of them is a statement about the vendor. A page we could not read is never reported as a page the vendor did not publish.
2026-08-31
Our daily database backup had been reporting success every morning while copying two tables out of seventy. It was configured with a list of table names, two of which did not exist, and it treated the resulting errors as warnings.
What changed: The backup now discovers the tables itself and fails loudly if any table cannot be exported or the total is implausibly small.
Every change to a published finding
When a clause on a vendor page changes — because we corrected it, because a re-reading of the vendor's document produced something different, or because we withdrew it — the before, the after and the reason are recorded here. This is written automatically, so it also catches changes nobody chose to make.
Nothing has changed yet. Every clause currently published is the first version of itself, and this list will fill as findings are corrected or re-surveyed. An empty log here means no finding has moved, not that none is being watched.
The watched-surface policy
For each vendor we watch a named set of public pages: sub-processor lists, data processing addenda, privacy and retention terms, trust and security pages, model and system cards, changelogs and pricing. Legal and policy pages are read weekly. Changelogs and model pages are read daily. The list for any vendor is published on that vendor's record and is never placed behind a sign-up or a payment.
Our scanner identifies itself as XitherBot and honors robots.txt. Some vendors configure their sites to refuse automated readers. When that happens we record that we were refused, and we do not disguise our scanner as a browser to get around it.
Where a vendor publishes nothing on a subject, that is recorded as a finding with the date we looked and the number of pages we searched. It is not left blank, because “they do not say” is often the most useful thing we can tell you.
Where our money comes from
What a vendor can and cannot buy
A vendor we watch can claim its record with an email at its own domain and take a copy of what we have compiled about its own supply chain — the changes, the quotes, the sources and dates — to save its legal and customer teams from assembling it by hand. The copy is free. What they do with it is theirs; it carries no Xither mark and is not our statement.
No vendor can buy a change to what we publish. Not an edit, not a softening, not a validation, not a removal. Correcting a genuine error is free and always will be — charging for that would put a price on our own mistakes and reward us for making them.
Three things make that checkable rather than merely promised. Every finding is produced mechanically — a page is read, hashed, quoted with its URL and date — with no editorial step where a preference could enter. Every quote can be verified against the vendor's own live page in one click, by you. And every change to a published finding is recorded in the change log with its reason, so a softening would be visible whether or not you knew who had paid us.
We do not name which vendors have taken a copy, because a company's dealings with us are not ours to publish. We do report how many, so you can judge the scale of the relationship rather than take our word for its irrelevance. Today: 0 of the vendors we watch hold a copy of the record about their own supply chain.
Standing offer
Right of reply
If you are a vendor and something in your record is wrong, tell us and we will correct it. Point us at the page that says otherwise and we will record that instead, with its date. If our scanner is being refused by your site, allowlist XitherBot and your record becomes maintainable again. Corrections are shown on the record along with the correction date, because a record that quietly changes is not a record.