A trust score that says how much of itself was measured
Most reputation scores are a single number with no way to tell a confident one
from a guess. Four stars from six ratings and four stars from six thousand print
identically, and the reader supplies the confidence themselves, usually
generously. This post is about what happens when a protocol refuses to do that.
Here is the live trust response for Cresva's own storefront, captured 16
September 2026:
{ "score": 50, "unweighted_score": 62.5, "tier": "bronze", "trend": "stable", "components": { "data_accuracy": 50, "fulfillment_speed": null, "return_rate": null, "negotiation_fairness": 50, "response_reliability": 50, "dispute_record": null, "customer_satisfaction": 50 }, "measured_components": { "data_accuracy": true, "fulfillment_speed": false, "return_rate": false, "negotiation_fairness": true, "response_reliability": true, "dispute_record": false, "customer_satisfaction": true }, "measured_weight": 0.55, "provisional": true, "provisional_reason": "No completed transaction has been recorded for this brand, so nothing here rests on observed behaviour.", "verified_transactions": 0 }
Three of the seven are null, and that is the design
fulfillment_speed, return_rate and dispute_record come back null. Not
zero, not fifty, not a category average. Nothing has happened that would measure
them, so the response says nothing rather than something plausible.
A zero would have been the worst available answer. On a 0 to 100 scale a zero
reads as terrible, so a storefront with no dispute history would be reported as
having the worst possible dispute record. A middle value is only slightly better
and is worse in one respect: it is unfalsifiable. A reader cannot tell a
measured 50 from an assumed one, so every number in the response becomes
suspect at once.
measured_components exists so a consumer does not have to infer the
distinction from a null. It is the same information stated positively, because a
client that filters on components.fulfillment_speed > 60 and one that first
checks measured_components.fulfillment_speed behave very differently on the
same payload.
measured_weight is the field to read first
0.55 means components carrying 55 percent of the total weight have evidence
behind them. Below 0.5 no tier is published at all: tier comes back as
unrated, which is not a low tier but the absence of one.
This is the field that separates a score from a verdict. A 50 with
measured_weight: 1.0 is a storefront that has been observed and is average. A
50 with measured_weight: 0.55 is a storefront that has been half observed.
Those are different facts and a single number cannot hold both.
provisional says it in words
provisional: true with provisional_reason spelling out the cause:
`"No completed transaction has been recorded for this brand, so nothing here
rests on observed behaviour."` The same response carries
verified_transactions: 0, which is where that sentence comes from.
A field that explains itself in prose is unusual in an API and it is here for a
specific reader: the one who is about to put this number in front of a shopper.
A boolean can be ignored. A sentence that will be quoted is harder to ignore.
The ladder
| tier | score |
|---|---|
| Unrated | under 40 |
| Bronze | 40 to 59 |
| Silver | 60 to 74 |
| Gold | 75 to 89 |
| Platinum | 90 to 100 |
Unrated is on the ladder deliberately. A ladder that starts at Bronze is a
ladder every storefront appears to be on, and the most common real state, not
enough evidence yet, would have nowhere to sit.
What to do with it
GET /api/storefront/{brandId}/trust for the score.
GET /api/storefront/{brandId}/trust/signals for what went into it.
If you are building an agent, the useful rule is to branch on
provisional before you branch on score. A provisional score is not a bad
score. It is a statement that the question has not been answered yet, and
presenting it to a shopper as though it had is the failure this design exists
to make difficult.