Skip to content

a way to publish what a provider says without publishing it as a measurement - #2777

Merged
Flotapponnier merged 1 commit into
mainfrom
feat/provider-claims
Oct 2, 2026
Merged

Flotapponnier merged 1 commit into
mainfrom
feat/provider-claims

Conversation

@Flotapponnier

Copy link
Copy Markdown
Collaborator

Aurora asked us to cover swap insurance, confidentiality, and whether users are shielded from questionable liquidity. Real properties a reader would want, and this site has no instrument for any of them.

It also had no way to say so. The registry carries free-text fields with no source and no date, and a page that printed a vendor's claim unqualified would make us the thing we were built against — /about says it plainly: marketing pages quote "real-time" without a number; this page quotes the number.

The shape

claims?: {
  label: string;       // "Swap insurance"
  value: string;       // the provider's position, plain words
  source: string;      // https URL where we read it
  verifiedAt: string;  // YYYY-MM-DD a human last looked
}[]

Three fields a measurement does not need, all required.

Rendered in its own section, after the description and before the measured leaderboard, under a heading that names the speaker: "Stated by , not measured here". The note draws the line:

These are the provider's own statements about properties no benchmark on this site measures. We checked that each one appears at the source on the date given; we did not verify that it holds.

A claim never enters a benchmark, never ranks anything, never moves a leader.

Two guards

Staleness. A claim goes stale at six months and says so on the page rather than ageing quietly into something that reads current. Stale ones sort last, so the section opens on what we stand behind.

No superlatives. A superlative in a claim value fails the test. The measured columns are where a provider gets to be fastest; laundering a boast through a "claim" would be worse than not having the mechanism at all.

The registry test walks every entry, so a malformed claim fails the build instead of reaching a page unsourced.

Nothing is populated

Each claim needs a human to read the source and date it. Inventing them to demonstrate the feature would be the exact failure this is built to prevent.

Found while in there

Seven registry fields (features, pricing, longDescription, founded, docs, github, blog) carry a comment saying they are "surfaced on the product detail page when present". Not one is read by any code. Only description, url, twitter and parent are. The comment now says what is true, so the next person does not add an eighth expecting it to render.

tsc clean, 426 tests pass (12 new), pnpm validate passes, lint 0 errors.

…urement

Aurora asked us to cover swap insurance, confidentiality, and whether users
are shielded from questionable liquidity. Those are real properties a reader
would want, and this site has no instrument for any of them. It also has no
way to say so: the registry carries free-text fields with no source and no
date, and a page that printed a vendor's claim unqualified would make us the
thing we were built against. The /about page says it plainly, that marketing
pages quote "real-time" without a number and this one quotes the number.

So a claim carries three things a measurement does not need, all required:
where we read it, when a human last looked, and the provider's own words. The
product page renders them in their own section, after the description and
before the measured leaderboard, under a heading that names the speaker:
"Stated by <provider>, not measured here". The note under it draws the line
the section exists for, that we checked the statement appears at the source on
that date and did not verify that it holds.

A claim never enters a benchmark, never ranks anything, never moves a leader.

Two guards. A claim goes stale at six months and says so on the page rather
than ageing quietly into something that reads current, and stale ones sort
last so the section opens on what we stand behind. And a superlative in a
claim value fails the test: the measured columns are where a provider gets to
be fastest, and laundering a boast through a "claim" would be worse than not
having the mechanism.

The registry test walks every entry, so a malformed claim fails the build
instead of reaching a page unsourced.

Nothing is populated. Each claim needs a human to read the source and date it,
and inventing them to demonstrate the feature would be the exact failure this
is built to prevent.

Also corrected a false comment while in there: seven registry fields said they
were "surfaced on the product detail page when present" and not one of them is
read by any code. They are now marked as what they are.
@Flotapponnier
Flotapponnier merged commit 0cb4298 into main Oct 2, 2026
2 checks passed
@Flotapponnier
Flotapponnier deleted the feat/provider-claims branch November 3, 2026 11:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant