Sato Hub

Transparency

What changed in the Sato Hub catalog this month?

Over the last 6 months Sato Hub added 257 listings and retired 1, recorded 0 verification changes, applied 0 corrections from 0 verified claims, and decided 3 submissions, as of 2026-09-14.

Derived when this page was rendered, from the catalog's own write pipelines. Last built 2026-09-14.

The last 6 months

One row per calendar month, newest first. A quiet month is shown as zeroes rather than dropped.

MonthAddedRetiredStatusVerif.ClaimsCorrectionsStagedAppliedPendingSubs listedheldrejectedFlagscleared
2026-09110100073115921010—
2026-08200000110238300019—
2026-072411400062934821200072—
2026-06300000761747000012—
2026-050000000000000—
2026-040000000000000—

113 dead-project flags stood open when this page was built.

What we got wrong

Derived, not written. A retraction is a listing we retired within 30 days of listing it — a project that should not have passed review. A downgrade is an earned verification status taken back. Both are folds over the same event log, so they appear here whether or not anyone would have chosen to mention them.

Retractions

Verification downgrades

No earned verification status was taken back in this window.

Where each number comes from

Listings added
resource_events rows with kind=listing carrying the title the add-path writes, counted by the month they occurred.
Listings retired
resource_events rows with kind=status whose new value is Deprecated — the lever that hides a listing site-wide. The listing stays in the record; it stops being presented.
Status changes
every resource_events row with kind=status, retirements included. A status change is an edit to what we say a project is doing.
Verification changes
every resource_events row with kind=verification, in both directions. Downgrades are listed separately below.
Claims verified
listing_claims rows at status=verified, by the month control of the listing's own domain was proven by DNS TXT or a well-known file. A claim grants no trust — it unlocks descriptive corrections and nothing else.
Corrections applied
listing_edits rows at status=applied — a field a verified claimant corrected that passed the allowlist and the schema on the way back in.
Enrichment proposals staged
enrichment_proposals rows created that month. The bot proposes; it never writes live data.
…applied
of those rows, the ones now at status=applied — the high-confidence structural tier, put through the same validation as a human edit.
…still pending
of those rows, the ones still at status=pending — commercial and low-confidence fields waiting on a human. A backlog is published, not hidden.
Submissions listed
submissions whose triage decision was list, counted in the month the decision was recorded.
…held
triage decision hold — something we could not check, not something we judged.
…rejected or duplicate
triage decisions reject and duplicate, counted together.
Dead-project flags raised
resource_flags rows first seen that month: an unreachable site, no repository or account activity in 90 days, or a reader's report. A flag is a queue entry for review, never an automatic retirement.
…cleared
not published. The weekly sweep DELETES a flag row when the condition clears, so a cleared flag leaves no record to count. Unknown, never zero.

What this report leaves out

Figures about who reads or queries Sato Hub. This page counts what we did to the catalog, not who looked at it, and that boundary is enforced by a test rather than by intention. The rest of the record is public anyway: the changelog lists the individual events these counts are folded from, and the exports carry the catalog itself.

Questions

What does the Sato Hub transparency report count?
Editorial operations on the catalog: listings added, listings retired to Deprecated, status changes, verification changes, corrections applied from domain-verified claims, enrichment proposals staged against proposals applied and still pending, submissions decided list, hold or reject, and dead-project flags raised. Every figure is derived at page-render time from the tables the write pipelines fill; none of it is typed.
Does this report include Sato Hub's traffic or usage figures?
No, and it never will. This page is about the catalog's record-keeping, not its audience. Figures about who reads or queries Sato Hub stay on an internal gated dashboard and are not published here or anywhere else public.
How does Sato Hub publish its own mistakes?
Two ways, both derived rather than written. A retraction is a listing retired within 30 days of being listed — a project we published that should not have passed review. A downgrade is an earned verification status, Verified or Audited, taken back. Both are folds over the same append-only event log, so they appear without anyone deciding to mention them.
Why is the number of cleared dead-project flags missing?
Because clearing a flag deletes its row. The weekly sweep removes a flag when the condition it recorded no longer holds, so nothing remains to count. Rather than publish a zero that would read as 'we cleared none', the figure is published as unknown.
Can I correct something this report is based on?
Yes. Every listing page carries a report form for a dead link, wrong facts, a retired project or a security concern, which raises a flag in the same review queue the weekly sweep fills. If you control a listing's domain you can prove it and correct the descriptive fields directly, and those corrections are counted here.

Cite this page

Sato Hub. "Sato Hub transparency report — what changed in the catalog." Sato Hub, updated 2026-09-14, accessed 2026-09-14. https://satohub.ai/transparency

Data last refreshed 2026-09-14; this page is rebuilt daily. Citations carry the date so a reader can tell which snapshot a claim came from. Catalog data is licensed CC-BY-4.0 and the machine-readable copy is linked in the page's Dataset metadata.

Related: House rules · Changelog · Sato Score · Free data exports