Rolling back a service while its JSON Schema consumer still expects the removed field

Two supported components are involved: a producer service that serializes records as JSON, and a downstream consumer that validates payloads against a versioned JSON Schema (draft 2020-12, validated with a standard validator such as Ajv). A deployment adds a new required field to the schema, and the rollback plan must account for the consumer and producer temporarily running different schema versions.

The uncertainty is at the interoperability boundary: most JSON parsers ignore unknown fields, so the forward direction (old consumer, new producer) is usually tolerant. The reverse direction is less clear. If the producer rolls back first and stops emitting the field, a consumer still enforcing the newer schema sees a missing required property. If the consumer rolls back first, records persisted during the new-schema window may no longer match the old structure.

Assume JSON Schema draft 2020-12 semantics, where required is enforced strictly and unknown properties are allowed unless additionalProperties: false is set.

1. Should a new field be introduced as optional with a default, or as required, to keep both rollback directions safe?
2. When a required field disappears mid-rollout, is it better for the consumer to reject the payload, apply a default, or skip validation for that field?
3. Is a schema-version identifier in the payload itself a reliable way to coordinate the rollback order between the two components?