MATCH · EXPLAIN · NEGOTIATE
Registry design: budget and freshness are separate gates
Inspect seven synthetic registry entries. Apply hard eligibility gates before ranking and proposing a compatible local contract.
Scroll the diagram left or right to inspect every label.
Candidate inspector
Your experiment
Raise the cost budget to admit another candidate, then advance metadata age. Explain the difference between an unaffordable candidate and an expired registry record.
Ranked eligible candidates
Proposed local contract
Explain the exact score
Latency term = 1 − fixture p95 / 500. Cost term = 1 − fictional cost / 10. Observed-success term = (successes + 1) / (observations + 2). Weighted score = sum(weight × term) / sum(weights). All fixture terms are in [0,1]. If all weights are zero, every score is zero; agent ID gives a deterministic tie-break.
None of these terms can override tenant scope, curator policy, required skill/format/delivery, metadata TTL, cost budget or minimum observations. Inspection playback only reveals the computation; it does not advance metadata age. Use the separate age control for that experiment.
Offline registry-selection policy with synthetic entries, latencies, observations and fictional cost units. This is not a production marketplace, ADK registry API, real Agent Card schema validator, signature verifier, authentication system or remote-agent invocation. Curator approval is a fixture flag, not cryptographic proof. A high historical success estimate does not establish trust, safety or future reliability; no statistical confidence claim is made. Metadata freshness is not a liveness check. A2A does not prescribe this ranking formula or a standard curated-registry API. The local proposed contract is descriptive JSON, not an A2A wire request. Agent discovery and curated registry concepts.
Filter eligibility before ranking
Seven fictional candidates have tenant, skill, format, streaming, metadata age, cost and observation fields. The registry applies tenant and optional curator approval, capability compatibility, freshness, budget and minimum evidence as hard filters. Only survivors receive a selection rank. A fast or cheap candidate cannot use its score to bypass a failed hard requirement. The resulting contract is a local proposed record, not a negotiated remote agreement or a proof of agent trustworthiness.
Specify the hard requirements
Tenant limits the candidate set. Required skill and output format must be advertised; application/xml is intentionally unsupported by every candidate. Require streaming excludes nonstreaming entries. Require curator-approved fixture excludes the unreviewed candidate when enabled. Maximum metadata age is an inclusive TTL bound; Advance metadata age adds elapsed seconds to every entry. Fictional cost-unit budget is a per-candidate maximum. Minimum fixture observations rejects candidates with too little evidence even when their observed success fraction is high.
Inspect the ranking terms
Latency weight uses one minus p95 divided by five hundred. Cost weight uses one minus cost divided by ten. Observed-success weight uses (successes plus one) divided by (trials plus two), a smoothed fixture ratio. The weighted average uses the sum of the three weights. All-zero weights yield score zero and alphabetical identifier order breaks ties. Inspect candidate, or click its table row, to read that candidate’s terms and rejection reasons. A high score on an ineligible row does not make it selectable.
Reproduce a budget and compatibility boundary
This page opens with budget one: ranger qualifies under ordinary requirements while scout costs three. Increase budget to five and compare eligible candidates and the selected score. Common baseline settings restores the shared baseline, which also uses budget five; it is not the page’s original budget-one opening. Select application/xml and verify that no candidate and no contract are returned. Restore JSON, select team-b and require summarization: the only team-b entry cannot supply that skill. Relaxing weights cannot fix either empty result.
View gates and avoid performance claims
Play reveals six gates across sixty inspection seconds; Pause holds progress, Next gate advances, Restart inspection rewinds, Speed changes pace and Inspection time scrubs. Requirement edits recompute and rewind. There is no distributed registry replication, heartbeat transport, live health probe or measured reputation service. Metadata age is a provided number, not an observed expiry timer. The synthetic p95 and cost figures only make ranking arithmetic inspectable. A real registry still needs authenticated ownership, schema/version rules and an explicit policy for stale or unavailable results.