Your Discovery Example Is a Promise — We Replayed 1,602 of Ours to Check

A 402 response is not just a price. In the extensions.bazaar block it can also carry an input example and an output example — a sample request and a sample answer. Directory crawlers index them, and agents use them to decide whether an endpoint does what they need before they pay.

That makes an example a claim. If the sample answer disagrees with what the handler actually returns, the agent has three bad options: conclude the endpoint is broken, conclude the platform is lying, or spend money to find out. None of those are good, and all of them are avoidable if the example is true.

We replayed ours to see how many were.

Method

For every service with a published output example (1,602 of them — one endpoint's correct answer is an empty set and was excluded from this population), we took the published input, sent it to the handler that serves it over loopback, and compared the real response against the advertised example with a recursive key-subset check. Arrays are compared strictly; nested objects allow the response to carry extra keys but not to drop an advertised one.

Comparing once is not enough, because a large share of endpoints are supposed to vary: prices, block heights, AI text, random values. A disagreement there is not a defect. So every mismatch was replayed two more times with the same input. If the three real responses were byte-identical and still disagreed with the example, that is a stable difference — the kind a user would hit every single time.

Results

The 17 stable differences broke down cleanly:

• 9 time-derived. "Days since 2026-01-01" was 284 when the example was captured and 289 when it was replayed. "Days remaining" on a certificate only moves one way. These examples are snapshots and will drift every day.
• 7 upstream data that changes daily or hourly. FX rates, funding-rate windows, news feeds, prediction-market volumes, a live bounty list.
• 1 real defect. An endpoint that returns DNS record sets was advertising one ordering of the A records and, half the time, serving the other.

The defect: the DNS resolver round-robins

Ask a resolver the same question twice and you get the same set of records in a different order. That is normal DNS behaviour. It becomes a bug the moment a handler passes the array through unchanged while the 402 advertises a fixed ordering: an agent that calls twice and diffs the answers sees a change that never happened, and an agent that pattern-matches against the example is told its correct answer is wrong.

The fix is small — sort at the boundary, one shared helper, no field added:

const { sortDns } = require('../lib/dnssort');
// ...
result[tt] = sortDns(records.map(format));

Same record set, one deterministic answer. We verified it by calling the same endpoint four times and comparing response bytes: identical.

The more interesting mistake was ours

That was not the first pass. An earlier sweep had already found the ordering problem in 18 other handlers and fixed them. This one was missed — and the reason is worth writing down, because it is a mistake that looks like success.

The fix population had been drawn from that day's mismatch report: whichever endpoints happened to disagree with their example were inspected, and the ones with the same signature were fixed. But the ordering cycles. On the day of the sweep, the resolver happened to return the A records in the same order the example advertised. So the endpoint did not appear in the mismatch report, was not in the fix population, and kept the defect — while every guard printed clean.

A defect population drawn from the sample that happened to fail is not the population. The population is every object that can have the defect.

The correct population is source-derived: every deployed handler that requires DNS and calls .resolve*() or .reverse(). That is 21 files here, not 18, and it is derived mechanically instead of from a bucket of symptoms. The same pass also caught a handler that joined TXT records before anyone looked at their order.

We now run that census daily against the deployed bytes. It enforces three things: every DNS-serving handler must sort, self-sort, or reduce the array to a scalar; a handler not on the table is a failure; and a table row with no matching handler is also a failure, because a policy row that nothing enforces is worse than no row at all.

What this does and does not fix

The 17 stable differences were not all bugs, and we did not "fix" them by deleting the examples. Volatile endpoints still advertise a snapshot — that is the honest thing to publish, and the directory expects a sample. What changed is that we now know exactly which examples are snapshots and which are claims, and a replayed sample that contradicts its handler is a red light rather than a shrug.

The one real defect is fixed. The population it hid in is now enumerated from source and checked every day.

All numbers in this post are from a single replay run on 2026-10-17 against the deployed handler bytes; the method and per-endpoint buckets are in the repository's artifacts directory.