JSON unknown-field tolerance configuration for rolling deployments

Goal: define a consistent policy for handling unknown JSON fields across services during rolling upgrades so that producers can emit new fields before consumers are updated without causing deserialization failures.

Constraints: major libraries diverge in default behavior — Jackson fails on unknown properties unless configured, Go’s encoding/json and Python’s json module ignore them, and Newtonsoft.Json ignores by default but can be set to error. No cross‑language standard exists for annotating field optionality, and security‑sensitive contexts may require strict parsing, which conflicts with migration flexibility.

• What configuration pattern can enforce ignore‑unknown‑fields globally while still surfacing breaking changes such as field renames or type shifts?
• How can a team verify that each language runtime respects the policy in a canary deployment?
• Is there a recommended way to annotate optional fields in JSON payloads to aid compatibility across services?