Federation, original measurement

Why every ARD registry gives you a different answer

31 August 2026 · 7 min read

We put the same 26 queries to every public ARD registry. The union of their indexes was 68% larger than the largest single one, and not one of them implemented federation: auto, the mode the specification makes the default. Asking for it returned byte-identical results to asking for nothing.

The test

Four public ARD registries existed when we measured: GitHub Agent Finder, WellKnown, Hugging Face Discover and Desvela. We asked each the same 26 probe queries spanning search, email, databases, images, payments, scraping and the rest, and counted the distinct resources each returned.

The union is 68% larger than the best single index. Every client that picks one registry is silently choosing to miss most of what exists.

The specification already solved this

Section 5.4 defines three federation modes, and auto is the default:

The Registry queries upstream registries automatically, merges their results with its own, and returns a unified response.

So we tested it, sending each registry the same query twice: once with federation: none and once with auto.

Every one returned identical results, and the only source value in any response was the registry's own domain. The default mode of the specification is, at time of writing, unimplemented across the entire ecosystem.

pip install ard-publish
python -m ard_publish check yourdomain.com

Why fuse on rank rather than score

Merging results from several registries is not concatenation, because their scores are not comparable. Measured across the same result sets:

One registry crams everything into the top ten points, another spreads across sixty. A score of 94 means something different in each, and merging on score would import whichever calibration was loudest.

Reciprocal rank fusion avoids this by using only the ordering each registry produced, the part each one is genuinely competent about, and discarding the numbers. A resource several registries rank highly rises; one that a single registry loves does not dominate.

A note on that 6.7

WellKnown holds the largest incumbent index and returns accurate top results, but the average gap between its best and worst result is under seven points. A client cannot tell a strong match from a weak one, which defeats the purpose of returning a score at all. Ranking is only useful when the gap is legible.

What we built

Neuronto implements federation: auto as specified: concurrent fan-out to every other public registry under a hard time budget, fused with reciprocal rank fusion, with the per-upstream outcome reported back so a caller can see which registries answered and which timed out.

{"results": [ ... ],
 "federation": {"mode": "auto", "registries": [
   {"name": "WellKnown", "ok": true,  "ms": 449, "results": 20},
   {"name": "Desvela",   "ok": true,  "ms": 143, "results": 7},
   {"name": "GitHub Agent Finder", "ok": false, "error": "budget exceeded"}
 ]}}

A slow peer costs the budget and nothing more. And because a federating registry serves other people's indexes, it is useful from the first day rather than after years of crawling, which is the argument for building one while the ecosystem is still small.

The full comparison, including conformance results, is on the registries page.

curl -s https://neuronto.com/search \
  -H 'content-type: application/json' \
  -d '{"query":{"text":"scrape a website"},"federation":"auto"}'

claude mcp add --transport http neuronto https://neuronto.com/mcp

Keep reading