Two blocks, deliberately separated
The split exists so that a reader can tell at a glance which facts were allowed to influence a verdict and which are context.A. Security and risk
Independent, source-cited. This block — and only this block — feeds the trust rating.B. Business and company
Descriptive context. Not a rating input. May be vendor-claimed or enrichment-sourced.The separation is not cosmetic. A vendor can correct their headcount or their pricing page on their own profile; nothing they write can reach the block that produces a score. See Independence.
Provenance on every field
Each published field carries a tag and a source link:
A field with no provenance and no verified date does not publish. That is enforced at publish time, not left to convention — which is what makes the ratings defensible and the freshness guarantee auditable.
Comparing two vendors side by side
Built. A profile answers is this vendor safe to adopt?; a shortlist usually needs which of these two? — so any two vendors in the same category can be read side by side at/compare/{a}-vs-{b}, with the Security & Risk block laid out field by field and a source and verified date on both sides.
Three deliberate constraints:
- Same-category pairs only, and only where both profiles clear a completeness bar. Comparing an LLM provider against a developer tool answers nothing, and a half-empty comparison is worse than none — so the full cross-product is not generated.
- A field only one side publishes still shows, with the other marked not assessed. Absent means nobody checked, which is a different answer from a value, and dropping the row would hide the difference that matters.
- The pair slug is sorted, so one pair never becomes two URLs, and a vendor compared against itself is a 404.
noindex below it rather than spending crawl budget on a thin page.
Freshness is a product surface
Built. The rules and the automation both exist now. Every published field carries a
last_verified_at date that only advances on re-confirmation; a per-vendor source registry records what backs each field; a scheduled worker re-crawls sources whose cadence says they are due; posture differences become typed, judged change events; and the change log, the change feeds and the staleness flags are all public. Watchlists and change alerts ride on these same events, and are built too — only material changes alert, with no way to opt into noise.What may advance a date
Built.last_verified_at is only worth reading if it cannot move for the wrong reason — if a date could advance because a crawler ran rather than because the fact was re-confirmed, it degrades into the date we last ran a crawler. So a re-read resolves each field into one of three outcomes, and only one of them advances anything:
Two rules follow from this, and both are enforced rather than intended:
- Confirmation is per field, never per page. A re-read of a trust centre backing six fields confirms only the fields it could actually locate there — not all six because the fetch succeeded.
- Silence is not confirmation. A field the re-read never mentioned is treated as unconfirmed, so it ages honestly rather than riding along on its neighbours.
The source registry
Built. Rather than re-reading the free-text citation on each field, ATX keeps a per-vendor registry of the sources themselves — trust centres, model cards, certification registries, privacy policies, status pages, incident feeds — with fetch metadata and health on each. It was backfilled from the citations already on every published field, so it started with real coverage rather than empty. A source that fails repeatedly is flagged as dead rather than quietly skipped, because a vendor removing their trust centre is a posture change in disguise, and exactly the sort of thing a reviewer needs told. Source types are assigned by a URL heuristic that is labelled as one: an unrecognised URL is classified as other rather than given a confident wrong guess. Due diligence has a shelf life. A profile describing last quarter’s posture is not merely less useful than a current one — for this job it is worthless, and a reviewer who trusts it is worse off than one who knew they had nothing. So currency is treated as a feature with its own machinery:Continuous re-verification
Trust centres, model cards, certification registries, and incident feeds are re-crawled on a schedule, with the cadence tied to the vendor’s risk tier. A pass only touches sources that are actually due, so running it often stays cheap.
Dates that must be earned
A field’s
last_verified_at advances only when the fact is re-confirmed against its source. Nothing is refreshed by the passage of a crawl.Change detection
Posture is diffed over time. A new sub-processor, a dropped certification, a model swap, or a new incident becomes a typed change event on a public change log and a machine-readable feed.
Staleness surfaced everywhere
Profiles, Ask ATX answers, and exported reports all show per-field verified dates and flag anything past its re-verification window.
Change events, and which ones matter
Built. Diffing two values is the easy half. The hard half is deciding whether a difference is a posture change at all: a vendor rewording a paragraph of their DPA is not one; dropping SOC 2 is. Getting that judgement wrong is costly in both directions, so it is made explicitly rather than left to a diff:- Too noisy and watchlist alerts become worthless, members switch them off, and the feature is dead.
- Too quiet and the freshness guarantee is a lie.
The three-tier data model
Behind the profile sit three separate layers, because “a vendor” means something different at each:Ask ATX
How these fields are queried in plain language — and why every claim in an answer resolves back to one of them.