Building Agentic Commerce #3: Reading Trust Score v4.1
Trust Score v4.1: three weighted dimensions, an optional bonus and confidence caps. Read each response's engine; legacy v2 fallback remains possible.
Executive summary
Trust Score v4.1 combines three weighted dimensions with an optional external-assurance bonus and confidence-tier caps. Each response identifies the engine used; some responses fall back to legacy v2. A legacy v2 component breakdown does not explain an overall score produced by v4.1.
Published
2026-04-06
Updated: 2026-09-13
6 min read
Author
Trusteed
Published by Trusteed
Written and maintained by the team that builds Trusteed. Technical claims in these articles are backed by the surfaces linked from each piece and by the signed capability registry at /.well-known/trusteed-capabilities.json, which is the arbiter when an article and a status surface disagree.
About TrusteedCategory
Developer Guides
Trust Score v4.1 combines three weighted dimensions with an optional external-assurance bonus and confidence-tier caps. Each response identifies the engine used; some responses fall back to legacy v2. A legacy v2 component breakdown does not explain an overall score produced by v4.1.
Issuing a receipt does not mean a payment was settled. At the 2026-09-13 review, the public merchant registry reported beta_closed, no production merchants and accepts_real_payments=false. Check /.well-known/merchant-index.json for current availability; demonstrations and checkout previews are not evidence of real purchases.
Read the engine before the number
Read engines.overall and engines.breakdown before interpreting a score. overall uses 0–1; trust_score_v41 uses 0–100 when available. With engines.mixed=true, the breakdown does not explain overall. insufficient_data is missing usable evidence, not a measured zero; the public route can return a degraded v2 fallback.
An agent that consumes Trusteed scores can use them as one input to a decision. Other agents may use reviews, visual information or other sources. A score does not authorize a purchase, replace consent or guarantee fulfillment.
How v4.1 is calculated
- 1merchantReliabilityBase: operational evidence about the merchant.
- 2agenticReadiness: readiness to serve agents.
- 3agenticEvidence: evidence from agent-led operations.
- 4External Assurance: optional bonus up to 10 points, subject to evidence gates. It is not a fourth weighted dimension.
Weights depend on confidence and are renormalized across applicable dimensions. The external-assurance bonus is applied after the base score, before the tier cap. For the published base model, caps are 65 for cold_start, 85 for human_established, 92 for agent_verified_thin and 100 for agent_verified. Read the live methodology for criteria and any enabled extensions; a tier name is not an identity-verification certificate.
Missing evidence and fallback
Read verified, measured, proxy, self_declared, not_applicable and synthetic_blocked as distinct evidence qualities. Missing data must not be presented as a measured zero. If the v4.1 overlay is disabled, fails or produces no value, the public route can serve legacy v2. A degraded v2 result is not comparable to v4.1 as if both had the same evidence requirements.
Read and verify the API response
GET https://api.trusteed.xyz/api/v1/stores/{slug}/trust-score returns the public score. Resolve the merchant and its data source from /.well-known/merchant-index.json; do not assume the same path on another host reads the same database. Verify the response signature using the issuer’s trusted JWKS. A valid signature authenticates the response, not the quality of all source data.
Observed on 2026-09-13 for demo-store, a sandbox store; this is a dated example, not its current score: ```json { "overall": 0.447, "trust_score_v41": 44.7, "confidence_level": "cold_start", "engines": { "overall": "v4.1", "breakdown": "v2", "mixed": true } } ```
Search ranking and checkout policies
Search eligibility, result ranking and checkout enforcement are separate decisions. Consult the contract of the specific endpoint and merchant configuration. A public score can come from a different engine than a stored value used by search. Labels such as VERIFIED are score bands, not proof of identity or permission to skip confirmation.
Merchant and agent trust are different subjects
Merchant Trust Score describes the merchant. Buyer-agent and seller-agent trust concern other actors and their own controls. Do not reuse a merchant score as the agent’s authorization or copy thresholds between these policies.
Legacy v2: the component breakdown
The legacy v2 model is a weighted sum on a 0–1 scale, scheduled every 6 hours. Its components may still appear beside a v4.1 overall when engines.mixed=true. Only use this breakdown to explain a number when engines.overall identifies v2. The methodology endpoint lists the weights and labels this scope legacy_v2.
- 1Catalog signals: how complete, how fresh, how accurate on price and availability the merchant's data is.
- 2Operational signals: what the merchant's published policies cover, and how its checkouts, fulfillments and disputes have actually gone.
- 3Post-sale and consistency signals, added in v2 on top of the original eight.
- 4This post names the groups, not the fields. GET /api/v1/trust/methodology returns each component with its weight and labels this scope legacy_v2 — that list is the one that cannot be stale, and a copy in a blog post is the one that goes stale first.
Implementation checklist
- 1Read the merchant’s host, engines, scales, confidence and timestamp together.
- 2When the response is mixed, do not reconstruct the v4.1 overall from v2 components.
- 3Treat missing evidence and v2 fallback explicitly in your decision policy.
- 4Consult merchant rules and authorization separately from the score.
- 5Check real payment availability before treating a preview or demo as a purchase.
Frequently asked questions
How is the current Trust Score calculated?
Trust Score v4.1 combines three weighted dimensions with an optional external-assurance bonus and confidence-tier caps. Each response identifies the engine used; some responses fall back to legacy v2. A legacy v2 component breakdown does not explain an overall score produced by v4.1.
Why does the API show both 0–1 and 0–100?
Read engines.overall and engines.breakdown before interpreting a score. overall uses 0–1; trust_score_v41 uses 0–100 when available. With engines.mixed=true, the breakdown does not explain overall. insufficient_data is missing usable evidence, not a measured zero; the public route can return a degraded v2 fallback.
How often is it recalculated?
The legacy v2 job is scheduled every 6 hours. The public v4.1 overlay can run on request. Read engine and timestamp together, especially for mixed responses.
Does a high score authorize payment?
No. Authorization, merchant rules and payment availability are separate checks. A score is not a guarantee of settlement or fulfillment.
Sources and references
- Trust Score methodology
Trusteed
- Trust Score guide
Trusteed
- Public merchant registry
Trusteed
Related articles
Developer Guides
Building Agentic Commerce #1: Multi-Protocol Checkout with MCP + x402 + ACP in One Flow
One agent, three protocols, one checkout. Here's how MCP, x402 stablecoin payments, and ACP work together to let AI agents buy products, with code examples you can run today.
Developer Guides
Building Agentic Commerce #2: How AI Agents Discover Your Store Without an API Key
Before an agent can buy anything, it needs to find your store. Here's the 6-phase discovery chain that takes an AI agent from zero knowledge to checkout-ready in under 2 seconds, with no pre-configuration required.
Agentic Commerce
Agentic Commerce: The Practical Guide for E-commerce Teams
A business-first guide to understanding what changes in discovery, trust, checkout, and operations when AI agents start influencing purchases.