What are Sato Hub's trust rules?

Self-reported is not verified. Null is unknown. It is never zero. Unknown never becomes no. Never sum across venues, chains or stages. A death is a measurement. A disclosure describes. It never clears. A claim grants no trust. We never hold your keys, and we never hold your funds. No listing is presented as safe, audited, verified or profitable without evidence. Every verdict and every route is signed; verify it against our published key. We cannot quietly change what we published yesterday. Every number names its method, its source field and its date.

Does Sato Hub say whether a project is safe?

No. No listing, score, verdict or route on Sato Hub is presented as safe, audited, verified or profitable without evidence, and every published figure names what was read, the field it came from and the date it was written. Where evidence would be needed and does not exist, the field stays empty.

What does a null mean in Sato Hub's data?

Unknown, never zero. A reading we could not take says nothing about the thing we were reading, so it is published as null with the reason, never rounded down and never dropped into an average.

Does claiming a listing make it verified?

No. Proving control of a listing's domain lets the owner correct descriptive fields only — text, links, tags, chains. It cannot reach verification status, score, ranking, featuring or any market flag, and there is no public claimed badge, because a badge reads as endorsement.

House rules

How we handle evidence

Each rule links to a page where you can watch it kept.

Rules12

01
Self-reported is not verified.
A project saying a thing about itself is a claim, and we record it as a claim. A check we ran ourselves is evidence, and we record what was checked and when. The two never share a badge. Nothing in any self-serve path — a submission, a registration, a claimed listing — can mint a verified state.
Kept on: Sato Score methodology · Preflight rules · Agent Passport
02
Null is unknown. It is never zero.
A reading we could not take says nothing about the thing we were reading. An unmeasured number is published as null with the reason it is null, never rounded to zero and never dropped into an average. In every ranking, unknown sits below a good reading and above nothing — never below a bad one.
Kept on: Agent economy · How Sato Route chooses · One page per number
03
Unknown never becomes no.
Absence of a record is absence of a record. When we hold nothing, the answer is unknown — not a low-confidence guess, and not a quiet negative. This is the rule that costs us the most, because unknown is a worse-looking answer than a confident one.
Kept on: Preflight rules
04
Never sum across venues, chains or stages.
Every measured row carries the grain it was measured at. Adding rows across different venues, chains or funnel stages produces a number that means nothing and reads as if it means everything, so the storage grain is built to make that addition impossible rather than merely discouraged.
Kept on: Agent economy · One page per number
05
A death is a measurement.
When a project goes quiet or an endpoint stops answering, we record it and keep the record. Dropping dead things out of the dataset makes every survivor look healthier than it is. A retirement is an observation about silence, never a judgment about the people who built the thing.
Kept on: Reliability · Changelog
06
A disclosure describes. It never clears.
A skill disclosure lists what a skill does — hosts it contacts, credentials it asks for, shells it can reach. Listing those things is not approving them, and an empty disclosure is not a clean bill. Where a registry ran its own scan, that result is attributed to the registry, not adopted as ours.
Kept on: Skills
07
A claim grants no trust.
Proving control of a listing's domain lets the owner correct descriptive fields — text, links, tags, chains. It cannot touch verification status, score, ranking, featuring or any market flag, and there is no public claimed badge, because a badge reads as endorsement and a claim is not one. The editable set is an allowlist, checked twice and asserted by a test.
Kept on: Sato Score methodology
08
We never hold your keys, and we never hold your funds.
Sato Route hands back a transaction; you sign it. Fees are parameters inside the transaction you sign or an entry in a venue's own reward split, disclosed before signing, and an unsigned or failed transaction pays nothing. Nothing we run relays, forwards, nets or settles a payment.
Kept on: Sato Route · How Sato Route chooses
09
No listing is presented as safe, audited, verified or profitable without evidence.
The words we will not write are not a style preference; they are load-bearing. Every published verdict, score and route says what was read and when, and stops there. Where evidence would be needed and does not exist, the field stays empty rather than being filled with something that reads well.
Kept on: Sato Score methodology · Preflight rules · x402 verified
10
Every verdict and every route is signed; verify it against our published key.
A Preflight verdict and a Sato Route decision leave here with a detached Ed25519 signature over the exact bytes and the timestamp — in the Sato-Signature header, and again inside the JSON for clients that never see headers. Anyone holding a plan, a CI log or a receipt can check it against the key set at /.well-known/jwks.json and know that we said this, on this date, unaltered. Retired keys stay published for ninety days so old statements keep verifying. What a signature does not do is make the statement truer: a signed verdict is still a description of what was checked, a signed quote is still not a fill, and where no key is configured we publish no signature rather than a decorative one.
Kept on: Signing policy · Public keys · How Sato Route chooses · Security posture
11
We cannot quietly change what we published yesterday.
Every morning, every Sato Score we publish is committed to a single Merkle root over (listing, score, tier, date). The root is signed with the same key as our verdicts, published at /.well-known/sato-score-roots.json for ninety days, and — where an attestation key is configured — written to Ethereum Attestation Service on Base. Each verification record carries that listing's leaf, its proof, and a command that folds the proof against the published root rather than against anything this server says in the same breath. What this buys is narrow and it is deliberate: it proves what we published and when, not that a score is correct. An anchored wrong number is a wrong number with a receipt. The reason to build it anyway is that it constrains us and nobody else — every other page here asks you to believe our database, and this is the one that does not.
Kept on: Published roots · Sato Score methodology · Security posture
12
Every number names its method, its source field and its date.
A figure without a method is a rumour with a decimal point. Ours travel with the field they were read from and the moment they were written, so anyone can re-read them and disagree with us using our own data.
Kept on: One page per number · Preflight rules · Free data exports

The evidence words

Every claim on a listing carries one word saying how we know it, with the source and the date. Listed is not the same as checked: a self-reported row is the project’s own words, and it never gets a mark.

self-reported: The project says so — its README, docs, website or listing submission. We carry it as written and have not checked it ourselves. Most facts on most listings are this, and it is not a mark against them.
observed: We saw it ourselves on the date shown: a commit or release in the public feed, an endpoint that answered our probe, a registry read on-chain. One reading, dated — not a promise that it is still true.
reproduced: We re-ran the project's documented install and entry point in a fresh container and both completed. It shows the install path works as written on that date; it says nothing about what the software does once running.
reviewed: A person checked the claim against evidence. The only rows that carry this word are a Verified or Audited status, and they name the evidence where it is recorded.
computed: We derived it from the rows above by a published rule — the Sato Score is the one example. It is only as good as its inputs, and the rule is on /sato-score.

Custody rows use Sato Check’s own three classes, unchanged, so there is one vocabulary rather than two. They line up with the words above:

declared: Sato Check: the project's own setup says so — an env var it asks for, a tool it describes. Same footing as self-reported.
traced: Sato Check: our static read of the published package or repo found it in the code. We read it; we did not run it.
observed (custody): The same word as above: we ran the package in a sandbox with planted test keys and watched where they went. A “not observed” covers install and start-up under our test conditions, and says so.

What this costs

Keeping these rules means publishing worse-looking answers than we could. Unknown appears where a confident number would read better. Dead projects stay in the record where dropping them would lift every average. Most of the index sits at caution, because most projects have never been independently checked — including good ones. That is the honest shape of the data.

Whether we keep them is checkable. The transparency report counts what we did to the catalog each month — listings added and retired, corrections applied, submissions decided — and derives our own retractions and verification downgrades from the same event log, so they appear whether or not we would have chosen to mention them.

Reference

QuestionsWhat people ask about this pageShowHide