What do public ARD registries actually return?

Same queries, same day, every public registry that speaks the ARD spec's POST /search. Zero-dependency harness, one command, one JSON per edition. Published by Desvela, which competes in this table — its row is marked, and the method below is written to survive being read by a rival.

The table — 2 Sep 2026

Medians of 5 samples. Cold = fresh connection per request, what a one-off agent call pays. Warm = keep-alive. Both published: our first harness version measured only warm and reported 307 ms for an endpoint curl timed at 1.16 s. Neither number lies; publishing only one means picking the convenient one.

The metric that matters most: gibberish

The negative control. xkqjvwz mplfrbn tzghdkw means nothing in any language. An honest registry returns zero results. Two of the four return ten — one scoring them 51–56, the other 96–100.

The second is the worse failure, and it is worth being precise about why. A noise floor at 55 is at least distinguishable from a strong match; a noise floor at 100 means the top score is reachable by meaningless input, so no threshold anywhere on the scale separates signal from noise. A client that filters on score > 90 gets pure noise and no way to tell.

Disclosure on Neuronto: its crawler indexes this registry — it is currently the largest single source of traffic to our own /search — and it ranks our entries first for 5 of our 5 published queries. We are not independent observers of each other, and we are reporting a defect in a registry that sends us traffic. Both facts are here so you can weigh them.

What this benchmark does not measure

• Semantic ranking quality. It would require human relevance judgment — and that judgment would come from us, an interested party. Where the rival's semantic search is better than ours, and for some queries it is, this benchmark will not show it. Read their results yourself.
• Coverage. Comparing index sizes without probing for catch-all servers is the error that produces headline numbers. On 1 Sep 2026, our own crawler counted 745 "publishers" of /.well-known/ard.json in the Tranco top-100K — a path the spec had introduced six days earlier and that no third party served on that date. We sampled 12 live: none published anything, they were servers answering 200 to any URL.
  Updated 2 Sep 2026: real adoption has since begun — neuronto.com serves a genuine, canary-clean manifest. The 745 is a dated measurement, not a claim about today, and it stays because that is the whole point: a zero baseline can only be captured before adoption exists. Coverage claims need canary probing; the monthly census does that, this page does not.

Our own limits, declared

• 4/5, not 5/5. In the rival index our entries rank first for four of our five published queries. The fifth ranks lower because our catalog entry was deliberately written not to self-preference. The original publication bar said 5/5; it was rewritten, because honesty had made it impossible.
• The 8 duplicates are ours. We publish the same catalog on desvela.ai and desvela.dev, so the same entry reaches indexers twice — same url, different urn. Letting both through is the indexer's missing endpoint-dedupe, but the duplicate originates with us.
• Hugging Face Discover does not index us at all, and its latency does not improve with keep-alive — its cost is compute, not connection. Both facts are in the data; we do not know why it excludes us.

Reproduce it

git clone https://github.com/mrenzo20/ard-retrieval-benchmark
cd ard-retrieval-benchmark
node run.mjs      # Node ≥ 20, no dependencies, ~4 minutes

The query set, the registry roster with exclusions and reasons, and every edition's raw JSON live in the repo. If you re-run it and get different numbers, that is a finding — open an issue.